NEW changes in stable-new
Processing changes file: rustc_1.41.1+dfsg1-1~deb10u1_i386-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_armhf-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_i386.changes ACCEPT
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_arm64-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_s390x.changes ACCEPT
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_all.changes ACCEPT
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_ppc64el-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_amd64-buildd.changes ACCEPT
Bug#969349: buster-pu: package chrony/3.4-4+deb10u1
Hi,
On 2020-08-31T21:34+0200, Vincent Blut wrote:
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
[ Reason ]
chrony versions prior to 3.5.1 are vulnerable to a symlink race when
creating the PID file. CVE-2020-14367 has been assigned to this
vulnerability.
In accordance with Salvatore Bonaccorso from the security team, no DSA
has been released.
[ Impact ]
Data loss and a denial of service due to the path traversal are possible
in some cases.
While that sounds worrisome, this vulnerabilily can’t be exploited using
the default configuration provided by chrony on Debian, that’s why the
security team marked it as “unimportant”.
[ Tests ]
I manually tested the proposed update to ensure that chronyd still runs
fine using the default PID file location and an alternative one where
the vulnerability could be exploited. I can confirm that the issue is
fixed by the proposed patch and that no regression appeared while
testing.
[ Risks ]
Most of the other major distributions provide this patch now with no
apparent problems, so the risks seem quite low.
[ 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 ]
Switch from fopen() to the open() function with the O_CREAT|O_EXCL flags
to avoid following a symlink and writing the PID to an unexpected file
when chronyd still has the root privileges.
[ Other info ]
I also took the oportunity to fix the autopkgtest of chrony which was
failing on Buster since quite a while.
In the meantime, Matt Corallo encountered a limitation in our AppArmor
profile, which prevents the use of the “tempcomp” directive (#970421).
Updated debdiff attached.
Cheers,
Vincent
diff -Nru chrony-3.4/debian/changelog chrony-3.4/debian/changelog
--- chrony-3.4/debian/changelog 2019-03-18 19:35:34.0 +0100
+++ chrony-3.4/debian/changelog 2020-09-16 13:44:04.0 +0200
@@ -1,3 +1,19 @@
+chrony (3.4-4+deb10u1) buster; urgency=medium
+
+ * debian/patches/:
+- Add create-new-file-when-writing-pidfile.patch to prevent symlink race
+when writing to PID file (CVE-2020-14367).
+
+ * debian/tests/:
+- Fix a regression when running upstream-simulation-test-suite autopkgtest
+on Buster.
+
+ [ Matt Corallo ]
+ * debian/usr.sbin.chronyd:
+- Fix temperature reading. (Closes: #970421)
+
+ -- Vincent Blut Wed, 16 Sep 2020 13:44:04 +0200
+
chrony (3.4-4) unstable; urgency=medium
* debian/patches/*:
diff -Nru chrony-3.4/debian/.gitlab-ci.yml chrony-3.4/debian/.gitlab-ci.yml
--- chrony-3.4/debian/.gitlab-ci.yml2019-03-18 19:35:34.0 +0100
+++ chrony-3.4/debian/.gitlab-ci.yml2020-09-16 13:40:06.0 +0200
@@ -1,20 +1,7 @@
-include:
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+include:
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+ -
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
-build:
-extends: .build-unstable
-reprotest:
-extends: .test-reprotest
-
-lintian:
-extends: .test-lintian
-
-autopkgtest:
-extends: .test-autopkgtest
-allow_failure: true
-
-piuparts:
-extends: .test-piuparts
-
-blhc:
-extends: .test-blhc
+variables:
+ RELEASE: 'buster'
diff -Nru chrony-3.4/debian/patches/create-new-file-when-writing-pidfile.patch
chrony-3.4/debian/patches/create-new-file-when-writing-pidfile.patch
--- chrony-3.4/debian/patches/create-new-file-when-writing-pidfile.patch
1970-01-01 01:00:00.0 +0100
+++ chrony-3.4/debian/patches/create-new-file-when-writing-pidfile.patch
2020-09-16 13:40:06.0 +0200
@@ -0,0 +1,187 @@
+From f00fed20092b6a42283f29c6ee1f58244d74b545 Mon Sep 17 00:00:00 2001
+From: Miroslav Lichvar
+Date: Thu, 6 Aug 2020 09:31:11 +0200
+Subject: main: create new file when writing pidfile
+
+When writing the pidfile, open the file with the O_CREAT|O_EXCL flags
+to avoid following a symlink and writing the PID to an unexpected file,
+when chronyd still has the root privileges.
+
+The Linux open(2) man page warns about O_EXCL not working as expected on
+NFS versions before 3 and Linux versions before 2.6. Saving pidfiles on
+a distributed filesystem like NFS is not generally expected, but if
+there is a reason to do that, these old kernel and NFS versions are not
+considered to be supported for saving files by chronyd.
+
+This is a minimal backport specific to this issue of the following
+commits:
+- commit 2fc8edacb810 ("use PATH_MAX")
+- commit f4c6a00b2a11 ("logging: call exit() in LOG_Message()")
+- commit 7a4c396bba8f ("util: add functions for common file operations")
+- commit e18903a6b563 ("switch to new util file functions")
+
+Reported-by: Matthias Gerstner
+
+--- a/logging.c
b/logging.
NEW changes in stable-new
Processing changes file: llvm-toolchain-7_7.0.1-8+deb10u1_source.changes ACCEPT
Processed: llvm-toolchain-7 7.0.1-8+deb10u1 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 970424 = buster pending Bug #970424 [release.debian.org] buster-pu: package llvm-toolchain-7/1:7.0.1-8+deb10u1 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 970424: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970424 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#970424: llvm-toolchain-7 7.0.1-8+deb10u1 flagged for acceptance
package release.debian.org tags 970424 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: llvm-toolchain-7 Version: 7.0.1-8+deb10u1 Explanation: fix bugs affecting rustc build
Bug#970402: transition: log4cxx
On Tue, 15 Sep 2020 21:29:50 +0200 Emilio Pozuelo Monfort > > Waiting for the green light from you ;-) > > Go ahead. the new log4xx 0.11 is now in unstable and has built on all release archs. (So, I guess the binmnu party can start now ;-) Cheers, -- tobi
Bug#970427: buster-pu: package rust-cbindgen/0.14.4-1~deb10u1
On 16/09/2020 12:12, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2020-09-16 at 11:24 +0200, Emilio Pozuelo Monfort wrote: >> This updates rust-cbindgen to 0.14. In order to do that we have to >> embed the build-deps, like we did for 0.8.7 in stretch. >> >> I have disabled the -dev packages. buster only has librust-cbindgen- >> dev, which has no (build-)rdeps, so we could decruft the old version >> with this update. >> The alternative would be to keep building it, but I'm not sure how >> that would work given the deps are not available in buster. We'd >> probably need to ship the vendored deps in the -dev, possibly causing >> upgrade issues due to file overwrites when installing the standalone >> packages from bullseye, so I didn't bother investigating that route. >> pkg-rust-maintainers@ in Cc in case they have any comments. >> >> Debdiff from 0.14 in [1] due to the size. I haven't uploaded it yet, >> please let me know if the plan to not build and decruft librust- >> cbindgen-dev is good and I'll proceed with the upload. > > Under the circumstances it seems like a reasonable plan. Please go > ahead. Thanks. Uploaded after bumping the rustc and cargo build-dependencies (it won't build with the old rust at least). Cheers, Emilio
Processed: Re: Bug#970427: buster-pu: package rust-cbindgen/0.14.4-1~deb10u1
Processing control commands: > tags -1 + confirmed Bug #970427 [release.debian.org] buster-pu: package rust-cbindgen/0.14.4-1~deb10u1 Added tag(s) confirmed. -- 970427: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970427 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#970427: buster-pu: package rust-cbindgen/0.14.4-1~deb10u1
Control: tags -1 + confirmed On Wed, 2020-09-16 at 11:24 +0200, Emilio Pozuelo Monfort wrote: > This updates rust-cbindgen to 0.14. In order to do that we have to > embed the build-deps, like we did for 0.8.7 in stretch. > > I have disabled the -dev packages. buster only has librust-cbindgen- > dev, which has no (build-)rdeps, so we could decruft the old version > with this update. > The alternative would be to keep building it, but I'm not sure how > that would work given the deps are not available in buster. We'd > probably need to ship the vendored deps in the -dev, possibly causing > upgrade issues due to file overwrites when installing the standalone > packages from bullseye, so I didn't bother investigating that route. > pkg-rust-maintainers@ in Cc in case they have any comments. > > Debdiff from 0.14 in [1] due to the size. I haven't uploaded it yet, > please let me know if the plan to not build and decruft librust- > cbindgen-dev is good and I'll proceed with the upload. Under the circumstances it seems like a reasonable plan. Please go ahead. Regards, Adam
Bug#970427: buster-pu: package rust-cbindgen/0.14.4-1~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, This updates rust-cbindgen to 0.14. In order to do that we have to embed the build-deps, like we did for 0.8.7 in stretch. I have disabled the -dev packages. buster only has librust-cbindgen-dev, which has no (build-)rdeps, so we could decruft the old version with this update. The alternative would be to keep building it, but I'm not sure how that would work given the deps are not available in buster. We'd probably need to ship the vendored deps in the -dev, possibly causing upgrade issues due to file overwrites when installing the standalone packages from bullseye, so I didn't bother investigating that route. pkg-rust-maintainers@ in Cc in case they have any comments. Debdiff from 0.14 in [1] due to the size. I haven't uploaded it yet, please let me know if the plan to not build and decruft librust-cbindgen-dev is good and I'll proceed with the upload. Cheers, Emilio [1] https://people.debian.org/~pochu/rust-cbindgen.debdiff.xz
Bug#970424: buster-pu: package llvm-toolchain-7/1:7.0.1-8+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
This should fix the rustc's i386 and mips* builds. I tested the i386 part,
for mips* will have to see how it goes (and request assistance from the
porters if it's not enough).
Debdiff attached, and package uploaded.
Thanks,
Emilio
diff -Nru llvm-toolchain-7-7.0.1/debian/changelog
llvm-toolchain-7-7.0.1/debian/changelog
--- llvm-toolchain-7-7.0.1/debian/changelog 2019-02-28 13:50:21.0
+0100
+++ llvm-toolchain-7-7.0.1/debian/changelog 2020-09-15 13:36:29.0
+0200
@@ -1,3 +1,11 @@
+llvm-toolchain-7 (1:7.0.1-8+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix for unordered cmpxchg instructions when building rustc.
+ * Disable nomadd4 instructions on mips*.
+
+ -- Emilio Pozuelo Monfort Tue, 15 Sep 2020 13:36:29 +0200
+
llvm-toolchain-7 (1:7.0.1-8) unstable; urgency=medium
* Fix a segfault in autopkgtest by brining
diff -Nru
llvm-toolchain-7-7.0.1/debian/patches/AtomicExpand-Fix-a-crash-bug-when-lowering-unordered-loads.patch
llvm-toolchain-7-7.0.1/debian/patches/AtomicExpand-Fix-a-crash-bug-when-lowering-unordered-loads.patch
---
llvm-toolchain-7-7.0.1/debian/patches/AtomicExpand-Fix-a-crash-bug-when-lowering-unordered-loads.patch
1970-01-01 01:00:00.0 +0100
+++
llvm-toolchain-7-7.0.1/debian/patches/AtomicExpand-Fix-a-crash-bug-when-lowering-unordered-loads.patch
2020-09-15 13:33:01.0 +0200
@@ -0,0 +1,28 @@
+From 2153c4b8281c1e5f25887ef9183947198c50a9d2 Mon Sep 17 00:00:00 2001
+From: Philip Reames
+Date: Tue, 19 Mar 2019 17:20:49 +
+Subject: [PATCH] [AtomicExpand] Fix a crash bug when lowering unordered loads
+ to cmpxchg
+
+Add tests for wider atomic loads and stores. In the process, fix a crasher
where we appearently handled unorder stores, but not loads, when lowering to
cmpxchg idioms.
+
+llvm-svn: 356482
+---
+ llvm/lib/CodeGen/AtomicExpandPass.cpp | 3 +
+ llvm/test/CodeGen/X86/atomic-unordered.ll | 234 +++---
+ 2 files changed, 213 insertions(+), 24 deletions(-)
+
+diff --git a/lib/CodeGen/AtomicExpandPass.cpp
b/lib/CodeGen/AtomicExpandPass.cpp
+index 10dd21d1ef9d..7a8013abccfb 100644
+--- a/lib/CodeGen/AtomicExpandPass.cpp
b/lib/CodeGen/AtomicExpandPass.cpp
+@@ -430,6 +430,9 @@ bool AtomicExpand::expandAtomicLoadToLL(LoadInst *LI) {
+ bool AtomicExpand::expandAtomicLoadToCmpXchg(LoadInst *LI) {
+ IRBuilder<> Builder(LI);
+ AtomicOrdering Order = LI->getOrdering();
++ if (Order == AtomicOrdering::Unordered)
++Order = AtomicOrdering::Monotonic;
++
+ Value *Addr = LI->getPointerOperand();
+ Type *Ty = cast(Addr->getType())->getElementType();
+ Constant *DummyVal = Constant::getNullValue(Ty);
diff -Nru llvm-toolchain-7-7.0.1/debian/patches/mips-force-nomadd4.diff
llvm-toolchain-7-7.0.1/debian/patches/mips-force-nomadd4.diff
--- llvm-toolchain-7-7.0.1/debian/patches/mips-force-nomadd4.diff
1970-01-01 01:00:00.0 +0100
+++ llvm-toolchain-7-7.0.1/debian/patches/mips-force-nomadd4.diff
2020-09-15 13:34:42.0 +0200
@@ -0,0 +1,18 @@
+The MIPS port aims to support the Loongson 3 family of CPUs in addition
+of the other MIPS CPUs. On the Loongson 3 family the MADD4 instructions
+are fused, while they are not fused on the other MIPS CPUs. In order to
+support both, we have to disabled those instructions.
+
+For that, the patch below basically corresponds to the --with-madd4=no
+used on the GCC side.
+
+--- a/clang/lib/Basic/Targets/Mips.h
b/clang/lib/Basic/Targets/Mips.h
+@@ -306,6 +306,7 @@ public:
+ FloatABI = HardFloat;
+ DspRev = NoDSP;
+ HasFP64 = isFP64Default();
++DisableMadd4 = true;
+
+ for (const auto &Feature : Features) {
+ if (Feature == "+single-float")
diff -Nru llvm-toolchain-7-7.0.1/debian/patches/series
llvm-toolchain-7-7.0.1/debian/patches/series
--- llvm-toolchain-7-7.0.1/debian/patches/series2019-02-28
13:49:26.0 +0100
+++ llvm-toolchain-7-7.0.1/debian/patches/series2020-09-15
13:31:10.0 +0200
@@ -161,3 +161,5 @@
kfreebsd/lldb_source_Plugins_Process_FreeBSD.diff
kfreebsd/tools_llvm-shlib_CMakeLists.txt.diff
kfreebsd/include_llvm_MC_MCELFObjectWriter.h.diff
+AtomicExpand-Fix-a-crash-bug-when-lowering-unordered-loads.patch
+mips-force-nomadd4.diff
