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
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