Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On 2021-07-18 13:06:18 +0800, Shengjing Zhu wrote: > On Sun, Jul 18, 2021 at 3:00 AM Sebastian Ramacher > wrote: > [..] > > Ah, I missed the debdiff due to the other discussion. Please go ahead. > > > > Uploaded, built and installed on all architecures. Thanks, binNMUs scheduled. Cheers > > -- > Shengjing Zhu -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Sun, Jul 18, 2021 at 3:00 AM Sebastian Ramacher wrote: [..] > Ah, I missed the debdiff due to the other discussion. Please go ahead. > Uploaded, built and installed on all architecures. -- Shengjing Zhu
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
(Replace pkg-go-maintain...@lists.alioth.debian.org with debian-go@lists.d.o, the alioth list is deprecated) On Sun, Jul 18, 2021 at 3:32 AM Adrian Bunk wrote: > > On Tue, Jul 13, 2021 at 02:08:22PM +0800, Shengjing Zhu wrote: > >... > > Sadly the std library are statically embedded in all packages built by Go > > compiler. > > So if there's security issue in std library, bunch of packages need to be > > rebuild. > >... > > It might be an improvement to switch to gccgo as default Go compiler > in bookworm? Might be. And it would be great if we can get some compiler experts or upstream to have some inputs. If anyone have experience on this area and want to drive this, I think it's worth to try. -- Shengjing Zhu
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Tue, Jul 13, 2021 at 02:08:22PM +0800, Shengjing Zhu wrote: >... > Sadly the std library are statically embedded in all packages built by Go > compiler. > So if there's security issue in std library, bunch of packages need to be > rebuild. >... It might be an improvement to switch to gccgo as default Go compiler in bookworm? cu Adrian
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On 2021-07-18 02:54:31 +0800, Shengjing Zhu wrote: > On Sun, Jul 18, 2021 at 2:52 AM Sebastian Ramacher > wrote: > > > > On 2021-07-18 02:49:26 +0800, Shengjing Zhu wrote: > > > On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher > > > wrote: > > > > > > > > On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote: > > > > > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu wrote: > > > > > > > > > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise 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=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? > > > > Not uploaded yet. But I have sent the debdiff, and wait for the ACK. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990825#17 Ah, I missed the debdiff due to the other discussion. Please go ahead. Cheers > > -- > Shengjing Zhu -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Sun, Jul 18, 2021 at 2:52 AM Sebastian Ramacher wrote: > > On 2021-07-18 02:49:26 +0800, Shengjing Zhu wrote: > > On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher > > wrote: > > > > > > On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote: > > > > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu wrote: > > > > > > > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise 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=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? > Not uploaded yet. But I have sent the debdiff, and wait for the ACK. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990825#17 -- Shengjing Zhu
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On 2021-07-18 02:49:26 +0800, Shengjing Zhu wrote: > On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher > wrote: > > > > On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote: > > > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu wrote: > > > > > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise 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=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 signature.asc Description: PGP signature
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher wrote: > > On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote: > > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu wrote: > > > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise 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=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
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote: > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu wrote: > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise 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=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. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Thu, Jul 15, 2021 at 1:54 AM Paul Wise 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=0 > generateClientKeyExchange is not an exported function, which is expected to be called by other library/softwares. Search "crypto/tls" is more accurate. https://codesearch.debian.net/search?q=crypto%2Ftls+filetype%3Ago=1=1 curl -s https://codesearch.debian.net/results/680cb0808e1dbe1d/packages.txt|wc -l 250 -- Shengjing Zhu
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu wrote: > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise 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=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..." -- Shengjing Zhu
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
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=0 golang-github-marten-seemann-qtls golang-github-marten-seemann-qtls-go1-15 golang-github-cloudflare-cfssl golang-refraction-networking-utls heartbleeder As well as anything that transitively build-depends on any of these. That said, I don't think rebuilding those packages will fix the issue, since they have embedded code copies of key_agreement.go and possibly use those copies instead of the code from the std library. There are also a number of other copies of key_agreement.go as well as copies of handshake_client.go, which calls the vulnerable code. $ apt-file search -I dsc key_agreement.go android-platform-external-boringssl: /src/ssl/test/runner/key_agreement.go chromium: /third_party/boringssl/src/ssl/test/runner/key_agreement.go gcc-avr: /gcc/libgo/go/crypto/tls/key_agreement.go gcc-riscv64-unknown-elf: /libgo/go/crypto/tls/key_agreement.go golang-1.15: /src/crypto/tls/key_agreement.go golang-1.16: /src/crypto/tls/key_agreement.go golang-github-cloudflare-cfssl: /scan/vendor/crypto/tls/key_agreement.go golang-github-marten-seemann-qtls: /key_agreement.go golang-github-marten-seemann-qtls-go1-15: /key_agreement.go golang-refraction-networking-utls: /key_agreement.go heartbleeder: /tls/key_agreement.go llvm-toolchain-9: /llgo/third_party/gofrontend/libgo/go/crypto/tls/key_agreement.go mono: /external/boringssl/ssl/test/runner/key_agreement.go $ apt-file search -I dsc handshake_client.go android-platform-external-boringssl: /src/ssl/test/runner/handshake_client.go chromium: /third_party/boringssl/src/ssl/test/runner/handshake_client.go gcc-avr: /gcc/libgo/go/crypto/tls/handshake_client.go gcc-riscv64-unknown-elf: /libgo/go/crypto/tls/handshake_client.go golang-1.15: /src/crypto/tls/handshake_client.go golang-1.16: /src/crypto/tls/handshake_client.go golang-github-cloudflare-cfssl: /scan/vendor/crypto/tls/handshake_client.go golang-github-marten-seemann-qtls: /handshake_client.go golang-github-marten-seemann-qtls-go1-15: /handshake_client.go golang-refraction-networking-utls: /handshake_client.go heartbleeder: /tls/handshake_client.go llvm-toolchain-9: /llgo/third_party/gofrontend/libgo/go/crypto/tls/handshake_client.go mono: /external/boringssl/ssl/test/runner/handshake_client.go -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Wed, Jul 14, 2021 at 03:13:13AM +, Paul Wise wrote: > On Tue, Jul 13, 2021 at 6:12 AM Shengjing Zhu wrote: > > > Sadly the std library are statically embedded in all packages built by Go > > compiler. > > So if there's security issue in std library, bunch of packages need to be > > rebuild. > > > > It may be possible to disassemble all Go binaries to see how many std > > libraries > > are embedded, but currently we don't have such tool to go through all > > unpacked binary > > packages. > > An alternative more brute-force approach might be to rebuild all > packages locally twice, once without the patched std library and once > with the patched std library, then use diffoscope to compare the > binaries and if there are any changes then request a binNMU for the > package. Packages that don't use the crypto library should not have it > linked in and should see no changes after rebuilding with the patch. That feels over-engineering/energy-wasting. But if someone can offer the compute resource, I can offer some time to write the scripts to do the work.
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
On Tue, Jul 13, 2021 at 6:12 AM Shengjing Zhu wrote: > Sadly the std library are statically embedded in all packages built by Go > compiler. > So if there's security issue in std library, bunch of packages need to be > rebuild. > > It may be possible to disassemble all Go binaries to see how many std > libraries > are embedded, but currently we don't have such tool to go through all > unpacked binary > packages. An alternative more brute-force approach might be to rebuild all packages locally twice, once without the patched std library and once with the patched std library, then use diffoscope to compare the binaries and if there are any changes then request a binNMU for the package. Packages that don't use the crypto library should not have it linked in and should see no changes after rebuilding with the patch. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
Hi,
On Mon, Jul 12, 2021 at 10:52:47AM +0200, Sebastian Ramacher wrote:
> > [ Risks ]
> >
> > It's security fix to standard library. So it needs binNMU for all Go
> > packages.
>
> That's about 1.7k source packages. It would help if you can reduce the
> set of affected packages to not waste time chasing binNMUs for packages
> that don't need them.
>
That's about 200+ binary packages. arch:all packages are not affected.
Sadly the std library are statically embedded in all packages built by Go
compiler.
So if there's security issue in std library, bunch of packages need to be
rebuild.
It may be possible to disassemble all Go binaries to see how many std libraries
are embedded, but currently we don't have such tool to go through all unpacked
binary
packages.
> Cheers
>
> > As it's near hard freeze, I'd like to ask whether to fix it before release
> > or after.
> > I don't have preference FWIW.
> > CCed security team as well.
> >
> > [ Checklist ]
> > [ ] all changes are documented in the d/changelog
> > [ ] I reviewed all changes and I approve them
> > [ ] attach debdiff against the package in testing
> >
> > [ Other info ]
> >
> > That's just pre-announcement by Go upstream. So I really don't have diff
> > yet.
> >
> > unblock golang-1.15/1.15.9-6
> >
As the security issue is disclosed now, I have prepared the debdiff.
diff -Nru golang-1.15-1.15.9/debian/changelog
golang-1.15-1.15.9/debian/changelog
--- golang-1.15-1.15.9/debian/changelog 2021-06-05 19:36:34.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-07-13 13:55:42.0 +0800
@@ -1,3 +1,12 @@
+golang-1.15 (1.15.9-6) unstable; urgency=medium
+
+ * Team upload.
+ * Backport patche for CVE-2021-34558
+crypto/tls: clients can panic when provided a certificate of the wrong type
+for the negotiated parameters
+
+ -- Shengjing Zhu Tue, 13 Jul 2021 13:55:42 +0800
+
golang-1.15 (1.15.9-5) unstable; urgency=medium
* Team upload.
diff -Nru golang-1.15-1.15.9/debian/patches/0013-CVE-2021-34558.patch
golang-1.15-1.15.9/debian/patches/0013-CVE-2021-34558.patch
--- golang-1.15-1.15.9/debian/patches/0013-CVE-2021-34558.patch 1970-01-01
08:00:00.0 +0800
+++ golang-1.15-1.15.9/debian/patches/0013-CVE-2021-34558.patch 2021-07-13
13:55:42.0 +0800
@@ -0,0 +1,46 @@
+From c77980bc077f3774276ab2deba78d8e6bfe4b3bd Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker
+Date: Wed, 9 Jun 2021 11:31:27 -0700
+Subject: [PATCH] [release-branch.go1.15] crypto/tls: test key type when
+ casting
+
+When casting the certificate public key in generateClientKeyExchange,
+check the type is appropriate. This prevents a panic when a server
+agrees to a RSA based key exchange, but then sends an ECDSA (or
+other) certificate.
+
+Updates #47143
+Fixes #47144
+Fixes CVE-2021-34558
+
+Thanks to Imre Rad for reporting this issue.
+
+Change-Id: Iabccacca6052769a605cccefa1216a9f7b7f6aea
+Reviewed-on:
https://team-review.git.corp.google.com/c/golang/go-private/+/1116723
+Reviewed-by: Filippo Valsorda
+Reviewed-by: Katie Hockman
+Reviewed-on: https://go-review.googlesource.com/c/go/+/334030
+Trust: Filippo Valsorda
+Run-TryBot: Filippo Valsorda
+Reviewed-by: Dmitri Shuralyov
+---
+ src/crypto/tls/key_agreement.go | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/src/crypto/tls/key_agreement.go b/src/crypto/tls/key_agreement.go
+index 7e6534bd465e3..22f1b2e1f2441 100644
+--- a/src/crypto/tls/key_agreement.go
b/src/crypto/tls/key_agreement.go
+@@ -67,7 +67,11 @@ func (ka rsaKeyAgreement) generateClientKeyExchange(config
*Config, clientHello
+ return nil, nil, err
+ }
+
+- encrypted, err := rsa.EncryptPKCS1v15(config.rand(),
cert.PublicKey.(*rsa.PublicKey), preMasterSecret)
++ rsaKey, ok := cert.PublicKey.(*rsa.PublicKey)
++ if !ok {
++ return nil, nil, errors.New("tls: server certificate contains
incorrect key type for selected ciphersuite")
++ }
++ encrypted, err := rsa.EncryptPKCS1v15(config.rand(), rsaKey,
preMasterSecret)
+ if err != nil {
+ return nil, nil, err
+ }
diff -Nru golang-1.15-1.15.9/debian/patches/series
golang-1.15-1.15.9/debian/patches/series
--- golang-1.15-1.15.9/debian/patches/series2021-06-05 19:36:34.0
+0800
+++ golang-1.15-1.15.9/debian/patches/series2021-07-13 13:55:42.0
+0800
@@ -10,3 +10,4 @@
0010-CVE-2021-33195-2.patch
0011-CVE-2021-33197.patch
0012-CVE-2021-33198.patch
+0013-CVE-2021-34558.patch
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
Control: tags -1 moreinfo On 2021-07-08 23:46:31, Shengjing Zhu wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: z...@debian.org, t...@security.debian.org > > Please unblock package golang-1.15 > > [ Reason ] > Just received a pre-announcement[1] by Go upstream: > > > We plan to issue Go 1.16.6 and Go 1.15.14 on Monday, July 12. > > These are minor releases that include security fixes to the standard > > library. > > [1] https://groups.google.com/g/golang-announce/c/JvWG9FUUYT0/m/VK1iHZosAgAJ > > Go upstream defines there levels for security issue, PUBLIC, PRIVATE, and > URGENT. > This is level PRIVATE. > > [ Impact ] > > [ Tests ] > > [ Risks ] > > It's security fix to standard library. So it needs binNMU for all Go packages. That's about 1.7k source packages. It would help if you can reduce the set of affected packages to not waste time chasing binNMUs for packages that don't need them. Cheers > As it's near hard freeze, I'd like to ask whether to fix it before release or > after. > I don't have preference FWIW. > CCed security team as well. > > [ Checklist ] > [ ] all changes are documented in the d/changelog > [ ] I reviewed all changes and I approve them > [ ] attach debdiff against the package in testing > > [ Other info ] > > That's just pre-announcement by Go upstream. So I really don't have diff yet. > > unblock golang-1.15/1.15.9-6 > -- Sebastian Ramacher
Processed: Re: Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
Processing control commands: > tags -1 moreinfo Bug #990825 [release.debian.org] [pre-approval] unblock: golang-1.15/1.15.9-6 Added tag(s) moreinfo. -- 990825: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990825 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: z...@debian.org, t...@security.debian.org Please unblock package golang-1.15 [ Reason ] Just received a pre-announcement[1] by Go upstream: > We plan to issue Go 1.16.6 and Go 1.15.14 on Monday, July 12. > These are minor releases that include security fixes to the standard library. [1] https://groups.google.com/g/golang-announce/c/JvWG9FUUYT0/m/VK1iHZosAgAJ Go upstream defines there levels for security issue, PUBLIC, PRIVATE, and URGENT. This is level PRIVATE. [ Impact ] [ Tests ] [ Risks ] It's security fix to standard library. So it needs binNMU for all Go packages. As it's near hard freeze, I'd like to ask whether to fix it before release or after. I don't have preference FWIW. CCed security team as well. [ Checklist ] [ ] all changes are documented in the d/changelog [ ] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] That's just pre-announcement by Go upstream. So I really don't have diff yet. unblock golang-1.15/1.15.9-6
