Bug#1036704: unblock: dhcpcd5/9.4.1-22

2023-05-24 Thread Shengjing Zhu
On Wed, May 24, 2023 at 9:57 PM Shengjing Zhu  wrote:
> [ Checklist ]
>   [x] attach debdiff against the package in testing

Sorry, missing attachment...


dhcpcd5_9.4.1-22.debdiff
Description: Binary data


Bug#1036704: unblock: dhcpcd5/9.4.1-22

2023-05-24 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dhcp...@packages.debian.org, z...@debian.org, 
martin-eric.rac...@iki.fi
Control: affects -1 + src:dhcpcd5

Please unblock package dhcpcd5

[ Reason ]
The packages fails to run on ppc64el (syscall is blocked by seccomp
policy).
And `dhcpcd -U` command also fails to run on all arch (newfstatat syscall
introduced by glibc is blocked by seccomp policy)

While trying to run autopkgtests to verify these issues, I find it contains
isolation-machine tests, which never run Debian infra, but are broken.
So this version contains fixes for autopkgtests too.

[ Impact ]
Without the unblock, the package is not functional entirely on ppc64el,
and one subcommand is not functional on all arch.

[ Tests ]
It has autopkgtests, but non-trival ones need isolation-machine.
I've run them on Ubuntu autopkgtest infra.

[ Risks ]
Code is trival and easy to review.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
None

unblock dhcpcd5/9.4.1-22



Bug#1036164: nmu: fcitx5-zhuyin_5.0.11-1

2023-05-16 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: fcitx5-zhu...@packages.debian.org, z...@debian.org
Control: affects -1 + src:fcitx5-zhuyin

nmu fcitx5-zhuyin_5.0.11-1 . ANY . unstable . -m "Rebuild with libpinyin/2.8.1 
(Closes: #1036163)"

There must be better way to track this binary file format, but I'm not sure
how to implement it.
binNMU might be the easiest way currently.



Bug#1036078: unblock: docker-registry/2.8.2+ds1-1

2023-05-14 Thread Shengjing Zhu
+0800
@@ -1,3 +1,14 @@
+docker-registry (2.8.2+ds1-1) unstable; urgency=medium
+
+  * Team upload
+  * New upstream version 2.8.2+ds1
++ CVE-2023-2253: Catalog API endpoint can lead to OOM via malicious user
+  input (Closes: #1035956)
+  * Drop patch merged by upstream
++ 0009-Fix-panic-in-inmemory-driver.patch
+
+ -- Shengjing Zhu   Sat, 13 May 2023 23:21:12 +0800
+
 docker-registry (2.8.1+ds1-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru -w 
docker-registry-2.8.1+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
 
docker-registry-2.8.2+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
--- 
docker-registry-2.8.1+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
2022-06-29 20:32:34.0 +0800
+++ 
docker-registry-2.8.2+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
2023-05-13 23:21:12.0 +0800
@@ -12,10 +12,10 @@
  1 file changed, 1 insertion(+)
 
 diff --git a/registry/handlers/api_test.go b/registry/handlers/api_test.go
-index 2d3edc7..a07184b 100644
+index bf037d4..207e167 100644
 --- a/registry/handlers/api_test.go
 +++ b/registry/handlers/api_test.go
-@@ -2468,6 +2468,7 @@ func createRepository(env *testEnv, t *testing.T, 
imageName string, tag string)
+@@ -2728,6 +2728,7 @@ func createRepository(env *testEnv, t *testing.T, 
imageName string, tag string)
  // Test mutation operations on a registry configured as a cache.  Ensure that 
they return
  // appropriate errors.
  func TestRegistryAsCacheMutationAPIs(t *testing.T) {
diff -Nru -w 
docker-registry-2.8.1+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
 
docker-registry-2.8.2+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
--- 
docker-registry-2.8.1+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
2022-06-29 20:32:34.0 +0800
+++ 
docker-registry-2.8.2+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
1970-01-01 08:00:00.0 +0800
@@ -1,23 +0,0 @@
-From: Shengjing Zhu 
-Date: Sun, 27 Mar 2022 19:38:07 +0800
-Subject: Fix panic in inmemory driver
-
-Forwarded: https://github.com/distribution/distribution/pull/3615

- registry/storage/driver/inmemory/mfs.go | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/registry/storage/driver/inmemory/mfs.go 
b/registry/storage/driver/inmemory/mfs.go
-index 9a2865f..24eeef9 100644
 a/registry/storage/driver/inmemory/mfs.go
-+++ b/registry/storage/driver/inmemory/mfs.go
-@@ -279,6 +279,9 @@ func (f *file) sectionReader(offset int64) io.Reader {
- }
- 
- func (f *file) ReadAt(p []byte, offset int64) (n int, err error) {
-+  if offset >= int64(len(f.data)) {
-+  return 0, io.EOF
-+  }
-   return copy(p, f.data[offset:]), nil
- }
- 
diff -Nru -w docker-registry-2.8.1+ds1/debian/patches/series 
docker-registry-2.8.2+ds1/debian/patches/series
--- docker-registry-2.8.1+ds1/debian/patches/series 2022-06-29 
20:32:34.0 +0800
+++ docker-registry-2.8.2+ds1/debian/patches/series 2023-05-13 
23:21:12.0 +0800
@@ -6,4 +6,3 @@
 0006-Skip-TestHTTPChecker.patch
 0007-Skip-TestRegistryAsCacheMutationAPIs.patch
 0008-Skip-flaky-TestGracefulShutdown-and-TestRegistrySupp.patch
-0009-Fix-panic-in-inmemory-driver.patch
diff -Nru -w docker-registry-2.8.1+ds1/.dockerignore 
docker-registry-2.8.2+ds1/.dockerignore
--- docker-registry-2.8.1+ds1/.dockerignore 1970-01-01 08:00:00.0 
+0800
+++ docker-registry-2.8.2+ds1/.dockerignore 2023-05-11 18:11:57.0 
+0800
@@ -0,0 +1 @@
+bin/
diff -Nru -w docker-registry-2.8.1+ds1/health/doc.go 
docker-registry-2.8.2+ds1/health/doc.go
--- docker-registry-2.8.1+ds1/health/doc.go 2022-03-09 01:52:36.0 
+0800
+++ docker-registry-2.8.2+ds1/health/doc.go 2023-05-11 18:11:57.0 
+0800
@@ -13,7 +13,7 @@
 // particularly useful for checks that verify upstream connectivity or
 // database status, since they might take a long time to return/timeout.
 //
-// Installing
+// # Installing
 //
 // To install health, just import it in your application:
 //
@@ -35,7 +35,7 @@
 // After importing these packages to your main application, you can start
 // registering checks.
 //
-// Registering Checks
+// # Registering Checks
 //
 // The recommended way of registering checks is using a periodic Check.
 // PeriodicChecks run on a certain schedule and asynchronously update the
@@ -84,7 +84,7 @@
 //   return Errors.new("This is an error!")
 //  }))
 //
-// Examples
+// # Examples
 //
 // You could also use the health checker mechanism to ensure your application
 // only comes up if certain conditions are met, or to allow the developer to
diff -Nru -w docker-registry-2.8.1+ds1/registry/api/v2/descriptors.go 
docker-registry-2.8.2+ds1/registry/api/v2/descriptors.go
--- docker-registry-2.8.1+ds1/registry/api/v2/descriptors.go2022-03-09 
01:52:36.0 +0800
+++ docker-registry-2.8.2+ds1/registry/api/v2/descriptors.go2023-05

Bug#1033976: [pre-approve] unblock: golang-1.19/1.19.8-2

2023-04-05 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: golang-1...@packages.debian.org, z...@debian.org
Control: affects -1 + src:golang-1.19

Please unblock package golang-1.19

[ Reason ]
Two upstream minor versions, fixing 5 CVEs

+ CVE-2023-24532: crypto/elliptic: incorrect P-256 ScalarMult and
  ScalarBaseMult results
+ CVE-2023-24537: go/parser: infinite loop in parsing
+ CVE-2023-24538: html/template: backticks not treated as string delimiters
+ CVE-2023-24534: net/http, net/textproto: denial of service from excessive
  memory allocation
+ CVE-2023-24536: net/http, net/textproto, mime/multipart: denial of
  service from excessive resource consumption

[ Impact ]

Several security issues in the Go standard libraries.

[ Tests ]
Besise the unittests upstream added in the new release, I have use the new
version to build some Go packages. And the result is good.

[ Risks ]
Toolchain package and no autopkgtest.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

  I attached the debdiff with
  filterdiff --exclude '*_test.go' --exclude '*_windows*' --exclude 
'*/testdata/*' \
--exclude '*/go.mod' --exclude '*/go.sum' --exclude '*/modules.txt'

[ Other info ]
It may be the last golang-1.19 version to be uploaded during freeze.
The next release is expected (if no urgent CVE happens) to be May, which
is probably hard-freeze time.

unblock golang-1.19/1.19.8-2
diff -Nru golang-1.19-1.19.6/debian/changelog 
golang-1.19-1.19.8/debian/changelog
--- golang-1.19-1.19.6/debian/changelog 2023-02-17 17:56:44.0 +0800
+++ golang-1.19-1.19.8/debian/changelog 2023-04-05 02:15:56.0 +0800
@@ -1,3 +1,25 @@
+golang-1.19 (1.19.8-1) experimental; urgency=medium
+
+  * Team upload
+  * New upstream version 1.19.8
++ CVE-2023-24537: go/parser: infinite loop in parsing
++ CVE-2023-24538: html/template: backticks not treated as string delimiters
++ CVE-2023-24534: net/http, net/textproto: denial of service from excessive
+  memory allocation
++ CVE-2023-24536: net/http, net/textproto, mime/multipart: denial of
+  service from excessive resource consumption
+
+ -- Shengjing Zhu   Wed, 05 Apr 2023 02:15:56 +0800
+
+golang-1.19 (1.19.7-1) experimental; urgency=medium
+
+  * Team upload
+  * New upstream version 1.19.7
++ CVE-2023-24532: crypto/elliptic: incorrect P-256 ScalarMult and
+  ScalarBaseMult results
+
+ -- Shengjing Zhu   Wed, 08 Mar 2023 13:54:08 +0800
+
 golang-1.19 (1.19.6-2) unstable; urgency=medium
 
   * Team upload
diff -Nru golang-1.19-1.19.6/src/cmd/go/internal/work/exec.go 
golang-1.19-1.19.8/src/cmd/go/internal/work/exec.go
--- golang-1.19-1.19.6/src/cmd/go/internal/work/exec.go 2023-02-14 
01:38:43.0 +0800
+++ golang-1.19-1.19.8/src/cmd/go/internal/work/exec.go 2023-03-30 
05:15:17.0 +0800
@@ -2764,6 +2764,36 @@
}
}
 
+   // Scrutinize CFLAGS and related for flags that might cause
+   // problems if we are using internal linking (for example, use of
+   // plugins, LTO, etc) by calling a helper routine that builds on
+   // the existing CGO flags allow-lists. If we see anything
+   // suspicious, emit a special token file "preferlinkext" (known to
+   // the linker) in the object file to signal the that it should not
+   // try to link internally and should revert to external linking.
+   // The token we pass is a suggestion, not a mandate; if a user is
+   // explicitly asking for a specific linkmode via the "-linkmode"
+   // flag, the token will be ignored. NB: in theory we could ditch
+   // the token approach and just pass a flag to the linker when we
+   // eventually invoke it, and the linker flag could then be
+   // documented (although coming up with a simple explanation of the
+   // flag might be challenging). For more context see issues #58619,
+   // #58620, and #58848.
+   flagSources := []string{"CGO_CFLAGS", "CGO_CXXFLAGS", "CGO_FFLAGS"}
+   flagLists := [][]string{cgoCFLAGS, cgoCXXFLAGS, cgoFFLAGS}
+   if flagsNotCompatibleWithInternalLinking(flagSources, flagLists) {
+   tokenFile := objdir + "preferlinkext"
+   if cfg.BuildN || cfg.BuildX {
+   b.Showcmd("", "echo > %s", tokenFile)
+   }
+   if !cfg.BuildN {
+   if err := os.WriteFile(tokenFile, nil, 0666); err != 
nil {
+   return nil, nil, err
+   }
+   }
+   outObj = append(outObj, tokenFile)
+   }
+
if cfg.BuildMSan {
cgoCFLAGS = append([]string{"-fsanitize=memory"}, cgoCFLAGS...)
cgoLDFLAGS 

Bug#1032004: nmu: packages built by golang-1.15

2023-02-26 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: z...@debian.org

Hi,

Maybe there's bug in the scripts to rebuild for outdated Built-Using.
There are still packages built by golang-1.15.

$ grep-dctrl -r -s Package -F Built-Using 'golang-1.1[0-8]' 
/var/lib/apt/lists/*debian_dists_testing_main_binary-amd64_Packages
Package: codesearch
Package: ffuf
Package: tmpl
Package: fernet-go
Package: blueprint-tools
Package: cli-spinner
Package: ripper
Package: golang-statik
Package: golang-github-rsc-devweb
Package: goxkcdpwgen
Package: heartbleeder
Package: hellfire
Package: opensmtpd-filter-rspamd
Package: opensmtpd-filter-senderscore



Bug#1031630: bullseye-pu: package containerd/1.4.13~ds1-1~deb11u4

2023-02-19 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: contain...@packages.debian.org, t...@security.debian.org, 
z...@debian.org
Control: affects -1 + src:containerd

[ Reason ]

Backport patches for 2 CVE:

* CVE-2023-25153: OCI image importer memory exhaustion
* CVE-2023-25173: Supplementary groups are not set up properly

[ Impact ]

[ Tests ]

CVE-2023-25153 is simple fix without test.
CVE-2023-25173 is covered by some unit tests and I've tested
it on a Kubernetes cluster.

[ Risks ]

The patch for CVE-2023-25153 is simple and cherry-picked from upstream
1.5 branch directly. It should not be risky.

The patch for CVE-2023-25173 is difficult to backport (many conflicts
when apply patches from 1.5 branch).
So I have rewrite it based on the commits on 1.5 branch. Especially this
commit https://github.com/containerd/containerd/commit/a62c38bf.
The 1.4.x package doesn't include CRI integration tests so I have to test
it by hand on a real Kubernetes cluster. In upstream a62c38bf commit message,
they have shown the tests cases. So I use them to verify on Kubernetes.

With containerd/1.4.13~ds1-1~deb11u3, the log is

NAMESPACE NAMEREADY   STATUS RESTARTS AGE
default   test-group-add-1-group-add-1234 0/1 Error  014m
default   test-no-option  0/1 Error  014m
default   test-user-1234  0/1 Error  014m
default   test-user-1234-1234 0/1 Error  014m
default   test-user-1234-group-add-1234   0/1 Error  014m

The container output is like

# kubectl logs test-no-option
+ id
+ '[' 'uid=0(root) gid=0(root) groups=10(wheel)' '=' 'uid=0(root) gid=0(root) 
groups=0(root),10(wheel)' ]

With containerd/1.4.13~ds1-1~deb11u4, the log is

NAMESPACE NAMEREADY   STATUS  RESTARTS  AGE
default   test-group-add-1-group-add-1234 0/1 Completed   0 4s
default   test-no-option  0/1 Completed   0 4s
default   test-user-1234  0/1 Completed   0 4s
default   test-user-1234-1234 0/1 Completed   0 4s
default   test-user-1234-group-add-1234   0/1 Completed   0 4s

The container output is like

# kubectl logs test-no-option
+ id
+ '[' 'uid=0(root) gid=0(root) groups=0(root),10(wheel)' '=' 'uid=0(root) 
gid=0(root) groups=0(root),10(wheel)' ]

It has passed the upstream tests.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

See attachment.

[ Other info ]

No
diff -Nru containerd-1.4.13~ds1/debian/changelog 
containerd-1.4.13~ds1/debian/changelog
--- containerd-1.4.13~ds1/debian/changelog  2022-12-08 10:24:34.0 
+0800
+++ containerd-1.4.13~ds1/debian/changelog  2023-02-17 23:11:26.0 
+0800
@@ -1,3 +1,10 @@
+containerd (1.4.13~ds1-1~deb11u4) bullseye; urgency=medium
+
+  * CVE-2023-25153: OCI image importer memory exhaustion
+  * CVE-2023-25173: Supplementary groups are not set up properly
+
+ -- Shengjing Zhu   Fri, 17 Feb 2023 23:11:26 +0800
+
 containerd (1.4.13~ds1-1~deb11u3) bullseye; urgency=medium
 
   * CVE-2022-23471: CRI plugin: Fix goroutine leak during Exec
diff -Nru containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch 
containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
--- containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch  
1970-01-01 08:00:00.0 +0800
+++ containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch  
2023-02-17 23:11:26.0 +0800
@@ -0,0 +1,41 @@
+From: Samuel Karp 
+Date: Thu, 12 Jan 2023 18:06:41 -0800
+Subject: CVE-2023-25153
+
+Origin: backport, https://github.com/containerd/containerd/commit/959e1cf9
+---
+ images/archive/importer.go | 13 +++--
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/images/archive/importer.go b/images/archive/importer.go
+index 2d04658..f24ab87 100644
+--- a/images/archive/importer.go
 b/images/archive/importer.go
+@@ -24,7 +24,6 @@ import (
+   "encoding/json"
+   "fmt"
+   "io"
+-  "io/ioutil"
+   "path"
+ 
+   "github.com/containerd/containerd/archive/compression"
+@@ -222,12 +221,14 @@ func ImportIndex(ctx context.Context, store 
content.Store, reader io.Reader, opt
+   return writeManifest(ctx, store, idx, ocispec.MediaTypeImageIndex)
+ }
+ 
++const (
++  kib   = 1024
++  mib   = 1024 * kib
++  jsonLimit = 20 * mib
++)
++
+ func onUntarJSON(r io.Reader, j interface{}) error {
+-  b, err := ioutil.ReadAll(r)
+-  if err != nil {
+-  return err
+-  }
+-  return json.Unmarshal(b, j)
++  return json.NewDecoder(io.Li

Bug#1031408: unblock: containerd/1.6.18~ds1-1

2023-02-16 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: contain...@packages.debian.org, publicsuf...@packages.debian.org, 
z...@debian.org
Control: affects -1 + src:containerd src:golang-golang-x-net src:publicsuffix

Please age package containerd

[ Reason ]

* New upstream version 1.6.18~ds1
  + CVE-2023-25153: OCI image importer memory exhaustion
  + CVE-2023-25173: Supplementary groups are not set up properly
* Install cni-bridge-fp to /usr/lib/cni in autopkgtest

[ Impact ]

Delay of security fix.

[ Tests ]

This package has integration tests in autopkgtest.
Though there are known failures cri-integration (one of the integrations).
But it's not regression. 1.6.17~ds1-1 has 5 failed test cases. I've fixed the
tests scripts in 1.6.18~ds1-1, and it has only 1 failed test case now.

[ Risks ]

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]

To age containerd, the following packages need age as well.
+ golang-golang-x-net/1:0.7.0+dfsg-1

  * New upstream version 0.7.0
 + CVE-2022-41723: http2/hpack: avoid quadratic complexity in hpack decoding

+ publicsuffix/20230209.2326-1

  * new upstream version



Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

2023-02-15 Thread Shengjing Zhu
On Wed, Feb 15, 2023 at 9:23 PM Adrian Bunk  wrote:
> > And regarding make golang-go the first alternative, currently we have:
> > + Build-Depends golang-any | golang-go | gccgo
> > + golang-any Depends golang-go | gccgo-go
> > Is there anything we can improve for aspcud resolver?
>
> The resolver is not to blame for a bug in the build dependencies.
>
> In unstable and experimental only the first alternative is considered,
> therefore
>   Build-Depends: golang-go | ...
> would instruct the resolver to install golang-go.
>
> Safest would be to not offer any alternatives in the build dependencies,
> instead create a profile for bootstrapping golang-go from gccgo.

I now created #1031351, which I think is the underlying problem.
Let's keep discussion there and reduce the noise in this unblock request.

-- 
Shengjing Zhu



Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

2023-02-15 Thread Shengjing Zhu
On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu  wrote:
>
> On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> >
> > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > >...
> > > The package currently FTBFS on i386/experimental but it won't be problem 
> > > on
> > > unstable.
> > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > which has a bug https://github.com/golang/go/issues/51850.
> > > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > > bootstrap.
> > >...
> >
> > I gave it back on the affected architectures with an extra-depends on
> > golang-go, which confirmed that the package builds there.
> >
> > But relying on resolver behaviour is incredibly fragile, please make
> > golang-go the only (or at least the first) alternative in the build
> > dependencies.
>
> In theory gccgo should be able to bootstrap golang-go.
> And we do use gccgo to build golang-go on ppc64, and haven't met any
> problem so far.
> The new affected arch is because of lack of exercise, so nobody is
> aware of this.
> Now they are tracked at #1031349.
>

And regarding make golang-go the first alternative, currently we have:
+ Build-Depends golang-any | golang-go | gccgo
+ golang-any Depends golang-go | gccgo-go
Is there anything we can improve for aspcud resolver?

-- 
Shengjing Zhu



Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

2023-02-15 Thread Shengjing Zhu
On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
>
> On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> >...
> > The package currently FTBFS on i386/experimental but it won't be problem on
> > unstable.
> > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > which has a bug https://github.com/golang/go/issues/51850.
> > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > bootstrap.
> >...
>
> I gave it back on the affected architectures with an extra-depends on
> golang-go, which confirmed that the package builds there.
>
> But relying on resolver behaviour is incredibly fragile, please make
> golang-go the only (or at least the first) alternative in the build
> dependencies.

In theory gccgo should be able to bootstrap golang-go.
And we do use gccgo to build golang-go on ppc64, and haven't met any
problem so far.
The new affected arch is because of lack of exercise, so nobody is
aware of this.
Now they are tracked at #1031349.

--
Shengjing Zhu



Bug#1028452: unblock: golang-1.19/1.19.5-1

2023-01-19 Thread Shengjing Zhu
On Thu, Jan 19, 2023 at 6:01 PM Sebastiaan Couwenberg
 wrote:
>
> On 1/19/23 10:26, Shengjing Zhu wrote:
> > On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers  wrote:
> >>> The history record for golang point release doesn't show regressions.
> >>
> >> That's good, are you talking about point release in general, or releases
> >> to stable?
> >
> > Missed this one. I'm talking about the upstream point release. We
> > haven't met regression so far when we update golang-1.x packages in
> > unstable.
>
> I remember 1.18.4 introducing a regression that broke icingadb:
>
>   https://bugs.debian.org/1015088
>

Oh! you're right. I do forget this.

However it happens when people are too eager to use "generic" in Go,
when it's said by upstream that "generic" is not stable in Go1.18.
But yeah it's still breakage in point release. So upstream decides[1]
not fixing any "generic" bugs in later Go1.18 point release.

[1] https://github.com/golang/go/issues/53852#issuecomment-1184912669

-- 
Shengjing Zhu



Bug#1028452: unblock: golang-1.19/1.19.5-1

2023-01-19 Thread Shengjing Zhu
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers  wrote:
> > The history record for golang point release doesn't show regressions.
>
> That's good, are you talking about point release in general, or releases
> to stable?

Missed this one. I'm talking about the upstream point release. We
haven't met regression so far when we update golang-1.x packages in
unstable.

-- 
Shengjing Zhu



Bug#1028452: unblock: golang-1.19/1.19.5-1

2023-01-19 Thread Shengjing Zhu
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers  wrote:
>
> Dear Shengjing,
>
> On 11-01-2023 09:32, Shengjing Zhu wrote:
> > This is a point release for golang 1.19 which happens today.
>
> Where can I find the upstream policy on point release updates? Or, if
> not documented in one place, can you describe it? Is 1.19 a bug-fix only
> branch already, or are new feature appearing in point release updates
> too? In other words, help us assess the risk.
>

It's documented at https://go.dev/doc/devel/release#policy
Yes, only bug fix. Usually there are only a few commits in each point release.

> > [ Impact ]
> >
> > If we can be closer to upstream latest release, it will be easier to 
> > backport
> > security patch for bookworm.
>
> That holds for every package, but we're now frozen, so we need to balance.
>
> > The history record for golang point release doesn't show regressions.
>
> That's good, are you talking about point release in general, or releases
> to stable? For security updates in Debian stable releases, have you also
> been uploading new point releases, or did you pick patches every time?
>

For bullseye, I uploaded the last point release of Go1.15.
See 
https://tracker.debian.org/news/1284112/accepted-golang-115-11515-1deb11u1-source-into-proposed-updates-stable-new-proposed-updates/

It's a bit sad that upstream support is very short, which is 1 year
for a major version. For Go1.19, it will EOL on 2023 Aug, which is
very close to bookworm release. So I'll try to upload the last point
release of Go1.19 in the 12.1 or 12.2 cycle. After that we would only
backport security patches back.

-- 
Shengjing Zhu



Bug#1028452: unblock: golang-1.19/1.19.5-1

2023-01-18 Thread Shengjing Zhu
Control: reopen -1
Control: retitle -1 [pre-approval] unblock: golang-1.19/1.19.5-1

Hi,

On Thu, Jan 19, 2023 at 3:45 AM Debian Bug Tracking System

> On Thu, 12 Jan 2023 16:28:51 +0100 Paul Gevers  wrote:
> > But golang-1.19 is in sync between unstable and testing.
>
> Closing.
>
> Paul

Sorry not to make it clear. It's a pre-approval request.

-- 
Shengjing Zhu



Bug#1028452: unblock: golang-1.19/1.19.5-1

2023-01-12 Thread Shengjing Zhu
On Thu, Jan 12, 2023 at 11:28 PM Paul Gevers  wrote:
>
> Hi Shengjing,
>
> On 11-01-2023 09:32, Shengjing Zhu wrote:
> > Please unblock package golang-1.19
>
> But golang-1.19 is in sync between unstable and testing.
>

Because I haven't uploaded. This unblock request is for 1.19.5-1,
while unstable has 1.19.4-1.

> > This is a point release for golang 1.19 which happens today.
>
> I suspect you're asking for an exception as golang is on our toolchain
> list [0]? In *my* interpretation of the freeze date, you have until
> today to upload. (Yes, I know others in the team have argued differently
> on irc, we'll need to clarify that better next round). So, if you're
> quick you didn't even *need* to ask for an exception if you otherwise
> meet the criteria [1]. Please check and if you meet them, go ahead if
> you upload happens within 2 days.
>

Yes, for toolchain freeze. golang-1.19 doesn't have autopkgtest for
itself. So it will take 5 days to migrate. So it's already late for me
to upload. As I read the backlog on irc, when someone asks for rust
update, they are told the package should be in testing when the freeze
starts.

> > + Many Go packages still record Built-Using field, so this upload will 
> > block >Go packages from migration. Release team need to rebuild outdated
> Built-Using.
>
> I don't think it blocks migration (but maybe I'm misunderstanding what
> you mean). But why hasn't this been fixed by now? Do you know if bugs
> have been filed?
>

I mean if I upload golang-1.19 to unstable, and if it's unapproved to
migrate to testing, then any Go packages built with
golang-1.19/unstable will be blocked on migration. Since they have
Built-Using of golang-1.19/unstable, and must be migrated after
golang-1.19.

And for abuse of Built-Using field, dpkg has added a new field, which
is called Static-Built-Using. Anthony Fok has implemented it in
dh-golang, and has migrated some packages to use that new field. But
this is not something that can be automated. So all Go packages need
manual update.
There's no call for doing this inside the team yet. That's slow in progress.

> >The Go point release or security release may happen several times during 
> > freeze.
> >What kind of release can be expected to be unblocked during freeze?
>
> Again, it's written in [1]. Please let me know if there's something unclear.
>
> But this bug report triggered me: did the golang security situation
> already improved during this release cycle. I may be misremembering, but
> I recall the problems on the security archive side haven't been fixed,
> have they?
>

For some reference, I did several security updates for golang-1.15 for
bullseye, but we didn't rebuild other packages. These security updates
are not urgent enough anyway.
And others also update some Go packages for bullseye. In general, we
just do the usual update for stable release.

As for the security archive, IIRC, for bullseye, the security team did
 need to ask ftp-master to copy some individual packages manually. I'm
not sure how it is going now. But given the low update frequency I
overseved for bullseye, probably that works.

-- 
Shengjing Zhu



Bug#1028452: unblock: golang-1.19/1.19.5-1

2023-01-11 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: golang-1...@packages.debian.org, z...@debian.org
Control: affects -1 + src:golang-1.19

Please unblock package golang-1.19

This is a point release for golang 1.19 which happens today.

[ Reason ]

Update the latest release.

[ Impact ]

If we can be closer to upstream latest release, it will be easier to backport
security patch for bookworm.

[ Tests ]

Upstream does well tests. And I have tried to use the new version to compile
some programs.

[ Risks ]

The history record for golang point release doesn't show regressions.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

+ This package doesn't have autopkgtest.
+ Many Go packages still record Built-Using field, so this upload will block
  Go packages from migration. Release team need to rebuild outdated Built-Using.

  The Go point release or security release may happen several times during 
freeze.
  What kind of release can be expected to be unblocked during freeze?

unblock golang-1.19/1.19.5-1
diff -Nru golang-1.19-1.19.4/debian/changelog 
golang-1.19-1.19.5/debian/changelog
--- golang-1.19-1.19.4/debian/changelog 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/changelog 2023-01-11 15:35:00.0 +0800
@@ -1,3 +1,13 @@
+golang-1.19 (1.19.5-1) unstable; urgency=medium
+
+  * Team upload
+  * Add NO_PNG_PKG_MANGLE to prevent mangling testdata.
+This is Ubuntu specific behaviour so they can sync the package without
+vendor patch.
+  * New upstream version 1.19.5
+
+ -- Shengjing Zhu   Wed, 11 Jan 2023 15:35:00 +0800
+
 golang-1.19 (1.19.4-1) unstable; urgency=medium
 
   * New upstream version 1.19.4
diff -Nru golang-1.19-1.19.4/debian/rules golang-1.19-1.19.5/debian/rules
--- golang-1.19-1.19.4/debian/rules 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/rules 2023-01-11 15:35:00.0 +0800
@@ -7,6 +7,9 @@
 # for DEB_VERSION_UPSTREAM
 include /usr/share/dpkg/pkg-info.mk
 
+# Ubuntu mangles png files by default, which can break the testdata.
+export NO_PNG_PKG_MANGLE := 1
+
 export GOVER := $(shell echo $(DEB_VERSION_UPSTREAM) | grep -oP 
'^([0-9]+\.[0-9]+)')
 
 export GOROOT := $(CURDIR)
diff -Nru golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go 
golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go
--- golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go 2022-12-02 
02:12:53.0 +0800
+++ golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go 2023-01-10 
06:38:01.0 +0800
@@ -329,30 +329,46 @@
if err != nil {
return fmt.Errorf("unable to find dlltool path: 
%v\n%s\n", err, out)
}
-   args := []string{strings.TrimSpace(string(out)), "-D", args[6], 
"-l", libgoname, "-d", "libgo.def"}
-
-   // This is an unfortunate workaround for 
https://github.com/mstorsjo/llvm-mingw/issues/205 in which
-   // we basically reimplement the contents of the dlltool.sh 
wrapper: https://git.io/JZFlU
-   dlltoolContents, err := os.ReadFile(args[0])
-   if err != nil {
-   return fmt.Errorf("unable to read dlltool: %v\n", err)
+   dlltoolpath := strings.TrimSpace(string(out))
+   if filepath.Ext(dlltoolpath) == "" {
+   // Some compilers report slash-separated paths without 
extensions
+   // instead of ordinary Windows paths.
+   // Try to find the canonical name for the path.
+   if lp, err := exec.LookPath(dlltoolpath); err == nil {
+   dlltoolpath = lp
+   }
}
-   if bytes.HasPrefix(dlltoolContents, []byte("#!/bin/sh")) && 
bytes.Contains(dlltoolContents, []byte("llvm-dlltool")) {
-   base, name := filepath.Split(args[0])
-   args[0] = filepath.Join(base, "llvm-dlltool")
-   var machine string
-   switch prefix, _, _ := strings.Cut(name, "-"); prefix {
-   case "i686":
-   machine = "i386"
-   case "x86_64":
-   machine = "i386:x86-64"
-   case "armv7":
-   machine = "arm"
-   case "aarch64":
-   machine = "arm64"
+
+   args := []string{dlltoolpath, "-D", args[6], "-l", libgoname, 
"-d", "libgo.def"

Bug#1025754: bullseye-pu: package containerd/1.4.13~ds1-1~deb11u3

2022-12-08 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: contain...@packages.debian.org, z...@debian.org
Control: affects -1 + src:containerd

[ Reason ]

Backport patch for CVE-2022-23471.

https://github.com/containerd/containerd/security/advisories/GHSA-2qjp-425j-52j9

> A bug was found in containerd's CRI implementation where a user can exhaust
> memory on the host.

[ Impact ]


[ Tests ]

No new test is added, but the patch is simple and easy to review.
It is taken from upstream 1.5 release branch without modification.

[ Risks ]

Code is trivial.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

See attachment

[ Other info ]

No
diff -Nru containerd-1.4.13~ds1/debian/changelog 
containerd-1.4.13~ds1/debian/changelog
--- containerd-1.4.13~ds1/debian/changelog  2022-06-07 03:07:20.0 
+0800
+++ containerd-1.4.13~ds1/debian/changelog  2022-12-08 10:24:34.0 
+0800
@@ -1,3 +1,9 @@
+containerd (1.4.13~ds1-1~deb11u3) bullseye; urgency=medium
+
+  * CVE-2022-23471: CRI plugin: Fix goroutine leak during Exec
+
+ -- Shengjing Zhu   Thu, 08 Dec 2022 10:24:34 +0800
+
 containerd (1.4.13~ds1-1~deb11u2) bullseye-security; urgency=high
 
   * CVE-2022-31030: CRI plugin: Host memory exhaustion through ExecSync
diff -Nru containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch 
containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch
--- containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch  
1970-01-01 08:00:00.0 +0800
+++ containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch  
2022-12-08 10:24:34.0 +0800
@@ -0,0 +1,56 @@
+From: Danny Canter 
+Date: Mon, 28 Nov 2022 14:45:34 -0800
+Subject: CVE-2022-23471
+
+Origin: backport, https://github.com/containerd/containerd/commit/6cd11527
+---
+ .../cri/pkg/streaming/remotecommand/httpstream.go | 15 ---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git 
a/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go 
b/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go
+index 0417a1a..9177fa7 100644
+--- 
a/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go
 
b/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go
+@@ -33,6 +33,7 @@ limitations under the License.
+ package remotecommand
+ 
+ import (
++  gocontext "context"
+   "encoding/json"
+   "errors"
+   "fmt"
+@@ -132,7 +133,7 @@ func createStreams(req *http.Request, w 
http.ResponseWriter, opts *Options, supp
+ 
+   if ctx.resizeStream != nil {
+   ctx.resizeChan = make(chan remotecommand.TerminalSize)
+-  go handleResizeEvents(ctx.resizeStream, ctx.resizeChan)
++  go handleResizeEvents(req.Context(), ctx.resizeStream, 
ctx.resizeChan)
+   }
+ 
+   return ctx, true
+@@ -425,7 +426,7 @@ WaitForStreams:
+ // supportsTerminalResizing returns false because v1ProtocolHandler doesn't 
support it.
+ func (*v1ProtocolHandler) supportsTerminalResizing() bool { return false }
+ 
+-func handleResizeEvents(stream io.Reader, channel chan<- 
remotecommand.TerminalSize) {
++func handleResizeEvents(ctx gocontext.Context, stream io.Reader, channel 
chan<- remotecommand.TerminalSize) {
+   defer runtime.HandleCrash()
+   defer close(channel)
+ 
+@@ -435,7 +436,15 @@ func handleResizeEvents(stream io.Reader, channel chan<- 
remotecommand.TerminalS
+   if err := decoder.Decode(); err != nil {
+   break
+   }
+-  channel <- size
++
++  select {
++  case channel <- size:
++  case <-ctx.Done():
++  // To avoid leaking this routine, exit if the http 
request finishes. This path
++  // would generally be hit if starting the process fails 
and nothing is started to
++  // ingest these resize events.
++  return
++  }
+   }
+ }
+ 
diff -Nru containerd-1.4.13~ds1/debian/patches/series 
containerd-1.4.13~ds1/debian/patches/series
--- containerd-1.4.13~ds1/debian/patches/series 2022-06-07 03:07:20.0 
+0800
+++ containerd-1.4.13~ds1/debian/patches/series 2022-12-08 10:24:34.0 
+0800
@@ -8,3 +8,4 @@
 0008-Add-RPi1-RPi0-workaround.patch
 0009-CVE-2022-31030.patch
 0010-CVE-2022-24769.patch
+0011-CVE-2022-23471.patch


Bug#1024385: bullseye-pu: package openvpn-auth-radius/2.1-7+deb11u1

2022-11-18 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: z...@debian.org

[ Reason ]

Fix #954264: Support for verify-client-cert openvpn 2.4 directive.

[ Impact ]
The current version doesn't work with openvpn version (2.5.1) in stable.
The old workaround only works for openvpn 2.4.

[ Tests ]
On #954264, one reporter is someone I know and trust, and he has verified on
his vpn server.
But I don't have a openvpn server with radius, so I only reviewed the code.

[ Risks ]
The patch is trivial and easy to review.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

+ if (param == "verify-client-cert")
+ {
+ this->deletechars();
+ if (line != 
"verify-client-certrequired")
+ {
+ 
this->clientcertnotrequired=true;
+ }
+ }

Add a new check for directive "verify-client-cert".

[ Other info ]
No.
diff -Nru openvpn-auth-radius-2.1/debian/changelog 
openvpn-auth-radius-2.1/debian/changelog
--- openvpn-auth-radius-2.1/debian/changelog2018-10-28 20:10:22.0 
+0800
+++ openvpn-auth-radius-2.1/debian/changelog2022-11-19 00:59:14.0 
+0800
@@ -1,3 +1,10 @@
+openvpn-auth-radius (2.1-7+deb11u1) bullseye; urgency=medium
+
+  * Add patch to support verify-client-cert directive in openvpn 2.4
+    (Closes: #954264)
+
+ -- Shengjing Zhu   Sat, 19 Nov 2022 00:59:14 +0800
+
 openvpn-auth-radius (2.1-7) unstable; urgency=low
 
   * QA upload.
diff -Nru 
openvpn-auth-radius-2.1/debian/patches/0006-Support-verify-client-cert-directive-in-openvpn-2.4.patch
 
openvpn-auth-radius-2.1/debian/patches/0006-Support-verify-client-cert-directive-in-openvpn-2.4.patch
--- 
openvpn-auth-radius-2.1/debian/patches/0006-Support-verify-client-cert-directive-in-openvpn-2.4.patch
   1970-01-01 08:00:00.0 +0800
+++ 
openvpn-auth-radius-2.1/debian/patches/0006-Support-verify-client-cert-directive-in-openvpn-2.4.patch
   2022-11-19 00:59:14.0 +0800
@@ -0,0 +1,29 @@
+From: Shengjing Zhu 
+Date: Sat, 12 Nov 2022 19:25:57 +0800
+Subject: Support verify-client-cert directive in openvpn 2.4
+
+Bug-Debian: #954264
+Forwarded: no
+---
+ Config.cpp | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/Config.cpp b/Config.cpp
+index b600fab..d914818 100644
+--- a/Config.cpp
 b/Config.cpp
+@@ -180,6 +180,14 @@ int Config::parseConfigFile(const char * configfile)
+ 
this->clientcertnotrequired=true;
+ }
+ }
++if (param == "verify-client-cert")
++{
++this->deletechars();
++if (line != 
"verify-client-certrequired")
++{
++
this->clientcertnotrequired=true;
++}
++}
+ if (param == 
"username-as-common-name")
+ {
+ this->deletechars();
diff -Nru openvpn-auth-radius-2.1/debian/patches/series 
openvpn-auth-radius-2.1/debian/patches/series
--- openvpn-auth-radius-2.1/debian/patches/series   2018-10-28 
18:45:40.0 +0800
+++ openvpn-auth-radius-2.1/debian/patches/series   2022-11-19 
00:59:14.0 +0800
@@ -3,3 +3,4 @@
 30_build-with-debug-symbols.diff
 35_verbose_built.diff
 40_use_cppflags.diff
+0006-Support-verify-client-cert-directive-in-openvpn-2.4.patch


Bug#1016418: transition: fmtlib

2022-08-16 Thread Shengjing Zhu
On Wed, Aug 17, 2022 at 3:07 AM Sebastian Ramacher  wrote:
>
> On 2022-08-15 20:35:49 +0800, Shengjing Zhu wrote:
> > CC spdlog maintainer as well.
> >
> > On Mon, Aug 15, 2022 at 01:45:32PM +0200, Sebastian Ramacher wrote:
> > > Let's note hide spdlog's ABI breakage that is unreleated to the fmtlib
> > > transition. Please fix this issue first and remove the moreinfo tag once
> > > that's done.
> >
> > What's your suggestions to fix the spdlog ABI breakage?
>
> The ABI breakage was caused by adding a new argument to some functions
> with a default argument. This could be fixed by keeping the old
> functions around.
>

TBH, given libspdlog1.10 is in experimental, I feel it's more correct
to just do a spdlog transition.

-- 
Shengjing Zhu



Bug#1017412: transition: spdlog

2022-08-15 Thread Shengjing Zhu
On Tue, Aug 16, 2022 at 2:18 AM Shengjing Zhu  wrote:
> Ben file:
>
> title = "spdlog";
> is_affected = .depends ~ "libspdlog1" | .depends ~ "libspdlog1.10";
> is_good = .depends ~ "libspdlog1.10";
> is_bad = .depends ~ "libspdlog1";

I'm not sure how ben handles virtual package.

Maybe it should be libspdlog1-fmt8 vs libspdlog1.10-fmt8.

-- 
Shengjing Zhu



Bug#1017412: transition: spdlog

2022-08-15 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: z...@debian.org, debian-med-packag...@lists.alioth.debian.org

Ben file:

title = "spdlog";
is_affected = .depends ~ "libspdlog1" | .depends ~ "libspdlog1.10";
is_good = .depends ~ "libspdlog1.10";
is_bad = .depends ~ "libspdlog1";

As per #1016418 (transition: fmtlib), #1015742 (libspdlog1: ABI breakage
without SONAME bump), I have bumped spdlog SOVERSION to 1.10, which follows
upstream upcoming changes in next release, though we have diverted the
SOVERSION for spdlog/1.10.

PS. this binary-NEW package is accepted really quickly by ftp-master.



Bug#1016418: transition: fmtlib

2022-08-15 Thread Shengjing Zhu
On Mon, Aug 15, 2022 at 8:36 PM Shengjing Zhu  wrote:
>
> CC spdlog maintainer as well.
>
> On Mon, Aug 15, 2022 at 01:45:32PM +0200, Sebastian Ramacher wrote:
> > Let's note hide spdlog's ABI breakage that is unreleated to the fmtlib
> > transition. Please fix this issue first and remove the moreinfo tag once
> > that's done.
>
> What's your suggestions to fix the spdlog ABI breakage?
>
> Currently,
>
> + spdlog/1.9 ftbfs with fmtlib/9
> + Upstream doesn't want to fix the ABI breakage in spdlog/1.10, the opening
>   issue is closed without fix.
>
> Solutions?
>
> + revert spdlog to 1.9 and let it use a embedded copy of fmtlib, so it won't
>   block fmtlib/9 transition.

This seems much more complicated since packages may use spdlog and fmt together.

>
>   But I think it needs to use soversion libspdlog1, not libspdlog1-fmt8 as 
> well?
>
> + bump spdlog so version in Debian only without coordination from upstream.
>
>   For example, -> libspdlog1.10-fmt8
>

So I will upload NMU to bump spdlog soversion to 1.10.

It's unfortunate that we diverted from upstream with the soversion.
But we'll align with upstream once spdlog 1.11 is released.

@spdlog maintainer, if you disagree with this, there is still enough
time to retract my NMU since it hits the NEW queue.

> + kick spdlog out of testing.

This is impossible as spdlog is a key package.

-- 
Shengjing Zhu



Bug#1016418: transition: fmtlib

2022-08-15 Thread Shengjing Zhu
CC spdlog maintainer as well.

On Mon, Aug 15, 2022 at 01:45:32PM +0200, Sebastian Ramacher wrote:
> Let's note hide spdlog's ABI breakage that is unreleated to the fmtlib
> transition. Please fix this issue first and remove the moreinfo tag once
> that's done.

What's your suggestions to fix the spdlog ABI breakage?

Currently,

+ spdlog/1.9 ftbfs with fmtlib/9
+ Upstream doesn't want to fix the ABI breakage in spdlog/1.10, the opening
  issue is closed without fix.

Solutions?

+ revert spdlog to 1.9 and let it use a embedded copy of fmtlib, so it won't
  block fmtlib/9 transition.

  But I think it needs to use soversion libspdlog1, not libspdlog1-fmt8 as well?

+ bump spdlog so version in Debian only without coordination from upstream.

  For example, -> libspdlog1.10-fmt8

+ kick spdlog out of testing.



Bug#1016418: transition: fmtlib

2022-07-31 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: z...@debian.org

Ben file:

title = "fmtlib";
is_affected = .depends ~ "libfmt8" | .depends ~ "libfmt9";
is_good = .depends ~ "libfmt9";
is_bad = .depends ~ "libfmt8";

fmtlib 9 has been release for a while, I'd like to start the transition.

I have built the rerverse-depends, and all ftbfs bugs have been filed.
See the affected packages in 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=fmtlib

Most packages have been fixed, or fixed-upstream, or have patches.

The left packages are
+ #1014677 src:opendht, I think the root cause is restinio, so I will re-test
  after the new restinio is uploaded.
+ #1014678 src:openimageio, it's not in testing.

One difficult situation is spdlog.

I have uploaded spdlog/1.10 last few days, but it causes a regression, since 
upstream
breaks the ABI without bumping SOVERSION (#1016408).

After filling bugs on upstream (https://github.com/gabime/spdlog/issues/2454),
the response seems depressed. They will start to use the package minior version 
in
soversion, like 1.11, instead of maintaining a stable soversion.

OTOH, spdlog in Debian already doesn't use soversion to track transition, since 
it embeds
fmtlib version in it's shared library. Currently it's libspdlog1-fmt8.

With the fmt transition, spdlog will also transit to libspdlog1-fmt9. So it can 
solve the ABI
regression by spdlog/1.10.



Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

2022-06-12 Thread Shengjing Zhu
X-Debbugs-CC: siret...@debian.org, t...@security.debian.org

Hi,

On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote:
> diff -Nru runc-1.0.0~rc93+ds1/debian/changelog 
> runc-1.0.0~rc93+ds1/debian/changelog
> --- runc-1.0.0~rc93+ds1/debian/changelog  2022-06-12 14:49:36.0 
> -0400
> +++ runc-1.0.0~rc93+ds1/debian/changelog  2021-05-19 14:46:14.0 
> -0400
> @@ -1,10 +1,3 @@
> -runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium
> -
> -  * Team upload.
> -  * backport upstream patch: Honor seccomp defaultErrnoRet, Closes: #1012030
> -
> - -- Reinhard Tartler   Sun, 12 Jun 2022 14:49:36 -0400
> -

Could you include the patch for CVE-2022-29162?

https://security-tracker.debian.org/tracker/CVE-2022-29162

If you don't have time, I can work on this later in this week.



Bug#1006768: golang-1.15 1.15.15-1~deb11u3 flagged for acceptance

2022-03-05 Thread Shengjing Zhu
Hi

On Sun, Mar 6, 2022 at 1:55 AM Adam D Barratt  wrote:
>
> package release.debian.org
> tags 1006768 = bullseye pending
> thanks
>

It should be 1005340 (1.15.15-1~deb11u3).

1006768 is for another CVE, thus 1.15.15-1~deb11u4. Sorry for
requesting a new version for golang-1.15 again.

-- 
Shengjing Zhu



Bug#1006768: bullseye-pu: package golang-1.15/1.15.15-1~deb11u4

2022-03-04 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: z...@debian.org, t...@security.debian.org

[ Reason ]

Backport patch for CVE-2022-24921.

[ Impact ]

CVE-2022-24921:
regexp: stack exhaustion compiling deeply nested expressions

This is bug in standard library.

[ Tests ]

The backported patch has new regression tests in it.

[ Risks ]

Low, change is small. Backport from 1.16 release without modification.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable
  golang-1.15 has been removed from unstable.

[ Changes ]

See attachment.

[ Other info ]

I don't think the severity needs to rebuild other Go packages.
diff -Nru golang-1.15-1.15.15/debian/changelog 
golang-1.15-1.15.15/debian/changelog
--- golang-1.15-1.15.15/debian/changelog2022-02-11 23:45:44.0 
+0800
+++ golang-1.15-1.15.15/debian/changelog2022-03-04 21:48:18.0 
+0800
@@ -1,3 +1,10 @@
+golang-1.15 (1.15.15-1~deb11u4) bullseye; urgency=medium
+
+  * Backport patch for CVE-2022-24921:
+regexp: stack exhaustion compiling deeply nested expressions
+
+ -- Shengjing Zhu   Fri, 04 Mar 2022 21:48:18 +0800
+
 golang-1.15 (1.15.15-1~deb11u3) bullseye; urgency=medium
 
   * Backport patches for CVE-2022-23806 CVE-2022-23772 CVE-2022-23773
diff -Nru golang-1.15-1.15.15/debian/patches/0015-CVE-2022-24921.patch 
golang-1.15-1.15.15/debian/patches/0015-CVE-2022-24921.patch
--- golang-1.15-1.15.15/debian/patches/0015-CVE-2022-24921.patch
1970-01-01 08:00:00.0 +0800
+++ golang-1.15-1.15.15/debian/patches/0015-CVE-2022-24921.patch
2022-03-04 21:48:18.0 +0800
@@ -0,0 +1,169 @@
+From: Russ Cox 
+Date: Wed, 2 Feb 2022 16:41:32 -0500
+Subject: CVE-2022-24921
+
+Origin: backport, https://github.com/golang/go/commit/2b65cde5
+---
+ src/regexp/syntax/parse.go  | 72 +++--
+ src/regexp/syntax/parse_test.go |  7 
+ 2 files changed, 77 insertions(+), 2 deletions(-)
+
+diff --git a/src/regexp/syntax/parse.go b/src/regexp/syntax/parse.go
+index 7b40309..d7cf2af 100644
+--- a/src/regexp/syntax/parse.go
 b/src/regexp/syntax/parse.go
+@@ -76,13 +76,29 @@ const (
+   opVerticalBar
+ )
+ 
++// maxHeight is the maximum height of a regexp parse tree.
++// It is somewhat arbitrarily chosen, but the idea is to be large enough
++// that no one will actually hit in real use but at the same time small enough
++// that recursion on the Regexp tree will not hit the 1GB Go stack limit.
++// The maximum amount of stack for a single recursive frame is probably
++// closer to 1kB, so this could potentially be raised, but it seems unlikely
++// that people have regexps nested even this deeply.
++// We ran a test on Google's C++ code base and turned up only
++// a single use case with depth > 100; it had depth 128.
++// Using depth 1000 should be plenty of margin.
++// As an optimization, we don't even bother calculating heights
++// until we've allocated at least maxHeight Regexp structures.
++const maxHeight = 1000
++
+ type parser struct {
+   flags   Flags // parse mode flags
+   stack   []*Regexp // stack of parsed expressions
+   free*Regexp
+   numCap  int // number of capturing groups seen
+   wholeRegexp string
+-  tmpClass[]rune // temporary char class work space
++  tmpClass[]rune  // temporary char class work space
++  numRegexp   int // number of regexps allocated
++  height  map[*Regexp]int // regexp height for height limit check
+ }
+ 
+ func (p *parser) newRegexp(op Op) *Regexp {
+@@ -92,16 +108,52 @@ func (p *parser) newRegexp(op Op) *Regexp {
+   *re = Regexp{}
+   } else {
+   re = new(Regexp)
++  p.numRegexp++
+   }
+   re.Op = op
+   return re
+ }
+ 
+ func (p *parser) reuse(re *Regexp) {
++  if p.height != nil {
++  delete(p.height, re)
++  }
+   re.Sub0[0] = p.free
+   p.free = re
+ }
+ 
++func (p *parser) checkHeight(re *Regexp) {
++  if p.numRegexp < maxHeight {
++  return
++  }
++  if p.height == nil {
++  p.height = make(map[*Regexp]int)
++  for _, re := range p.stack {
++  p.checkHeight(re)
++  }
++  }
++  if p.calcHeight(re, true) > maxHeight {
++  panic(ErrInternalError)
++  }
++}
++
++func (p *parser) calcHeight(re *Regexp, force bool) int {
++  if !force {
++  if h, ok := p.height[re]; ok {
++  return h
++  }
++  }
++  h := 1
++  for _, sub := range re.Sub {
++  hsub := p.calcHeight(sub, false)
++  if h < 1+hsub {
++   

Bug#1005340: bullseye-pu: package golang-1.15/1.15.15-1~deb11u3

2022-02-11 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: z...@debian.org, t...@security.debian.org

[ Reason ]
Backport patches for CVE-2022-23806 CVE-2022-23772 CVE-2022-23773

[ Impact ]

+ CVE-2022-23806: crypto/elliptic: fix IsOnCurve for big.Int values
  that are not valid coordinates
+ CVE-2022-23772: math/big: prevent large memory consumption in
  Rat.SetString
+ CVE-2022-23773: cmd/go: prevent branches from materializing into versions

All are minor security issues, so I'd like to go with stable-pu.

[ Tests ]

For CVE-2022-23806 and CVE-2022-23772, regression tests are backported as well.

For CVE-2022-23773 the tests in upstream patch are hard to backport, so I test
it manully. The test is similar with upstream patch[1]

[1] 
https://github.com/golang/go/commit/fa4d9b8e2bc2612960c80474fca83a4c85a974eb#diff-6d41824e441b8846a74c31ab4968dc114a1e650c05172e1f89826ea9e55d4c5aR421

For example, running

  GOPROXY=direct /usr/lib/go-1.15/bin/go get 
vcs-test.golang.org/git/semver-branch.git@v1.0.0

Will get same result and error in [1].

[ Risks ]

Patch for CVE-2022-23806 and CVE-2022-23772 are trivial and easy to review.
Patch for CVE-2022-23773 is larger, and is backported by 3way merge.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable
  golang-1.15 has been removed from unstable.

[ Changes ]

See attachment.

[ Other info ]

CVE-2022-23806 and CVE-2022-23772 are for Go std library, which is statically
linked in all Go programs. But these issues look like too minor to rebuild all
Go programs.
diff -Nru golang-1.15-1.15.15/debian/changelog 
golang-1.15-1.15.15/debian/changelog
--- golang-1.15-1.15.15/debian/changelog2021-12-04 17:37:57.0 
+0800
+++ golang-1.15-1.15.15/debian/changelog2022-02-11 23:45:44.0 
+0800
@@ -1,3 +1,14 @@
+golang-1.15 (1.15.15-1~deb11u3) bullseye; urgency=medium
+
+  * Backport patches for CVE-2022-23806 CVE-2022-23772 CVE-2022-23773
++ CVE-2022-23806: crypto/elliptic: fix IsOnCurve for big.Int values
+  that are not valid coordinates
++ CVE-2022-23772: math/big: prevent large memory consumption in
+  Rat.SetString
++ CVE-2022-23773: cmd/go: prevent branches from materializing into versions
+
+ -- Shengjing Zhu   Fri, 11 Feb 2022 23:45:44 +0800
+
 golang-1.15 (1.15.15-1~deb11u2) bullseye; urgency=medium
 
   * Backport patch for CVE-2021-38297
diff -Nru golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch 
golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch
--- golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch
1970-01-01 08:00:00.0 +0800
+++ golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch
2022-02-11 23:45:44.0 +0800
@@ -0,0 +1,132 @@
+From: Filippo Valsorda 
+Date: Wed, 2 Feb 2022 09:15:44 -0800
+Subject: CVE-2022-23806
+
+Origin: backport, https://github.com/golang/go/commit/6b3e741a
+---
+ src/crypto/elliptic/elliptic.go  |  5 +++
+ src/crypto/elliptic/elliptic_test.go | 81 
+ src/crypto/elliptic/p224.go  |  5 +++
+ 3 files changed, 91 insertions(+)
+
+diff --git a/src/crypto/elliptic/elliptic.go b/src/crypto/elliptic/elliptic.go
+index f93dc16..afedf18 100644
+--- a/src/crypto/elliptic/elliptic.go
 b/src/crypto/elliptic/elliptic.go
+@@ -71,6 +71,11 @@ func (curve *CurveParams) polynomial(x *big.Int) *big.Int {
+ }
+ 
+ func (curve *CurveParams) IsOnCurve(x, y *big.Int) bool {
++  if x.Sign() < 0 || x.Cmp(curve.P) >= 0 ||
++  y.Sign() < 0 || y.Cmp(curve.P) >= 0 {
++  return false
++  }
++
+   // y² = x³ - 3x + b
+   y2 := new(big.Int).Mul(y, y)
+   y2.Mod(y2, curve.P)
+diff --git a/src/crypto/elliptic/elliptic_test.go 
b/src/crypto/elliptic/elliptic_test.go
+index e80e773..bb16b0d 100644
+--- a/src/crypto/elliptic/elliptic_test.go
 b/src/crypto/elliptic/elliptic_test.go
+@@ -721,3 +721,84 @@ func testMarshalCompressed(t *testing.T, curve Curve, x, 
y *big.Int, want []byte
+   t.Errorf("point did not round-trip correctly: got (%v, %v), 
want (%v, %v)", X, Y, x, y)
+   }
+ }
++
++func testAllCurves(t *testing.T, f func(*testing.T, Curve)) {
++  tests := []struct {
++  name  string
++  curve Curve
++  }{
++  {"P256", P256()},
++  {"P256/Params", P256().Params()},
++  {"P224", P224()},
++  {"P224/Params", P224().Params()},
++  {"P384", P384()},
++  {"P384/Params", P384().Params()},
++  {"P521", P521()},
++  {"P521/Params", P521().Params()},
++  }
++   

Bug#1001587: transition: fmtlib

2021-12-12 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: z...@debian.org
Control: block -1 by 1001527

Hi,

fmtlib has bumped its SO name to 8.

I have rebuilt the reverse dependencies, the situation is:

+ spdlog/1.8.5 FTBFS, but the new version 1.9.2 has been uploaded to
  experimental, which works with fmtlib 8.
+ vast FTBFS, bug has been filed, #1001527
+ purify FTBFS, but for other reason, #1001528.
+ Other packages are in unstable only, and FTBFS:
  dpaste, ring, tiledb, lizardfs

P.S. since some level 3 packages build-depend fmtlib and spdlog, so I rebuild
with fmtlib/8 and spdlog/1.9.2 together.

Ben file:

title = "fmtlib";
is_affected = .depends ~ "libfmt7" | .depends ~ "libfmt8";
is_good = .depends ~ "libfmt8";
is_bad = .depends ~ "libfmt7";



Bug#1001100: bullseye-pu: package golang-1.15/1.15.15-1~deb11u2

2021-12-11 Thread Shengjing Zhu
On Sun, Dec 12, 2021 at 1:49 AM Shengjing Zhu  wrote:
>
> On Sun, Dec 12, 2021 at 1:45 AM Adam D. Barratt
>  wrote:
> >
> > Control: tags -1 + moreinfo
> >
> > On Fri, 2021-12-10 at 00:11 +0800, Shengjing Zhu wrote:
> > > On Sat, Dec 04, 2021 at 06:31:35PM +0800, Shengjing Zhu wrote:
> > [...]
> > > > Backport patches for CVE-2021-38297 and CVE-2021-41771.
> > > >
> > > > [ Impact ]
> > > >
> > > > + CVE-2021-38297 is for people using WASM with Go
> > > > + CVE-2021-41771 is in debug/macho standard library
> > > >
> > [...]
> > > I'd like to amend this request.
> > >
> > > Backport two patches for CVE-2021-44716 and CVE-2021-44717. Both are
> > > taken from upstream 1.16
> > > branch without modification.
> > >
> >
> > None of these issues appears to be resolved in the golang-1.15 package
> > in unstable. Is that correct?
> >
>
> Hmm, I forget golang-1.15 hasn't been removed from unstable yet, since
> two packages still depend on it.
> I'll update it for unstable. (I really want to see it removed from 
> unstable...)
>

Now golang-1.15/1.15.15-5 is in unstable, with same patches in this pu.

-- 
Shengjing Zhu



Bug#1001100: bullseye-pu: package golang-1.15/1.15.15-1~deb11u2

2021-12-11 Thread Shengjing Zhu
On Sun, Dec 12, 2021 at 1:45 AM Adam D. Barratt
 wrote:
>
> Control: tags -1 + moreinfo
>
> On Fri, 2021-12-10 at 00:11 +0800, Shengjing Zhu wrote:
> > On Sat, Dec 04, 2021 at 06:31:35PM +0800, Shengjing Zhu wrote:
> [...]
> > > Backport patches for CVE-2021-38297 and CVE-2021-41771.
> > >
> > > [ Impact ]
> > >
> > > + CVE-2021-38297 is for people using WASM with Go
> > > + CVE-2021-41771 is in debug/macho standard library
> > >
> [...]
> > I'd like to amend this request.
> >
> > Backport two patches for CVE-2021-44716 and CVE-2021-44717. Both are
> > taken from upstream 1.16
> > branch without modification.
> >
>
> None of these issues appears to be resolved in the golang-1.15 package
> in unstable. Is that correct?
>

Hmm, I forget golang-1.15 hasn't been removed from unstable yet, since
two packages still depend on it.
I'll update it for unstable. (I really want to see it removed from unstable...)

-- 
Shengjing Zhu



Bug#1001100: bullseye-pu: package golang-1.15/1.15.15-1~deb11u2

2021-12-09 Thread Shengjing Zhu
On Sat, Dec 04, 2021 at 06:31:35PM +0800, Shengjing Zhu wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: z...@debian.org, t...@security.debian.org
> 
> [ Reason ]
> 
> Backport patches for CVE-2021-38297 and CVE-2021-41771.
> 
> [ Impact ]
> 
> + CVE-2021-38297 is for people using WASM with Go
> + CVE-2021-41771 is in debug/macho standard library
> 
> Both IMO only have limited users.
> 
> [ Tests ]
> 
> + CVE-2021-38297 I didn't test the WASM part since it's unclear
>   how to test...
> + CVE-2021-41771 the upstream patch contains a bad binary to trigger
>   the issue in the unit test.
> 
> [ Risks ]
> 
> Both patches are taken from upstream 1.16 branch without modification.
> And they are small except a big test file.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> 
> golang-1.15 (1.15.15-1~deb11u2) bullseye; urgency=medium
> 
>   * Backport patch for CVE-2021-38297
> When invoking functions from WASM modules, built using GOARCH=wasm 
> GOOS=js,
> passing very large arguments can cause portions of the module to be 
> overwritten
> with data from the arguments.
>   * Backport patch for CVE-2021-41771
> debug/macho: invalid dynamic symbol table command can cause panic
> 
> [ Other info ]
> 
> I don't think we need to rebuild all Go packages with the severity of these 
> two issues.

I'd like to amend this request.

Backport two patches for CVE-2021-44716 and CVE-2021-44717. Both are taken from 
upstream 1.16
branch without modification.

Thanks.
diff -Nru golang-1.15-1.15.15/debian/changelog 
golang-1.15-1.15.15/debian/changelog
--- golang-1.15-1.15.15/debian/changelog2021-09-11 15:54:07.0 
+0800
+++ golang-1.15-1.15.15/debian/changelog2021-12-04 17:37:57.0 
+0800
@@ -1,3 +1,18 @@
+golang-1.15 (1.15.15-1~deb11u2) bullseye; urgency=medium
+
+  * Backport patch for CVE-2021-38297
+When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js,
+passing very large arguments can cause portions of the module to be 
overwritten
+with data from the arguments.
+  * Backport patch for CVE-2021-41771
+debug/macho: invalid dynamic symbol table command can cause panic
+  * Backport patch for CVE-2021-44716
+net/http: limit growth of header canonicalization cache
+  * Backport patch for CVE-2021-44717
+syscall: don’t close fd 0 on ForkExec error
+
+ -- Shengjing Zhu   Sat, 04 Dec 2021 17:37:57 +0800
+
 golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
 
   [ Anthony Fok ]
diff -Nru golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch 
golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch
--- golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch
1970-01-01 08:00:00.0 +0800
+++ golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch
2021-12-04 17:37:57.0 +0800
@@ -0,0 +1,60 @@
+From: Michael Knyszek 
+Date: Thu, 2 Sep 2021 16:51:59 -0400
+Subject: CVE-2021-38297
+
+Origin: backport, https://github.com/golang/go/commit/4548fcc8
+---
+ misc/wasm/wasm_exec.js   |  7 +++
+ src/cmd/link/internal/ld/data.go | 11 ++-
+ 2 files changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/misc/wasm/wasm_exec.js b/misc/wasm/wasm_exec.js
+index 8501ae7..b56f3f1 100644
+--- a/misc/wasm/wasm_exec.js
 b/misc/wasm/wasm_exec.js
+@@ -527,6 +527,13 @@
+   offset += 8;
+   });
+ 
++  // The linker guarantees global data starts from at 
least wasmMinDataAddr.
++  // Keep in sync with 
cmd/link/internal/ld/data.go:wasmMinDataAddr.
++  const wasmMinDataAddr = 4096 + 4096;
++  if (offset >= wasmMinDataAddr) {
++  throw new Error("command line too long");
++  }
++
+   this._inst.exports.run(argc, argv);
+   if (this.exited) {
+   this._resolveExitPromise();
+diff --git a/src/cmd/link/internal/ld/data.go 
b/src/cmd/link/internal/ld/data.go
+index 2b55a5f..ee5c794 100644
+--- a/src/cmd/link/internal/ld/data.go
 b/src/cmd/link/internal/ld/data.go
+@@ -2268,6 +2268,11 @@ func assignAddress(ctxt *Link, sect *sym.Section, n 
int, s loader.Sym, va uint64
+   return sect, n, va
+ }
+ 
++// On Wasm, we reserve 4096 bytes for zero page, then 4096 bytes for 
wasm_exec.js
++// to store command line args. Data sections starts from at least address 
8192.
++// Keep in sync

Bug#1001115: bullseye-pu: package docker.io/20.10.5+dfsg1-1+deb11u1

2021-12-08 Thread Shengjing Zhu
Control: tags -1 - moreinfo

On Sun, Dec 05, 2021 at 12:01:35AM +0800, Shengjing Zhu wrote:
> [ Other info ]
> 
> + Please build docker.io after containerd/1.4.12~ds1-1~deb11u1 has been built.
>   So the RPi1/RPi0 workaround(#998909) will be used.
> + The "clone3" hasn't been in testing yet(due to FTBFS on mips64el/mipsel
>   previously, but I have fixed it in docker.io/20.10.11+dfsg1-2. It will 
> hopefully
>   migrate to testing in 5 days).
> 
>   So I have added the moreinfo tag.

These fixes have been migrated to testing now.



Bug#1001115: bullseye-pu: package docker.io/20.10.5+dfsg1-1+deb11u1

2021-12-04 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye moreinfo
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: z...@debian.org, arna...@kali.org, t...@security.debian.org

[ Reason ]

Backport 3 CVE patches.

+ CVE-2021-41089: Create parent directories inside a chroot during docker
  cp to prevent a specially crafted container from changing permissions of
  existing files in the host’s filesystem.
+ CVE-2021-41091: Lock down file permissions to prevent unprivileged users
  from discovering and executing programs in /var/lib/docker.
+ CVE-2021-41092: Ensure default auth config has address field set, to
  prevent credentials being sent to the default registry. (Closes: #998292)

And backport 1 patch to run container which
uses "clone3" syscall (for example glibc 2.34)

[ Impact ]

Except the security patches, user will not able to run container like
fedora:rawhide, ubuntu:impish (same reason with containerd) without disabling
seccomp(lost security protect).

[ Tests ]

+ CVE-2021-41089 I haven't figured out how to trigger the bug, but the patch
  is backported without modification from upstream 20.10 branch.
+ CVE-2021-41091 I have verified the patch. With the patch, non-root user is
  not able to run setuid file in /var/lib/docker.
+ CVE-2021-41092 this patch includes upstream unit test.

+ "clone3" patch
  I have installed it on bullseye vm and succefully run following command:

  docker run --rm -it registry.fedoraproject.org/fedora:rawhide /usr/bin/curl 
www.debian.org

  Without the patch, this command will fail.

[ Risks ]

The 3 CVE patches are backported from upstream 20.10 branch without 
modification.
The "clone3" patch is backported with modification, since upstream patch fails 
on
mips64el and mipsel. But the modification is also provided by upstream, although
they decided not to merged into 20.10 branch, since they want to fix it in 
conainer
spec, which would take long time.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

  * Backport patches for CVE-2021-41089 CVE-2021-41091 CVE-2021-41092
+ CVE-2021-41089: Create parent directories inside a chroot during docker
  cp to prevent a specially crafted container from changing permissions of
  existing files in the host’s filesystem.
+ CVE-2021-41091: Lock down file permissions to prevent unprivileged users
  from discovering and executing programs in /var/lib/docker.
+ CVE-2021-41092: Ensure default auth config has address field set, to
  prevent credentials being sent to the default registry. (Closes: #998292)
  * Backport "clone3" syscall workaround in default seccomp policy
(Closes: #995191)

[ Other info ]

+ Please build docker.io after containerd/1.4.12~ds1-1~deb11u1 has been built.
  So the RPi1/RPi0 workaround(#998909) will be used.
+ The "clone3" hasn't been in testing yet(due to FTBFS on mips64el/mipsel
  previously, but I have fixed it in docker.io/20.10.11+dfsg1-2. It will 
hopefully
  migrate to testing in 5 days).

  So I have added the moreinfo tag.
diff -Nru docker.io-20.10.5+dfsg1/debian/changelog 
docker.io-20.10.5+dfsg1/debian/changelog
--- docker.io-20.10.5+dfsg1/debian/changelog2021-03-10 00:53:21.0 
+0800
+++ docker.io-20.10.5+dfsg1/debian/changelog2021-12-04 18:53:03.0 
+0800
@@ -1,3 +1,18 @@
+docker.io (20.10.5+dfsg1-1+deb11u1) bullseye; urgency=medium
+
+  * Backport patches for CVE-2021-41089 CVE-2021-41091 CVE-2021-41092
++ CVE-2021-41089: Create parent directories inside a chroot during docker
+  cp to prevent a specially crafted container from changing permissions of
+  existing files in the host’s filesystem.
++ CVE-2021-41091: Lock down file permissions to prevent unprivileged users
+  from discovering and executing programs in /var/lib/docker.
++ CVE-2021-41092: Ensure default auth config has address field set, to
+  prevent credentials being sent to the default registry. (Closes: #998292)
+  * Backport "clone3" syscall workaround in default seccomp policy
+(Closes: #995191)
+
+ -- Shengjing Zhu   Sat, 04 Dec 2021 18:53:03 +0800
+
 docker.io (20.10.5+dfsg1-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru docker.io-20.10.5+dfsg1/debian/patches/CVE-2021-41089.patch 
docker.io-20.10.5+dfsg1/debian/patches/CVE-2021-41089.patch
--- docker.io-20.10.5+dfsg1/debian/patches/CVE-2021-41089.patch 1970-01-01 
08:00:00.0 +0800
+++ docker.io-20.10.5+dfsg1/debian/patches/CVE-2021-41089.patch 2021-12-04 
18:08:34.0 +0800
@@ -0,0 +1,28 @@
+Description: chrootarchive: don't create parent dirs outside of chroot
+Origin: backport, https://github.com/moby/moby/commit/80f1169e
+--- a/engine/pkg/chrootarchive/archive.go

Bug#1001100: bullseye-pu: package golang-1.15/1.15.15-1~deb11u2

2021-12-04 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: z...@debian.org, t...@security.debian.org

[ Reason ]

Backport patches for CVE-2021-38297 and CVE-2021-41771.

[ Impact ]

+ CVE-2021-38297 is for people using WASM with Go
+ CVE-2021-41771 is in debug/macho standard library

Both IMO only have limited users.

[ Tests ]

+ CVE-2021-38297 I didn't test the WASM part since it's unclear
  how to test...
+ CVE-2021-41771 the upstream patch contains a bad binary to trigger
  the issue in the unit test.

[ Risks ]

Both patches are taken from upstream 1.16 branch without modification.
And they are small except a big test file.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

golang-1.15 (1.15.15-1~deb11u2) bullseye; urgency=medium

  * Backport patch for CVE-2021-38297
When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js,
passing very large arguments can cause portions of the module to be 
overwritten
with data from the arguments.
  * Backport patch for CVE-2021-41771
debug/macho: invalid dynamic symbol table command can cause panic

[ Other info ]

I don't think we need to rebuild all Go packages with the severity of these two 
issues.
diff -Nru golang-1.15-1.15.15/debian/changelog 
golang-1.15-1.15.15/debian/changelog
--- golang-1.15-1.15.15/debian/changelog2021-09-11 15:54:07.0 
+0800
+++ golang-1.15-1.15.15/debian/changelog2021-12-04 17:37:57.0 
+0800
@@ -1,3 +1,14 @@
+golang-1.15 (1.15.15-1~deb11u2) bullseye; urgency=medium
+
+  * Backport patch for CVE-2021-38297
+When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js,
+passing very large arguments can cause portions of the module to be 
overwritten
+with data from the arguments.
+  * Backport patch for CVE-2021-41771
+debug/macho: invalid dynamic symbol table command can cause panic
+
+ -- Shengjing Zhu   Sat, 04 Dec 2021 17:37:57 +0800
+
 golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
 
   [ Anthony Fok ]
diff -Nru golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch 
golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch
--- golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch
1970-01-01 08:00:00.0 +0800
+++ golang-1.15-1.15.15/debian/patches/0008-CVE-2021-38297.patch
2021-12-04 17:37:57.0 +0800
@@ -0,0 +1,60 @@
+From: Michael Knyszek 
+Date: Thu, 2 Sep 2021 16:51:59 -0400
+Subject: CVE-2021-38297
+
+Origin: backport, https://github.com/golang/go/commit/4548fcc8
+---
+ misc/wasm/wasm_exec.js   |  7 +++
+ src/cmd/link/internal/ld/data.go | 11 ++-
+ 2 files changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/misc/wasm/wasm_exec.js b/misc/wasm/wasm_exec.js
+index 8501ae7..b56f3f1 100644
+--- a/misc/wasm/wasm_exec.js
 b/misc/wasm/wasm_exec.js
+@@ -527,6 +527,13 @@
+   offset += 8;
+   });
+ 
++  // The linker guarantees global data starts from at 
least wasmMinDataAddr.
++  // Keep in sync with 
cmd/link/internal/ld/data.go:wasmMinDataAddr.
++  const wasmMinDataAddr = 4096 + 4096;
++  if (offset >= wasmMinDataAddr) {
++  throw new Error("command line too long");
++  }
++
+   this._inst.exports.run(argc, argv);
+   if (this.exited) {
+   this._resolveExitPromise();
+diff --git a/src/cmd/link/internal/ld/data.go 
b/src/cmd/link/internal/ld/data.go
+index 2b55a5f..ee5c794 100644
+--- a/src/cmd/link/internal/ld/data.go
 b/src/cmd/link/internal/ld/data.go
+@@ -2268,6 +2268,11 @@ func assignAddress(ctxt *Link, sect *sym.Section, n 
int, s loader.Sym, va uint64
+   return sect, n, va
+ }
+ 
++// On Wasm, we reserve 4096 bytes for zero page, then 4096 bytes for 
wasm_exec.js
++// to store command line args. Data sections starts from at least address 
8192.
++// Keep in sync with wasm_exec.js.
++const wasmMinDataAddr = 4096 + 4096
++
+ // address assigns virtual addresses to all segments and sections and
+ // returns all segments in file order.
+ func (ctxt *Link) address() []*sym.Segment {
+@@ -2277,10 +2282,14 @@ func (ctxt *Link) address() []*sym.Segment {
+   order = append(order, )
+   Segtext.Rwx = 05
+   Segtext.Vaddr = va
+-  for _, s := range Segtext.Sections {
++  for i, s := range Segtext.Sections {
+   va = uint64(Rnd(int64(va), int64(s.Align)))
+   s.Vaddr = va
+   va += s.Length
++
++  if ctxt.IsWasm() && i == 0 && va < wasmMinDataA

Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

2021-12-03 Thread Shengjing Zhu
On Sat, Dec 4, 2021 at 12:30 AM Julien Cristau  wrote:
>
> On Sat, Dec 04, 2021 at 12:28:27AM +0800, Shengjing Zhu wrote:
> > On Fri, Dec 03, 2021 at 04:32:16PM +0100, Julien Cristau wrote:
> > > Control: tag -1 confirmed
> > >
> > > On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote:
> > > > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
> > >
> > > This looks fine to me, go ahead.
> >
> > Thanks for the review. I'm not sure if it's too late to amend this
> > update.
> >
> Might be best to go with the original one first, and file a new bug for
> the new changes, because I don't know when I can get to reviewing more.
>

Uploaded with the original one.

-- 
Shengjing Zhu



Bug#1000448: bullseye-pu: package containerd/1.4.12~ds1-1~deb11u1

2021-12-03 Thread Shengjing Zhu
On Sat, Dec 4, 2021 at 12:11 AM Adam D. Barratt
 wrote:
>
> Control: tags -1 + confirmed
>
> On Tue, 2021-11-23 at 19:27 +0800, Shengjing Zhu wrote:
> > I'd like to update containerd in bullseye to latest upstream
> > patch version. Upstream does maintain a stable release branch
> > 1.4.x with only backporting important bugfix.
> >
> > Notably:
> > 1.4.12~ds1-1~deb11u1 will have:
> >
> > + Workaround for "clone3" syscall. So users can run images like
> >   fedora:rawhide, ubuntu:impish, which has enabled clone3 syscall
> >   in glibc.
> >   See also https://bugs.launchpad.net/cloud-images/+bug/1943049
> > + Mitigate CVE-2021-41190: Handle ambiguous OCI manifest parsing
> > + Backport RPi1/RPi0 workaround #998909
> >
>
> Please go ahead.
>

Uploaded.

-- 
Shengjing Zhu



Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

2021-12-03 Thread Shengjing Zhu
On Fri, Dec 03, 2021 at 04:32:16PM +0100, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote:
> > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
> 
> This looks fine to me, go ahead.

Thanks for the review. I'm not sure if it's too late to amend this
update.

I'd like to add two patches.

Amend for d/changelog:

  * Backport patch for CVE-2021-38297
When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js,
passing very large arguments can cause portions of the module to be 
overwritten
with data from the arguments.
  * Backport patch for CVE-2021-41771
debug/macho: invalid dynamic symbol table command can cause panic

Amend two files in d/patches (attached)

+ debian/patches/0008-CVE-2021-38297.patch
  This patch is small. Backport from upstream 1.16 branch directly without 
modification.
+ debian/patches/0009-CVE-2021-41771.patch
  This is patch contains a large base64 testdata file, just for testing. 
Otherwise it's
  small as well.
  And it's also backport from upstream 1.16 branch directly with modification.

Other info:

The debian security tracker says golang-1.15 also affects CVE-2021-41772, but 
after checking
myself I think the affected code is introduced in golang 1.16

The debian security tracker also doesn't mention CVE-2021-38297

I will talk to security team to update the status on tracker.
From: Michael Knyszek 
Date: Thu, 2 Sep 2021 16:51:59 -0400
Subject: CVE-2021-38297

Origin: backport, https://github.com/golang/go/commit/4548fcc8
---
 misc/wasm/wasm_exec.js   |  7 +++
 src/cmd/link/internal/ld/data.go | 11 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/misc/wasm/wasm_exec.js b/misc/wasm/wasm_exec.js
index 8501ae7..b56f3f1 100644
--- a/misc/wasm/wasm_exec.js
+++ b/misc/wasm/wasm_exec.js
@@ -527,6 +527,13 @@
 offset += 8;
 			});
 
+			// The linker guarantees global data starts from at least wasmMinDataAddr.
+			// Keep in sync with cmd/link/internal/ld/data.go:wasmMinDataAddr.
+			const wasmMinDataAddr = 4096 + 4096;
+			if (offset >= wasmMinDataAddr) {
+throw new Error("command line too long");
+			}
+
 			this._inst.exports.run(argc, argv);
 			if (this.exited) {
 this._resolveExitPromise();
diff --git a/src/cmd/link/internal/ld/data.go b/src/cmd/link/internal/ld/data.go
index 2b55a5f..ee5c794 100644
--- a/src/cmd/link/internal/ld/data.go
+++ b/src/cmd/link/internal/ld/data.go
@@ -2268,6 +2268,11 @@ func assignAddress(ctxt *Link, sect *sym.Section, n int, s loader.Sym, va uint64
 	return sect, n, va
 }
 
+// On Wasm, we reserve 4096 bytes for zero page, then 4096 bytes for wasm_exec.js
+// to store command line args. Data sections starts from at least address 8192.
+// Keep in sync with wasm_exec.js.
+const wasmMinDataAddr = 4096 + 4096
+
 // address assigns virtual addresses to all segments and sections and
 // returns all segments in file order.
 func (ctxt *Link) address() []*sym.Segment {
@@ -2277,10 +2282,14 @@ func (ctxt *Link) address() []*sym.Segment {
 	order = append(order, )
 	Segtext.Rwx = 05
 	Segtext.Vaddr = va
-	for _, s := range Segtext.Sections {
+	for i, s := range Segtext.Sections {
 		va = uint64(Rnd(int64(va), int64(s.Align)))
 		s.Vaddr = va
 		va += s.Length
+
+		if ctxt.IsWasm() && i == 0 && va < wasmMinDataAddr {
+			va = wasmMinDataAddr
+		}
 	}
 
 	Segtext.Length = va - uint64(*FlagTextAddr)
From: Roland Shoemaker 
Date: Thu, 14 Oct 2021 13:02:01 -0700
Subject: CVE-2021-41771

Origin: backport, https://github.com/golang/go/commit/d19c5bdb
---
 src/debug/macho/file.go  | 9 +
 src/debug/macho/file_test.go | 7 +++
 .../macho/testdata/gcc-amd64-darwin-exec-with-bad-dysym.base64   | 1 +
 3 files changed, 17 insertions(+)
 create mode 100644 src/debug/macho/testdata/gcc-amd64-darwin-exec-with-bad-dysym.base64

diff --git a/src/debug/macho/file.go b/src/debug/macho/file.go
index 085b0c8..73cfce3 100644
--- a/src/debug/macho/file.go
+++ b/src/debug/macho/file.go
@@ -345,6 +345,15 @@ func NewFile(r io.ReaderAt) (*File, error) {
 			if err := binary.Read(b, bo, ); err != nil {
 return nil, err
 			}
+			if hdr.Iundefsym > uint32(len(f.Symtab.Syms)) {
+return nil, {offset, fmt.Sprintf(
+	"undefined symbols index in dynamic symbol table command is greater than symbol table length (%d > %d)",
+	hdr.Iundefsym, len(f.Symtab.Syms)), nil}
+			} else if hdr.Iundefsym+hdr.Nundefsym > uint32(len(f.Symtab.Syms)) {
+return nil, {offset, fmt.Sprintf(
+	"number of undefined symbols after index in dynamic symbol table command is greater than symbol table length (%d > %d)",
+	hdr.Iundefsym+hdr.Nundefsym, len(f.Symtab.Syms)), nil}
+			}
 			dat := make([]byte, hdr.Nindirectsyms*4)
 			if _, err := r.ReadAt(dat, int64

Bug#993315: bullseye-pu: package im-config/0.46-1+deb11u1

2021-12-03 Thread Shengjing Zhu
On Fri, Dec 3, 2021 at 10:26 PM Julien Cristau  wrote:
>
> Control: tag -1 confirmed
>
> On Tue, Aug 31, 2021 at 12:12:58AM +0800, Shengjing Zhu wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: bullseye
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > X-Debbugs-Cc: z...@debian.org
> >
> > [ Reason ]
> > Two fixes related to Fcitx5, the Chinese/Japanese/Korean input method.
> > + 990742
> >   Fcitx5 should be preferred to Fcitx4. When upgrading from buster, which
> >   installs Fcitx4 by default, the old version may still around. So when
> >   both versions installed, the new one should be used.
> >
> > + 977203
> >   The input method related env for Fcitx5 should be "fcitx", not "fcitx5".
> >   Some property software may not recognize the "fcitx5" env, and results
> >   poor experience since they may fallback to legacy "xim" mode.
> >
> This looks fine, go ahead.
>

Uploaded.


--
Shengjing Zhu



Bug#993315: bullseye-pu: package im-config/0.46-1+deb11u1

2021-11-30 Thread Shengjing Zhu
Hi

Can we get this to 11.2, the change is small and easy to review.

Thanks.

-- 
Shengjing Zhu



Bug#995946: Please rebuild all Go packages on i386 which are built by golang-1.16 and golang-1.17

2021-10-08 Thread Shengjing Zhu
Package: release.debian.org
Severity: wishlist
X-Debbugs-Cc: z...@debian.org

The golang-1.16 package before 1.16.9-2, golang-1.17 package before 1.17.2-1
enables SSE2 on i386 accidentally. #995708

It has been fixed in golang-1.16/1.16.9-2 and golang-1.17/1.17.2-1.

Please rebuild all the Go packages on i386.

Following packages are affected:

Packages build with golang-1.16 on i386:

apkverifier
badger
balloon
c2go
chasquid
containerd
docker.io
douceur
garagemq
go-exploitdb
go-qrcode
golang-chroma
golang-docker-credential-helpers
golang-golang-x-tools
gopls
hjson-go
hugo
kcptun
libsecsipid-dev
libsecsipid1
minify
ncbi-entrez-direct
nncp
panicparse
podman
podman-docker
secsipidx
seqkit
sshesame
textql
unikmer
vcfanno
webhook

Packages build with golang-1.17 on i386:

gdu



Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

2021-09-11 Thread Shengjing Zhu
On Tue, Aug 31, 2021 at 01:30:13AM +0800, Shengjing Zhu wrote:
> 
> Changelog:
> 
> diff -Nru golang-1.15-1.15.9/debian/changelog 
> golang-1.15-1.15.15/debian/changelog
> --- golang-1.15-1.15.9/debian/changelog   2021-07-13 13:55:42.0 
> +0800
> +++ golang-1.15-1.15.15/debian/changelog  2021-08-31 00:37:05.0 
> +0800
> @@ -1,3 +1,23 @@
> +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
> +
> +  * Team upload.
> +  * Rebuild 1.15.15 for bullseye.
> +Fix CVE-2021-36221: net/http: panic due to racy read of persistConn
> +after handler panic (Closes: #991961)
> +
> + -- Shengjing Zhu   Tue, 31 Aug 2021 00:37:05 +0800
> +
> +golang-1.15 (1.15.15-1) unstable; urgency=medium
> +
> +  * Team upload.
> +  * New upstream version 1.15.15
> +  * Remove security patches which were previously backported
> +for 1.15.9 but are already in 1.15.15
> +  * Update Standards-Version to 4.5.1, no changes needed
> +  * Change Section from devel to golang
> +
> + -- Anthony Fok   Sun, 15 Aug 2021 16:44:15 -0600
> +
>  golang-1.15 (1.15.9-6) unstable; urgency=medium
>  
>* Team upload.
> 

Since a new CVE is published for go compiler, I have backported to this version 
as well.
The new changes are:

diff -Nru golang-1.15-1.15.9/debian/changelog 
golang-1.15-1.15.15/debian/changelog
--- golang-1.15-1.15.9/debian/changelog 2021-07-13 13:55:42.0 +0800
+++ golang-1.15-1.15.15/debian/changelog2021-09-11 15:54:07.0 
+0800
@@ -1,3 +1,29 @@
+golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
+
+  [ Anthony Fok ]
+  * Fix Lintian warning tab-in-license-text
+debian/copyright (starting at line 381)
+
+  [ Shengjing Zhu ]
+  * Rebuild 1.15.15 for bullseye
++ Include fix for CVE-2021-36221 (Closes: #991961)
+  net/http: panic due to racy read of persistConn after handler panic
+  * Backport patch for CVE-2021-39293
+archive/zip: overflow in preallocation check can cause OOM panic
+
+ -- Shengjing Zhu   Sat, 11 Sep 2021 15:54:07 +0800
+
+golang-1.15 (1.15.15-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream version 1.15.15
+  * Remove security patches which were previously backported
+for 1.15.9 but are already in 1.15.15
+  * Update Standards-Version to 4.5.1, no changes needed
+  * Change Section from devel to golang
+
+ -- Anthony Fok   Sun, 15 Aug 2021 16:44:15 -0600
+

The full diff is still at 
https://people.debian.org/~zhsj/golang-1.15_1.15.15-1~deb11u1.debdiff



Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

2021-08-30 Thread Shengjing Zhu
nux.go|3 
 src/internal/poll/sendfile_solaris.go  |3 
 src/math/big/arith_s390x.s |  192 
 src/math/big/arith_test.go |   65 ++
 src/math/big/ratconv.go|   15 
 src/math/big/ratconv_test.go   |   25 +
 src/net/dnsclient_unix_test.go |  321 ++
 src/net/http/h2_bundle.go  |2 
 src/net/http/httputil/reverseproxy.go  |   31 -
 src/net/http/httputil/reverseproxy_test.go |  102 
 src/net/http/omithttp2.go  |4 
 src/net/http/transport.go  |   39 +
 src/net/http/transport_test.go |   84 +++
 src/net/lookup.go  |  159 ++-
 src/net/sendfile_test.go   |   64 ++
 src/os/readfrom_linux_test.go  |   32 +
 src/run.bash   |   10 
 src/run.bat|4 
 src/run.rc |9 
 src/runtime/asm_arm64.s|   47 +-
 src/runtime/cgo/gcc_windows_386.c  |1 
 src/runtime/cgo/gcc_windows_amd64.c|1 
 src/runtime/cgo/libcgo_windows.h   |   12 
 src/runtime/pprof/pprof_test.go|3 
 src/runtime/signal_unix.go |2 
 src/runtime/symtab.go  |8 
 src/runtime/symtab_test.go |   85 +++
 src/runtime/sys_linux_ppc64x.s |   86 +++
 src/runtime/time.go|5 
 src/syscall/exec_linux_test.go |1 
 src/syscall/syscall_windows.go |   34 +
 src/syscall/zsyscall_windows.go|6 
 src/time/sleep_test.go |   16 
 src/time/zoneinfo.go   |   33 -
 src/time/zoneinfo_read.go  |   44 +-
 src/time/zoneinfo_test.go  |   95 +++-
 src/vendor/golang.org/x/net/http/httpguts/httplex.go   |   10 
 src/vendor/modules.txt |2 
 test/escape5.go|   11 
 test/fixedbugs/issue42876.go   |   18 
 test/fixedbugs/issue45175.go   |   29 +
 test/fixedbugs/issue46653.dir/bad/bad.go   |   64 ++
 test/fixedbugs/issue46653.dir/main.go  |   27 +
 test/fixedbugs/issue46653.go   |   10 
 94 files changed, 2240 insertions(+), 1649 deletions(-)

Changelog:

diff -Nru golang-1.15-1.15.9/debian/changelog 
golang-1.15-1.15.15/debian/changelog
--- golang-1.15-1.15.9/debian/changelog 2021-07-13 13:55:42.0 +0800
+++ golang-1.15-1.15.15/debian/changelog2021-08-31 00:37:05.0 
+0800
@@ -1,3 +1,23 @@
+golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Rebuild 1.15.15 for bullseye.
+Fix CVE-2021-36221: net/http: panic due to racy read of persistConn
+after handler panic (Closes: #991961)
+
+ -- Shengjing Zhu   Tue, 31 Aug 2021 00:37:05 +0800
+
+golang-1.15 (1.15.15-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream version 1.15.15
+  * Remove security patches which were previously backported
+for 1.15.9 but are already in 1.15.15
+  * Update Standards-Version to 4.5.1, no changes needed
+  * Change Section from devel to golang
+
+ -- Anthony Fok   Sun, 15 Aug 2021 16:44:15 -0600
+
 golang-1.15 (1.15.9-6) unstable; urgency=medium
 
   * Team upload.

Full: https://people.debian.org/~zhsj/golang-1.15_1.15.15-1~deb11u1.debdiff

[ Other info ]
If my guess it correct, Go1.15 is EOL since Go1.17 is released. So this
is probably the only minor release we want to upload.



Bug#993315: bullseye-pu: package im-config/0.46-1+deb11u1

2021-08-30 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: z...@debian.org

[ Reason ]
Two fixes related to Fcitx5, the Chinese/Japanese/Korean input method.
+ 990742
  Fcitx5 should be preferred to Fcitx4. When upgrading from buster, which
  installs Fcitx4 by default, the old version may still around. So when
  both versions installed, the new one should be used.

+ 977203
  The input method related env for Fcitx5 should be "fcitx", not "fcitx5".
  Some property software may not recognize the "fcitx5" env, and results
  poor experience since they may fallback to legacy "xim" mode.

[ Impact ]

Bad input experience.

[ Tests ]
These two changes are already included in testing for some days, and I
have using it daily without problems.

Though I tested the version in testing, the version in testing are
identical to this one, except one non-functional change in bug-script.

[ Risks ]
None, the change is trivial.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

diff -Nru im-config-0.46/debian/changelog im-config-0.46/debian/changelog
--- im-config-0.46/debian/changelog 2020-12-18 17:38:00.0 +0800
+++ im-config-0.46/debian/changelog 2021-08-30 23:54:06.0 +0800
@@ -1,3 +1,17 @@
+im-config (0.46-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+
+  [ Gunnar Hjalmarsson ]
+  * Replace "fcitx" with "fcitx5" in IM_CONFIG_PREFERRED_RULE variable
+(closes: #990742)
+
+  [ Shengjing Zhu ]
+  * Change IM_MODULE env for fcitx5 to "fcitx" (closes: #977203,
+LP: #1928360)
+
+ -- Shengjing Zhu   Mon, 30 Aug 2021 23:54:06 +0800
+
 im-config (0.46-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch
--- 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch
1970-01-01 08:00:00.0 +0800
+++ 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch
2021-08-30 23:54:06.0 +0800
@@ -0,0 +1,25 @@
+From: Gunnar Hjalmarsson 
+Date: Mon, 7 Jun 2021 09:29:12 +0200
+Subject: Change IM_MODULE env for fcitx5 to "fcitx"
+
+Closes: #977203
+Origin: https://salsa.debian.org/input-method-team/im-config/-/commit/53d6a32b
+---
+ data/23_fcitx5.rc | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/data/23_fcitx5.rc b/data/23_fcitx5.rc
+index e5e957b..c4a44cc 100644
+--- a/data/23_fcitx5.rc
 b/data/23_fcitx5.rc
+@@ -12,8 +12,8 @@ if [ "$IM_CONFIG_PHASE" = 1 ]; then
+ XMODIFIERS=@im=fcitx
+ 
+ # Let's assume all required modules are installed
+-GTK_IM_MODULE=fcitx5
+-QT_IM_MODULE=fcitx5
++GTK_IM_MODULE=fcitx
++QT_IM_MODULE=fcitx
+ CLUTTER_IM_MODULE=xim
+ 
+ fi
diff -Nru 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
--- 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
   1970-01-01 08:00:00.0 +0800
+++ 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
   2021-08-30 23:54:06.0 +0800
@@ -0,0 +1,37 @@
+From: Gunnar Hjalmarsson 
+Date: Mon, 16 Aug 2021 22:16:00 +0200
+Subject: Replace "fcitx" with "fcitx5" in IM_CONFIG_PREFERRED_RULE
+
+Closes: #990742
+Origin: https://salsa.debian.org/input-method-team/im-config/-/commit/e35ee1d2
+---
+ default/im-config-Debian | 2 +-
+ default/im-config-Ubuntu | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/default/im-config-Debian b/default/im-config-Debian
+index bb574de..6c53132 100644
+--- a/default/im-config-Debian
 b/default/im-config-Debian
+@@ -30,7 +30,7 @@ CJKV_DEFAULT_DESKTOP="*"
+ CJKV_LOCALES="zh_TW:zh_HK:zh_SG:zh_CN:ja_JP:ko_KR:vi_VN"
+ 
+ # Set locale dependent preferred IM over standard auto mode if not GNOME
+-IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx:zh_TW,fcitx:zh_HK,fcitx:zh_SG,fcitx"
++IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5"
+ 
+ # User and system wide configuration is normally done via im-config program.
+ # The above IM_CONFIG_PREFERRED_RULE sets locale dependent preferred IM
+diff --git a/default/im-config-Ubuntu b/default/im-config-Ubuntu
+index dfd537c..6ef8373 100644
+--- a/default/im-config-Ubuntu
 b/default/im-config-Ubuntu
+@@ -30,7 +30,7 @@ CJKV_DEFAULT_DESKTOP="LXQt"
+ CJKV_LOCALES="zh_TW:zh_HK:zh_SG:zh_CN:ja_JP:ko_KR:vi_VN"
+ 
+ # Set locale dependent preferred IM ove

Re: Bug#991961: golang-1.15: CVE-2021-36221

2021-08-06 Thread Shengjing Zhu
Hi,

On Sat, Aug 7, 2021 at 1:51 AM Salvatore Bonaccorso  wrote:
>
> Source: golang-1.15
> Version: 1.15.9-6
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/golang/go/issues/46866
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
>
> Hi,
>
> The following vulnerability was published for golang-1.15.
>
> CVE-2021-36221[0]:
> | net/http: panic due to racy read of persistConn after handler panic
>

The issue looks minor(upstream disclose it without pre-announce).
Should we fix it before the bullseye release?
Fixing issues in the compiler's std library needs to rebuild the whole
world, see #990825

Or we just postpone later, or just fix the compiler package along?

-- 
Shengjing Zhu



Bug#991287: unblock: containerd/1.4.5~ds1-2

2021-07-19 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package containerd

[ Reason ]
Backport patch for CVE-2021-32760:
https://github.com/containerd/containerd/security/advisories/GHSA-c72p-9xmj-rx3w

[ Impact ]
If it's blocked, the package has security issue.

[ Tests ]
Upstream has added a regression test to the patch.

[ Risks ]
Only one line change(in archive/tar_unix.go file), and a new test (in 
archive/tar_unix.go file).

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock containerd/1.4.5~ds1-2


diff -Nru containerd-1.4.5~ds1/debian/changelog 
containerd-1.4.5~ds1/debian/changelog
--- containerd-1.4.5~ds1/debian/changelog   2021-05-12 13:17:38.0 
+0800
+++ containerd-1.4.5~ds1/debian/changelog   2021-07-20 02:36:10.0 
+0800
@@ -1,3 +1,9 @@
+containerd (1.4.5~ds1-2) unstable; urgency=medium
+
+  * Backport patches for CVE-2021-32760
+
+ -- Shengjing Zhu   Tue, 20 Jul 2021 02:36:10 +0800
+
 containerd (1.4.5~ds1-1) unstable; urgency=medium
 
   * New upstream patch version v1.4.5
diff -Nru containerd-1.4.5~ds1/debian/gbp.conf 
containerd-1.4.5~ds1/debian/gbp.conf
--- containerd-1.4.5~ds1/debian/gbp.conf2021-05-12 13:17:38.0 
+0800
+++ containerd-1.4.5~ds1/debian/gbp.conf2021-07-20 02:36:10.0 
+0800
@@ -1,4 +1,5 @@
 [DEFAULT]
 pristine-tar = True
 debian-branch = debian/sid
+upstream-branch = upstream/sid
 dist = DEP14
diff -Nru containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch 
containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch
--- containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch   
1970-01-01 08:00:00.0 +0800
+++ containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch   
2021-07-20 02:36:10.0 +0800
@@ -0,0 +1,91 @@
+From 03aa748c11663e87a72fab92b7ab7c88c28bf13e Mon Sep 17 00:00:00 2001
+From: Derek McGowan 
+Date: Tue, 6 Jul 2021 12:37:54 -0700
+Subject: [PATCH 1/2] Use chmod path for checking symlink
+
+Signed-off-by: Derek McGowan 
+(cherry picked from commit 27597ccfd30d8aa06b448062896bccfb33ad8f22)
+Signed-off-by: Derek McGowan 
+---
+ archive/tar_unix.go | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/archive/tar_unix.go b/archive/tar_unix.go
+index 6e89d2fdbc9..c22e79bf2be 100644
+--- a/archive/tar_unix.go
 b/archive/tar_unix.go
+@@ -113,7 +113,7 @@ func handleTarTypeBlockCharFifo(hdr *tar.Header, path 
string) error {
+ 
+ func handleLChmod(hdr *tar.Header, path string, hdrInfo os.FileInfo) error {
+   if hdr.Typeflag == tar.TypeLink {
+-  if fi, err := os.Lstat(hdr.Linkname); err == nil && 
(fi.Mode() == 0) {
++  if fi, err := os.Lstat(path); err == nil && 
(fi.Mode() == 0) {
+   if err := os.Chmod(path, hdrInfo.Mode()); err != nil && 
!os.IsNotExist(err) {
+   return err
+   }
+
+From 664f93ead6c613a9f0e9932dfa75c602dbe35f41 Mon Sep 17 00:00:00 2001
+From: Derek McGowan 
+Date: Tue, 6 Jul 2021 16:23:03 -0700
+Subject: [PATCH 2/2] Add test for archive breakout test for lchmod
+
+Signed-off-by: Derek McGowan 
+(cherry picked from commit ad81d76219a75559cb9d74a214efe0d779d7cbef)
+Signed-off-by: Derek McGowan 
+---
+ archive/tar_test.go | 35 +++
+ 1 file changed, 35 insertions(+)
+
+diff --git a/archive/tar_test.go b/archive/tar_test.go
+index 568f5a95f1c..8ffd3f221b8 100644
+--- a/archive/tar_test.go
 b/archive/tar_test.go
+@@ -243,6 +243,11 @@ func TestBreakouts(t *testing.T) {
+   return nil
+   }
+   errFileDiff := errors.New("files differ")
++  td, err := ioutil.TempDir("", "test-breakouts-")
++  if err != nil {
++  t.Fatal(err)
++  }
++  defer os.RemoveAll(td)
+ 
+   isSymlinkFile := func(f string) func(string) error {
+   return func(root string) error {
+@@ -744,6 +749,36 @@ func TestBreakouts(t *testing.T) {
+   // resolution ends up just removing etc
+   validator: fileNotExists("etc/passwd"),
+   },
++  {
++
++  name: "HardlinkSymlinkChmod",
++  w: func() tartest.WriterToTar {
++  p := filepath.Join(td, "perm400")
++  if err := ioutil.WriteFile(p, []byte("..."), 
0400); err != nil {
++  t.Fatal(err)
++  }
++  ep := filepath.Join(td, 
"also-exists-outside-root")
++  if err := iout

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

2021-07-17 Thread Shengjing Zhu
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

2021-07-17 Thread Shengjing Zhu
(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

2021-07-17 Thread Shengjing Zhu
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

2021-07-17 Thread Shengjing Zhu
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

2021-07-14 Thread Shengjing Zhu
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

2021-07-14 Thread Shengjing Zhu
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

2021-07-14 Thread Shengjing Zhu
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

2021-07-13 Thread Shengjing Zhu
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

2021-07-08 Thread Shengjing Zhu
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



Bug#989498: unblock: golang-1.15/1.15.9-5

2021-06-14 Thread Shengjing Zhu
On Thu, Jun 10, 2021 at 7:23 PM Shengjing Zhu  wrote:
>
> On Sun, Jun 06, 2021 at 10:16:15PM +0200, Paul Gevers wrote:
> > So let's keep this bug open to keep track of this and only close it when
> > all rebuilds have migrated. Please know that I expect the golang team to
> > keep an eye on this too and warn us if anything is going wrong or takes
> > longer than expected. Please refrain from uploading any of the reverse
> > dependencies until their rebuild has migrated.
> >

Looks like @sramacher aged some packages today, now testing doesn't
have out-of-dated built-using Go packages.
Would you like to close the bug?

+ However one Go package is uploaded to unstable today[1], which I
think we will need to rebuild one more package[2] eventually, but I
think it could be tracked elsewhere?
+ @siretart want to upload podman, since it's a leaf package, and
doesn't have reverse built-using packages, I guess it doesn't need to
be tight with the rebuild progress?

[1] 
https://tracker.debian.org/news/1242770/accepted-golang-github-saracen-walker-012-1-source-into-unstable/
[2] only package fzf has built-using golang-github-saracen-walker

--
Shengjing Zhu



Bug#989498: unblock: golang-1.15/1.15.9-5

2021-06-10 Thread Shengjing Zhu
On Sun, Jun 06, 2021 at 10:16:15PM +0200, Paul Gevers wrote:
> So let's keep this bug open to keep track of this and only close it when
> all rebuilds have migrated. Please know that I expect the golang team to
> keep an eye on this too and warn us if anything is going wrong or takes
> longer than expected. Please refrain from uploading any of the reverse
> dependencies until their rebuild has migrated.
> 

Most packages have been migrated today. However following packages are missing
unblock for binNMU.

+ delve/1.6.1-1
+ golang-github-sylabs-sif/1.0.9-2/ mipsel and mips64el only
+ runc/1.0.0~rc93+ds1-5



Bug#989498: unblock: golang-1.15/1.15.9-5

2021-06-06 Thread Shengjing Zhu
On Sun, Jun 6, 2021 at 11:46 AM Paul Gevers  wrote:
>
> Control: tags -1 moreinfo
>
> Hi Shengjing,
>
> On 05-06-2021 13:57, Shengjing Zhu wrote:
> > Please unblock package golang-1.15
>
> You're well aware that golang builds statically so normally we're not
> done with just accepting one package. Do we now need to also rebuild
> everything that build depends on golang (I'd expect so)?

Yes. That's why the compiler is uploaded in unstable, as rebuilding in
unstable is much easier before release. We didn't manage to rebuild
any package in buster for the compiler security update after release.

> Did anything in
> the golang community get uploaded to unstable that needs reverting
> before it can migrate?

>From my observation[1], all packages are in good condition, thanks to
the freezone policy this year. Most Go packages are not key packages,
and have non-trivial autopkgtest.
+ one package still has long migration days, which is secsipidx(only 5
of 20 days old), but it will not block the migration of the Go
compiler or other packages.
+ one package won't migrate, which is kubernetes, but the
outdated-built-using rebuild script will not pick it up, as it doesn't
have built-using field. (This doesn't mean it doesn't need to be
rebuilt for the compiler security update, but no one cares about this
package).

[1] https://people.debian.org/~zhsj/out-of-sync.html

-- 
Shengjing Zhu



Bug#989498: unblock: golang-1.15/1.15.9-5

2021-06-05 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-1.15

[ Reason ]

Backport patches for CVE-2021-33195 CVE-2021-33197 CVE-2021-33198

[ Impact ]
Security issue.

[ Tests ]
Unit tests provided by upstream.

[ Risks ]
+ Key package

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock golang-1.15/1.15.9-5


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-02 10:56:03.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-06-05 19:36:34.0 +0800
@@ -1,3 +1,15 @@
+golang-1.15 (1.15.9-5) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patches for CVE-2021-33195 CVE-2021-33197 CVE-2021-33198
++ CVE-2021-33195: net: Lookup functions may return invalid host names
++ CVE-2021-33197: net/http/httputil: ReverseProxy forwards Connection
+  headers if first one is empty
++ CVE-2021-33198: math/big: (*Rat).SetString with 
"1.770p02041010010011001001"
+  crashes with "makeslice: len out of range"
+
+ -- Shengjing Zhu   Sat, 05 Jun 2021 19:36:34 +0800
+
 golang-1.15 (1.15.9-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch 
golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch
--- golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch   
1970-01-01 08:00:00.0 +0800
+++ golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch   
2021-06-05 19:36:34.0 +0800
@@ -0,0 +1,369 @@
+From 31d60cda1f58b7558fc5725d2b9e4531655d980e Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Thu, 27 May 2021 10:40:06 -0700
+Subject: [PATCH] [release-branch.go1.15] net: verify results from Lookup* are
+ valid domain names
+
+For the methods LookupCNAME, LookupSRV, LookupMX, LookupNS, and
+LookupAddr check that the returned domain names are in fact valid DNS
+names using the existing isDomainName function.
+
+Thanks to Philipp Jeitner and Haya Shulman from Fraunhofer SIT for
+reporting this issue.
+
+Updates #46241
+Fixes #46356
+Fixes CVE-2021-33195
+
+Change-Id: I47a4f58c031cb752f732e88bbdae7f819f0af4f3
+Reviewed-on: https://go-review.googlesource.com/c/go/+/323131
+Trust: Roland Shoemaker 
+Run-TryBot: Roland Shoemaker 
+TryBot-Result: Go Bot 
+Reviewed-by: Filippo Valsorda 
+Reviewed-by: Katie Hockman 
+(cherry picked from commit cdcd02842da7c004efd023881e3719105209c908)
+Reviewed-on: https://go-review.googlesource.com/c/go/+/323269
+---
+ src/net/dnsclient_unix_test.go | 157 +
+ src/net/lookup.go  | 111 ---
+ 2 files changed, 255 insertions(+), 13 deletions(-)
+
+diff --git a/src/net/dnsclient_unix_test.go b/src/net/dnsclient_unix_test.go
+index 06553636eee25..819f20b887ae6 100644
+--- a/src/net/dnsclient_unix_test.go
 b/src/net/dnsclient_unix_test.go
+@@ -1799,3 +1799,160 @@ func TestPTRandNonPTR(t *testing.T) {
+   t.Errorf("names = %q; want %q", names, want)
+   }
+ }
++
++func TestCVE202133195(t *testing.T) {
++  fake := fakeDNSServer{
++  rh: func(n, _ string, q dnsmessage.Message, _ time.Time) 
(dnsmessage.Message, error) {
++  r := dnsmessage.Message{
++  Header: dnsmessage.Header{
++  ID: q.Header.ID,
++  Response:   true,
++  RCode:  
dnsmessage.RCodeSuccess,
++  RecursionAvailable: true,
++  },
++  Questions: q.Questions,
++  }
++  switch q.Questions[0].Type {
++  case dnsmessage.TypeCNAME:
++  r.Answers = []dnsmessage.Resource{}
++  case dnsmessage.TypeA: // CNAME lookup uses a A/ as 
a proxy
++  r.Answers = append(r.Answers,
++  dnsmessage.Resource{
++  Header: 
dnsmessage.ResourceHeader{
++  Name:   
dnsmessage.MustNewName(".golang.org."),
++  Type:   
dnsmessage.TypeA,
++  Class:  
dnsmessage.ClassINET,
++  Length: 4,
++  },
++  Body: {
++ 

Bug#989380: unblock: golang-1.15/1.15.9-4

2021-06-02 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-1.15

[ Reason ]
Backport patch for CVE-2021-33196

[ Impact ]
Security issue

[ Tests ]
Upstream has its own unit tests, and a new test is added in patch as
well.

[ Risks ]
+ Key package
+ Diff is small

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock golang-1.15/1.15.9-4

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-05-08 14:22:26.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-06-02 10:56:03.0 +0800
@@ -1,3 +1,12 @@
+golang-1.15 (1.15.9-4) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patch for CVE-2021-33196
+archive/zip: malformed archive may cause panic or memory exhaustion
+https://github.com/golang/go/issues/46396
+
+ -- Shengjing Zhu   Wed, 02 Jun 2021 10:56:03 +0800
+
 golang-1.15 (1.15.9-3) unstable; urgency=medium
 
   * Fix failed TestDependencyVersionsConsistent test.
diff -Nru golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch 
golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch
--- golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch 1970-01-01 
08:00:00.0 +0800
+++ golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch 2021-06-02 
10:56:03.0 +0800
@@ -0,0 +1,124 @@
+From: Roland Shoemaker 
+Date: Tue, 11 May 2021 11:31:31 -0700
+Subject: archive/zip: only preallocate File slice if reasonably sized
+
+Since the number of files in the EOCD record isn't validated, it isn't
+safe to preallocate Reader.Files using that field. A malformed archive
+can indicate it contains up to 1 << 128 - 1 files. We can still safely
+preallocate the slice by checking if the specified number of files in
+the archive is reasonable, given the size of the archive.
+
+Thanks to the OSS-Fuzz project for discovering this issue and to
+Emmanuel Odeke for reporting it.
+
+Updates #46242
+Fixes #46396
+Fixes CVE-2021-33196
+
+Change-Id: I3c76d8eec178468b380d87fdb4a3f2cb06f0ee76
+Reviewed-on: https://go-review.googlesource.com/c/go/+/318909
+Trust: Roland Shoemaker 
+Trust: Katie Hockman 
+Trust: Joe Tsai 
+Run-TryBot: Roland Shoemaker 
+TryBot-Result: Go Bot 
+Reviewed-by: Katie Hockman 
+Reviewed-by: Joe Tsai 
+(cherry picked from commit 74242baa4136c7a9132a8ccd9881354442788c8c)
+Reviewed-on: https://go-review.googlesource.com/c/go/+/322949
+Reviewed-by: Filippo Valsorda 
+
+Origin: backport, 
https://github.com/golang/go/commit/c92adf420a3d9a5510f9aea382d826f0c9216a10
+---
+ src/archive/zip/reader.go  | 10 ++-
+ src/archive/zip/reader_test.go | 59 ++
+ 2 files changed, 68 insertions(+), 1 deletion(-)
+
+diff --git a/src/archive/zip/reader.go b/src/archive/zip/reader.go
+index 13ff9dd..2d5151a 100644
+--- a/src/archive/zip/reader.go
 b/src/archive/zip/reader.go
+@@ -84,7 +84,15 @@ func (z *Reader) init(r io.ReaderAt, size int64) error {
+   return err
+   }
+   z.r = r
+-  z.File = make([]*File, 0, end.directoryRecords)
++  // Since the number of directory records is not validated, it is not
++  // safe to preallocate z.File without first checking that the specified
++  // number of files is reasonable, since a malformed archive may
++  // indicate it contains up to 1 << 128 - 1 files. Since each file has a
++  // header which will be _at least_ 30 bytes we can safely preallocate
++  // if (data size / 30) >= end.directoryRecords.
++  if (uint64(size)-end.directorySize)/30 >= end.directoryRecords {
++  z.File = make([]*File, 0, end.directoryRecords)
++  }
+   z.Comment = end.comment
+   rs := io.NewSectionReader(r, 0, size)
+   if _, err = rs.Seek(int64(end.directoryOffset), io.SeekStart); err != 
nil {
+diff --git a/src/archive/zip/reader_test.go b/src/archive/zip/reader_test.go
+index adca87a..6f67d2e 100644
+--- a/src/archive/zip/reader_test.go
 b/src/archive/zip/reader_test.go
+@@ -1070,3 +1070,62 @@ func TestIssue12449(t *testing.T) {
+   t.Errorf("Error reading the archive: %v", err)
+   }
+ }
++
++func TestCVE202133196(t *testing.T) {
++  // Archive that indicates it has 1 << 128 -1 files,
++  // this would previously cause a panic due to attempting
++  // to allocate a slice with 1 << 128 -1 elements.
++  data := []byte{
++  0x50, 0x4b, 0x03, 0x04, 0x14, 0x00, 0x08, 0x08,
++  0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
++  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
++  0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x02,
++  0x03, 0x62, 0x61, 0x65, 0x03, 0x04, 0x00, 0x00

Bug#988983: unblock: golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4

2021-05-29 Thread Shengjing Zhu
Hi,

On Sat, May 22, 2021 at 10:21 PM Shengjing Zhu  wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: z...@debian.org
>
> Please unblock package golang-golang-x-net
>
> [ Reason ]
> Backport patch for CVE-2021-33194
> x/net/html: infinite loop in ParseFragment
>
> [ Impact ]
> It fixes security issues.
>
> [ Tests ]
> Upstream has added a unit test for the issue in the patch.
>
> [ Risks ]
> + Diff is small
> + Key package
>
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
>
> [ Other info ]
> Need rebuild packages which have built-using with old version of
> golang-golang-x-net
>
> unblock golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4

Ping?

-- 
Shengjing Zhu



Bug#989194: unblock: smartdns/33+dfsg-2.1

2021-05-28 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package smartdns

[ Reason ]
Fix invalid systemd unit file, https://bugs.debian.org/989072

[ Impact ]
systemd journal will have "Unknown key" noise.

[ Tests ]
I have installed the new version, and check the systemd journal.
There's no complain from systemd now.

[ Risks ]
No, trivial fix.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock smartdns/33+dfsg-2.1


diff -Nru smartdns-33+dfsg/debian/changelog smartdns-33+dfsg/debian/changelog
--- smartdns-33+dfsg/debian/changelog   2020-12-02 19:57:30.0 +0800
+++ smartdns-33+dfsg/debian/changelog   2021-05-28 00:37:23.0 +0800
@@ -1,3 +1,12 @@
+smartdns (33+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+ACK by maintainer.
+  * Backport patch to fix TimeoutStopSec key in systemd unit file
+(Closes: #989072)
+
+ -- Shengjing Zhu   Fri, 28 May 2021 00:37:23 +0800
+
 smartdns (33+dfsg-2) unstable; urgency=medium
 
   [ Chris Lamb ]
diff -Nru 
smartdns-33+dfsg/debian/patches/fix-TimeoutStopSec-key-in-systemd-unit.patch 
smartdns-33+dfsg/debian/patches/fix-TimeoutStopSec-key-in-systemd-unit.patch
--- 
smartdns-33+dfsg/debian/patches/fix-TimeoutStopSec-key-in-systemd-unit.patch
1970-01-01 08:00:00.0 +0800
+++ 
smartdns-33+dfsg/debian/patches/fix-TimeoutStopSec-key-in-systemd-unit.patch
2021-05-28 00:37:23.0 +0800
@@ -0,0 +1,29 @@
+From: Felix Yan 
+Date: Thu, 10 Sep 2020 21:54:48 +0800
+Subject: fix TimeoutStopSec key in systemd unit
+
+Origin: backport, 
https://github.com/pymumu/smartdns/commit/baa1397fb0d748055d56042739f19aff3f69c4fe
+---
+ systemd/smartdns.service.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/systemd/smartdns.service.in b/systemd/smartdns.service.in
+index 79e218c..450e0a0 100644
+--- a/systemd/smartdns.service.in
 b/systemd/smartdns.service.in
+@@ -3,7 +3,6 @@ Description=smartdns server
+ After=network.target 
+ StartLimitBurst=0
+ StartLimitIntervalSec=60
+-TimeoutStopSec=5
+ 
+ [Service]
+ Type=forking
+@@ -13,6 +12,7 @@ ExecStart=@SBINDIR@/smartdns -p @RUNSTATEDIR@/smartdns.pid 
$SMART_DNS_OPTS
+ KillMode=process
+ Restart=always
+ RestartSec=2
++TimeoutStopSec=5
+ 
+ [Install]
+ WantedBy=multi-user.target
diff -Nru smartdns-33+dfsg/debian/patches/series 
smartdns-33+dfsg/debian/patches/series
--- smartdns-33+dfsg/debian/patches/series  2020-12-02 19:56:09.0 
+0800
+++ smartdns-33+dfsg/debian/patches/series  2021-05-28 00:37:23.0 
+0800
@@ -1,2 +1,3 @@
 init.patch
 reproducible-build.patch
+fix-TimeoutStopSec-key-in-systemd-unit.patch



Bug#988983: unblock: golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4

2021-05-22 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-golang-x-net

[ Reason ]
Backport patch for CVE-2021-33194
x/net/html: infinite loop in ParseFragment

[ Impact ]
It fixes security issues.

[ Tests ]
Upstream has added a unit test for the issue in the patch.

[ Risks ]
+ Diff is small
+ Key package

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Need rebuild packages which have built-using with old version of
golang-golang-x-net

unblock golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4


diff -Nru golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog
--- golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog   
2021-05-08 12:12:17.0 +0800
+++ golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog   
2021-05-22 22:01:02.0 +0800
@@ -1,3 +1,11 @@
+golang-golang-x-net (1:0.0+git20210119.5f4716e+dfsg-4) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patch for CVE-2021-33194
+x/net/html: infinite loop in ParseFragment
+
+ -- Shengjing Zhu   Sat, 22 May 2021 22:01:02 +0800
+
 golang-golang-x-net (1:0.0+git20210119.5f4716e+dfsg-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
--- 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
1970-01-01 08:00:00.0 +0800
+++ 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
2021-05-22 22:01:02.0 +0800
@@ -0,0 +1,114 @@
+From: Nigel Tao 
+Date: Sun, 18 Apr 2021 21:15:27 +1000
+Subject: html: ignore templates nested within foreign content
+
+Fixes #46288
+Fixes CVE-2021-33194
+
+Change-Id: I2fe39702de8e9aab29965c1526e377a6f9cdf056
+Reviewed-on: https://go-review.googlesource.com/c/net/+/311090
+Reviewed-by: Filippo Valsorda 
+Run-TryBot: Filippo Valsorda 
+Trust: Roland Shoemaker 
+TryBot-Result: Go Bot 
+---
+ html/parse.go  | 24 +++-
+ html/parse_test.go | 22 ++
+ 2 files changed, 45 insertions(+), 1 deletion(-)
+
+diff --git a/html/parse.go b/html/parse.go
+index f91466f..038941d 100644
+--- a/html/parse.go
 b/html/parse.go
+@@ -663,6 +663,24 @@ func inHeadIM(p *parser) bool {
+   // Ignore the token.
+   return true
+   case a.Template:
++  // TODO: remove this divergence from the HTML5 spec.
++  //
++  // We don't handle all of the corner cases when mixing 
foreign
++  // content (i.e.  or ) with . 
Without this
++  // early return, we can get into an infinite loop, 
possibly because
++  // of the "TODO... further divergence" a little below.
++  //
++  // As a workaround, if we are mixing foreign content 
and templates,
++  // just ignore the rest of the HTML. Foreign content is 
rare and a
++  // relatively old HTML feature. Templates are also rare 
and a
++  // relatively new HTML feature. Their combination is 
very rare.
++  for _, e := range p.oe {
++  if e.Namespace != "" {
++  p.im = ignoreTheRemainingTokens
++  return true
++  }
++  }
++
+   p.addElement()
+   p.afe = append(p.afe, )
+   p.framesetOK = false
+@@ -683,7 +701,7 @@ func inHeadIM(p *parser) bool {
+   if !p.oe.contains(a.Template) {
+   return true
+   }
+-  // TODO: remove this divergence from the HTML5 spec.
++  // TODO: remove this further divergence from the HTML5 
spec.
+   //
+   // See 
https://bugs.chromium.org/p/chromium/issues/detail?id=829668
+   p.generateImpliedEndTags()
+@@ -2127,6 +2145,10 @@ func afterAfterFramesetIM(p *parser) bool {
+   return true
+ }
+ 
++func ignoreTheRemainingTokens(p *parser) bool {
++  return true
++}
++
+ const whitespaceOrNUL = whitespace + "\x00"
+ 
+ // Section 12.2.6.5
+diff --git a/html/parse_test.go b/html/parse_test.go
+index 58dce5f..019333d 100644
+--- a/html/parse_test.go
 b/html/parse_test.go
+@@ -267,6 +267,9 @

Bug#988802: unblock: runc/1.0.0~rc93+ds1-4

2021-05-19 Thread Shengjing Zhu
On Thu, May 20, 2021 at 2:33 AM Shengjing Zhu  wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: z...@debian.org
>
> Please unblock package runc
>
> [ Reason ]
> Fix CVE-2021-30465
> https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r
>
> [ Impact ]
> The package can migrate itself(have autopkgtest and not key package),
> but I'd like to reduce the age.
>
> [ Tests ]
> I have done some basic tests. But I'm not sure how to trigger the security
> issue that I can't verify if it's really fixed.
>
> [ Risks ]
> The patch provided by upstream can't be applied clearly to the version we have
> in sid. So I look the changes and backport another two PR, which makes the 
> diff
> a bit large.
>

After I have uploaded -4, then I find upstream has provided a patchset
for runc/1.0.0~rc93, but only on oss-security list,
https://www.openwall.com/lists/oss-security/2021/05/19/2

So the patches I made in -4 are replaced by upstream one.

$ cat debian/patches/CVE-2021-30465/*|diffstat
b/libcontainer/container_linux.go  |7 +--
b/libcontainer/init_linux.go   |1
b/libcontainer/rootfs_linux.go |   42 +++---
b/libcontainer/specconv/example.go |   18 +++
b/libcontainer/utils/utils.go  |   54 +++
b/libcontainer/utils/utils_test.go |   35 +++
libcontainer/container_linux.go|4 +
libcontainer/rootfs_linux.go   |  289
++--
8 files changed, 283 insertions(+), 167 deletions(-)

The changes are almost the same with -4.

Please unblock runc/1.0.0~rc93+ds1-5



Bug#988802: unblock: runc/1.0.0~rc93+ds1-4

2021-05-19 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package runc

[ Reason ]
Fix CVE-2021-30465
https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r

[ Impact ]
The package can migrate itself(have autopkgtest and not key package),
but I'd like to reduce the age.

[ Tests ]
I have done some basic tests. But I'm not sure how to trigger the security
issue that I can't verify if it's really fixed.

[ Risks ]
The patch provided by upstream can't be applied clearly to the version we have
in sid. So I look the changes and backport another two PR, which makes the diff
a bit large.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing
  Since only patches are added in debian/patches dir, I just attached the 3
  new patches.

[ Other info ]

unblock runc/1.0.0~rc93+ds1-4


debian/changelog:

 runc (1.0.0~rc93+ds1-4) unstable; urgency=high
 .
   * Team upload.
   * Backport patches for CVE-2021-30465 (Closes: #988768)
 To apply CVE-2021-30465 patch clearly, following PR are backported as
 well:
 + https://github.com/opencontainers/runc/pull/2798
 + https://github.com/opencontainers/runc/pull/2818

$ cat debian/patches/00{11,12,13}*|filterdiff -x '*.bats' -x '*_test.go' 
|diffstat

 b/libcontainer/container_linux.go  |   10 +
 b/libcontainer/init_linux.go   |1
 b/libcontainer/rootfs_linux.go |   64 ++---
 b/libcontainer/specconv/example.go |   18 +-
 b/libcontainer/utils/utils.go  |   54 +++
 libcontainer/container_linux.go|   52 ++-
 libcontainer/rootfs_linux.go   |  251 ++---
 7 files changed, 283 insertions(+), 167 deletions(-)

$ cat debian/patches/00{11,12,13}*|filterdiff -x '*.bats' -x '*_test.go'

From: Kir Kolyshkin 
Date: Tue, 23 Feb 2021 17:58:07 -0800
Subject: PR2818 Fix cgroup2 mount for rootless case

Backport this PR so we can apply the patch for CVE-2021-30465

1. libct/newInitConfig: nit
2. libct/rootfs: introduce and use mountConfig
3 .libct/rootfs/mountCgroupV2: minor refactor
4. Fix cgroup2 mount for rootless case
5. tests/int: use bfq test with rootless
6. tests/int: add a case for cgroupv2 mount

Origin: backport, https://github.com/opencontainers/runc/pull/2818
---
 libcontainer/container_linux.go  | 10 +--
 libcontainer/init_linux.go   |  1 +
 libcontainer/rootfs_linux.go | 64 
 libcontainer/specconv/example.go | 18 +--
 tests/integration/cgroups.bats   | 34 +
 5 files changed, 96 insertions(+), 31 deletions(-)

diff --git a/libcontainer/container_linux.go b/libcontainer/container_linux.go
index 3dca29e..1cbc734 100644
--- a/libcontainer/container_linux.go
+++ b/libcontainer/container_linux.go
@@ -594,6 +594,9 @@ func (c *linuxContainer) newInitConfig(process *Process) 
*initConfig {
AppArmorProfile:  c.config.AppArmorProfile,
ProcessLabel: c.config.ProcessLabel,
Rlimits:  c.config.Rlimits,
+   CreateConsole:process.ConsoleSocket != nil,
+   ConsoleWidth: process.ConsoleWidth,
+   ConsoleHeight:process.ConsoleHeight,
}
if process.NoNewPrivileges != nil {
cfg.NoNewPrivileges = *process.NoNewPrivileges
@@ -607,9 +610,10 @@ func (c *linuxContainer) newInitConfig(process *Process) 
*initConfig {
if len(process.Rlimits) > 0 {
cfg.Rlimits = process.Rlimits
}
-   cfg.CreateConsole = process.ConsoleSocket != nil
-   cfg.ConsoleWidth = process.ConsoleWidth
-   cfg.ConsoleHeight = process.ConsoleHeight
+   if cgroups.IsCgroup2UnifiedMode() {
+   cfg.Cgroup2Path = c.cgroupManager.Path("")
+   }
+
return cfg
 }
 
diff --git a/libcontainer/init_linux.go b/libcontainer/init_linux.go
index c57af0e..6817970 100644
--- a/libcontainer/init_linux.go
+++ b/libcontainer/init_linux.go
@@ -70,6 +70,7 @@ type initConfig struct {
RootlessEUID bool  `json:"rootless_euid,omitempty"`
RootlessCgroups  bool  
`json:"rootless_cgroups,omitempty"`
SpecState*specs.State  `json:"spec_state,omitempty"`
+   Cgroup2Path  string`json:"cgroup2_path,omitempty"`
 }
 
 type initer interface {
diff --git a/libcontainer/rootfs_linux.go b/libcontainer/rootfs_linux.go
index 411496a..5d2d74c 100644
--- a/libcontainer/rootfs_linux.go
+++ b/libcontainer/rootfs_linux.go
@@ -17,6 +17,7 @@ import (
"github.com/moby/sys/mountinfo"
"github.com/mrunalp/fileutils"
"github.com/opencontainers/runc/libcontainer/cgroups"
+   "github.com/opencontainers/runc/libcontainer/cgroups/fs2"

Bug#988579: unblock: kcm-fcitx5/5.0.3-3

2021-05-16 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package kcm-fcitx5

[ Reason ]
Add missing dependencies.

[ Impact ]
Installing kde-config-fcitx5 may not work out of box.

[ Tests ]
Check the install log.

[ Risks ]
No

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock kcm-fcitx5/5.0.3-3

diffstat for kcm-fcitx5-5.0.3 kcm-fcitx5-5.0.3

 changelog |6 ++
 control   |3 +++
 2 files changed, 9 insertions(+)

diff -Nru kcm-fcitx5-5.0.3/debian/changelog kcm-fcitx5-5.0.3/debian/changelog
--- kcm-fcitx5-5.0.3/debian/changelog   2021-02-22 00:54:24.0 +0800
+++ kcm-fcitx5-5.0.3/debian/changelog   2021-05-16 14:54:13.0 +0800
@@ -1,3 +1,9 @@
+kcm-fcitx5 (5.0.3-3) unstable; urgency=medium
+
+  * Add missing Depends for kde-config-fcitx5
+
+ -- Shengjing Zhu   Sun, 16 May 2021 14:54:13 +0800
+
 kcm-fcitx5 (5.0.3-2) unstable; urgency=medium
 
   * Backport patch to fix typo in desktop file
diff -Nru kcm-fcitx5-5.0.3/debian/control kcm-fcitx5-5.0.3/debian/control
--- kcm-fcitx5-5.0.3/debian/control 2021-02-22 00:54:24.0 +0800
+++ kcm-fcitx5-5.0.3/debian/control 2021-05-16 14:54:13.0 +0800
@@ -53,6 +53,9 @@
 Architecture: any
 Multi-Arch: same
 Depends:
+ kde-cli-tools,
+ qml-module-org-kde-kcm,
+ qml-module-org-kde-kirigami2,
  ${misc:Depends},
  ${shlibs:Depends},
 Description: KDE configuration module for Fcitx5



Bug#988210: [pre-approval] unblock: golang-1.15/1.15.9-2

2021-05-08 Thread Shengjing Zhu
Control: retitle -1 unblock: golang-1.15/1.15.9-3

On Fri, May 07, 2021 at 10:22:04PM +0200, Sebastian Ramacher wrote:
> > Please unblock package golang-1.15
> > 
> > [ Reason ]
> > Backport patch for CVE-2021-31525
> > net/http: ReadRequest can stack overflow due to recursion with very
> > large headers. https://github.com/golang/go/issues/45711
> 
> Please go ahead und remove the moreinfo tag once the package is
> available in unstable.
> 

It seems I forget to run all the test in my local sbuild env.
golang-1.15/1.15.9-2 FTBFS on buildd, so here is golang-1.15/1.15.9-3

new diff:

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-03-11 23:43:18.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-05-08 14:22:26.0 +0800
@@ -1,3 +1,27 @@
+golang-1.15 (1.15.9-3) unstable; urgency=medium
+
+  * Fix failed TestDependencyVersionsConsistent test.
+When dpkg-source unpack tarball, it produces .pc dir in source dir.
+The last patch 0007-CVE-2021-31525.patch causes
+go.mod/go.sum/modules.txt files in .pc dir with old content.
+Then TestDependencyVersionsConsistent picks these old content in .pc
+dir, results error:
+--- FAIL: TestDependencyVersionsConsistent (0.00s)
+moddeps_test.go:217: Modules within GOROOT require different versions 
of golang.org/x/net.
+moddeps_test.go:229: std   requires 
v0.0.0-20201008223702-a5fa9d4b7c91
+moddeps_test.go:229: std   requires 
v0.0.0-20210428183841-261fb518b1ed
+
+ -- Shengjing Zhu   Sat, 08 May 2021 14:22:26 +0800
+
+golang-1.15 (1.15.9-2) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patch for CVE-2021-31525
+net/http: ReadRequest can stack overflow due to recursion with very
+large headers. https://github.com/golang/go/issues/45711
+
+ -- Shengjing Zhu   Sat, 08 May 2021 02:45:35 +0800
+
 golang-1.15 (1.15.9-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
golang-1.15-1.15.9/debian/patches/0006-skip-userns-test-in-schroot-as-well.patch
 
golang-1.15-1.15.9/debian/patches/0006-skip-userns-test-in-schroot-as-well.patch
--- 
golang-1.15-1.15.9/debian/patches/0006-skip-userns-test-in-schroot-as-well.patch
2021-03-11 23:43:18.0 +0800
+++ 
golang-1.15-1.15.9/debian/patches/0006-skip-userns-test-in-schroot-as-well.patch
2021-05-08 14:22:26.0 +0800
@@ -3,7 +3,6 @@
 Subject: skip userns test in schroot as well
 
 When schroot is using overlayfs, it fails to detect it as chroot.
-
 ---
  src/syscall/exec_linux_test.go | 7 +++
  1 file changed, 7 insertions(+)
diff -Nru golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch 
golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch
--- golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch 1970-01-01 
08:00:00.0 +0800
+++ golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch 2021-05-08 
14:22:26.0 +0800
@@ -0,0 +1,45 @@
+From: Katie Hockman 
+Date: Wed, 28 Apr 2021 14:47:48 -0400
+Subject: [PATCH] [release-branch.go1.15] std: update golang.org/x/net to
+ 20210428183841-261fb518b1ed
+
+Steps:
+  go get -d golang.org/x/net@release-branch.go1.15
+  go mod tidy
+  go mod vendor
+
+This http2 bundle does not need to be updated.
+
+Fixes #45711
+
+Change-Id: I085ca592dfc8d5d9c328a7979142e88e7130a813
+Reviewed-on: https://go-review.googlesource.com/c/go/+/314790
+Trust: Katie Hockman 
+Run-TryBot: Katie Hockman 
+Reviewed-by: Dmitri Shuralyov 
+---
+ src/vendor/golang.org/x/net/http/httpguts/httplex.go | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/src/vendor/golang.org/x/net/http/httpguts/httplex.go 
b/src/vendor/golang.org/x/net/http/httpguts/httplex.go
+index e7de24e..c79aa73 100644
+--- a/src/vendor/golang.org/x/net/http/httpguts/httplex.go
 b/src/vendor/golang.org/x/net/http/httpguts/httplex.go
+@@ -137,11 +137,13 @@ func trimOWS(x string) string {
+ // contains token amongst its comma-separated tokens, ASCII
+ // case-insensitively.
+ func headerValueContainsToken(v string, token string) bool {
+-  v = trimOWS(v)
+-  if comma := strings.IndexByte(v, ','); comma != -1 {
+-  return tokenEqual(trimOWS(v[:comma]), token) || 
headerValueContainsToken(v[comma+1:], token)
++  for comma := strings.IndexByte(v, ','); comma != -1; comma = 
strings.IndexByte(v, ',') {
++  if tokenEqual(trimOWS(v[:comma]), token) {
++  return true
++  }
++  v = v[comma+1:]
+   }
+-  return tokenEqual(v, token)
++  return tokenEqual(trimOWS(v), token)
+ }
+ 
+ // lowerASCII returns the ASCII lowercase version of b.
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-03-11 23:43:18.0 
+0800
+++ golang-1.15-1.15.9/debian/patches/series2021-05-08

Bug#988223: unblock: golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-3

2021-05-07 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-golang-x-net

[ Reason ]
Same as #988210, backport patch for CVE-2021-31525
net/http: ReadRequest can stack overflow due to recursion with very
large headers. https://github.com/golang/go/issues/45710

[ Impact ]
Fix a security issue.

[ Tests ]
Manual test for the affected function.

[ Risks ]
The diff is small.
The package is key package.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
No

unblock golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-3


diff -Nru golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog
--- golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog   
2021-02-05 07:37:28.0 +0800
+++ golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog   
2021-05-08 12:12:17.0 +0800
@@ -1,3 +1,12 @@
+golang-golang-x-net (1:0.0+git20210119.5f4716e+dfsg-3) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patch for CVE-2021-31525
+net/http: ReadRequest can stack overflow due to recursion with very
+large headers. https://github.com/golang/go/issues/45710
+
+ -- Shengjing Zhu   Sat, 08 May 2021 12:12:17 +0800
+
 golang-golang-x-net (1:0.0+git20210119.5f4716e+dfsg-2) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-31525.patch
 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-31525.patch
--- 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-31525.patch
1970-01-01 08:00:00.0 +0800
+++ 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-31525.patch
2021-05-08 12:12:17.0 +0800
@@ -0,0 +1,49 @@
+From 89ef3d95e781148a0951956029c92a211477f7f9 Mon Sep 17 00:00:00 2001
+From: Katie Hockman 
+Date: Fri, 23 Apr 2021 12:56:01 -0400
+Subject: [PATCH] http/httpguts: remove recursion in HeaderValuesContainsToken
+
+Previously, httpguts.HeaderValuesContainsToken called a
+function which could recurse to the point of a stack
+overflow when given a very large header (~10MB).
+
+Credit to Guido Vranken who reported the crash as
+part of the Ethereum 2.0 bounty program.
+
+Fixes CVE-2021-31525
+
+Fixes golang/go#45710
+
+Change-Id: I2c54ce3b2acf1c5efdea66db0595b93a3f5ae5f3
+Reviewed-on: https://go-review.googlesource.com/c/net/+/313069
+Trust: Katie Hockman 
+Run-TryBot: Katie Hockman 
+TryBot-Result: Go Bot 
+Reviewed-by: Filippo Valsorda 
+Reviewed-by: Roland Shoemaker 
+---
+ http/httpguts/httplex.go | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/http/httpguts/httplex.go b/http/httpguts/httplex.go
+index e7de24ee6..c79aa73f2 100644
+--- a/http/httpguts/httplex.go
 b/http/httpguts/httplex.go
+@@ -137,11 +137,13 @@ func trimOWS(x string) string {
+ // contains token amongst its comma-separated tokens, ASCII
+ // case-insensitively.
+ func headerValueContainsToken(v string, token string) bool {
+-  v = trimOWS(v)
+-  if comma := strings.IndexByte(v, ','); comma != -1 {
+-  return tokenEqual(trimOWS(v[:comma]), token) || 
headerValueContainsToken(v[comma+1:], token)
++  for comma := strings.IndexByte(v, ','); comma != -1; comma = 
strings.IndexByte(v, ',') {
++  if tokenEqual(trimOWS(v[:comma]), token) {
++  return true
++  }
++  v = v[comma+1:]
+   }
+-  return tokenEqual(v, token)
++  return tokenEqual(trimOWS(v), token)
+ }
+ 
+ // lowerASCII returns the ASCII lowercase version of b.
diff -Nru 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/series 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/series
--- golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/series  
2020-02-21 21:20:40.0 +0800
+++ golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/series  
2021-05-08 12:12:17.0 +0800
@@ -1 +1,2 @@
 publicsuffix.patch
+CVE-2021-31525.patch



Bug#988210: [pre-approval] unblock: golang-1.15/1.15.9-2

2021-05-07 Thread Shengjing Zhu
On Sat, May 8, 2021 at 3:18 AM Shengjing Zhu  wrote:
[...]
> Due to the static link of Go packages, and the out of date built-using
> thing, it needs another round of rebuild of all Go packages before
> bullseye release.

Regarding to rebuild Go packages, I think it's easier if we do it
before release.
AFAIK, rebuild in stable doesn't happen for buster when golang-1.11
has security fixes. And I'm unsure if it will happen in bullseye.

-- 
Shengjing Zhu



Bug#988210: [pre-approval] unblock: golang-1.15/1.15.9-2

2021-05-07 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-1.15

[ Reason ]
Backport patch for CVE-2021-31525
net/http: ReadRequest can stack overflow due to recursion with very
large headers. https://github.com/golang/go/issues/45711

[ Impact ]
Though CVE is assigned, the issue doesn't look like a serious one.
So if it's not approved, I think we can address it with other future
security fixes through DSA after release.

[ Tests ]
I have did a manual test for the affected function, to see if it's
stackoverflow with and without patch.

[ Risks ]
The diff is small.
The package is key package.
Due to the static link of Go packages, and the out of date built-using
thing, it needs another round of rebuild of all Go packages before
bullseye release.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
golang-golang-x-net needs same fix for CVE-2021-31525


unblock golang-1.15/1.15.9-2


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-03-11 23:43:18.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-05-08 02:45:35.0 +0800
@@ -1,3 +1,12 @@
+golang-1.15 (1.15.9-2) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patch for CVE-2021-31525
+net/http: ReadRequest can stack overflow due to recursion with very
+large headers. https://github.com/golang/go/issues/45711
+
+ -- Shengjing Zhu   Sat, 08 May 2021 02:45:35 +0800
+
 golang-1.15 (1.15.9-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch 
golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch
--- golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch 1970-01-01 
08:00:00.0 +0800
+++ golang-1.15-1.15.9/debian/patches/0007-CVE-2021-31525.patch 2021-05-08 
02:45:35.0 +0800
@@ -0,0 +1,90 @@
+From 5aed4ce3c854bdbbb6dd5c1ccfa15c23d4b6c989 Mon Sep 17 00:00:00 2001
+From: Katie Hockman 
+Date: Wed, 28 Apr 2021 14:47:48 -0400
+Subject: [PATCH] [release-branch.go1.15] std: update golang.org/x/net to
+ 20210428183841-261fb518b1ed
+
+Steps:
+  go get -d golang.org/x/net@release-branch.go1.15
+  go mod tidy
+  go mod vendor
+
+This http2 bundle does not need to be updated.
+
+Fixes #45711
+
+Change-Id: I085ca592dfc8d5d9c328a7979142e88e7130a813
+Reviewed-on: https://go-review.googlesource.com/c/go/+/314790
+Trust: Katie Hockman 
+Run-TryBot: Katie Hockman 
+Reviewed-by: Dmitri Shuralyov 
+---
+ src/go.mod   |  2 +-
+ src/go.sum   |  4 ++--
+ src/vendor/golang.org/x/net/http/httpguts/httplex.go | 10 ++
+ src/vendor/modules.txt   |  2 +-
+ 4 files changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/src/go.mod b/src/go.mod
+index 6b97366bbe6c..dfcba7a1c8ac 100644
+--- a/src/go.mod
 b/src/go.mod
+@@ -4,7 +4,7 @@ go 1.15
+ 
+ require (
+   golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9
+-  golang.org/x/net v0.0.0-20201008223702-a5fa9d4b7c91
++  golang.org/x/net v0.0.0-20210428183841-261fb518b1ed
+   golang.org/x/sys v0.0.0-20200501145240-bc7a7d42d5c3 // indirect
+   golang.org/x/text v0.3.3-0.20200430171850-afb9336c4530 // indirect
+ )
+diff --git a/src/go.sum b/src/go.sum
+index fbd3279aade6..47e918848c3e 100644
+--- a/src/go.sum
 b/src/go.sum
+@@ -2,8 +2,8 @@ golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod 
h1:djNgcEr1/C05ACk
+ golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 
h1:psW17arqaxU48Z5kZ0CQnkZWQJsqcURM6tKiBApRjXI=
+ golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod 
h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
+ golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod 
h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
+-golang.org/x/net v0.0.0-20201008223702-a5fa9d4b7c91 
h1:zd7kl5i5PDM0OnFbRWVM6B8mXojzv8LOkHN9LsOrRf4=
+-golang.org/x/net v0.0.0-20201008223702-a5fa9d4b7c91/go.mod 
h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
++golang.org/x/net v0.0.0-20210428183841-261fb518b1ed 
h1:aunM0N/jnRHvQgZo3kYkfaAGet2kIMFOPIbopG5BhYw=
++golang.org/x/net v0.0.0-20210428183841-261fb518b1ed/go.mod 
h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
+ golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod 
h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
+ golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod 
h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+ golang.org/x/sys v0.0.0-20200323222414-85ca7c5b95cd/go.mod 
h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+diff --git a/src/vendor/golang.org/x/net/http/httpguts/httplex.go 
b/src/vendor/golang.org/x/net/http/httpguts/httplex.go
+index e7de24ee64ef..c79aa73f28bb 100644
+--- a/src/vendor

Bug#987056: unblock: golang-gopkg-yaml.v3/3.0.0~git20200121.a6ecf24-3

2021-04-16 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-gopkg-yaml.v3

[ Reason ]
Fix FTBFS on 32 bit arch

[ Impact ]
The package FTBFS on 32 bit arch.
And packages that build-dep on it _may_ have wrong behaviour on 32 bit arch.
But I think the underlying issue _may_ be minor.

[ Tests ]
Upstream unit tests, and autopkgtest on 32 bit arch.

[ Risks ]
Change is trivial. Key package.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
None

unblock golang-gopkg-yaml.v3/3.0.0~git20200121.a6ecf24-3
diff -Nru golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog
--- golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog 
2020-06-02 02:10:00.0 +0800
+++ golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog 
2021-04-16 00:25:23.0 +0800
@@ -1,3 +1,15 @@
+golang-gopkg-yaml.v3 (3.0.0~git20200121.a6ecf24-3) unstable; urgency=medium
+
+  * Team upload.
+  * Add patch to fix failed test on 32 bit arch (Closes: #987005)
+  * Update Section to golang
+  * Update Standards-Version to 4.5.1 (no changes)
+  * Remove test dependency from -dev package
+  * Remove redundant line in d/rules
+  * Fix uscan watch file
+
+ -- Shengjing Zhu   Fri, 16 Apr 2021 00:25:23 +0800
+
 golang-gopkg-yaml.v3 (3.0.0~git20200121.a6ecf24-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control
--- golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control   
2020-06-02 02:10:00.0 +0800
+++ golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control   
2021-04-16 00:25:23.0 +0800
@@ -1,14 +1,14 @@
 Source: golang-gopkg-yaml.v3
 Maintainer: Debian Go Packaging Team 
-Uploaders: Daniel Swarbrick 
-Section: devel
+Uploaders: Daniel Swarbrick ,
+Section: golang
 Testsuite: autopkgtest-pkg-go
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
-   dh-golang,
+   dh-golang (>= 1.39),
golang-any,
golang-gopkg-check.v1-dev,
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-gopkg-yaml.v3
 Vcs-Git: https://salsa.debian.org/go-team/packages/golang-gopkg-yaml.v3.git
@@ -17,8 +17,7 @@
 
 Package: golang-gopkg-yaml.v3-dev
 Architecture: all
-Depends: golang-gopkg-check.v1-dev,
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends},
 Description: YAML support for the Go language
  The yaml package enables Go programs to very comfortably encode and decode
diff -Nru 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
--- 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
   1970-01-01 08:00:00.0 +0800
+++ 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
   2021-04-16 00:25:23.0 +0800
@@ -0,0 +1,48 @@
+From: Shengjing Zhu 
+Date: Fri, 16 Apr 2021 00:40:09 +0800
+Subject: Fix -0b on 32-bit systems
+
+Origin: backport, https://github.com/go-yaml/yaml/pull/442
+---
+ decode_test.go | 7 ---
+ resolve.go | 2 +-
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/decode_test.go b/decode_test.go
+index 51f5070..9cac74c 100644
+--- a/decode_test.go
 b/decode_test.go
+@@ -175,9 +175,6 @@ var unmarshalTests = []struct {
+   }, {
+   "bin: -0b101010",
+   map[string]interface{}{"bin": -42},
+-  }, {
+-  "bin: 
-0b1000",
+-  map[string]interface{}{"bin": -9223372036854775808},
+   }, {
+   "decimal: +685_230",
+   map[string]int{"decimal": 685230},
+@@ -357,6 +354,10 @@ var unmarshalTests = []struct {
+   "int64_min: -9223372036854775808",
+   map[string]int64{"int64_min": math.MinInt64},
+   },
++  {
++  "int64_min_base2: 
-0b1000",
++  map[string]int64{"int64_min_base2": math.MinInt64},
++  },
+   {
+   "int64_neg_base2: 
-0b111",
+   map[string]int64{"int64_neg_base2": -math.MaxInt64},
+diff --git a/resolve.go b/resolve.go
+index 64ae88

Bug#986576: unblock: golang-golang-x-text/0.3.6-1

2021-04-07 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-golang-x-text

[ Reason ]
New upstream bugfix release, which fixes
1. CVE-2020-28851 In x/text in Go 1.15.4, an "index out of range" panic occurs
   in language.ParseAcceptLanguage while parsing the -u- extension.
   (x/text/language is supposed to be able to parse an HTTP Accept-Language
   header.)
2. x/text: panic in regionGroupDist
   https://github.com/golang/go/issues/43834

The package is key package, thus it needs unblock manually.

[ Impact ]
Security issue is not fixed.

[ Tests ]
Upstream thorough unit tests.

[ Risks ]
The change of the code is complex which I can't fully reviewed, but
since it fixes security problem, it may should be complex.
The code is reviewed by official Go team, and I trust them.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
There are only three commits between 0.3.5 and 0.3.6
https://github.com/golang/text/compare/v0.3.5...v0.3.6
Two commits fix the issue mentioned above. And another one is code format,
which unfortunately makes the diff quite large.
I will omit the format change in debdiff attached in this request.


unblock golang-golang-x-text/0.3.6-1


diff -Nru golang-golang-x-text-0.3.5/debian/changelog 
golang-golang-x-text-0.3.6/debian/changelog
--- golang-golang-x-text-0.3.5/debian/changelog 2021-01-19 02:11:19.0 
+0800
+++ golang-golang-x-text-0.3.6/debian/changelog 2021-04-07 02:18:47.0 
+0800
@@ -1,3 +1,10 @@
+golang-golang-x-text (0.3.6-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream release v0.3.6 (Closes: #980001, CVE-2020-28851)
+
+ -- Shengjing Zhu   Wed, 07 Apr 2021 02:18:47 +0800
+
 golang-golang-x-text (0.3.5-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-golang-x-text-0.3.5/debian/control 
golang-golang-x-text-0.3.6/debian/control
--- golang-golang-x-text-0.3.5/debian/control   2021-01-19 02:11:19.0 
+0800
+++ golang-golang-x-text-0.3.6/debian/control   2021-04-07 02:18:47.0 
+0800
@@ -1,13 +1,13 @@
 Source: golang-golang-x-text
 Maintainer: Debian Go Packaging Team 
 Uploaders: Martín Ferrari ,
-   Anthony Fok 
+   Anthony Fok ,
 Section: golang
 Testsuite: autopkgtest-pkg-go
 Priority: optional
 Build-Depends: debhelper-compat (= 13),
dh-golang (>= 1.31~),
-   golang-any (>= 2:1.7~)
+   golang-any (>= 2:1.7~),
 Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-golang-x-text
 Vcs-Git: https://salsa.debian.org/go-team/packages/golang-golang-x-text.git
@@ -18,8 +18,8 @@
 Package: golang-golang-x-text-dev
 Architecture: all
 Multi-Arch: foreign
-Depends: ${shlibs:Depends},
- ${misc:Depends}
+Depends: ${misc:Depends},
+ ${shlibs:Depends},
 Description: Supplementary Go text-related libraries
  golang.org/x/text is a repository of text-related packages, such as character
  encodings, text transformations, and locale-specific text handling.
diff -Nru golang-golang-x-text-0.3.5/debian/watch 
golang-golang-x-text-0.3.6/debian/watch
--- golang-golang-x-text-0.3.5/debian/watch 2021-01-19 02:11:19.0 
+0800
+++ golang-golang-x-text-0.3.6/debian/watch 2021-04-07 02:18:47.0 
+0800
@@ -1,4 +1,3 @@
 version=4
-opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%golang-golang-x-text-$1.tar.gz%"
 \
-https://github.com/golang/text/releases \
-(?:.*?/)?v?(\d[\d.]*)\.tar\.gz
+opts="mode=git, pgpmode=none" \
+  https://github.com/golang/text refs/tags/v([\d\.]+)
diff -Nru golang-golang-x-text-0.3.5/internal/language/language.go 
golang-golang-x-text-0.3.6/internal/language/language.go
--- golang-golang-x-text-0.3.5/internal/language/language.go2020-12-08 
08:13:44.0 +0800
+++ golang-golang-x-text-0.3.6/internal/language/language.go2021-03-30 
13:48:03.0 +0800
@@ -303,9 +303,17 @@
 // are of the allowed values defined for the Unicode locale extension ('u') in
 // 
https://www.unicode.org/reports/tr35/#Unicode_Language_and_Locale_Identifiers.
 // TypeForKey will traverse the inheritance chain to get the correct value.
+//
+// If there are multiple types associated with a key, only the first will be
+// returned. If there is no type associated with a key, it returns the empty
+// string.
 func (t Tag) TypeForKey(key string) string {
-   if start, end, _ := t.findTypeForKey(key); end != start {
-   return t.str[start:end]
+   if _, start, end, _ := t.findTypeForKey(key); end != start {
+   s := t.str[start:end]
+   if p := strings.IndexByte(s, '-'); p >= 0 {
+   s = s[:p]
+   }
+   return s
   

Bug#984988: pre-approval: unblock: golang-1.15/1.15.9-1

2021-03-12 Thread Shengjing Zhu
On Fri, Mar 12, 2021 at 5:16 PM Sebastian Ramacher  wrote:
> > unblock golang-1.15/1.15.9-1
>
> Assuming the uploads happens soon, please go ahead.
>

Thansk, it's has been uploaded and built on all arch.

-- 
Shengjing Zhu



Bug#984988: pre-approval: unblock: golang-1.15/1.15.9-1

2021-03-11 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org, team+go-compi...@tracker.debian.org

Please unblock package golang-1.15

[ Reason ]
Upstream security release, only target fix is introduced.
CVE-2021-27918: encoding/xml: infinite loop when using `xml.NewTokenDecoder`
with a custom `TokenReader`.
https://github.com/golang/go/issues/44913

[ Impact ]
Without this version, the Go compiler is vulnerable.
However with the new undetermined Go security policy, this
bug is classified as LOW (severity issues affect niche configurations,
have very limited impact, or are already widely known).
https://github.com/golang/go/issues/44918

[ Tests ]
+ Upstream tests in source package.
+ Have manually test some Go packages.

[ Risks ]
+ No autopkgtest
+ Diff is small

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
If this package is blocked in unstable, all Go packages will be prevented
from migrating to testing, due to the Built-Using thing..
So I fill this pre-approval request. And if possible, reduce the age too.

unblock golang-1.15/1.15.9-1


diff -Nru golang-1.15-1.15.8/debian/changelog 
golang-1.15-1.15.9/debian/changelog
--- golang-1.15-1.15.8/debian/changelog 2021-02-15 23:19:39.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-03-11 23:43:18.0 +0800
@@ -1,3 +1,12 @@
+golang-1.15 (1.15.9-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream version 1.15.9
++ encoding/xml: infinite loop when using `xml.NewTokenDecoder` with a
+  custom `TokenReader`. CVE-2021-27918
+
+ -- Shengjing Zhu   Thu, 11 Mar 2021 23:43:18 +0800
+
 golang-1.15 (1.15.8-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-1.15-1.15.8/src/encoding/xml/xml.go 
golang-1.15-1.15.9/src/encoding/xml/xml.go
--- golang-1.15-1.15.8/src/encoding/xml/xml.go  2021-02-05 20:48:37.0 
+0800
+++ golang-1.15-1.15.9/src/encoding/xml/xml.go  2021-03-10 22:29:35.0 
+0800
@@ -271,7 +271,7 @@
 // it will return an error.
 //
 // Token implements XML name spaces as described by
-// https://www.w3.org/TR/REC-xml-names/.  Each of the
+// https://www.w3.org/TR/REC-xml-names/. Each of the
 // Name structures contained in the Token has the Space
 // set to the URL identifying its name space when known.
 // If Token encounters an unrecognized name space prefix,
@@ -285,16 +285,17 @@
if d.nextToken != nil {
t = d.nextToken
d.nextToken = nil
-   } else if t, err = d.rawToken(); err != nil {
-   switch {
-   case err == io.EOF && d.t != nil:
-   err = nil
-   case err == io.EOF && d.stk != nil && d.stk.kind != stkEOF:
-   err = d.syntaxError("unexpected EOF")
+   } else {
+   if t, err = d.rawToken(); t == nil && err != nil {
+   if err == io.EOF && d.stk != nil && d.stk.kind != 
stkEOF {
+   err = d.syntaxError("unexpected EOF")
+   }
+   return nil, err
}
-   return t, err
+   // We still have a token to process, so clear any
+   // errors (e.g. EOF) and proceed.
+   err = nil
}
-
if !d.Strict {
if t1, ok := d.autoClose(t); ok {
d.nextToken = t
diff -Nru golang-1.15-1.15.8/src/encoding/xml/xml_test.go 
golang-1.15-1.15.9/src/encoding/xml/xml_test.go
--- golang-1.15-1.15.8/src/encoding/xml/xml_test.go 2021-02-05 
20:48:37.0 +0800
+++ golang-1.15-1.15.9/src/encoding/xml/xml_test.go 2021-03-10 
22:29:35.0 +0800
@@ -33,30 +33,90 @@
 
 func TestDecodeEOF(t *testing.T) {
start := StartElement{Name: Name{Local: "test"}}
-   t.Run("EarlyEOF", func(t *testing.T) {
-   d := NewTokenDecoder({earlyEOF: true, t: []Token{
-   start,
-   start.End(),
-   }})
-   err := d.Decode( {
-   XMLName Name `xml:"test"`
-   }{})
-   if err != nil {
-   t.Error(err)
+   tests := []struct {
+   name   string
+   tokens []Token
+   ok bool
+   }{
+   {
+   name: "OK",
+   tokens: []Token{
+   start,
+   start.End(),
+   },
+   ok: true,
+   },
+   {
+   name: "Malformed",
+   tokens: []Token{
+   st

Re: Issues regarding input methods for Bullseye

2021-03-08 Thread Shengjing Zhu
On Mon, Mar 8, 2021 at 6:45 AM Holger Wansing  wrote:
>
> Hi all,
>
> currently we have 4 bugreports open regarding input methods:
>
> #983704 Switch to fcitx5 for Simplified and Traditional Chinese desktop
> #941624 Recommending ibus breaks fcitx
> #983653 task-japanese-gnome-desktop: no Japanese input method available out 
> of the box
> #982175 task-japanese-desktop: should explicitly prefer mozc over anthy
>
> This correlates with Gnome's changing to Recommends: ibus.
>
> So, what's the way to solve these issues for Bullseye?
> What are the options?
>
> 1. Since Gnome only supports ibus, all relevant languages would need to get
>an ibus-* package installed, to run Gnome.
>Would that work? Is ibus working fine for all relevant languages?
>
> 2. There are of course people, who don't want to use ibus, but fcitx or uim.
>In that case, would it be ok, to install both (ibus + fctix|uim) ?
>It has been stated, that it's no problem, when more than one input method
>is installed, im-config is there to take care of that.
>
> 3. Getting Gnome reverting the Recommends:ibus dependency is probably no
>longer possible in this development status of Bullseye ... (?)
>
> 4. What about other desktop environments?
>Apart from the fcitx -> fcitx5 switch, are there any other changings
>needed?
>
> 5. 

Just FTR, as there's another thread in #983695.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983695#85

It may be better to recommend gnome-initial-setup for gnome tasks like
task-korean-gnome-desktop, to workaround that ibus doesn't have a
default config for all languages.



Re: Issues regarding input methods for Bullseye

2021-03-08 Thread Shengjing Zhu
On Mon, Mar 8, 2021 at 11:52 PM Holger Wansing  wrote:
>
> Am 8. März 2021 16:34:54 MEZ schrieb Shengjing Zhu :
> >I just looked at tasksel, but it seems it's not straightforward to
> >implement,
> >1. install ibus for GNOME
> >2. install other input method for DE except GNOME.
> >Since it's seems hard to express all DE without GNOME, except
> >enumerating them?
>
> I guess it would go like this:
>
> 1. install the IM method prefered by language team
> for all DE
>
> 2. install (additionally) ibus-* , if DE is Gnome.
>
> That way we would have two IM systems installed
> for Gnome, but im-config would take care of  that just
> fine, since ibus is the preferred choice.
>
> And for all other DEs we had that IM installed, what's
> preferred by the language team.
>
> Would that be reasonable?

Agree, it seems it's the feasible option currently.

But we need to add some new packages, task--gnome-desktop, for
languages which prefer non-ibus.

Which are:
1. task-amharic-gnome-desktop, *maybe NEW*, I didn't find amharic for ibus?
2. task-chinese-s-gnome-desktop, *NEW*, probably ibus-libpinyin
3. task-chinese-t-gnome-desktop, *NEW*, probably ibus-chewing
4. task-kannada-gnome-desktop, *NEW*, probably ibus-m17n
5. task-malayalam-gnome-desktop, *maybe NEW*, I didn't find malayalam for ibus?
6. task-telugu-gnome-desktop, already has, probably ibus-m17n
7. task-japanese-gnome-desktop, already has, patch in #983653

@Release Team, could you look at this? It's OK for these new packages.

-- 
Shengjing Zhu



Re: Issues regarding input methods for Bullseye

2021-03-08 Thread Shengjing Zhu
Hi,

On Mon, Mar 8, 2021 at 6:39 PM Shengjing Zhu  wrote:
>
> On Mon, Mar 8, 2021 at 5:05 PM Holger Wansing  wrote:
> >
> > Hi,
> >
> > Shengjing Zhu  wrote (Mon, 8 Mar 2021 13:14:26 +0800):
> > > IMO, we have 3 choice here:
> > >
> > > 1. All languages in tasksel should have a separate task for GNOME, and
> > > a separate task for other DE.
> > >
> > >The GNOME task installs ibus related language modules. And the
> > > other DE task installs the local team prefered input method and the
> > > corresponding language module.
> > >
> > >This is my preference, since the choice of GNOME upstream and
> > > maintainer shouldn't have influence on other DE. But we also respect
> > > the GNOME upstream and maintainer's choice.
> > >
> > >However currently only Japanese has the standalone GNOME task.
> >
> > This option requires to add new binary packages to tasksel, if I understand
> > correctly, but that is no longer possible for Bullseye, due to the freeze,
> > right?

I just looked at tasksel, but it seems it's not straightforward to implement,
1. install ibus for GNOME
2. install other input method for DE except GNOME.
Since it's seems hard to express all DE without GNOME, except enumerating them?

-- 
Shengjing Zhu



Re: Issues regarding input methods for Bullseye

2021-03-08 Thread Shengjing Zhu
On Mon, Mar 8, 2021 at 5:05 PM Holger Wansing  wrote:
>
> Hi,
>
> Shengjing Zhu  wrote (Mon, 8 Mar 2021 13:14:26 +0800):
> > IMO, we have 3 choice here:
> >
> > 1. All languages in tasksel should have a separate task for GNOME, and
> > a separate task for other DE.
> >
> >The GNOME task installs ibus related language modules. And the
> > other DE task installs the local team prefered input method and the
> > corresponding language module.
> >
> >This is my preference, since the choice of GNOME upstream and
> > maintainer shouldn't have influence on other DE. But we also respect
> > the GNOME upstream and maintainer's choice.
> >
> >However currently only Japanese has the standalone GNOME task.
>
> This option requires to add new binary packages to tasksel, if I understand
> correctly, but that is no longer possible for Bullseye, due to the freeze,
> right?

Let's loop debian-release@ as well.

Dear RT, the thread is started from
https://lists.debian.org/msgid-search/20210307232906.14715b8e982b03f94068d...@mailbox.org

I think there's always another option,

4. Document the incorrect default behavior of GNOME DE in the
release-notes. Tell the user to change the input method manually after
installing. And if something strange happens, uninstall ibus by hand.

-- 
Shengjing Zhu



Bug#984717: unblock: opencc/1.1.1+git20200624+ds2-10

2021-03-07 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org, by...@debian.org

Please unblock package opencc

Summary of changes since testing/1.1.1+git20200624+ds2-5

+ Enable upstream tests in package building.
+ Add autopkgtest
+ Backport 2 upstream patches to fix performance regression.

[ Reason ]

This fix is small, but the performance is improved a lot.
As opencc is also used in generating Debian official website
for Simplified and Traditional Chinese version, and a lot of text
needs to be processed by opencc, so the performance matters.

opencc is key package, so it needs manual unblock.

[ Impact ]
Without this patch, the performance drops a lot.

[ Tests ]
+ Upstream unit and integration tests
+ Autopkgtest for installed library and tool
+ Manual tests
  + With opencc in testing:

$ time opencc -c /usr/share/opencc/t2s.json -i <(printf "Open Chinese 
Convert 開放中文轉換\n%.0s" {1..5}) -o /dev/null

real0m40.328s
user0m40.272s
sys 0m0.105s


  + With opencc in unstable:

$ time opencc -c /usr/share/opencc/t2s.json -i <(printf "Open Chinese 
Convert 開放中文轉換\n%.0s" {1..5}) -o /dev/null

real0m0.556s
user0m0.551s
sys 0m0.065s


[ Risks ]

+ Patch is small
+ Key package

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
The upstream patch was first backported in 1.1.1+git20200624+ds2-6, but the 
tests
were not run, so Boyuan didn't notice the backport is incomplete. Then the 
backport
was reverted in -7. After adding tests and autopkgtest, the patches are 
backported
again in -10.


unblock opencc/1.1.1+git20200624+ds2-10

Diff:

Real effected code added are only 13 lines.
+ 
https://salsa.debian.org/debian/opencc/-/blob/debian/1.1.1+git20200624+ds2-10/debian/patches/0006-Fix-a-bug-in-the-calculation-of-DictGroup-keyMaxLeng.patch
  L28-L42
+ 
https://salsa.debian.org/debian/opencc/-/blob/debian/1.1.1+git20200624+ds2-10/debian/patches/0007-Fix-a-severe-performance-bug-in-Conversion-Convert-t.patch
  L78-L80

Full diff:

Also available at:
https://salsa.debian.org/debian/opencc/-/compare/debian%2F1.1.1+git20200624+ds2-5...debian%2F1.1.1+git20200624+ds2-10

Some long test code added by upstream commit are skipped below.

diff --git a/debian/changelog b/debian/changelog
index eee8331..69db793 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,48 @@
+opencc (1.1.1+git20200624+ds2-10) unstable; urgency=medium
+
+  * Team upload.
+  * Upload to unstable.
+  * Backport patch to fix performance regression again.
+Add
++ 0006-Fix-a-bug-in-the-calculation-of-DictGroup-keyMaxLeng.patch
++ 0007-Fix-a-severe-performance-bug-in-Conversion-Convert-t.patch
+
+ -- Shengjing Zhu   Sun, 07 Mar 2021 14:20:40 +0800
+
+opencc (1.1.1+git20200624+ds2-9) experimental; urgency=medium
+
+  * Team upload.
+  * Remove unused command from autopkgtest scripts
+  * Add build-essential to autopkgtest
+
+ -- Shengjing Zhu   Sun, 07 Mar 2021 00:54:22 +0800
+
+opencc (1.1.1+git20200624+ds2-8) experimental; urgency=medium
+
+  * Team upload.
+  * Enable test when building
+  * Add autopkgtest
+
+ -- Shengjing Zhu   Sat, 06 Mar 2021 17:57:00 +0800
+
+opencc (1.1.1+git20200624+ds2-7) unstable; urgency=high
+
+  * Team upload.
+  * Drop debian/patches/0005 for now due to regression reported.
+See also https://github.com/fcitx/fcitx5/issues/238 .
+
+ -- Boyuan Yang   Fri, 05 Mar 2021 09:37:48 -0500
+
+opencc (1.1.1+git20200624+ds2-6) unstable; urgency=high
+
+  * Team upload.
+  * debian/patches/0005: Add upstream patch to fix severe performance
+regression in `Conversion::Convert` that caused O(N^2) complexity.
+  * debian/rules: Disable parallel build to workaround some random
+build error for now.
+
+ -- Boyuan Yang   Sun, 28 Feb 2021 19:48:01 -0500
+
 opencc (1.1.1+git20200624+ds2-5) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 2eadce4..834dae0 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Build-Depends:
  darts,
  debhelper-compat (= 13),
  doxygen ,
+ googletest ,
  libmarisa-dev,
  libtclap-dev,
  python3:any,
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..cec628c
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,2 @@
+[DEFAULT]
+pristine-tar = True
diff --git a/debian/patches/use-cmake-install-libdir.patch 
b/debian/patches/0001-use-cmake-install-libdir.patch
similarity index 100%
rename from debian/patches/use-cmake-install-libdir.patch
rename to debian/patches/0001-use-cmake-install-libdir.patch
diff --git a/debian/patches/0003-use-system-libraries.patch 
b/debian/patches/0002-use-system-libraries.patch
similarity index 100%
rename from debian/patches/0003-use-system-libraries.patch
rename to debi

Bug#984565: unblock: containerd/1.4.4~ds1-1

2021-03-05 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package containerd

[ Reason ]
It's a new upstream point release with bugfix only, and
it fixes CVE-2021-21334
Most changes are cherry-pick by myself in upstream.

Diff:
https://salsa.debian.org/go-team/packages/containerd/-/compare/debian%2F1.4.3_ds1-2...debian%2F1.4.4_ds1-1
Many pb.go are changed, it's caused by another CVE fix, which is in
protobuf generator, golang-gogoprotobuf CVE-2021-3121
Without these pb.go files, the diff is small.

The package can migrate itself, but I file this unblock to
reduce the migrate days. Since it will become 20 days nows.

[ Impact ]
Bullseye will have 20 days without CVE fix.

[ Tests ]
The package has autopkgtest, and I have done other integration
tests, like tests with CRI-test[1], Kubernetes Node e2e tests[2].

[1] https://github.com/kubernetes-sigs/cri-tools
[2] 
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md

[ Risks ]
No

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
No

unblock containerd/1.4.4~ds1-1



Re: Go issues wrt. Debian infrastructure: moving forward

2021-01-31 Thread Shengjing Zhu
Hi,

It might be the time to resume the discussion...

On Sun, Aug 30, 2020 at 2:09 AM Ansgar  wrote:
>
> Hi,
>
> Clément Hermann writes:
> > The original message on debian-go and debian-release is here:
> >
> > https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org
>
> For the ftp-master side, I wanted to just import all sources from a
> stable release into security-master (in a private archive).  dak can
> then use these when binNMUs arrive, for Built-Using, or when people
> upload without the .orig.tar.gz included.  The second part should
> already work.
>
> There are currently two issues with this:
>
> - security-master.d.o should get more disk space.
>   Maybe we should get a (new) physical host for security-master that
>   provides this?  It should probably be a physical host and not a VM to
>   allow using a YubiKey (or similar) for the signing key.
>
> - Time. I currently don't have much to spend on Debian.
>
> Are there more issues that ftp-master would have to deal with?
>

Dear ftpmaster, will the task that imports all sources to
security-master be ready for bullseye?

-- 
Shengjing Zhu



Re: Podman 3.0 and Debian bullseye

2021-01-31 Thread Shengjing Zhu
On Sun, Jan 31, 2021 at 11:33 AM Dmitry Smirnov  wrote:
[...]
> Do you have experience operating local container registry??
> I have and I can tell that it is not fun, to say the least. Docker registry
> leaks disk space because it does not garbage collect some images...

Is there a known bug number which we can follow up there?
I do run a private registry with my CI, many images are pushed and
deleted daliy. But I haven't noticed disk space leaks.

> IMHO just saving built images to network share is the best, easiest, most
> reliable way of deploying local images. It is the best to avoid Docker
> registry whenever possible.

However only the registry is able to dedup the image layers.

-- 
Shengjing Zhu



Bug#979750: transition: skalibs execline s6

2021-01-11 Thread Shengjing Zhu
Hi,

On Mon, Jan 11, 2021 at 11:33 AM Shengjing Zhu  wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: z...@debian.org
>
> Hi,
>
> Skarnet.org softwares just released a new version today...
>
> http://skarnet.org/cgi-bin/archive.cgi?1:mss:1515:202101:mhcdpginfgieagphalne
>
> I have packaged three of them, which are skalibs, execline and s6.
>
> They both have SO bump this time. There's no reverse depend except for
> themselves.
>
> I have uploaded them to experimental, and still wait for the NEW queue.
> Can this be warranted for the "Soft Freeze" deadline as no other
> packages are involved.
>

They have been cleared from the NEW queue. Do you consider it a
transition or not?

-- 
Shengjing Zhu



Bug#979750: transition: skalibs execline s6

2021-01-10 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: z...@debian.org

Hi,

Skarnet.org softwares just released a new version today...

http://skarnet.org/cgi-bin/archive.cgi?1:mss:1515:202101:mhcdpginfgieagphalne

I have packaged three of them, which are skalibs, execline and s6.

They both have SO bump this time. There's no reverse depend except for
themselves.

I have uploaded them to experimental, and still wait for the NEW queue.
Can this be warranted for the "Soft Freeze" deadline as no other
packages are involved.

Thanks



Bug#977452: transition: fmtlib

2020-12-26 Thread Shengjing Zhu
On Fri, Dec 25, 2020 at 10:22 PM Sebastian Ramacher
 wrote:
>
> Control: tags -1 + confirmed
>
> On 2020-12-24 22:48:56, Shengjing Zhu wrote:
> > Some status updates.
> >
> > On Wed, Dec 16, 2020 at 1:19 AM Shengjing Zhu  wrote:
> > > spdlog is ftbfs because of symbols file, and is pending upload #977454
> > > Rebuild with fixed spdlog and fmtlib, following packages ftbfs, but
> > > not related to fmtlib/7.1.3
> > >
> >
> > spdlog is fixed and migrated to testing
> >
> > > + pytorch, impossible to build on a personal computer.. but only in sid..
> >
> > pytorch originally failed to build with fmtlib/7.1.3, but has been
> > fixed and migrated to testing.
> >
> > > + sopt #975843, ftbfs without fmtlib/7.1.3
> >
> > Though it ftbfs for other reasons, it has been fixed and migrated to 
> > testing.
> >
> > > + lizardfs ftbfs without fmtlib/7.1.3, only in sid
> > > + dpaste ftbfs without fmtlib/7.1.3, only in sid
> > >
> > > Other packages are just fine to build.
>
> Please go ahead with the upload to unstable.
>

Thanks. Uploaded. But still missing build from alpha, kfreebsd, hurd.
The queue on these archs seems long..

Please rebuild spdlog first. The other packages are compliled from
build-rdepends,

$ build-rdeps --distribution=unstable libfmt-dev
Reverse Build-depends in main:
--

bear
dpaste
fcitx5
fcitx5-chinese-addons
hinge
intel-gmmlib
knxd
kodi
libpog
lizardfs
mkvtoolnix
nheko
open3d
opendht
openimageio
osmid
purify
pytorch
rapmap
restinio
ring
salmon
sopt
spdlog
tiledb
waybar
yaramod

Found a total of 27 reverse build-depend(s) for libfmt-dev.

Some packages build-dpends on spdlog, after rebuilding, they gain new
depends on libfmt7 too, like hinge.
So I think it's needed to rebuild all packages.

-- 
Shengjing Zhu



Bug#978023: nmu: cpu-features_0.6.0-1

2020-12-24 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: z...@debian.org

nmu cpu-features_0.6.0-1 . amd64 . unstable . -m "rebuild on buildd"

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)



Bug#977452: transition: fmtlib

2020-12-24 Thread Shengjing Zhu
Some status updates.

On Wed, Dec 16, 2020 at 1:19 AM Shengjing Zhu  wrote:
> spdlog is ftbfs because of symbols file, and is pending upload #977454
> Rebuild with fixed spdlog and fmtlib, following packages ftbfs, but
> not related to fmtlib/7.1.3
>

spdlog is fixed and migrated to testing

> + pytorch, impossible to build on a personal computer.. but only in sid..

pytorch originally failed to build with fmtlib/7.1.3, but has been
fixed and migrated to testing.

> + sopt #975843, ftbfs without fmtlib/7.1.3

Though it ftbfs for other reasons, it has been fixed and migrated to testing.

> + lizardfs ftbfs without fmtlib/7.1.3, only in sid
> + dpaste ftbfs without fmtlib/7.1.3, only in sid
>
> Other packages are just fine to build.

-- 
Shengjing Zhu



Bug#977452: transition: fmtlib

2020-12-15 Thread Shengjing Zhu
On Tue, Dec 15, 2020 at 5:36 PM Shengjing Zhu  wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: z...@debian.org
>
>
> Hi,
>
> I have uploaded fmtlib 7.1.3 to experimental, I would like to request a
> slot to start this transition.
>
> In the past (fmtlib <= 6.x), it's a static only library. Last month I
> adopted it, and decide to build a shared library for 7.x.
>
> The old package has too much patches which are not merged by/forwarded
> to upstream, thus I do want have the 7.x(which is re-packaged from
> scratch) for bullseye.
>
> The new version will use what upstream provides. It will has two targets
> in its cmake system, one is head-only version, one is shared library
> version.
>
> So when r-depend packages rebuild with this new version, it can either
> use head-only version, or the shared library.
>
> For example in 
> https://sources.debian.org/src/fcitx5/5.0.3-2/CMakeLists.txt/#L82
> it will check which target exists.
>
> The ben file seems hard to rewrite, as there's no good way to check
> what is_good and is_bad.
>
> Following packages need to be rebuilt
>
> bear
> dpaste
> fcitx5
> fcitx5-chinese-addons
> hinge
> intel-gmmlib
> knxd
> kodi
> libpog
> lizardfs
> mkvtoolnix
> nheko
> open3d
> opendht
> openimageio
> osmid
> purify
> pytorch
> rapmap
> restinio
> ring
> salmon
> sopt
> spdlog
> tiledb
> waybar
> yaramod
>
> I will start to check if they can be rebuilt successfully.
>
> One thing to mention is that spdlog should be rebuilt first. As it uses
> fmtlib internal API and embedded fmtlib in its shared library
> previously. So if packages both use fmtlib and spdlog, they need to be
> rebuilt later.
>

spdlog is ftbfs because of symbols file, and is pending upload #977454
Rebuild with fixed spdlog and fmtlib, following packages ftbfs, but
not related to fmtlib/7.1.3

+ pytorch, impossible to build on a personal computer.. but only in sid..
+ sopt #975843, ftbfs without fmtlib/7.1.3
+ lizardfs ftbfs without fmtlib/7.1.3, only in sid
+ dpaste ftbfs without fmtlib/7.1.3, only in sid

Other packages are just fine to build.

-- 
Shengjing Zhu



Bug#977452: transition: fmtlib

2020-12-15 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: z...@debian.org


Hi,

I have uploaded fmtlib 7.1.3 to experimental, I would like to request a
slot to start this transition.

In the past (fmtlib <= 6.x), it's a static only library. Last month I
adopted it, and decide to build a shared library for 7.x.

The old package has too much patches which are not merged by/forwarded
to upstream, thus I do want have the 7.x(which is re-packaged from
scratch) for bullseye.

The new version will use what upstream provides. It will has two targets
in its cmake system, one is head-only version, one is shared library
version.

So when r-depend packages rebuild with this new version, it can either
use head-only version, or the shared library.

For example in https://sources.debian.org/src/fcitx5/5.0.3-2/CMakeLists.txt/#L82
it will check which target exists.

The ben file seems hard to rewrite, as there's no good way to check
what is_good and is_bad.

Following packages need to be rebuilt

bear
dpaste
fcitx5
fcitx5-chinese-addons
hinge
intel-gmmlib
knxd
kodi
libpog
lizardfs
mkvtoolnix
nheko
open3d
opendht
openimageio
osmid
purify
pytorch
rapmap
restinio
ring
salmon
sopt
spdlog
tiledb
waybar
yaramod

I will start to check if they can be rebuilt successfully.

One thing to mention is that spdlog should be rebuilt first. As it uses
fmtlib internal API and embedded fmtlib in its shared library
previously. So if packages both use fmtlib and spdlog, they need to be
rebuilt later.

Thanks

Shengjing Zhu



Bug#958200: RM: golang-gopkg-readline.v1/1.4-1

2020-04-19 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Hi,

Please rm golang-gopkg-readline.v1/1.4-1 from testing.

The situation is,

golang-gopkg-readline.v1 is removed from unstable, but I think it won't
be removed from testing automatically.
Since golang-github-robertkrimen-otto/0.0~git20180617.15f95af-2 in testing has
Build-Depends on golang-gopkg-readline.v1.

However I uploaded golang-github-robertkrimen-otto/0.0~git20180617.15f95af-3
to use golang-github-chzyer-readline.

But golang-github-chzyer-readline/1.4.39.g2972be2-1 in unstable can't migrate
to testing right now, since it causes autopkgtest regression of
golang-gopkg-readline.v1.

So to move on, I think the solution is to directly remove 
golang-gopkg-readline.v1
from testing. (But I'm not sure if after the removing, the autopkgtest 
regression
will be ignored automatically.)

Next time I'll do things in a more correct order..

Thanks



Bug#931551: transition: llvm-defaults to 8

2019-09-15 Thread Shengjing Zhu
Hi,

On Sun, Jul 07, 2019 at 04:29:31PM +0200, Sylvestre Ledru wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello
> 
> Now that we release buster, I would like to move llvm-defaults to 
> llvm-toolchain-8.
> 
> Thanks,
> Sylvestre
> 
> Ben file:
> 
> title = "llvm-defaults";
> 
> Affected: .depends ~ /(clang|llvm)1?-?[345678]/
> Good: .depends ~ /(clang|llvm)1?-?[8]/
> Bad: .depends ~ /(clang|llvm)1?-?[34567]/
> 

I recently package ccls, which depends on libllvm[1].
I'm curious why this ben file doesn't include libllvm?
And should I rebuild ccls manually? Or it will be handled by RT.
I don't see ccls is on [2].

[1] https://tracker.debian.org/pkg/ccls
[2] https://release.debian.org/transitions/html/llvm-defaults.html

Thanks
Shengjing Zhu


signature.asc
Description: PGP signature


Re: Haskell binnmus is there a problem?

2019-09-02 Thread Shengjing Zhu
Fix the Go team mailing list address.
(pkg-go-maintain...@lists.alioth.debian.org -> debian...@lists.debian.org)

On Mon, Sep 02, 2019 at 11:03:56AM +0200, Joachim Breitner wrote:
> Hi,
> 
> Am Montag, den 02.09.2019, 10:57 +0200 schrieb Philipp Kern:
> > FWIW, I started working on this. Unfortunately we do not really have 
> > transactions available to schedule all or nothing. If someone has a 
> > creative idea on how to best signal back partial success, let me know. 
> > :)
> > 
> > (My current best guess is a JSON file served as an attachment to the API 
> > call with success/failure states...)
> 
> 
> The JSON is for the response status, and the request will be the
> existing format as seen in 
> https://people.debian.org/~nomeata/binNMUs-haskell.txt
> right?
> 

I found previous mails failed to reach pkg-go alioth list.
So to the Go team, the disscution starts here,
https://lists.debian.org/debian-release/2019/08/msg00592.html

I want to volunteer to implement the necessary things on the Go team side.

-- 
Shengjing Zhu


signature.asc
Description: PGP signature


Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

2019-08-10 Thread Shengjing Zhu
On Sat, Aug 10, 2019 at 4:38 PM Arnaud Rebillout
 wrote:
>
> On 8/10/19 2:07 PM, Shengjing Zhu wrote:
> > On Sat, Aug 10, 2019 at 2:56 PM Shengjing Zhu  wrote:
> >> On Fri, Aug 9, 2019 at 10:09 PM Arnaud Rebillout
> >>  wrote:
> >>> On 8/9/19 5:15 PM, Adam D. Barratt wrote:
> >>>> The module apparently has three reverse build-dependencies:
> >>>>
> >>>> amazon-ecr-credential-helper:
> >>>> golang-github-docker-docker-credential-helpers-dev
> >>>> docker-pycreds: golang-docker-credential-helpers
> >>>> docker.io: golang-github-docker-docker-credential-helpers-dev (>= 0.6.1~)
> >>>>
> >>>> Would this update imply any of those needing to be rebuilt? If so, is
> >>>> that the end of the tree, or do we end up down a rabbit hole of Go
> >>>> libraries?
> >>> That's a good question. FWIW I tried this command, I got a different
> >>> result from you:
> >>>
> >>> $ dose-ceve -T deb \
> >>>   --deb-native-arch=amd64 \
> >>>   -r golang-github-docker-docker-credential-helpers-dev \
> >>>
> >>> debsrc:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_source_Sources
> >>> \
> >>>
> >>> deb:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
> >>> \
> >>>   | grep-dctrl -n -s Package '' \
> >>>   | sort -u
> >>> golang-docker-dev
> >>> golang-github-docker-docker-credential-helpers-dev
> >>> golang-github-docker-docker-dev
> >>> golang-github-fsouza-go-dockerclient-dev
> >>> golang-github-samalba-dockerclient-dev
> >>>
> >>> I suppose that for every package ending with -dev in this list, we
> >>> should also get the reverse build-depends? Then we're going down the
> >>> rabbit hole.
> >>>
> >>> But I'm not sure that following the reverse build-depends is the right
> >>> way to do it. Maybe following the Built-Using field is better.
> >>>
> >>> Let me CC the Go team (question is: how to figure out which package to
> >>> rebuild after uploading
> >>> golang-github-docker-docker-credential-helpers-dev to stable).
> >> I think checking Built-Using is the right answer (for buster).
> >>
> >> For src:golang-github-docker-docker-credential-helpers, the following
> >> packages need rebuild:
> >>
> >> src:amazon-ecr-credential-helper
> >>
> >> Other packages you find with build-depends don't build an arch:any
> >> package, so no need of binNMU.
>
>
> What command do you use to get the list of packages who have a
> Built-Using on a specific package?
>

ben query -s Source ".built-using ~
/golang-github-docker-docker-credential-helpers/"
/path/to/some/stable_main_binary-amd64_Packages

PS, ben needs version >=0.8.3



--
Shengjing Zhu



Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

2019-08-10 Thread Shengjing Zhu
On Sat, Aug 10, 2019 at 2:56 PM Shengjing Zhu  wrote:
>
> On Fri, Aug 9, 2019 at 10:09 PM Arnaud Rebillout
>  wrote:
> >
> > On 8/9/19 5:15 PM, Adam D. Barratt wrote:
> > > The module apparently has three reverse build-dependencies:
> > >
> > > amazon-ecr-credential-helper:
> > > golang-github-docker-docker-credential-helpers-dev
> > > docker-pycreds: golang-docker-credential-helpers
> > > docker.io: golang-github-docker-docker-credential-helpers-dev (>= 0.6.1~)
> > >
> > > Would this update imply any of those needing to be rebuilt? If so, is
> > > that the end of the tree, or do we end up down a rabbit hole of Go
> > > libraries?
> >
> > That's a good question. FWIW I tried this command, I got a different
> > result from you:
> >
> > $ dose-ceve -T deb \
> >   --deb-native-arch=amd64 \
> >   -r golang-github-docker-docker-credential-helpers-dev \
> >
> > debsrc:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_source_Sources
> > \
> >
> > deb:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
> > \
> >   | grep-dctrl -n -s Package '' \
> >   | sort -u
> > golang-docker-dev
> > golang-github-docker-docker-credential-helpers-dev
> > golang-github-docker-docker-dev
> > golang-github-fsouza-go-dockerclient-dev
> > golang-github-samalba-dockerclient-dev
> >
> > I suppose that for every package ending with -dev in this list, we
> > should also get the reverse build-depends? Then we're going down the
> > rabbit hole.
> >
> > But I'm not sure that following the reverse build-depends is the right
> > way to do it. Maybe following the Built-Using field is better.
> >
> > Let me CC the Go team (question is: how to figure out which package to
> > rebuild after uploading
> > golang-github-docker-docker-credential-helpers-dev to stable).
>
> I think checking Built-Using is the right answer (for buster).
>
> For src:golang-github-docker-docker-credential-helpers, the following
> packages need rebuild:
>
> src:amazon-ecr-credential-helper
>
> Other packages you find with build-depends don't build an arch:any
> package, so no need of binNMU.

The pkg:docker.io maybe is affected, but I'm not sure.
src:golang-github-docker-docker-credential-helpers is embedded, but
it's not shown in the Built-Using field of pkg:docker.io.

This could be either a bug in docker.io or dh-golang.

-- 
Shengjing Zhu



Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

2019-08-10 Thread Shengjing Zhu
On Fri, Aug 9, 2019 at 10:09 PM Arnaud Rebillout
 wrote:
>
> On 8/9/19 5:15 PM, Adam D. Barratt wrote:
> > The module apparently has three reverse build-dependencies:
> >
> > amazon-ecr-credential-helper:
> > golang-github-docker-docker-credential-helpers-dev
> > docker-pycreds: golang-docker-credential-helpers
> > docker.io: golang-github-docker-docker-credential-helpers-dev (>= 0.6.1~)
> >
> > Would this update imply any of those needing to be rebuilt? If so, is
> > that the end of the tree, or do we end up down a rabbit hole of Go
> > libraries?
>
> That's a good question. FWIW I tried this command, I got a different
> result from you:
>
> $ dose-ceve -T deb \
>   --deb-native-arch=amd64 \
>   -r golang-github-docker-docker-credential-helpers-dev \
>
> debsrc:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_source_Sources
> \
>
> deb:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
> \
>   | grep-dctrl -n -s Package '' \
>   | sort -u
> golang-docker-dev
> golang-github-docker-docker-credential-helpers-dev
> golang-github-docker-docker-dev
> golang-github-fsouza-go-dockerclient-dev
> golang-github-samalba-dockerclient-dev
>
> I suppose that for every package ending with -dev in this list, we
> should also get the reverse build-depends? Then we're going down the
> rabbit hole.
>
> But I'm not sure that following the reverse build-depends is the right
> way to do it. Maybe following the Built-Using field is better.
>
> Let me CC the Go team (question is: how to figure out which package to
> rebuild after uploading
> golang-github-docker-docker-credential-helpers-dev to stable).

I think checking Built-Using is the right answer (for buster).

For src:golang-github-docker-docker-credential-helpers, the following
packages need rebuild:

src:amazon-ecr-credential-helper

Other packages you find with build-depends don't build an arch:any
package, so no need of binNMU.

-- 
Shengjing Zhu



Re: Experiment: permanent transition tracker for Go

2019-07-26 Thread Shengjing Zhu
On Sat, Jul 27, 2019 at 6:40 AM Jonathan Wiltshire  wrote:
[...]
>
> I can see the value of this for the Go team internally, but it isn't
> something we're going to run on release.d.o as it is. Is it possible to
> express this as a .ben file?
>

Probably implementing this in ben is much better. I'll find sometime
and try. It maybe need to add a new virtual field in ben, like the
uninstallable one.

--
Shengjing Zhu



Experiment: permanent transition tracker for Go

2019-07-26 Thread Shengjing Zhu
Hi Go team and release team,

During Debconf19, I wrote a project to track the Go transition. If you
think it's worth and interesting, please talk to me. I'm still here
tonight, but I'll leave tomorrow morning.

https://people.debian.org/~zhsj/go-transition/
https://github.com/zhsj/go-transition

-- 
Shengjing Zhu



Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

2019-06-26 Thread Shengjing Zhu
On Tue, Jun 25, 2019 at 08:13:46PM +0200, Paul Gevers wrote:
[...] 
> That said, I decided to unblock docker.io.
> 

Thanks!

But... you have a typo in the hint. The version should be
18.09.1+dfsg1-7.1.

-- 
Shengjing Zhu


signature.asc
Description: PGP signature


Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

2019-06-24 Thread Shengjing Zhu
On Mon, Jun 24, 2019 at 09:08:07PM +0200, Paul Gevers wrote:
[...]
> > The bug is not from upstream. Previously a file was removed from
> > upstream tarball, named engine/pkg/chrootarchive/archive_test.go, which
> > has an important init func:
[...]
> Are you saying this file is only needed for testing? This file isn't
> needed for docker.io itself? Why was it stripped in the first place?
> 

All files with _test.go suffix are for tests in Go.
The maintainer commented in debian/clean:

## Privileged tests:
...
engine/pkg/chrootarchive/archive_test.go

> > Well, after adding this func back, the tests run and the host doesn't
> > crash.
> > 
> > However the tests still can't pass in schroot, the log says:
> 
> [...]
> 
> > Short version: these tests need privileged permission.
> 
> And your schroot doesn't provide those. How about any better container?
> How about buildds?
> 

You can have privileged permission in container if you give it such
permission, like SYS_ADMIN permission, or in docker --privileged.

But none of buildds is allowed. It's too dangerous. Only VM is suitable
for such tests.

-- 
Shengjing Zhu


signature.asc
Description: PGP signature


  1   2   >