Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Shengjing Zhu <zhsj@debian.org>]

On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher <sramacher@debian.org> wrote:
>
> On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote:
> > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu <zhsj@debian.org> wrote:
> > >
> > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise <pabs@debian.org> wrote:
> > > >
> > > > On Wed, 2021-07-14 at 20:16 +0800, Shengjing Zhu wrote:
> > > >
> > > > > That feels over-engineering/energy-wasting.
> > > >
> > > > Another option would be to search the source code, and these findings
> > > > would need to be confirmed using grep, but looking at codesearch:
> > > >
> > > >    https://codesearch.debian.net/search?q=%5C.generateClientKeyExchange&literal=0
> > > >
> > >
> > > generateClientKeyExchange is not an exported function, which is
> > > expected to be called by other library/softwares.
> >
> > oops, it should be "which is not expected..."
>
> What's the status? If we cannot reduce the number of packages to binNMU,
> then this needs to happen soon. Otherwise there won't be enough time to
> chase all the rebuilds.
>

>From my perspertive, for std library security fix in Go compiler, it's
better to rebuild all Go packages.

It's not possible to figure out the affected packages at sub-lib(eg
the crypto/tls package in std lib) level by source package.
Only possible with binary packages, either by
+ disassemble
+ or rebuild at local first to see if the result binary changes.

PS, the embedded version of Go std libary is tracked at all Go
packages' Built-Using field. And it's only tracked at source package
level, not every sub-lib level.
So for other Go lib packages security updates, we don't need to
rebuild the world.

-- 
Shengjing Zhu