On Wed, May 8, 2019 at 2:45 PM Paul Gevers <elb...@debian.org> wrote: > > Hi, > > On 27-04-2019 09:31, Shengjing Zhu wrote: > > Please CC debian...@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 http://paste.debian.net/1082099/ 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
