On 2021-07-18 02:49:26 +0800, Shengjing Zhu wrote: > 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. Sorry, I meant: what's the status of the golang-1.15 upload? Cheers > > -- > Shengjing Zhu -- Sebastian Ramacher
Attachment:
signature.asc
Description: PGP signature