Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
Hi Emilio, > Also, can't we reduce this list further? Are all those packages using the > crypto > module? I can remove: * kxd * golang-bindata * golang-gogoprotobuf * golang-goprotobuf * ngrok * obfs4proxy * pt-websocket * slt I've gone-ahead and uploaded the rest. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
On Mon, 11 Feb 2019 at 21:28, Emilio Pozuelo Monfort
wrote:
> On 11/02/2019 09:24, Chris Lamb wrote:
> > Hi Tobias,
> >
> >> The remaining packages on the list maybe need a rebuild for jessie:
> >>
> >> aptly
> >> direnv
> >> golang-bindata
> >> golang-gogoprotobuf
> >> golang-goprotobuf
> >> heartbleeder
> >> kxd
> >> ngrok
> >> obfs4proxy
> >> pt-websocket
> >> slt
> >
> > Great stuff — thanks for this. LTS team, just as a sanity check;
> > uploading each of these with "dpkg-buildpackage -S […]" should be
> > sufficient, right?
>
> Erm, why -S ? You need a source+binary upload, as usual.
>
> Also, can't we reduce this list further? Are all those packages using the
> crypto
> module? Or is there no easy way to determine that?
>
It is possible using 'go list' to be certain about transitive dependencies
of the modules being compiled, but it's not super easy to get into the
position of being able to use it. For a package that uses dh-golang
straightforwardly like heartbleeder, I did this:
1) built it using sbuild -p never
2) entered the session for the build
3) cd-ed to the build directory
4) extracfed the "go import path" for the package:
(sid-amd64)root@ringil:/build/heartbleeder-MCxoon/heartbleeder-0.1.1# grep
-i ^xs-go-import-path debian/control
XS-Go-Import-Path: github.com/titanous/heartbleeder
5) found the packages that build binaries:
(sid-amd64)root@ringil:/build/heartbleeder-MCxoon/heartbleeder-0.1.1#
GOPATH=$(pwd)/obj-x86_64-linux-gnu/ go list -f '{{ if eq .Name "main"
}}{{.ImportPath}}{{end}}' github.com/titanous/heartbleeder/... >
packages-making-executables
6) found the packages that these packages depend on:
(sid-amd64)root@ringil:/build/heartbleeder-MCxoon/heartbleeder-0.1.1#
GOPATH=$(pwd)/obj-x86_64-linux-gnu/ go list -f '{{ range .Deps }}{{ . }}
{{end}}' $(cat packages-making-executables ) | sort | uniq > dependencies
7) looked for crypto/elliptic in this list:
(sid-amd64)root@ringil:/build/heartbleeder-MCxoon/heartbleeder-0.1.1# grep
crypto/elliptic dependencies
crypto/elliptic
So looks like heartbleeder should be rebuilt.
The dh_golang script in dh-golang is in a much better position to get this
information at package build time and store it ... somewhere. But I've no
idea where and of course that's a solution for the next CVE, not this one.
Cheers,
mwh
Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
On 11/02/2019 09:24, Chris Lamb wrote: > Hi Tobias, > >> The remaining packages on the list maybe need a rebuild for jessie: >> >> aptly >> direnv >> golang-bindata >> golang-gogoprotobuf >> golang-goprotobuf >> heartbleeder >> kxd >> ngrok >> obfs4proxy >> pt-websocket >> slt > > Great stuff — thanks for this. LTS team, just as a sanity check; > uploading each of these with "dpkg-buildpackage -S […]" should be > sufficient, right? Erm, why -S ? You need a source+binary upload, as usual. Also, can't we reduce this list further? Are all those packages using the crypto module? Or is there no easy way to determine that? Emilio
Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
Hi Tobias, > The remaining packages on the list maybe need a rebuild for jessie: > > aptly > direnv > golang-bindata > golang-gogoprotobuf > golang-goprotobuf > heartbleeder > kxd > ngrok > obfs4proxy > pt-websocket > slt Great stuff — thanks for this. LTS team, just as a sanity check; uploading each of these with "dpkg-buildpackage -S […]" should be sufficient, right? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
Am 08.02.2019 um 20:46 schrieb Dr. Tobias Quathamer: > With that in mind, the list gets much shorter. Is there an easy way to > find out if a source package produces only the -dev binary package? One > hint at finding the right packages would be that the -dev packages are > arch:all, while other binary packages are arch:any. It's surely not the most elegant approach, but I've taken the list from build-rdeps and saved it in a file called "packages.txt". Then I've used the following commandline to find all source packages which produce a binary package which is not arch:all. $ for i in `cat packages.txt`; do grep-dctrl --regex -FPackage ^$i --and --not -FArchitecture all -sPackage -n /var/lib/apt/lists/*Sources; done This gets you a list with some false positives, because those false positive packages are wrongly marked as arch:any instead of arch:all. They only contain go source code and are not compiled, so they don't need a rebuild with the fixed golang compiler. The remaining packages on the list maybe need a rebuild for jessie: aptly direnv golang-bindata golang-gogoprotobuf golang-goprotobuf heartbleeder kxd ngrok obfs4proxy pt-websocket slt If you'd like, you could probably boil this list further down by grepping for crypto/elliptic in the package's source code. >>> Please note that I was not able to get build-rdeps to run in a >>> jessie chroot >> >> (Ah, not just me then; I needed to hack the "sid|unstable" bit in >> the code but didn't want to yak-shave that at the time!) > > :-) Nice to know, I was at a loss in that chroot, only wondering how the > hell you got that command to run ... Oh well, just RTFM. I've discovered a helpful option: $ build-rdeps --distribution jessie golang-go Sigh. Regards, Tobias signature.asc Description: OpenPGP digital signature
Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
Am 08.02.2019 um 17:31 schrieb Chris Lamb:
> Hi Tobias,
>
>> $ grep-dctrl -FBuild-Depends golang-go -w -sPackage
>> /var/lib/apt/lists/*Sources
> [..]
>>
>> Please note that there are probably a lot of false positives in this
>> list, because not every package uses crypto/elliptic.
>
> Indeed. So how reliable would it be to look for "crypto/elliptic"
> and skip those? I fear that might accidentally exclude packages due
> to transitive imports / Build-Depends or similar?
>
> Or: should I just save effort and upload the lot?
Hi Chris,
I've just recently joined the go compiler team, so I'm not an expert --
but from my understanding, there should be no transitive imports in this
specific case.
If I understand you correctly, you mean that package "A" does not use
crypto/elliptic itself, but Build-Depends on package "B", which *does*
use crypto/elliptic, right?
The golang compiler itself is affected, so any package ("A" in the
example) which Build-Depends on a -dev package which uses
crypto/elliptic ("B" in the example) should also have a Build-Depends on
golang-go. Therefore, I think it would be save to skip all packages
which only produce a -dev package.
With that in mind, the list gets much shorter. Is there an easy way to
find out if a source package produces only the -dev binary package? One
hint at finding the right packages would be that the -dev packages are
arch:all, while other binary packages are arch:any.
Does this help and/or makes sense? :-)
>> Please note that I was not able to get build-rdeps to run in a
>> jessie chroot
>
> (Ah, not just me then; I needed to hack the "sid|unstable" bit in
> the code but didn't want to yak-shave that at the time!)
:-) Nice to know, I was at a loss in that chroot, only wondering how the
hell you got that command to run ...
Regards,
Tobias
signature.asc
Description: OpenPGP digital signature
Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
Hi Tobias, > $ grep-dctrl -FBuild-Depends golang-go -w -sPackage > /var/lib/apt/lists/*Sources [..] > > Please note that there are probably a lot of false positives in this > list, because not every package uses crypto/elliptic. Indeed. So how reliable would it be to look for "crypto/elliptic" and skip those? I fear that might accidentally exclude packages due to transitive imports / Build-Depends or similar? Or: should I just save effort and upload the lot? > Please note that I was not able to get build-rdeps to run in a > jessie chroot (Ah, not just me then; I needed to hack the "sid|unstable" bit in the code but didn't want to yak-shave that at the time!) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update
Am 08.02.2019 um 16:20 schrieb Chris Lamb: > Hi all, > >>> There is no sensible way to schedule binnmu's via security. So far none >>> appeared AFAIK. > […] >> thanks for the quick feedback still! > > Indeed thanks for the feedback. Looking into this quickly from a > jessie chroot: > > $ build-rdeps golang > > Reverse Build-depends in main: > -- > > heartbleeder > golang-gocapability-dev > aptly > > Assuming that is right (it seems a curiously small number to me...) > I then believe we may only need sourceful uploads of: > > * aptly > * heartbleeder > > ... as golang-gocapability-dev does not import "crypto/elliptic". > However, it could be using it transitively so it might be worth > uploading just in case. > > Sound sensible? Hi all, I think the small number is due to the "golang" keyword. If you search for golang-go, the actual go compiler at that time, you'll get more packages. Please note that I was not able to get build-rdeps to run in a jessie chroot, so you might want to execute "build-rdeps golang-go" in your chroot to compare the lists. However, this list has been generated with the following command: $ grep-dctrl -FBuild-Depends golang-go -w -sPackage /var/lib/apt/lists/*Sources codesearch direnv go-md2man gocode golang-barcode golang-bindata golang-blackfriday golang-context golang-coreos-log golang-dbus golang-dns golang-doozer golang-ed25519-dev golang-etcd golang-go-dbus golang-go-flags golang-go-patricia golang-go-systemd golang-go.crypto golang-go.tools golang-gocheck golang-godebiancontrol-dev golang-gogoprotobuf golang-goprotobuf golang-goptlib golang-goyaml golang-libgeoip golang-log4go golang-metrics golang-mreiferson-httpclient golang-mux golang-nzaat golang-objx golang-openldap golang-pb golang-pretty golang-pty golang-raft golang-rrd golang-siphash-dev golang-termbox golang-testify golang-text golang-thrift golang-uuid golang-vhost golang-websocket gopacket kxd libguestfs ngrok obfs4proxy pt-websocket slt Please note that there are probably a lot of false positives in this list, because not every package uses crypto/elliptic. Regards, Tobias signature.asc Description: OpenPGP digital signature
Re: [SECURITY] [DLA 1664-1] golang security update
Hi all, > > There is no sensible way to schedule binnmu's via security. So far none > > appeared AFAIK. […] > thanks for the quick feedback still! Indeed thanks for the feedback. Looking into this quickly from a jessie chroot: $ build-rdeps golang Reverse Build-depends in main: -- heartbleeder golang-gocapability-dev aptly Assuming that is right (it seems a curiously small number to me...) I then believe we may only need sourceful uploads of: * aptly * heartbleeder ... as golang-gocapability-dev does not import "crypto/elliptic". However, it could be using it transitively so it might be worth uploading just in case. Sound sensible? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: [SECURITY] [DLA 1664-1] golang security update
Hi Salvatore, On Fri, Feb 08, 2019 at 09:02:49AM +0100, Salvatore Bonaccorso wrote: > The point we discussed with Tobias Quathamer was boiling down to: > > But if there are any Go-based applications in stretch which are affected by > > the ECC issue, we could schedule binNMUs by the next stretch point release. > There is no sensible way to schedule binnmu's via security. So far none > appeared AFAIK. sigh. thanks for the quick feedback still! -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: [SECURITY] [DLA 1664-1] golang security update
Hi Holger, On Wed, Feb 06, 2019 at 11:24:34PM +, Holger Levsen wrote: > Dear golang maintainers and security team, > > this came up on the LTS mailing list... > > On Wed, Feb 06, 2019 at 11:42:12PM +0100, Chris Lamb wrote: > > > all golang Debian packages are (as elsewhere) statically compiled > > > and linked so we'd need to rebuild all the rdeps > > Hm. Can we avoid /all/ the rdeps? I mean, grep the rdeps for ones > > that use this library? > > how was this handled for DSA-4379 and 4380? The point we discussed with Tobias Quathamer was boiling down to: > But if there are any Go-based applications in stretch which are affected by > the ECC issue, we could schedule binNMUs by the next stretch point release. There is no sensible way to schedule binnmu's via security. So far none appeared AFAIK. Regards, Salvatore
Re: [SECURITY] [DLA 1664-1] golang security update
On 06/02/2019 23:47, Antoine Beaupré wrote: > On 2019-02-06 23:42:12, Chris Lamb wrote: >> Hi Antoine, >> >>> all golang Debian packages are (as elsewhere) statically compiled >>> and linked so we'd need to rebuild all the rdeps >> >> Hm. Can we avoid /all/ the rdeps? I mean, grep the rdeps for ones >> that use this library? > > Yeah, that's what I was implying, sorry if that was unclear... I'm not > actually sure how that works. I assume it's a bunch of binNMUs, Note that due to the fact the security archive is a separate dak instance, it doesn't contain all the sources from the main archive, only those that were specifically uploaded to -security. Meaning: we can't binNMU packages that are not in the security archive, they will need sourceful uploads instead (unless an ftp-master uses some magic to copy packages to -security, I know there are plans to make -security synced with the main archive but it hasn't happened yet). See how Markus handled the agg (header-only lib) security update by following up with no change uploads of the two rdeps. > but we > first need to figure out which packages actually use that specific lib. The golang maintainers use the Built-Using field to keep track of what is using what and what packages need to be rebuilt (e.g. when golang-defaults is updated). But that may not be good enough in this case if only a part of golang is affected. Better ask the golang or the security team to see how they handled it. Cheers, Emilio
Re: [SECURITY] [DLA 1664-1] golang security update
Dear golang maintainers and security team, this came up on the LTS mailing list... On Wed, Feb 06, 2019 at 11:42:12PM +0100, Chris Lamb wrote: > > all golang Debian packages are (as elsewhere) statically compiled > > and linked so we'd need to rebuild all the rdeps > Hm. Can we avoid /all/ the rdeps? I mean, grep the rdeps for ones > that use this library? how was this handled for DSA-4379 and 4380? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: [SECURITY] [DLA 1664-1] golang security update
Antoine Beaupré wrote: > > Hm. Can we avoid /all/ the rdeps? I mean, grep the rdeps for ones > > that use this library? > > Yeah, that's what I was implying, sorry if that was unclear... I'm not > actually sure how that works. I assume it's a bunch of binNMUs, but we > first need to figure out which packages actually use that specific lib. Shall we loop the golang maintainers in here? They might even have such a script or otherwise have some insight here... Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: [SECURITY] [DLA 1664-1] golang security update
On 2019-02-06 23:42:12, Chris Lamb wrote: > Hi Antoine, > >> all golang Debian packages are (as elsewhere) statically compiled >> and linked so we'd need to rebuild all the rdeps > > Hm. Can we avoid /all/ the rdeps? I mean, grep the rdeps for ones > that use this library? Yeah, that's what I was implying, sorry if that was unclear... I'm not actually sure how that works. I assume it's a bunch of binNMUs, but we first need to figure out which packages actually use that specific lib. Maintaining golang security update is really tricky.. :/ I wish we could just dynamically link everything in Debian, but I'm afraid that's heresy (even if technically possible, apparently) in Golang circles... a. -- The greatest crimes in the world are not committed by people breaking the rules but by people following the rules. It's people who follow orders that drop bombs and massacre villages. - Banksy
Re: [SECURITY] [DLA 1664-1] golang security update
Hi Antoine, > all golang Debian packages are (as elsewhere) statically compiled > and linked so we'd need to rebuild all the rdeps Hm. Can we avoid /all/ the rdeps? I mean, grep the rdeps for ones that use this library? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: [SECURITY] [DLA 1664-1] golang security update
On 2019-02-06 22:17:26, Chris Lamb wrote: > It was discovered that there was a denial of service vulnerability > or possibly even the ability to conduct private key recovery > attacks within in the elliptic curve cryptography handling in the > Go programming language libraries. Hello Chris! Have you given any thought to the impact this could have on the build-dependencies that might be affected by this vulnerability? As you probably know, all golang Debian packages are (as elsewhere) statically compiled and linked so we'd need to rebuild all the rdeps to have this properly fixed in the dependencies... A. -- Si Dieu est, l'homme est esclave ; or l'homme peut, doit être libre, donc Dieu n'existe pas. Et si Dieu existait, il faudrait s'en débarrasser! - Michel Bakounine
