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
