Bug#955807: marked as done (transition: netcdf)
Your message dated Wed, 29 Apr 2020 09:15:48 +0200 with message-id <20200429071548.gc95...@ramacher.at> and subject line Re: Bug#955807: transition: netcdf has caused the Debian Bug report #955807, regarding transition: netcdf to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 955807: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955807 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-netcdf.html Control: block -1 by 955715 955749 955806 NetCDF bumped it SONAME requiring a transition. Most rdeps built successfully except adios, oasis3 & metview as summarized below. Transition: netcdf libnetcdf15 (1:4.7.3-1+b1) -> libnetcdf18 (1:4.7.4-1~exp2) The status of the most recent rebuilds is as follows. adios (1.13.1-21)FTBFS (#955715) cmor (3.5.0-3) OK coda (2.21-4) SKIP (B-D only) dx (1:4.4.4-12) OK eccodes(2.17.0-1) OK exodusii (6.02.dfsg.1-8)OK gdal (3.0.4+dfsg-1) OK gerris (20131206+dfsg-19) SKIP (B-D only) grace (1:5.1.25-7) OK grads (3:2.2.1-2)OK gri(2.12.26-1)SKIP (B-D only) kst(2.0.8-3) SKIP (B-D only) labplot(2.7.0-1) OK libminc(2.4.03-2) OK libpdl-netcdf-perl (4.20-6) OK nco(4.9.1-1) OK ncview (2.1.8+ds-3) OK netcdf-cxx (4.3.1-2) OK netcdf-cxx-legacy (4.2-11) OK netcdf-fortran (4.5.2+ds-1) OK netcdf4-python (1.5.3-1) OK octave-netcdf (1.0.13-1) OK r-cran-ncdf4 (1.17-1) OK r-cran-rnetcdf (2.1-1-1) OK ruby-netcdf(0.7.2-3) OK v-sim (3.7.2-8) OK cdftools (3.0.2-4) SKIP (B-D only) deal.ii(9.1.1-9) SKIP (B-D only) emoslib(2:4.5.9-3)SKIP (B-D only) etsf-io(1.0.4-4) SKIP (B-D only) ferret-vis (7.5.0-2) OK gmt(6.0.0+dfsg-1) OK gnudatalanguage(0.9.9-12) OK grass (7.8.2-1) OK harp (1.9.2-1) OK minc-tools (2.3.00+dfsg-3)OK ncl(6.6.2-1) OK oasis3 (3.mct+dfsg.121022-14) FTBFS (#955749) paraview (5.7.0-4) SKIP (B-D only) python-escript (5.5-5)SKIP (B-D only) vtk6 (6.3.0+dfsg2-5)OK vtk7 (7.1.1+dfsg2-2)OK lammps (20191120+dfsg1-2) OK odb-api(0.18.1-10)SKIP (B-D only) pyferret (7.5.0-5) OK qgis (3.10.4+dfsg-1)OK magics++ (4.3.0-1) OK cdo(1.9.9~rc2-1) OK metview(5.8.1-2) FTBFS (#955806) Kind Regards, Bas --- End Message --- --- Begin Message --- On 2020-04-28 09:45:15 +0200, Sebastian Ramacher wrote: > On 2020-04-28 06:26:00, Sebastiaan Couwenberg wrote: > > On 4/27/20 5:57 AM, Sebastiaan Couwenberg wrote: > > > On 4/25/20 9:09 PM, Sebastian Ramacher wrote: > > >> On 2020-04-25 17:23:03, Sebastiaan Couwenberg wrote: > > >>> vtk7 (7.1.1+dfsg2-3) was just uploaded and it FTBFS as reported in > > >>> #958817. > > >>> > > >>> Since it's a key package the RC bug won't trigger autoremoval of it and > > >>> its rdeps like lammps. > > >>> > > >>> If #958817 is not fixed soon, rebuilds in testing-proposed-updates like > > >>> for hdf5 may be required to enable migration of netcdf and the affected > > >>> packages. > > >> > > >> I don't think this will be necessary. libnetcdf15 and libnetcdf18 are > > >> co-installable so netcdf should be smooth-updatable. > > > > > > netcdf and most rdeps have migrated to testing. eccodes & vtk7 should > > > migrated tomorrow. gdal on armel & mips* still need to migrate as well. > > > > eccodes & vtk7 have migrated. gdal on armel & mips* is still TODO. > > gdal is blocked on libgeotiff which should be ready tomorrow. libnetcdf15 got removed from stable. So that's do
NEW changes in stable-new
Processing changes file: linux_4.19.118-1_mips64el.changes ACCEPT
Bug#956590: tracker.debian.org: provide excuse for not migrating to testing
On 13/04/2020 17:02, Drew Parsons wrote: > Thanks for the analysis, Mattia. > > That processing output certainly is hard to parse. Does it mean those > packages > listed for s390x at the end of the dataset are the ones which are making the > problem? Yes. Those packages would become uninstallable if the set listed before migrated to testing. Some notes to consider as well: - s390x was not the only problem, just an example. britney picks a random architecture to do the first tests, and if they fail it stops there, but if they pass it will check every architecture to ensure that nothing breaks - arch:all packages are only checked on amd64 and i386 atm so there likely were some more uninstallable packages that were not reported there. Emilio
Bug#956467: transition: qhull
On 29.04.20 10:02, Emilio Pozuelo Monfort wrote: > If upstream broke the ABI > without bumping the SONAME that's probably the correct solution, but it'd be > good if you can convince them to bump it in the next version I agree, and I did submit a bugreport [1], but no reply so far. > In any case you can go ahead with this. Thanks. [1] https://github.com/qhull/qhull/issues/58
Processed: Re: Bug#956467: transition: qhull
Processing control commands: > tags -1 confirmed Bug #956467 [release.debian.org] transition: qhull Added tag(s) confirmed. -- 956467: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956467 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956467: transition: qhull
Control: tags -1 confirmed On 11/04/2020 19:23, Timo Röhling wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: block -1 by 956460 956461 956462 > > Dear release team, > > I would like to transition qhull 2019.1 after some ABI breaking changes > in upstream. API seems mostly unaffected, except for a deprecated > include path that has been removed. This affects three packages (see below). I see you bumped the SONAME diverging from upstream. If upstream broke the ABI without bumping the SONAME that's probably the correct solution, but it'd be good if you can convince them to bump it in the next version to avoid diverging from them and other distros and breaking compatibility with third party binaries (although in this specific instance I doubt it's much of a worry). In any case you can go ahead with this. Cheers, Emilio
Bug#959081: buster-pu: package libssh/0.8.7-1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hello,
Please allow an upload to fix #956308 (CVE-2020-1730).
That upload should also probably end up in the coming point release
changelog|
7 +++
patches/0001-CVE-2020-1730-Fix-a-possible-segfault-when-zeroing-AES-CT.patch |
32
patches/series |
1 +
3 files changed, 40 insertions(+)
Kind regards,
Laurent Bigonville
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
>From 75f81629de6636a82d0129ad86d9b41dd5d9b8da Mon Sep 17 00:00:00 2001
From: Laurent Bigonville
Date: Wed, 29 Apr 2020 10:38:58 +0200
Subject: [PATCH] Fix possible DoS in client and server when handling AES-CTR
keys with OpenSSL, cherry-picked from upstream (Closes: #956308
CVE-2020-1730)
---
debian/changelog | 7
...ossible-segfault-when-zeroing-AES-CT.patch | 32 +++
debian/patches/series | 1 +
3 files changed, 40 insertions(+)
create mode 100644
debian/patches/0001-CVE-2020-1730-Fix-a-possible-segfault-when-zeroing-AES-CT.patch
diff --git a/debian/changelog b/debian/changelog
index c4273f2f..8225fbd2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libssh (0.8.7-1+deb10u1) buster; urgency=medium
+
+ * Fix possible DoS in client and server when handling AES-CTR keys with
+OpenSSL, cherry-picked from upstream (Closes: #956308 CVE-2020-1730)
+
+ -- Laurent Bigonville Tue, 28 Apr 2020 13:40:28 +0200
+
libssh (0.8.7-1) unstable; urgency=medium
* New upstream bug fix release 0.8.7.
diff --git
a/debian/patches/0001-CVE-2020-1730-Fix-a-possible-segfault-when-zeroing-AES-CT.patch
b/debian/patches/0001-CVE-2020-1730-Fix-a-possible-segfault-when-zeroing-AES-CT.patch
new file mode 100644
index ..cdbc51f5
--- /dev/null
+++
b/debian/patches/0001-CVE-2020-1730-Fix-a-possible-segfault-when-zeroing-AES-CT.patch
@@ -0,0 +1,32 @@
+From: Andreas Schneider
+Date: Tue, 11 Feb 2020 11:52:33 +0100
+Subject: CVE-2020-1730: Fix a possible segfault when zeroing AES-CTR key
+
+Fixes T213
+
+Signed-off-by: Andreas Schneider
+Reviewed-by: Anderson Toshiyuki Sasaki
+(cherry picked from commit b36272eac1b36982598c10de7af0a501582de07a)
+---
+ src/libcrypto.c | 8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/src/libcrypto.c b/src/libcrypto.c
+index 340a3e6..b3285e0 100644
+--- a/src/libcrypto.c
b/src/libcrypto.c
+@@ -636,8 +636,12 @@ static void aes_ctr_encrypt(struct ssh_cipher_struct
*cipher, void *in, void *ou
+ }
+
+ static void aes_ctr_cleanup(struct ssh_cipher_struct *cipher){
+-explicit_bzero(cipher->aes_key, sizeof(*cipher->aes_key));
+-SAFE_FREE(cipher->aes_key);
++if (cipher != NULL) {
++if (cipher->aes_key != NULL) {
++explicit_bzero(cipher->aes_key, sizeof(*cipher->aes_key));
++}
++SAFE_FREE(cipher->aes_key);
++}
+ }
+
+ #endif /* HAVE_OPENSSL_EVP_AES_CTR */
diff --git a/debian/patches/series b/debian/patches/series
index 842c602c..db23779b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
+0001-CVE-2020-1730-Fix-a-possible-segfault-when-zeroing-AES-CT.patch
1003-custom-lib-names.patch
2003-disable-expand_tilde_unix-test.patch
--
2.26.2
NEW changes in stable-new
Processing changes file: linux-signed-i386_4.19.118+1_i386.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux-signed-amd64_4.19.118+1_amd64-buildd.changes ACCEPT Processing changes file: linux-signed-arm64_4.19.118+1_arm64.changes ACCEPT
Bug#959101: buster-pu: package debian-security-support/2020.04.16~deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to update debian-security-support in buster, preferedly to the version
in bullseye (modulo changelog entry), as I think the changes are safe and sane
also because this will make updating the package in future easier.
The reason I want debian-security-support/2020.04.16~deb10u2 is that it
fixes '#890862: debian-security-support: Please change from su to runuser'
so that no PAM session is triggered on each apt run.
2020.04.16~deb10u2 also has some code trivial cleanups from pre-wheezy times,
plus documentation, translation and test updates.
Alternatively I could also imagine doing an upload with just the files
security-support-ended.deb(8|9|10) and security-support-limited updated
and security-support-ended.deb7 probably dropped. However then my question
is, what version number to use for that update, maybe
2019.12.12~2020.04.16~deb10u2?
(I'd like to keep 2020.04.16 in the version number as that is the lasted-updated
date of the information inside the package...)
What do you think? The full diff is attached and the diffstat is
$ debdiff debian-security-support_2019.12.12~deb10u1.dsc
debian-security-support_2020.04.16.dsc |diffstat
check-support-status.hook| 10
check-support-status.in | 88 ---
debian/changelog | 103
debian/control |2
debian/debian-security-support.lintian-overrides |1
debian/debian-security-support.postinst | 10
debian/source/lintian-overrides |1
man/check-support-status.txt |6
po/cs.po | 12 -
po/da.po | 16 -
po/de.po | 276 +++
po/debian-security-support.pot |4
po/es.po |5
po/fr.po |6
po/it.po | 14 -
po/ja.po | 25 --
po/nl.po | 73 +++---
po/pl.po | 47 ++-
po/pt.po | 31 +-
po/pt_BR.po | 55 ++--
po/ru.po | 26 +-
po/sv.po | 70 ++---
security-support-ended.deb10 |1
security-support-ended.deb7 | 66 -
security-support-ended.deb8 |5
security-support-ended.deb9 |6
security-support-limited |3
t/check-support-status.t | 70 +
28 files changed, 551 insertions(+), 481 deletions(-)
--
cheers,
Holger
---
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
There are no jobs on a dead planet.
diff -Nru debian-security-support-2019.12.12~deb10u1/check-support-status.hook debian-security-support-2020.04.16/check-support-status.hook
--- debian-security-support-2019.12.12~deb10u1/check-support-status.hook 2019-05-14 14:09:54.0 +0200
+++ debian-security-support-2020.04.16/check-support-status.hook 2020-02-23 21:30:06.0 +0100
@@ -39,17 +39,11 @@
# Closes: #824081
cd /tmp
-MODES="ended limited"
-
-# Don't invoke earlyend if an unsupporting version is still running. Closes: #824015
-found_version="$(dpkg-query -f '${Version}' -W debian-security-support)"
-if dpkg --compare-versions "2016.03.30" '<=' "$found_version"; then
-MODES="$MODES earlyend"
-fi
+MODES="ended limited earlyend"
for MODE in $MODES ; do
OUTPUT="$TEMPDIR/output"
-su "$USERNAME" --shell /bin/bash --command "
+runuser "$USERNAME" --shell /bin/bash --command "
check-support-status \
--type $MODE \
--no-heading \
diff -Nru debian-security-support-2019.12.12~deb10u1/check-support-status.in debian-security-support-2020.04.16/check-support-status.in
--- debian-security-support-2019.12.12~deb10u1/check-support-status.in 2019-11-01 15:19:34.0 +0100
+++ debian-security-support-2020.04.16/check-support-status.in 2020-03-15 11:03:17.0 +0100
@@ -11,7 +11,7 @@
VERSION='[% VERSION %]'
# Oldest Debian version included in debian-security-support
-DEB_LOWEST_VER_ID=7
+DEB_LOWEST_VER_ID=8
# Version ID for next Debian stable
DEB_NEXT_VER_ID=11
@@ -21,13 +21,15 @@
fi
if [ "$DEBIAN_VERSION" -lt "$DEB_LOWEST_VER_ID" ] || [ "$DEBIAN_VERSION" -gt
NEW changes in stable-new
Processing changes file: linux_4.19.118-2_source.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_source.changes ACCEPT Processing changes file: linux-signed-amd64_4.19.98+1+deb10u1_source.changes ACCEPT Processing changes file: linux-signed-arm64_4.19.98+1+deb10u1_source.changes ACCEPT Processing changes file: linux-signed-i386_4.19.98+1+deb10u1_source.changes ACCEPT
Bug#955211: release.debian.org: Transition r-base for 4.0.0
All, R 4.0.0 was released as scheduled on Friday, source packages have been in experimental since Friday too. There is one build failure on ppc64el but we now know what causes it so a bug fix from upstream should be forthcoming shortly. The bug can also be circumvented by (on that platform only) configuring with --disable-long-double. As such, we're ready, so I may I would like to nudge you towards considering a start for this transition. R is reasonably widely used language that is very well supported in Debian, and it would be good to have this updated upstream version be part of Debian testing and the next release. Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#959081: buster-pu: package libssh/0.8.7-1
Control: tags -1 + confirmed On Wed, 2020-04-29 at 10:45 +0200, Laurent Bigonville wrote: > Please allow an upload to fix #956308 (CVE-2020-1730). Please go ahead. > That upload should also probably end up in the coming point release That's the general idea of p-u, yeah. :-) Regards, Adam
Processed: Re: Bug#959081: buster-pu: package libssh/0.8.7-1
Processing control commands: > tags -1 + confirmed Bug #959081 [release.debian.org] buster-pu: package libssh/0.8.7-1 Added tag(s) confirmed. -- 959081: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959081 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#959133: release.debian.org: Transition for gsl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition GNU GSL 2.6 was release last fall; the package is stable and does not move too much upstream. It has been in 'auto transition' for a while following my initial upload to experimental. Could we maybe nudge it towards transition? Tentative ben file (copied from https://release.debian.org/transitions/html/auto-gsl.html and edited) - title = "gsl"; is_affected = .depends ~ "libgsl25" | .depends ~ "libgsl23"; is_good = .depends ~ "libgsl25"l is_bad = .depends ~"r-api-3.5" - Let me know if I can help otherwise. Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
NEW changes in stable-new
Processing changes file: linux_4.19.118-2_all.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_all.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_amd64-buildd.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_arm64.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_armel.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_armhf.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_i386.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux_4.19.118-2_ppc64el.changes ACCEPT Processing changes file: linux_4.19.118-2_s390x.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_mips.changes ACCEPT Processing changes file: linux-latest_105+deb10u4_s390x-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux_4.19.118-2_armel.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux-latest_105+deb10u4_mips64el-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux_4.19.118-2_amd64-buildd.changes ACCEPT Processing changes file: linux_4.19.118-2_arm64.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux_4.19.118-2_armhf.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux_4.19.118-2_i386.changes ACCEPT
NEW changes in stable-new
Processing changes file: linux-latest_105+deb10u4_ppc64el-buildd.changes ACCEPT
Bug#955547: buster-pu: package waagent/2.2.45-4~deb10u1
On Sat, Apr 25, 2020 at 07:23:11PM +0100, Adam D. Barratt wrote: > Please go ahead. Uploaded. Bastian -- A father doesn't destroy his children. -- Lt. Carolyn Palamas, "Who Mourns for Adonais?", stardate 3468.1.
