[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#928026: security support for golang packages in Buster

On Wed, May 8, 2019 at 2:45 PM Paul Gevers <elbrus@debian.org> wrote:
> Hi,
> On 27-04-2019 09:31, Shengjing Zhu wrote:
> > Please CC debian-go@lists.debian.org and me.
> Done.
> [...]
> > IIUC, there're two concerns for Go packages.
> [...]
> > 2. binNMU without full source upload for security-master.
> >
> >    It's still not possible, and I don't know there's any effort to
> >    change the dak.
> >
> >    But I want to know how security team handles other static linked
> >    languages, like rust, haskell, ocaml, etc.
> With respect to binNMU'ing, static linking is not a problem, only
> arch:all is. Most haskell (4 vs 1048) and ocaml (21 vs 233) aren't
> arch:all. haskell and ocaml have a framework in place to at least know
> the status in unstable/testing. See e.g. the "permanent trackers" at
> https://release.debian.org/transitions/ I don't know yet what this means
> for security support. Neither do I know what it means for rust.
> >    It's not the issue for only Go packages.
> But most haskell and ocaml packages can be binNMU'd.
> >    The easiest probably is to binNMU in stable-pu.
> I don't understand what you mean by this last sentence. You mean to not
> do a binNMU but a full NMU for all the arch:all packages? I think the
> problem of the security team is that they don't want to commit to that.

All the arch:all golang packages, are only meant for building other
arch:any packages.
Let's say one arch:all package(take golang-golang-x-net-dev for
example) has security bug, we need:
1. fix the golang-golang-x-net-dev, do an usual upload.
2. since golang-golang-x-net-dev is statically embedded in other
arch:any packages, rebuild/binNMU these packages.

These steps usually work, when in unstable.

But for stable release, we need to do 1&2 in security-master. 1 is
possible, just like normal packages.
After 1 is done in security-master, we need to rebuild the reverse
depends. However binNMU is not possible in security-master. The
secrity-master doesn't share orig tarball with ftp-master. So in
security-master, full-NMU should be done for *many* packages.

And, other arch:all packages are not involved in these steps. Because
these packages are not affected, since they only contain the their own
Go source code files.

> [bug 928227]
> On 05-05-2019 18:00, Shengjing Zhu wrote:> Hi,
> [...]
> >> On Tue, Apr 30, 2019 at 05:07:57PM +0800, Drew Parsons wrote:
> >>> Please unblock package golang-golang-x-net-dev
> >>>
> >>> Upstream has provided patches addressing security issues
> >>> CVE-2018-17846 / CVE-2018-17847 / CVE-2018-17848
> >>> (Debian bug #911795).
> >>
> >> How will unblocking this fix these issues? golang-golang-x-net-dev is
> embedded
> >> in a number of packages in buster. If they are not updated, the
> unblock will
> >> not fix anything. How will this be handled?
> >>
> >
> > All the reverse depends need binNMU.
> > Since the Go packages are using(abusing) Built-Using tag, probably the
> > release team will binNMU all outdated Built-Using packages at this
> > period(before release)?
> I think the rebuild (or at least a big chunk of it) has already been
> done. And, as noted above, that we can't binNMU arch:all yet. Will you
> source upload those and add the list to bug 928227 and tell us which
> additional packages need to be scheduled for a binNMU?
> Just wondering, does anybody already have tooling/scripts/urls do check
> the current status? If not, I'll cook up something to assess the
> situation for myself. I'll update bug 928227 when I have some data.

There's no tool yet, but some SQL scripts like

As show in the result, for
golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3, probably 66
packages need binNMU.

Shengjing Zhu

Reply to: