On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher <sramac...@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 <z...@debian.org> wrote: > > > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise <p...@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