Re: golang-go.crypto / CVE-2019-11841
On Fri, Oct 09, 2020 at 12:17:26PM +0200, Emilio Pozuelo Monfort wrote: > On 09/10/2020 00:23, Brian May wrote: > > 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. > > I would look for an automated way to do this. E.g. by downloading and > inspecting the binaries to see if they have the affected code. > > I think Adrian handled a go update and its rdeps in the past. Adding him to > Cc in case he has any ideas. >... I went manually through the rdeps, and claimed only Go packages with few redps needing rebuilding. So sorry, no easy ideas from me. > Cheers, > Emilio cu Adrian
Re: golang-go.crypto / CVE-2019-11841
Emilio Pozuelo Monfort writes: > I would look for an automated way to do this. E.g. by downloading and > inspecting > the binaries to see if they have the affected code. Hmmm. Good idea in theory, but not sure how to do this in practise. I tried building two copies of acmetool, and comparing, but it looks like go builds are not yet reproducible. There is the known issue that the build path is encoded in the result. But I am getting other differences too. Hmm. But it looks like /usr/bin/acmetool contains strings such as: /tmp/brian/tmpxbsh4mst/build/amd64/source/obj-x86_64-linux-gnu/src/golang.org/x/crypto/ocsp/ocsp.go This looks like a source file. Wonder if it is possible to extract a list of all source files that were used to build acmetool... So far not getting anywhere with "readelf". But maybe "strings" might be sufficient. -- Brian May
