Emilio Pozuelo Monfort <po...@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 <b...@debian.org>
