New Golang Packaging Guidelines: Feedback needed and appreciated
by Robert-André Mauchin
Hello Fedora people,
As you may or may not know, currently applied Golang packaging guidelines
have always been simply a « draft ». Part of the new Go SIG mission is to
update ours best practices and tooling. As such, Nicolas Mailhot designed a
new set of macros based on lua script to improve our current situation. As a
result, we needed to draft new guidelines to reflect the future implementation
of these macros.
I have written these new guidelines and I'd like to ask for your help in
order to review them: both from current Go SIG packagers point of view and
from novices in the matter, in order to make sure they are clear and
understandable enough for everyone.
I have uploaded a mirror of the Guidelines on my FedoraPeople space:
https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
Please, if you have 10 mn to spare, read them and send me feedback. If you
wish you can also directly send me a Merge Request on Pagure:
https://pagure.io/fork/eclipseo/packaging-committee/ (branch
implement_golang_guidelines).
Best regards,
Robert-André
5 years, 1 month
New time slot for the Go SIG meeting
by Jakub Cajka
Hello,
we agreed to find better time slot for our meeting on our last meeting as is seems that the current slot is no good anymore. I have created new poll to find better one. https://framadate.org/QX6R7hxJ2mM6HO8m Time is in the UTC and don't pay attention to the day dates as this is just to illustrate a week.
Along with the change of the slot I would like to propose to change the cadence of the meeting to bi-weekly(every 2 weeks, from current, every 3 weeks). If you want it to be held more often or less please say so.
JC
5 years, 1 month
Re: [golang-dev] proposal: public module authentication with the Go
notary
by Nicolas Mailhot
Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit :
> Le 2019-03-13 20:33, thepudds1460(a)gmail.com a écrit :
> >
> > However, even in advance of that, I have seen different people put
> > together one-off shell scripts or similar that are capable of
> > putting
> > a properly formed entry into the module cache such that it can be
> > used
> > by GOPROXY=file://your/path. For example:
> > https://github.com/komuw/goproxy/blob/master/goproxy.sh#L71
>
> And I have my own (unpublished incomplete and unfinished) code to
> try doing the same thing. Not elegant code I'm especially proud of,
> just quick and dirty “get it to work before august” code.
Anyway here is the code, not finished, not feature-complete, very
lightly tested, but already doing some useful things
https://pagure.io/modist/
You can add it to your collection of code that tries to do things with
Go modules.
That shows up pretty clearly that what should have been a very light
and thin wrapping of go upstream module tools, with some custom code to
translate go version syntax to rpm version syntax, is anything but
light and thin, and requires digging deeply in internal go code, and
extrapolating from go help messages.
(for example the very light testing I did this afternoon shows that go
version strings do not pass the roundtrip test, so either I can not
wrap my head around go module pseudoversion documentation, or the go
tool is doing something else than what is documented, or a mix of
both).
A thick compatibility layer (not calling directly high-level exported
APIs or go commands) basically means there is a high risk of future
divergence and incompatibility.
And the published code still needs to grow a command to generate list
files, and it's missing a call to tidy the go.mod content after the
module zip content changed, and probably other things I have not
identified yet.
And, I have no clue how to feed the result to the go build and go test
commands in addition to a GOPROXY system directory and the content of
the user Go cache, since the whole point is to prepare clean candidate
module files, and they can not be mixed in the same directories as
other modules while this processed is not finished. But my cunning plan
right now is to focus on creating and inspecting modules, and just let
Jakub deal with the compiler-side problems in Fedora. I don't have
enough braincells left to do both at once. And I still need to write
the matching adaptation layer rpm-side, which Jakub won't do.
Regards,
--
Nicolas Mailhot
5 years, 1 month
[NEEDINFO from nim] New Go macros: disambiguation between goipaths / goaltipaths
by Robert-André Mauchin
Nim,
Can you explain in what context would goipaths be used? What's the difference
with goaltipaths?
From what I tested:
- goipaths will install several import paths into the same devel package
- goaltipaths will generate compat-devel packages in care of renames etc.
I don't understand in what use cases goipaths should be used. I don't recall
ever seeing a Go source package with two import paths at the same time. Even
so, why would we install both in the same devel package, instead of making one
package for each import path.
Can you shed a light on what is the intended use?
Thanks,
Robert-André
5 years, 1 month
Fwd: [security] Vulnerability in golang.org/x/crypto/salsa20
by Jakub Cajka
FYI it seems there has been discovered security vulnerability in the golang-googlecode-go-crypto package. Hopefully we will have tracking BZ shortly.
JC
----- Forwarded Message -----
From: "Filippo Valsorda" <filippo(a)golang.org>
To: golang-nuts(a)googlegroups.com
Sent: Wednesday, March 20, 2019 11:53:53 PM
Subject: [security] Vulnerability in golang.org/x/crypto/salsa20
Hello gophers, Commit b7391e95
<https://go.googlesource.com/crypto/+/b7391e95e576cacdcdd422573063bc057239...>
fixes a vulnerability in the amd64 implementation of the
golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa packages
that affects large message sizes or high counter values. If more than 256
GiB of keystream is generated, or if the counter otherwise grows greater
than 32 bits, the amd64 implementation will first generate incorrect
output, and then cycle back to previously generated keystream. Repeated
keystream bytes can lead to loss of confidentiality in encryption
applications, or to predictability in CSPRNG applications. The issue might
affect uses of golang.org/x/crypto/nacl with extremely large messages.
Architectures
other than amd64 and uses that generate less than 256 GiB of keystream for
a single salsa20.XORKeyStream
<http://godoc.org/golang.org/x/crypto/salsa20#XORKeyStream> invocation are
unaffected. The vulnerable code is derived from the amd64-xmm5 and
amd64-xmm6 implementations that are distributed with SUPERCOP
<https://bench.cr.yp.to/supercop.html>, NaCl <https://nacl.cr.yp.to/> and
at https://cr.yp.to/snuffle.html. The issue is present in those upstreams,
but is not considered a problem by their author because of the policy at
https://nacl.cr.yp.to/valid.html, and because support for counters larger
than 32 bits is an incomplete experiment. We attach a patch that applies to
the amd64-xmm5 and amd64-xmm6 salsa20.s files for any downstream that might
want to fix this issue. This issue was discovered and reported by Michael
McLoughlin. Cheers, Filippo for the Go team
--
You received this message because you are subscribed to the Google Groups "golang-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-announce+unsubscribe(a)googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
5 years, 1 month
Re: [golang-dev] proposal: public module authentication with the Go
notary
by Jakub Cajka
----- Original Message -----
> From: "Sam Whited" <sam(a)samwhited.com>
> To: "rprichard via golang-dev" <golang-dev(a)googlegroups.com>
> Sent: Monday, March 4, 2019 7:06:37 PM
> Subject: Re: [golang-dev] proposal: public module authentication with the Go notary
>
> TL;DR — Right now when fetching a module Google isn't involved, and I'd
> like it to stay that way. Please let me configure and use different
> notaries without also using a proxy.
>
> > There is no plan to allow use of alternate notaries, which would add
> > complexity and potentially reduce the overall security of the system,
> > allowing different users to be attacked by compromising different
> > notaries.
>
> If you're somewhere that Google doesn't service (eg. due to U.S. export
> laws) does this mean you're entirely out of luck and can't use the new
> security features? It seems unfortunate that a developer in Iran would
> have to fall back to the TOFU model just because Google decided to bless
> themselves and not allow anyone else to run a notary or jump through
> extra hoops to configure or run a proxy.
>
> > We originally considered having multiple notaries signing individual
> > go.sum entries and requiring the go command to collect signatures from
> > a quorum of notaries before accepting an entry. That design depended
> > on the uptime of multiple services and could still be compromised
> > undetectably by compromising enough notaries. That is, that design
> > would blindly trust a quorum of notaries.
>
> This seems strictly superior to blindly trusting a single notary. Why
> does Google think it will be more secure than Google and Mozilla, or
> Google and Microsoft, or Google and <your company>?
>
> As far as uptime is concerned, you're always limited to the uptime of
> your least available notary, I don't necessarily think Google's uptime
> will be any better than any other large company that might choose to run
> a notary, so that seems fine: I have the option of trusting only
> notaries with high availability, meaning that it's likely no worse than
> if I just trusted Google.
>
> > The design presented here uses the transparent log eliminates blind
> > trust in a quorum of notaries and instead uses a “trust but verify”
> > model with a single notary.
>
> We could also "trust but verify" a quorum of notaries, so this seems
> like a false dichotomy.
>
> On a more personal note, having a non-Google controlled notary seems
> like an absolute requirement to me and I would prefer to avoid using a
> Google run service entirely if possible. Google doesn't need to know
> anything about what modules my company is using. I do appreciate the
> privacy section, which addresses this, but tying the notary use to using
> a proxy or running your own proxy is likely out of reach for many
> individuals (including me).
>
> —Sam
I have a similar fears and worries here. First thing that popped on my mind(personally as a external observer) this is a move of Google to fully productize(data mine) a Go users community(for very limited payback), even if it is not a main driver it will make it irresistibly easy to do so(with google hosted notary).
IMHO this feature should be opt-in and the actual default instance of the notary should be run by trustworthy and independent 3rd party(ideally NPO) with clear and transparent privacy policy and on community accessible infrastructure(so a community members can actually participate in the maintenance and verify policies surrounding it, i.e. not like a current Go infra is run, only Google employees can contribute/touch it).
As I will carefully evaluate all the details of the final implementation, but from this first look I'm currently leaning to "patch out" or de-configure by default this feature in Fedora when/if it lands in upstream GC, to preserve the privacy of the users.
JC
PS: This is just my personal Fedora's GC maintainer take on this issue.
>
> On Mon, Mar 4, 2019, at 17:32, Russ Cox wrote:
> > Hi all,
> >
> > I wanted to let people here know about the proposal design we just
> > published: golang.org/design/25530-notary, for golang.org/issue/25530.
> > (We also mentioned this general idea in our blog post from back in
> > December, https://blog.golang.org/modules2019.)
> >
> > As usual, comments are welcome on the issue or, if you prefer not to
> > use the issue tracker, here in this thread.
> >
> > Thanks. Russ
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "golang-dev" group. To unsubscribe from this group and stop
> > receiving emails from it, send an email to golang-
> > dev+unsubscribe(a)googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.
>
> --
> Sam Whited
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscribe(a)googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
5 years, 1 month
Glide.lock folder mess
by Robert-André Mauchin
Hi!
Numerous Golang packages are plagued with an issue caused when jchaloup uploaded Glide files. In a lot of case he has doubled the glide.yaml instead of adding the qlide.lock:
Source1: glide.yaml
Source2: glide.yaml
The problem is that when goinstall doesn't find the glide.lock file:
%goinstall glide.lock glide.yaml
it creates a folder instead.
Now when we try to fix the problem by re-adding the glide.lock file to the Sources, we are asking RPM to replace a folder by a file at update time, which it refuses to do so to avoid losing data the user might have placed there.
We get errors like:
Error: Transaction check error:
file /usr/share/gocode/src/github.com/mitchellh/go-homedir/glide.lock from install of golang-github-mitchellh-go-homedir-devel-1.1.0-1.fc29.noarch conflicts with file from package golang-github-mitchellh-go-homedir-devel-0-0.10.20180708gitdf55a15.fc29.noarch
This is a PITA. the only workaround it to add a %pretrans lua macro to deal with the mess.
# Remove in F33
# Remove erroneous glide.lock folder
%pretrans devel -p <lua>
path = "%{gopath}/src/%{goipath}/glide.lock"
st = posix.stat(path)
if st and st.type == "directory" then
os.remove(path)
end
See https://fedoraproject.org/wiki/Packaging:Directory_Replacement#Scriptlet_...
I have no idea how many packages are affected. But it's more work on our already full plates.
Best regards,
Robert-André
5 years, 1 month