Re: golang-go.crypto / CVE-2019-11841
Emilio Pozuelo Monfort <pochu@debian.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
> golang-go.crypto.
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
time:
Package: acmetool
Package: chasquid
Package: coyim
Package: go-wire
Package: gocryptfs
Package: golang-github-azure-azure-sdk-for-go
Package: golang-github-azure-go-autorest
Package: golang-github-azure-go-ntlmssp
Package: golang-github-bowery-prompt
Package: golang-github-coreos-ioprogress
Package: golang-github-coreos-pkg
Package: golang-github-elithrar-simple-scrypt
Package: golang-github-endophage-gotuf
Package: golang-github-howeyc-gopass
Package: golang-github-kisom-goutils
Package: golang-github-pkg-sftp
Package: golang-github-rackspace-gophercloud
Package: golang-github-weaveworks-mesh
Package: golang-github-xenolf-lego
Package: golang-github-xordataexchange-crypt
Package: golang-golang-x-net-dev
Package: golang-gopkg-dancannon-gorethink.v2
Package: golang-gopkg-macaroon.v1
Package: govendor
Package: influxdb
Package: mongo-tools
Package: packer
Package: rclone
Package: restic
Package: snapd
Package: syncthing
Package: tendermint-ed25519
Package: tendermint-go-merkle
Package: golang-ed25519-dev
Package: golang-github-bradfitz-http2
Package: golang-github-endophage-gotuf
Package: golang-pault-go-debian
Package: influxdb
Package: obfs4proxy
Package: pluginhook
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
> needed.
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
in backports.
Or is this a candidate to add to
https://salsa.debian.org/debian/debian-security-support/-/blob/master/security-support-ended.deb9?
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. ?
same?
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 <bam@debian.org>
Reply to: