Re: golang-go.crypto / CVE-2019-11841
Emilio Pozuelo Monfort <firstname.lastname@example.org> writes:
> That go be a simplification. However there's a chance one of those golang-
> packages also has a bin package with a real binary, and then that may need to be
> rebuilt as well.
> Also, not all packages with compiled binaries necessarily need a rebuild. E.g.
> they may not use the affected code at all, just other parts of
I am inclined to think that golang-* packages with binaries that include
stuff from golang-go.crypto are likely to be for development/building
purposes only, and perhaps not so important ... ?
However it sounds like we need to investigate each package one at a
We probably need someway of keeping track of what packages have already
been looked at and their status with respect to this rebuild. Not really
convinced data/dla-needed.txt is up to this task.
>> How do I rebuild? Do I need to upload a new version?
> Unless they already are in stretch-security, then yes, sourceful uploads will be
I hope there are none of these packages that have the same version in
buster... Not seen any problems yet however.
Looking at items in the list from the top:
acmetool - automatic certificate acquisition tool for Let's Encrypt
OK, good candidate. A certificate signing tool needs to be secure. But,
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954189 - it looks
like the 0.0.58-5+b2 in stretch is likely to be completely broken and
unusable for unrelated reasons. Is this something we should be fixing?
My guess is anybody who needs in buster has already moved to the version
Or is this a candidate to add to
In any case, unlikely to use ssh public keys or cleartext signatures, so
probably won't need to rebuild.
chasquid - simple SMTP (email) server written in go
coyim - safe and secure XMPP chat client
go-wire - Go bindings for the Wire encoding protocol
gocryptfs - Encrypted overlay filesystem written in Go.
Unlikely to use ssh public keys or cleartext signatures. ?
In fact, I suspect this might hold true for the remainder of the
packages. With the exception of maybe golang-github-pkg-sftp. Which is
entirely go files.
How am I going so far? Too conservative?
However now I also realise another limitation in the above list. It
probably won't mention, for example, packages that build depend on
golang-github-pkg-sftp-dev which depends on golang-golang-x-crypto-dev.
Brian May <email@example.com>