Re: [pkg-golang-devel] [SECURITY] [DLA 1664-1] golang security update

2019-02-12 Thread Chris Lamb
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

2019-02-11 Thread Michael Hudson-Doyle
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

2019-02-11 Thread Emilio Pozuelo Monfort
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

2019-02-11 Thread Chris Lamb
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

2019-02-08 Thread Dr. Tobias Quathamer
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

2019-02-08 Thread Dr. Tobias Quathamer
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

2019-02-08 Thread 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?

> 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

2019-02-08 Thread Dr. Tobias Quathamer
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