Bug#1068024: Fwd: Accepted xz-utils 5.6.3-1 (source) into unstable
On 2024-10-24 23:38:31 [+0200], Thorsten Glaser wrote: > Do we trust these newer versions now? Yes. We started with 5.6.2 which was audited by upstream after the malicious party left. Sebastian
Bug#1085597: [Pkg-openssl-devel] Bug#1085597: Imported target "OpenSSL::Crypto" includes non-existent (still not fixed)
On 2024-10-20 17:20:50 [-0700], VDRU VDRU wrote: > I previously reported this for openssl 3.3.1-2 and it was incorrectly > marked as done/fixed in 3.3.1-6. This is *not* the case and the bug > still persists. The following is a copy of my original bug report, > which still applies: > > After updating from openssl 3.2.2-1, which didn't have this problem, I > now get the following when compiling with cmake: > > Imported target "OpenSSL::Crypto" includes non-existent path > > "/include" > > in its INTERFACE_INCLUDE_DIRECTORIES. > Possible reasons include: > > * The path was deleted, renamed, or moved to another location. > > * An install or uninstall procedure did not complete successfully. > > * The installation package was faulty and references files it does not > provide. You reported #1078020 as an issue with cmake and I found something upstream, backported and closed that bug. This looked like an issue. Now you open this bug because you claim that the bug, that you are facing, is still present in the latest upload or was not fixed where I claim it was. I received zero other reports regarding cmake build issue. The Debian archive appears still to build _or_ I was not pointed to a bug in a package so far. Before writing this email I pulled a cmake project which is not in Debian and this one built, too. I am done spending my free time trying to reproduce this problem. Please provide a testcase where you can show me that it breaks in 3.3.x series and was working in 3.2.x and earlier. If I don't get a way to properly reproduce this, I am going to close this bug with no action in approx two weeks. Sebastian
Bug#1085589: m2crypto: FTBFS on arm*
Package: m2crypto Version: 0.42.0-1 Severity: serious Tags: sid The package FTBFS on armel and armhf but used to build in the previous version. Sebastian
Bug#1085588: m2crypto: Remove invalid test for X509_REQ_set_version().
Package: m2crypto Version: 0.42.0-1 Severity: important Tags: sid patch control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.4 OpenSSL verifies the argument passed to X509_REQ_set_version() resulting in a failure. Patch attached fixes the issue. Sebastian From: Sebastian Andrzej Siewior Date: Sun, 20 Oct 2024 21:14:11 +0200 Subject: [PATCH] test_x509: Use only X509_VERSION_1 (0) as version for CSR. RFC 2986 only defines a single version for CSRs: X509_VERSION_1 (0). OpenSSL starting with 3.4 rejects everything else. Remove the tests where X509_VERSION_2 (1) is used X509_REQ_set_version. Signed-off-by: Sebastian Andrzej Siewior --- tests/test_x509.py | 2 -- 1 file changed, 2 deletions(-) diff --git a/tests/test_x509.py b/tests/test_x509.py index 5ec4af06fc8b3..568e1711d19b4 100644 --- a/tests/test_x509.py +++ b/tests/test_x509.py @@ -240,8 +240,6 @@ log = logging.getLogger(__name__) self.assertEqual(req.as_text(), req4t) self.assertEqual(req.as_der(), req4.as_der()) self.assertEqual(req.get_version(), 0) -req.set_version(1) -self.assertEqual(req.get_version(), 1) req.set_version(0) self.assertEqual(req.get_version(), 0) -- 2.45.2
Bug#1085434: sscg: Fix csr issue with openssl 3.4
Package: sscg Version: 3.0.2-1 Severity: important Tags: sid patch control: affects -1 src:openssl control: forwarded -1 https://github.com/sgallagher/sscg/pull/71 User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.4 OpenSSL verifies the argument passed to X509_REQ_set_version() resulting in a failure. Patch attached fixes the issue. Sebastian From: Sebastian Andrzej Siewior Date: Sat, 19 Oct 2024 15:43:20 +0200 Subject: [PATCH] x509: Use proper version for CSR. RFC 2986 only defines a single version for CSRs: X509_VERSION_1 (0). OpenSSL starting with 3.4 rejects everything else. Use X509_VERSION_1 as version for X509_REQ_set_version. Signed-off-by: Sebastian Andrzej Siewior --- src/x509.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/x509.c b/src/x509.c index 9f6f21b49c2dd..503b7b1b51ed4 100644 --- a/src/x509.c +++ b/src/x509.c @@ -169,7 +169,7 @@ sscg_x509v3_csr_new (TALLOC_CTX *mem_ctx, talloc_set_destructor ((TALLOC_CTX *)csr, _sscg_csr_destructor); /* We will generate only x509v3 certificates */ - sslret = X509_REQ_set_version (csr->x509_req, 2); + sslret = X509_REQ_set_version (csr->x509_req, X509_VERSION_1); CHECK_SSL (sslret, X509_REQ_set_version); subject = X509_REQ_get_subject_name (csr->x509_req); -- 2.45.2
Bug#1085222: libnet-ssleay-perl: Update test for openssl 3.4.0+
Package: libnet-ssleay-perl
Version: 1.94-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.4
Hi,
Starting with OpenSSL 3.4.0 (currently in experimental) the double colon
after "emailAddress" in othername, used via X509V3_EXT_print has been
removed. This is exposed in the test.
The patch attached updates the testsuite.
Sebastian
From: Sebastian Andrzej Siewior
Date: Wed, 16 Oct 2024 21:48:51 +0200
Subject: [PATCH] test: 32_x509_get_cert_info allow single colon.
Starting with 3.4.0 the double colon in emailAddress has been removed.
Adapt the test to allow a single colon in 3.4.0 and later.
Signed-off-by: Sebastian Andrzej Siewior
---
t/local/32_x509_get_cert_info.t | 4
1 file changed, 4 insertions(+)
diff --git a/t/local/32_x509_get_cert_info.t b/t/local/32_x509_get_cert_info.t
index 0f7e2d5a2719f..0fd1b689f1b1b 100644
--- a/t/local/32_x509_get_cert_info.t
+++ b/t/local/32_x509_get_cert_info.t
@@ -188,6 +188,10 @@ for my $f (keys (%$dump)) {
) {
$ext_data =~ s{(othername:) [^, ]+}{$1}g;
}
+ # Starting with 3.4.0 the double colon in emailAddress has been removed.
+ if (Net::SSLeay::SSLeay >= 0x3040) {
+ $ext_data =~ s{emailAddress::}{emailAddress:};
+ }
}
elsif ( $nid == 89 ) {
# The output formatting for certificate policies has a
--
2.45.2
Bug#1002056: Supporting alternative zlib implementations
On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote: > For example, ZIP files or Android APKs built on a Debian system will have a > different compressed stream, like the test files you mention. Which will > likely > break Reproducible Builds tooling like apksigcopier [1] and > reproducible-apk-tools [2]. wouldn't it work to compare the decompressed stream? Is an identical ZIP file a requirement? > There might also be issues with reproducibility of Debian packages themselves > if > e.g. zlib-ng output can differ on different hardware (e.g. number of cores) > even > with an otherwise identical build environment. At the very least I think it > would be good to know how all this could be affected (and how likely things > are > to remain as stable as zlib has been so far) before making a decision to > switch. I don't know at this time. Maybe we could throw it into exp first and evaluate the situtation. > - Fay Sebastian
Bug#1078937: [Pkg-javascript-devel] bookworm-pu: package openssl/3.0.14-1~deb12u1
On 2024-08-24 23:14:46 [+0200], Jérémy Lal wrote: > Le sam. 24 août 2024 à 13:52, Paul Gevers a écrit : > > Indeed, it is harmless. > Upstream nodejs has fixed this in the 20.x branch by allowing both error > codes in the failing test. Is it still the case and if so should I prepare an update or is someone planning a pu at a later point in time? > Jérémy Sebastian
Bug#1081018: firefox: Uses an embedded copy of zstd & brotli.
Source: firefox Version: 130.0-1 Severity: important If I see this right in the build log, then firefox uses an embedded copy of zstd & brotli. The package does not depend on any of those libraries (or libnss3). According to the build log it is compiled and about:config shows certificate_compression_brotli,zlib,zstd which are set to false and can be enabled. I assume that it also works if set to true but did not verify. Sebastian
Bug#1078274: clamav: FTBFS: clamscan/assorted_test.py::TC::test_pe_cert_trust FAILED
On 2024-09-01 22:02:27 [+0200], Santiago Vila wrote: > Could we please fix it in bookworm as well? > (packages in stable must build in stable) I plan to prepare 1.0.7 as pu this weekend. > Thanks. Sebastian
Bug#1074487: [Pkg-openssl-devel] Bug#1074487: CVE-2024-5535
On 2024-09-03 10:54:40 [+0100], Sean Whitton wrote: > Hello openssl maintainers, Hi, > I'm updating openssl in bullseye as part of the LTS effort. > > Is there anyone working on uploading a fix for CVE-2024-5535 to sid? > Could I be of help? No, thank you. That CVE is of minor severity, requires a ton of patches (incl. follow-up) and I didn't want to bother and fix it for stable and mess something up by accident or not cover it properly. It did not look worth it. And since I didn't do that I didn't have a reason to touch Sid. Today, there will be a new OpenSSL release including the fix for it. So this is what I intend to upload to Sid later today and approx a week later (depending on time & testing) open a pu for Bookworm. > Thanks. Sebastian
Bug#1078020: [Pkg-openssl-devel] Bug#1078020: Unfortunately 3.3.1-6 didn't fix the bug
On 2024-08-21 10:01:36 [-0700], VDRU VDRU wrote: > Hi, > I'm not really a coder so the requested project is a bit beyond my > ability. But, I did notice a patch in 3.3.1-7 that sounds like it may > fix the cause of this problem. If you get a moment, would you mind > looking at: > https://sources.debian.org/patches/openssl/3.3.1-7/Fix-cmake-generator.patch/ > > From the description, it sounds correct. What do you think? This is exactly the patch I added to the 3.3.1-6 (now -7) in order to fix the cmake problem you mentioned. > Cheers Sebastian
Bug#1078020: [Pkg-openssl-devel] Bug#1078020: Unfortunately 3.3.1-6 didn't fix the bug
On 2024-08-17 08:20:52 [-0700], VDRU VDRU wrote: > Hi, Hi, > I've just updated my openssl + libssl-dev to 3.3.1-6, which was > thought to have fixed the bug I reported. Unfortunately that's not the > case however. I once again deleted OpenSSLConfig.cmake and the problem > was fixed so I guess that file still isn't quite right..? it appears so, yes. I did backport a patch from upstream which looked like they fixed it so I hoped it solves it. > Any further ideas? Would you please submit a tiny project containing the cmakefile and a (maybe) a .c file which it links and compiles? You could strip everything non-essencial out of it. That would help to track it down. Otherwise I would have to wait until someone else complains or it is fixed upstream and it magicaly appears here… Sebastian
Bug#965041: [Pkg-openssl-devel] Bug#965041: Bug#965041: closed by Debian FTP Masters (reply to Sebastian Andrzej Siewior ) (Bug#965041: fixed
On 2024-08-18 10:45:08 [+0200], Paul Gevers wrote: > Hi, Hi, > On Wed, 14 Aug 2024 19:57:25 +0200 Sebastian Andrzej Siewior > wrote: > > I'm sorry if this is causing trouble. I splitted the legacy provider out > > and added a Recommends: assuming that it is pulled in by default. It did > > not pop on the debci. > > It also breaks reproducible builds: > https://tests.reproducible-builds.org/debian/stats_breakages_100d.png (via > diffoscope breakage). Buh. > > Is this causing enough trouble that you would say it needs a Depends: > > until this is resolved? > > I'd say so (with Release Team member hat on). Okay, will do so. > Paul Sebastian
Bug#965041: [Pkg-openssl-devel] Bug#965041: closed by Debian FTP Masters (reply to Sebastian Andrzej Siewior ) (Bug#965041: fixed in openssl
On 2024-08-18 20:29:44 [+0100], Colin Watson wrote: > On Wed, Aug 14, 2024 at 07:11:08PM +0100, Colin Watson wrote: > > Maybe it's worth you filing an issue on > > https://github.com/pyca/cryptography/issues to let cryptography upstream > > know about the problem? That way you could explain the change and > > discuss whether it makes sense to change cryptography to match the > > Debian-specific layout here, or whether it makes sense to change Debian > > in some other way. > > I filed https://github.com/pyca/cryptography/issues/11450. I'd > appreciate it if somebody from the Debian OpenSSL team could subscribe > to that issue so that I don't need to be a go-between. Colin, thanks a lot for opening the issue. > Thanks, Sebastian
Bug#1075828: bookworm-pu: package openssl/3.0.13-1~deb12u2
On 2024-08-14 21:05:28 [+0100], Adam D. Barratt wrote: > Sorry for the delay. No worries, thank you for handling it. > I've just flagged the bugfix upload for acceptance into p-u. If you'd > like to look at 3.0.14 as well, please open a new bug for that. If it > makes any difference, the window for 12.7 closes in about 10 days from > now. I just opened a pu for it. If I am late then I am late, don't worry too much ;) > Regards, > > Adam Sebastian
Bug#965041: [Pkg-openssl-devel] Bug#965041: closed by Debian FTP Masters (reply to Sebastian Andrzej Siewior ) (Bug#965041: fixed in openssl
On 2024-08-14 14:20:08 [+0100], Colin Watson wrote: > On Fri, Aug 09, 2024 at 09:15:20AM +, Debian Bug Tracking System wrote: > >* Split the legacy provider into its own package (Closes: #965041). > > By default, this breaks anything that uses python3-cryptography: > > https://github.com/pyca/cryptography/blob/43.0.0/src/rust/src/lib.rs#L77 > > There are two natural options: set CRYPTOGRAPHY_OPENSSL_NO_LEGACY, or > depend on openssl-provider-legacy. I guess the former is a reasonable > workaround, at least in the short term, but it's going to have to be > done in the test suite of the entire reverse-dependency tree of > python3-cryptography; or python3-cryptography itself would have to be > changed, which ideally would need to be coordinated with upstream since > it'd be a semantic change. > > Given what seems to have been a relatively weak and contested > justification for making this change, is this actually worth all the > effort? I'm sorry if this is causing trouble. I splitted the legacy provider out and added a Recommends: assuming that it is pulled in by default. It did not pop on the debci. Is this causing enough trouble that you would say it needs a Depends: until this is resolved? Sebastian
Bug#766052: [Pkg-openssl-devel] Bug#766052: closed by Joachim Bauch (Re: openssl: verify does not support single dash parameter)
control: found -1 1.0.1f-1 (the previous in unstable at the time for the timeline)
Bug#766052: closed by Joachim Bauch (Re: openssl: verify does not support single dash parameter)
control: reopen -1 control: found -1 3.3.1-2 On 2024-08-13 23:21:04 [+], Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the openssl package: > > #766052: openssl: verify does not support single dash parameter > > It has been closed by Joachim Bauch . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Joachim Bauch > by > replying to this email. Please don't close bugs in the BTS. Provide the information needed and leave closing the bug to the maintainer. Sebastian
Bug#1078509: [Pkg-openssl-devel] Bug#1078509: libcrypto.pc is missing libdir
On 2024-08-11 18:38:10 [+0200], Chris Hofstaedtler wrote: > openssl 3.3(.1) has a known issue with the installed pkg-config > files, causing build failures of depdendent packages like > pdns(-recursor). Basically, detection of the prefix used for > libssl.so is broken. Thank you for reporting. Strange that none of the CI jobs failed. > > Chris Sebastian
Bug#1078020: [Pkg-openssl-devel] Bug#1078020: Imported target "OpenSSL::Crypto" includes non-existent path
On 2024-08-07 06:57:51 [-0700], VDRU VDRU wrote: > Hi, Hi, > Thanks for replying. I'm not sure what test you want me to try but I > deleted the OpenSSLConfig.cmake you mentioned and the problem went > away so I guess your suspicion is correct that there's a problem with > that file? can you give a test case i.e. what you are doing that was working before and is not working any more. I think a smal simple cmake file where I can do "cmake ." and check what it is doing and what is missing/ wrong. I am not clever enought to do this cmake thingy. Sebastian
Bug#1078020: [Pkg-openssl-devel] Bug#1078020: Imported target "OpenSSL::Crypto" includes non-existent path
On 2024-08-05 23:16:38 [-0700], VDRU VDRU wrote: > After updating from openssl 3.2.2-1, which didn't have this problem, I > now get the following when compiling with cmake: > > Imported target "OpenSSL::Crypto" includes non-existent path > > "/include" > > in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: Can you give a test case, please? My cmake foo is quite low. The 3.3 series provides a OpenSSLConfig.cmake which is probably wrong. The 3.2 series had nothing so I don't know hat cmake did there, probably fallback to pkg-config. Sebastian
Bug#1074764: 3.0.14 released with fix
On 2024-07-31 12:23:24 [+0200], Anton Lundin wrote: > OpenSSL 3.0.14 is now released containing a cherry-pick of > 39ea78379826fa98e8dc8c0d2b07e2c17cd68380 as > https://github.com/openssl/openssl/commit/ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6 > > I'd love to see a fix for this bug rolled out in Debian 12. I did open #1075828 to fix exactly this issue. I just pinged the report/ request asking if we should update 3.0.14 right away given that there is a point release by the of the month. The wheels were in motion since the original report. > //Anton Sebastian
Bug#1077066: openssl: Regression in OpenSSL 3.0.12 caused SoftHSM to crash on exit
On 2024-07-25 19:51:31 [+0200], Ondřej Surý wrote: > Can we get 3.0.14 in stable, please? I did open #1075828 to fix exactly this issue. I just pinged the report/ request asking if we should update 3.0.14 right away given that there is a point release by the of the month. > Ondrej Sebastian
Bug#1075828: bookworm-pu: package openssl/3.0.13-1~deb12u2
On 2024-07-05 23:32:13 [+0200], To sub...@bugs.debian.org wrote: > In the meantime the patch, that broke it, was reverted and this change > is part of 3.0.14. I didn't propose 3.0.14 for Bookworm because it was > close to the point release. (This change is also part of 3.2.2 release > in unstable.) As a side note: The reporter of #1074764 confirmed that > thsi changes fixes the osslsigncode issue for him. Just wanted to check where we stand on this. The other option is adding 3.0.14 via the regular stable queue. I am currently back and could look into fallout should there be something (not that I am aware of something and nothing broke in unstable so far). Sebastian
Bug#1077763: gcc-14: An alignment request might be added before endbr on function entry.
Package: gcc-14 Version: 14.1.0-5 Severity: important Control: forwarded -1 https://gcc.gnu.org/PR116174 gcc-14 may add an alignment requesst before endbr with -fcf-protection=branch -O2. Upstream report has a testcase. This is just for tracking. Sebastian
Bug#1075924: ruby3.3: FTBFS with openssl 3.3
Package: src:ruby3.3 Version: 3.3.1-6 Severity: important Tags: sid patch control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.3 control: forwarded -1 https://github.com/ruby/openssl/pull/728 Ruby fails the CI-testsuite against openssl 3.3 in experimental. Based on CI-log: | 1) Error: |OpenSSL::TestASN1#test_utctime: |OpenSSL::ASN1::ASN1Error: utctime is too short | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode_test' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:411:in `test_utctime' | | 2) Error: |OpenSSL::TestASN1#test_generalizedtime: |OpenSSL::ASN1::ASN1Error: generalizedtime is too short | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode_test' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:433:in `test_generalizedtime' | |Finished tests in 732.831411s, 26.2202 tests/s, 7769.1375 assertions/s. |19215 tests, 5693468 assertions, 0 failures, 2 errors, 83 skips The patch appears to have been merged into the release branch. Sebastian
Bug#1075923: ruby3.2: FTBFS with openssl 3.3
Package: src:ruby3.2 Version: 3.2.3-1 Severity: important Tags: sid patch control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.3 control: forwarded -1 https://github.com/ruby/openssl/pull/728 Ruby fails the CI-testsuite against openssl 3.3 in experimental. Based on CI-log: | 1) Error: |OpenSSL::TestASN1#test_utctime: |OpenSSL::ASN1::ASN1Error: utctime is too short | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode_test' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:411:in `test_utctime' | | 2) Error: |OpenSSL::TestASN1#test_generalizedtime: |OpenSSL::ASN1::ASN1Error: generalizedtime is too short | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode_test' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:433:in `test_generalizedtime' | |Finished tests in 732.831411s, 26.2202 tests/s, 7769.1375 assertions/s. |19215 tests, 5693468 assertions, 0 failures, 2 errors, 83 skips The patch appears to have been merged into the release branch. Sebastian
Bug#1075922: ruby3.1: FTBFS with openssl 3.3
Package: src:ruby3.1 Version: 3.1.2-8.3 Severity: important Tags: sid patch control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.3 control: forwarded -1 https://github.com/ruby/openssl/pull/728 Ruby fails the CI-testsuite against openssl 3.3 in experimental. Based on CI-log: | 1) Error: |OpenSSL::TestASN1#test_utctime: |OpenSSL::ASN1::ASN1Error: utctime is too short | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode_test' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:411:in `test_utctime' | | 2) Error: |OpenSSL::TestASN1#test_generalizedtime: |OpenSSL::ASN1::ASN1Error: generalizedtime is too short | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:698:in `decode_test' | /tmp/autopkgtest-lxc.9xrphuye/downtmp/autopkgtest_tmp/test/openssl/test_asn1.rb:433:in `test_generalizedtime' | |Finished tests in 732.831411s, 26.2202 tests/s, 7769.1375 assertions/s. |19215 tests, 5693468 assertions, 0 failures, 2 errors, 83 skips The patch appears to have been merged into the release branch. Sebastian
Bug#1075828: bookworm-pu: package openssl/3.0.13-1~deb12u2
Package: release.debian.org
Control: affects -1 + src:openssl
X-Debbugs-Cc: open...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal
Well. There was a bug against openssl in unstable (and according to the
bug report I filled it against 3.0.12 [0]) that broke the SoftHSM
testsuite via libp11. This went nowhere; however I got a patch against
the openssl binary which worked around the issue (the testsuite used the
openssl binary and libp11 with a module from SoftHSM).
Due to mysteries circumstances I forgot about that patch while preparing
the update 3.0.13-1~deb12u1. On the bright side, #1074764 [1] was
reported against src:openssl affecting osslsigncode and the patch, I
forgot about, would not have helped. ¯\_(ツ)_/¯
In the meantime the patch, that broke it, was reverted and this change
is part of 3.0.14. I didn't propose 3.0.14 for Bookworm because it was
close to the point release. (This change is also part of 3.2.2 release
in unstable.) As a side note: The reporter of #1074764 confirmed that
thsi changes fixes the osslsigncode issue for him.
Now that osslsigncode is broken in Bookworm I propose to apply that one
patch (from upstream) to revert the code that broke osslsigncode as well
as libp11+SoftHSM.
There are still a few CVEs open against the Bookworm version but they
all are minor/ low severity. I would be more comfortable to just fix the
one issue at hand which would also make the review easier. Also maybe
route this via bookwork/updates.
I will start looking into a 3.0.14 pu in August at the earliest.
Please find attached the proposed debdiff.
[0] https://github.com/openssl/openssl/issues/22508
[1] https://bugs.debian.org/1074764
Sebastian
diff -Nru openssl-3.0.13/debian/changelog openssl-3.0.13/debian/changelog
--- openssl-3.0.13/debian/changelog 2024-03-03 10:47:43.0 +0100
+++ openssl-3.0.13/debian/changelog 2024-07-05 23:04:47.0 +0200
@@ -1,3 +1,10 @@
+openssl (3.0.13-1~deb12u2) bookworm; urgency=medium
+
+ * Revert "Improved detection of engine-provided private "classic"
+keys" (Closes: #1074764).
+
+ -- Sebastian Andrzej Siewior Fri, 05 Jul 2024 23:04:47 +0200
+
openssl (3.0.13-1~deb12u1) bookworm; urgency=medium
* Import 3.0.13
diff -Nru openssl-3.0.13/debian/patches/Revert-Improved-detection-of-engine-provided-private-clas.patch openssl-3.0.13/debian/patches/Revert-Improved-detection-of-engine-provided-private-clas.patch
--- openssl-3.0.13/debian/patches/Revert-Improved-detection-of-engine-provided-private-clas.patch 1970-01-01 01:00:00.0 +0100
+++ openssl-3.0.13/debian/patches/Revert-Improved-detection-of-engine-provided-private-clas.patch 2024-07-05 23:04:41.0 +0200
@@ -0,0 +1,78 @@
+From: Tomas Mraz
+Date: Fri, 15 Dec 2023 13:45:50 +0100
+Subject: Revert "Improved detection of engine-provided private "classic"
+ keys"
+
+This reverts commit 2b74e75331a27fc89cad9c8ea6a26c70019300b5.
+
+The commit was wrong. With 3.x versions the engines must be themselves
+responsible for creating their EVP_PKEYs in a way that they are treated
+as legacy - either by using the respective set1 calls or by setting
+non-default EVP_PKEY_METHOD.
+
+The workaround has caused more problems than it solved.
+
+Fixes #22945
+
+Reviewed-by: Dmitry Belyavskiy
+Reviewed-by: Neil Horman
+(Merged from https://github.com/openssl/openssl/pull/23063)
+
+(cherry picked from commit 39ea78379826fa98e8dc8c0d2b07e2c17cd68380)
+---
+ crypto/engine/eng_pkey.c | 42 --
+ 1 file changed, 42 deletions(-)
+
+diff --git a/crypto/engine/eng_pkey.c b/crypto/engine/eng_pkey.c
+index f84fcde46016..075a61b5bfbf 100644
+--- a/crypto/engine/eng_pkey.c
b/crypto/engine/eng_pkey.c
+@@ -79,48 +79,6 @@ EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id,
+ ERR_raise(ERR_LIB_ENGINE, ENGINE_R_FAILED_LOADING_PRIVATE_KEY);
+ return NULL;
+ }
+-/* We enforce check for legacy key */
+-switch (EVP_PKEY_get_id(pkey)) {
+-case EVP_PKEY_RSA:
+-{
+-RSA *rsa = EVP_PKEY_get1_RSA(pkey);
+-EVP_PKEY_set1_RSA(pkey, rsa);
+-RSA_free(rsa);
+-}
+-break;
+-# ifndef OPENSSL_NO_EC
+-case EVP_PKEY_SM2:
+-case EVP_PKEY_EC:
+-{
+-EC_KEY *ec = EVP_PKEY_get1_EC_KEY(pkey);
+-EVP_PKEY_set1_EC_KEY(pkey, ec);
+-EC_KEY_free(ec);
+-}
+-break;
+-# endif
+-# ifndef OPENSSL_NO_DSA
+-case EVP_PKEY_DSA:
+-{
+-DSA *dsa = EVP_PKEY_get1_DSA(pkey);
+-EVP_PKEY_set1_DSA(pkey, dsa);
+-DSA_free(dsa);
+-}
+-break;
+-#endif
+-# ifndef OPENSSL_NO_DH
+-case EVP_PKEY_DH:
+-{
+-DH *dh = EVP_PKEY_get1_DH(pkey);
+-EVP_PKEY_set1_DH(pkey, dh);
+-DH_free(dh);
+-}
+-break;
+-#endif
+-default:
+-/*Do nothing */
+-break;
+-}
+
Bug#1074764: [Pkg-openssl-devel] Bug#1074764: signing with osslsigncode fails with a segmentation fault since latest stable update
On 2024-07-02 16:23:58 [+0200], Sébastien Villemot wrote: > Dear Maintainers, > > Since the last upgrade of openssl on bookworm (version 3.0.13-1~deb12u1), code > signing using osslsigncode (and my Yubikey) now fails with a segmentation > fault. It was working properly with version 3.0.11-1~deb12u2 (and note that > downgrading solves the problem). > > Here is the command: > > $ osslsigncode sign -pkcs11module > /usr/lib/x86_64-linux-gnu/libykcs11.so.2 -key > "pkcs11:id=%01;type=private;pin-value=" -certs > ~/code-signing-certificate.pem -n Foo -i https://www.foo.org -t > http://timestamp.comodoca.com -in installer.exe -out > installer-signed.exe … > > Note that the segfault occurs in /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so > (from libengine-pkcs11-openssl), which is itself called by libcrypto.so.3 > (from > libssl3). Can you check if https://github.com/openssl/openssl/commit/39ea78379826fa98e8dc8c0d2b07e2c17cd68380 fixes it? > Cheers, Sebastian
Bug#1073128: [Pkg-clamav-devel] Bug#1073128: clamav: unaligned access on armhf architecture
control: forwarded -1 https://github.com/Cisco-Talos/clamav/pull/1293 On 2024-06-24 22:10:27 [+0200], To Gianfranco Costamagna wrote: > Instead of arguing with me, you could forward it directly to upstream > and give a pointer to apply whatever upsteams did. Forwarded upstream. Would be nice if you could test it since it works for me eitherway… Sebastian
Bug#1073128: [Pkg-clamav-devel] Bug#1073128: clamav: unaligned access on armhf architecture
On 2024-06-13 09:34:14 [+0200], Gianfranco Costamagna wrote:
> Hello, in Ubuntu, where the kernel is configured to forbid unaligned accesses
> on armhf, the package FTBFS
> (this should be reproducible also on some Debian buildd machines, this is why
> I'm reporting as serious severity)
Isn't ARMv6+ double of unaligned access? armhf requires VFP so that
should be something later. Or am I wrong here?
> example of failure:
> https://launchpadlibrarian.net/734963041/buildlog_ubuntu-oracular-armhf.clamav_1.3.1+dfsg-3ubuntu1_BUILDING.txt.gz
…
> The following patch makes sure the unaligned access is fixed:
>
> Description: resolve armhf failure to build from source.
Instead of arguing with me, you could forward it directly to upstream
and give a pointer to apply whatever upsteams did.
> Author: Vladimir Petko
> --- a/libclamav/special.c
> +++ b/libclamav/special.c
> @@ -48,7 +48,8 @@
>
> int cli_check_mydoom_log(cli_ctx *ctx)
> {
> -const uint32_t *record;
> +const uint32_t record[16];
> +const uint32_t mask = 0x;
please get rid of mask and add your data pointer here.
> uint32_t check, key;
> fmap_t *map = ctx->fmap;
> unsigned int blocks = map->len / (8 * 4);
> @@ -59,14 +60,20 @@
> if (blocks > 5)
> blocks = 5;
>
> -record = fmap_need_off_once(map, 0, 8 * 4 * blocks);
> -if (!record)
> +// returns unaligned memory block
> +const char* data = fmap_need_off_once(map, 0, 8 * 4 * blocks);
> +if (!data)
> return CL_CLEAN;
> +
> while (blocks) { /* This wasn't probably intended but that's what the
> current code does anyway */
> -if (record[--blocks] == 0x)
> +unsigned int offset = --blocks;
> +offset *=sizeof(uint32_t);
> +// safe (but slow) on unaligned memory
> +if (!memcmp(&data[offset], &mask, sizeof(uint32_t)))
> return CL_CLEAN;
something like
| while (blocks) { /* This wasn't probably intended but that's what the
current code does anyway */
| uint32_t local;
|
| memcpy(&local, &data[--blocks * sizeof(uint32_t)], sizeof(uint32_t));
| if (local == 0x)
| return CL_CLEAN;
I am halfway tempted to suggest a packed-wrapper but this would be best
to consult upstream first.
> }
> -
> +// copy into aligned array to perform bit operations
> +memcpy(record, data, sizeof(record));
> key = ~be32_to_host(record[0]);
> check = (be32_to_host(record[1]) ^ key) +
> (be32_to_host(record[2]) ^ key) +
Sebastian
Bug#1073013: nodejs: Testsuite fails with OpenSSL 3.2.2
Package: nodejs
Version: 20.14.0+dfsg-1
Severity: serious
Tags: patch
OpenSSL 3.2.2 introduced an error code a behaviour Node was testing and
now "test/parallel/test-http2-https-fallback.js" is unhappy. The OpenSSL
change is was introduced in https://github.com/openssl/openssl/pull/24338.
I don't know if node relies on that error outside of the testsuite. The
patch attached swaps the error code and the test passes. OpenSSL 3.2.2
is currently in unstable.
Sebastian
From: Sebastian Andrzej Siewior
Date: Tue, 11 Jun 2024 19:30:13 +
Subject: [PATCH] tests: Check for real error code
OpenSSL since 3.2.2 got an actual error code for the behaviour node was
testing. It was introduced by https://github.com/nodejs/node/pull/53384.
Signed-off-by: Sebastian Andrzej Siewior
---
test/parallel/test-http2-https-fallback.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/parallel/test-http2-https-fallback.js b/test/parallel/test-http2-https-fallback.js
index 8e0612375f48..d44e49ab021c 100644
--- a/test/parallel/test-http2-https-fallback.js
+++ b/test/parallel/test-http2-https-fallback.js
@@ -151,7 +151,7 @@ function onSession(session, next) {
// Incompatible ALPN TLS client
tls(Object.assign({ port, ALPNProtocols: ['fake'] }, clientOptions))
.on('error', common.mustCall((err) => {
- strictEqual(err.code, 'ECONNRESET');
+ strictEqual(err.code, 'ERR_SSL_TLSV1_ALERT_NO_APPLICATION_PROTOCOL');
cleanup();
testNoALPN();
}));
Bug#1071121: transition: clamav
On 2024-06-02 13:14:30 [+0200], Sebastian Ramacher wrote: > Great. Please go ahead. It built in unstable. I will upload libclamunrar, it requires a source-full upload. > Cheers Sebastian
Bug#1071121: transition: clamav
Control: tags -1 -moreinfo On 2024-05-15 13:22:13 [+0200], Emilio Pozuelo Monfort wrote: > Yes, go through experimental if you want to rename it. You'll have to add > proper conflicts/etc. Let us know once the package is accepted in > experimental. The package has been accepted in experimental. > Cheers, > Emilio Sebastian
Bug#1060011: [Pkg-clamav-devel] Bug#1060011:
On 2024-05-30 08:55:18 [+0530], Jaikumar Sharma wrote: > I've also stumbled upon due to this bug , is there any workaround available? Do you intend to use it and if so can you configure it manually? None of the options are enabled by default in the sample config file. > Thanks. Sebastian
Bug#1072191: [Pkg-clamav-devel] Bug#1072191: clamav: please add support for loong64
On 2024-05-30 02:14:22 [+], wuruilong wrote: > Dear Maintainer, > > Clamav fails to compile on loongarch because the package dependency > linux-raw-sys does not support loongarch. Please check the upstream > already support loongarch architecture, modify the code of clamav to > compile, but the compilation process will check the md5 value of the > modified file, please upgrade linux-raw-sys. the attached patch is for > reference only. It built in experimental already so you just need to wait until it migrates to unstable. > wuruilong Sebatian
Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…
On 2024-05-20 12:21:30 [+0200], Jean-Guilhem Cailton wrote: > Le 20/05/2024 à 10:11, Sebastian Andrzej Siewior a écrit : > > Okay. This was old testing -> new testing or Bookworm -> testing? Was > > this "apt upgrade && apt dist-upgrade" or just "apt dist-upgrade" ? > > This was old testing -> new testing. > This was just "apt full-upgrade". Okay. > It seems to me that having both :i386 and :amd64 libraries increases the > risk of failure, because of the many "apt" steps that can take place between > the removal of old :amd64 (that may happen close to the treatment of the > :i386 version, like here for libssl3) and install of t64:amd64. On the > contrary, when only :amd64 is present, it seems that the replacement install > closely follows the removal. how did you have two versions? I couldn't install :amd64 and :i386 of that package. I tried several bookworm -> testing upgrade but in bookworm I could install either :i386 or :amd64 version of postgres. Installing the other version removed the former… I performed a few upgrades and all succeeded. Anyway to reproduce what you did? > Jean-Guilhem Sebastian
Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…
On 2024-05-20 08:59:22 [+0200], Jean-Guilhem Cailton wrote: > Thank you Sebastian for your reply. > > I am sorry, but it is not possible for me to go back to the pre- > full-upgrade state to try what you suggest. Okay. This was old testing -> new testing or Bookworm -> testing? Was this "apt upgrade && apt dist-upgrade" or just "apt dist-upgrade" ? > Anyway, as shown by the extracts quoted, "apt full-upgrade" announced it was > going to remove both libssl3(:amd64 by default on my system) and > libssl3:i386, and install libssl3t64(:amd64) and libssl3t64:i386 instead. So > the presence of obsolete packages does not seem to have interfered. This is required for the transition. > By looking in the full log for instances of other libraries that had both > :amd64 and :i386 versions, and that were going to be removed in spite of > apparent "dependency problems", I noticed that the installation of the > replacement t64:amd64 version sometimes happened much later than the > removal. Now that I think about it, you need both PostgreSQL version since you need to perform an update of the databse (to get it from 15 to 16). Let me try to do this later and see what happens. But you have :i386 and :amd64 binaries. This shouldn't complicate the sitution much since sudo/ systemd and so on depend on the amd64 library only. Anyway. I will try to spin a Bookworm VM with psql and then update to testing and check what happens during the update. > So, my understanding is that, unfortunately, the postgresql-16 install > script error interrupted the full-upgrade before libssl3t64:amd64 had been > installed, which left the system without the libcrypto.so.3 needed by both > systemctl and sudo... Correct. Usually a transition is something like libfoo1 -> libfoo2 where the package names changes and the name of .so file changes, too. In this t64 transition however only the package name changes while the library file itself remains the same. That means thr new (t64) package conflict with the older (non-t64) and both can't exists at the same time. dpkg then needs to break the system a bit where it removes libssl3 and later adds libssl3t64 to the system. > Jean-Guilhem Sebastian
Bug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))
On 2024-05-19 16:18:59 [+0200], Jean-Guilhem Cailton wrote: > I should have added that the "apt full-upgrade" run that left the system > with a broken sudo was interrupted by an error, also due to the missing > libcrypto.so.3, and ended with: > > " > Préparation du dépaquetage de .../5-postgresql-16_16.3-1_amd64.deb ... > systemctl: error while loading shared libraries: libcrypto.so.3: cannot open > shared object file: No such file or directory > dpkg: avertissement: le sous-processus ancien paquet postgresql-16 script > pre-removal a renvoyé un état de sortie d'erreur 127 > dpkg: tentative d'exécution du script du nouveau paquet à la place... > systemctl: error while loading shared libraries: libcrypto.so.3: cannot open > shared object file: No such file or directory > dpkg: erreur de traitement de l'archive > /tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb (--unpack) : > le sous-processus nouveau postgresql-16 paquet pre-removal script a renvoyé > un état de sortie d'erreur 127 > Des erreurs ont été rencontrées pendant l'exécution : > /tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb > Erreur : Le délai d’attente est dépassé > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) You seem to have packages installed which are not in Debian anymore. From a quick glance that is - postgresql-14 - postgresql-15 The problem is basically that those packages require libssl3 while everything else in-system depends on libssl3t64 and this conflicts with libssl3. Both provide the same .so library file. Can you try if this update is doable having only packages available in Debian? The command "apt list ?obsolete" lists package which are no longer in the archive. Please ensure that you have no packages from third-party repo installed. Sebastian
Bug#1071121: transition: clamav
Package: release.debian.org Control: affects -1 + src:clamav X-Debbugs-Cc: cla...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal ClamAV 1.3.x has a new soname. I have the in package in experimental with libclamav12t64. I would like to go back to libclamav12 (there is already libclamav11t64 so I don't think there is a need to keep the t64 suffix any longer). The impact is small, three packages in main which I test-built and libclamunrar in non-free which I need to upload manually. I can pre-upload the libclamav12 to experimental to avoid the new queue if this is preferred. Ben file: title = "clamav"; is_affected = .depends ~ "libclamav11t64" | .depends ~ "libclamav12"; is_good = .depends ~ "libclamav12"; is_bad = .depends ~ "libclamav11t64"; Sebastian
Bug#1070667: [Pkg-openssl-devel] Bug#1070667: closed by Sebastian Andrzej Siewior (Re: Bug#1070667: libssl3: Cannot remove system package:)
On 2024-05-09 15:14:54 [+0300], Odysseas Romanos wrote: > Dear Sebastian Hi, > Thank you very much for your support. I will try manually as you > suggested. Do you need me to keep you updated or leave it as it is? You can let me know how it went but the bug report closed and does not require further updates. > Odysseus > Στάλθηκε από το iPhone μου Sebastian
Bug#1070667: libssl3: Cannot remove system package:
On 2024-05-07 12:20:51 [+0300], Odysseas Romanos wrote: > Old Trixie —> new trixie. Bug 1065135 seems unrelated to me. I am noob > to this so I apologize if I am not clear on my reporting That is okay. Just make sure you don't lose the Cc: so we have a public record. Now. We did (still do) have a time64_t transition which is where your problem originates. I need to check if this problem exists in upgrades from Bookworm to Trixie. If it does, we might need to add breaks+replaces to help apt/ dpkg figure out what to do. Otherwise it is transitional issue and probably not much to worry about. Are you still in a situation where you can't upgrade? > Odysseus > Στάλθηκε από το iPhone μου Sebastian
Bug#1070667: libssl3: Cannot remove system package:
+ Steve Langasek, Benjamin Drung On 2024-05-07 00:02:11 [+0300], Odysseas Romanos wrote: > Package: libssl3 > Version: 3.1.5-1 > Severity: important > X-Debbugs-Cc: oromanos2...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >I was trying to update the system via Discover >The outcome of the failed update was this message > WARNING: You are trying to remove the following essential packages: > libssl3 (due to coreutils) libapt-pkg6.0 (due to apt) libgnutls30 (due to > apt) libext2fs2 (due to e2fsprogs) >the outcome i expected was an up;dated system Is this bookworm -> trixie or old trixie -> new trixie? Not sure if this is related to #1065135 but it is transition related. Sebastian
Bug#1069825: [Pkg-clamav-devel] Bug#1069825: clamav-daemon stops working with LibClamAV Error: cl_engine_addref: engine == NULL
On 2024-04-25 13:38:51 [+0200], Michael Braun wrote: > Hi, Hi, > I'm scanning incoming mails using clamav-daemon and clamav-milter. > From time to time, my mailserver stops working due to clamav-daemon locking > up. > > The clamav logs read: > >6889 Apr 25 11:28:12 gate clamd[939931]: Thu Apr 25 11:28:11 2024 -> > !accept() failed: Too many open files > 1 Apr 25 11:32:11 gate systemd-journald[311]: Suppressed 490085 > messages from clamav-daemon.service > > (with many repetitions) > > 1 Apr 25 11:33:41 gate clamd[939931]: LibClamAV Error: > cl_engine_addref: engine == NULL > 1 Apr 25 11:33:41 gate clamd[939931]: Thu Apr 25 11:33:41 2024 -> > !cl_engine_addref() failed > 1 Apr 25 11:33:41 gate clamd[939931]: Thu Apr 25 11:33:41 2024 -> > !Command dispatch failed > > (with many repetitions) > > Workaround: systemctl restart clamav-daemon fixes the problem temporarely. My guess is that _something_ within clamd forgets to close a fd and then you hit the limit followed by the fallout later on. 0.103.10 isn't the latest version, it is 0.103.11 but judging from the changelog there isn't anything that changed. Now. You could look at /proc/$CLAMD_PID/fd/ and check what kind of fd is raising. I have here 10 fds in total, your limit should be at 1024 so you have an idea how danlging fd you should. That 10 depends on your setup in terms of IP listeners and/ or IP. On average it should remain constant except if it creates temporary files during scans or opens sockets for clients. The files are visible in /proc, sockets have just an inode number but `ss' will show you more details here. Once you identified those then I could start looking closer in the source once I know where to look. The other alternative you have is to update to Bookworm hoping that bug is gone. Sebastian
Bug#1069603: [Pkg-openssl-devel] Bug#1069603: Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert
On 2024-04-21 19:30:21 [+0200], Paul Gevers wrote: > Hi Hi, > > Could britney be hinted to migrate both at the same time? This should > > solve the issue you pointed out. > > There is no "please test together" knob if that's what you mean (is that > what you mean?). Yes, it is/ was. > I have triggered the test manually, so for now the lights > are green. Because those expire, I have added a hint to ignore the failure > of the old version in testing. Okay, thank you. In general I would poke the release team once I would expect it to migrate but didn't. But give the current events, I just waited until something happens. > Paul Sebastian
Bug#1069603: [Pkg-openssl-devel] Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert
On 2024-04-21 13:42:03 [+0200], Paul Gevers wrote: > opensslfrom testing3.2.1-3 > libcrypt-smime-perlfrom testing0.28-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of openssl to testing > [1]. Due to the nature of this issue, I filed this bug report against both > packages. Can you please investigate the situation and reassign the bug to > the right package? The problem is that libcrypt-smime-perl < 0.29 fails with openssl >= 3.2.0. This was solved by the Perl team with their 0.29 upload. This and 0.30 didn't migrate to testing and in the meantime we got OpenSSL into unstable which relies on that fix. The migration was delayed by the time_t transition. Could britney be hinted to migrate both at the same time? This should solve the issue you pointed out. Sebastian
Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1
On 2024-04-07 23:46:28 [+0200], To Adam D. Barratt wrote: > On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote: > > > > Sorry for not getting to this sooner. Is this still the case? > > So. This happened #1068045 (yapet broke with 1.0 format) due to the > update. On the bright side it has been broken in unstable but unnoticed. > Looking into it but also sleeping (but making progress). yapet is fixed in unstable. My understanding is that the maintainer will take care of it. I've been looking at the release.d.o page and there are deb-ci failures for nodejs. Those should be gone with nodejs/18.19.0+dfsg-6~deb12u1 which is in d-security. So based on this I would say all good ;) > > Regards, > > > > Adam Sebastian
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
control: tags -1 patch
control: reassign -1 yapet 2.6-1
On 2024-04-08 08:32:58 [+0200], Kurt Roeckx wrote:
> There might be a related change that doesn't allow restarting the
> operation with the same context without setting things up again.
Yapet is broken and the openssl update revealed the problem. I
reassigned it to yapet 2.6 but probably affects earlier versions.
But then the 1.1.1 series is no longer maintained so…
Patches attached and they hold the details of why and such.
This needs to be applied to unstable and Bookworm.
The testsuite passes and I can open Sean's test file.
Further testing is welcome by actual users ;)
I can NMU if needed just yell.
Sebastian
From a54b5e81a61aa7e77e45a970ce88b9b4269fde7d Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Mon, 8 Apr 2024 18:03:30 +0200
Subject: [PATCH 1/2] crypt/blowfish: Remove EVP_CIPHER_CTX_set_key_length().
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
yapet did for blowfish:
| EVP_CipherInit_ex(ctx, cipher, NULL, KEY, iv, mode);
| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
| EVP_CipherUpdate(ctx, …);
this worked in earlier OpenSSL versions and stopped working in
openssl-3.0.13. The problem here is that the
EVP_CIPHER_CTX_set_key_length() is ignored and the later OpenSSL version
returns rightfully an error "Provider routines::no key set" here.
Blowfish does support variable key lenghts but the key length has to be
set first followed by the actual key. Otherwise the blocksize (16) will
be used.
The correct way to deal with this would be:
| EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, mode);
| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
| EVP_CipherInit_ex(ctx, NULL, NULL, KEY, IV, mode);
| EVP_CipherUpdate(ctx, …);
Using now the proper way will break earlier databases because in the
blowfish case, always the default blocksize / 16 has been used.
In order to keep compatibility with earlier versions of the database and
openssl remove the EVP_CIPHER_CTX_set_key_length() invocation.
Fixes #26
Fixes #24
Signed-off-by: Sebastian Andrzej Siewior
---
src/libs/crypt/crypto.cc | 10 --
1 file changed, 10 deletions(-)
diff --git a/src/libs/crypt/crypto.cc b/src/libs/crypt/crypto.cc
index ade991edf961a..139e0823e753a 100644
--- a/src/libs/crypt/crypto.cc
+++ b/src/libs/crypt/crypto.cc
@@ -98,16 +98,6 @@ EVP_CIPHER_CTX* Crypto::initializeOrThrow(MODE mode) {
throw CipherError{_("Error initializing cipher")};
}
-success = EVP_CIPHER_CTX_set_key_length(context, _key->keySize());
-if (success != SSL_SUCCESS) {
-destroyContext(context);
-char msg[YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE];
-std::snprintf(msg, YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE,
- _("Cannot set key length on context to %d"),
- _key->keySize());
-throw CipherError{msg};
-}
-
return context;
}
--
2.43.0
>From aaa573b14bafcc9a6b46495bd4ffc15b90d35902 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Mon, 8 Apr 2024 18:19:12 +0200
Subject: [PATCH 2/2] crypt/aes: Remove EVP_CIPHER_CTX_set_key_length().
The EVP_CIPHER_CTX_set_key_length() in the AES-256-CBC case is pointless
because the key here is fixed EVP_CIPHER_CTX_set_key_length() and the
function does not change the size.
Remove the EVP_CIPHER_CTX_set_key_length() invocation.
Signed-off-by: Sebastian Andrzej Siewior
---
src/libs/crypt/aes256.cc | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/libs/crypt/aes256.cc b/src/libs/crypt/aes256.cc
index 1041b9c57347c..e105b1a5beddd 100644
--- a/src/libs/crypt/aes256.cc
+++ b/src/libs/crypt/aes256.cc
@@ -113,17 +113,6 @@ EVP_CIPHER_CTX* Aes256::initializeOrThrow(const SecureArray& ivec, MODE mode) {
throw CipherError{_("Error initializing cipher")};
}
-success = EVP_CIPHER_CTX_set_key_length(context, getKey()->keySize());
-if (success != SSL_SUCCESS) {
-LOG_MESSAGE(std::string{__func__} + ": Error setting key length");
-destroyContext(context);
-char msg[YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE];
-std::snprintf(msg, YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE,
- _("Cannot set key length on context to %d"),
- getKey()->keySize());
-throw CipherError{msg};
-}
-
return context;
}
--
2.43.0
Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1
On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote: > > Sorry for not getting to this sooner. Is this still the case? So. This happened #1068045 (yapet broke with 1.0 format) due to the update. On the bright side it has been broken in unstable but unnoticed. Looking into it but also sleeping (but making progress). > Regards, > > Adam Sebastian
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
On 2024-04-07 15:36:37 [+0800], Sean Whitton wrote:
> Hello,
Hi,
> On Sat 06 Apr 2024 at 03:24pm +02, Salvatore Bonaccorso wrote:
>
> > As it is a regression caused by libssl3 3.0.11 based to 3.0.13, why is
> > it reassigned to yapet? (the regression is as well present in
> > unstable).
>
> I was just thinking that it may be a flaw in how YAPET calls into
> openssl, and we don't have evidence either way atm.
The failure is due to openssl upstream commit
3a95d1e41abf ("update/final: Return error if key is not set")
and openssl complains with "error:1C800072:Provider routines::no key
set". I need to figure out if openssl forgot to account that a key has
been set or if something is wrong with the key.
Sebastian
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
On 2024-04-06 17:17:45 [+0800], Sean Whitton wrote: > Hello, Hi, > It looks like the problem is opening YAPET1.0-format databases, which > the manpage explicitly says is meant to work. > > I've made a sample YAPET1.0 database using a stretch VM. Using the > attached: > > - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it. > - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't. Thank you for the testcase. It asks for a password, what is it? Sebastian
Bug#1068348: xz-utils: Should activate trigger to force regenerating initramfs
On 2024-04-04 00:14:27 [+0200], Guillem Jover wrote: > Hi! Hi, > I initially was thinking that a conditionally triggered activation > when upgrading from the affected versions would be sufficient, but if > people have already upgraded, then that will still leave them with the > malicious stuff in their initramfs. Do you think about a one-time trigger to ensure the 5.6 release is gone or to keep it? I can't tell what happend exactly but the 5.6 release is gone from my _current_ initramfs so something triggered it already. Only the older "previous" kernel has it. > Thanks, > Guillem Sebastian
Bug#1065135: [Pkg-openssl-devel] Bug#1065135: sort: error while loading shared libraries: libcrypto.so.3
On 2024-02-29 20:37:25 [-0800], Steve Langasek wrote: > This is definitely not the behavior we want. However, the good thing is > that the dependency from coreutils to libssl is new since bookworm. As a > result, while this can affect users on upgrades from testing, it will not > affect upgrades from bookworm because libssl3t64 will be unpacked and > configured before the coreutils that uses it. Can I close this or there something that needs to be done here? Or do we wait until it gets migrated to testing? I *think* we could limit some of the dependencies since `sort' most likely needs nothing from libcrypto… But there were other reported (such as libreadline) so I'm not sure. Sebastian
Bug#1068024: revert to version that does not contain changes by bad actor
On 2024-04-02 14:34:20 [+0200], Guillem Jover wrote: > (Please do not take this mail as endorsing any specific action, just > wanted to clarify/correct the above.) Right, same here. The 5.4.x series has threaded decompression which I would like to keep. The 5.6.x series has branchless decompressor which improves decompressing performance. The 5.3.x series is alpha and should not be used in production but only for testing. I'm not sure what happens with the XZ_5.3..alpha symbols, I hope they get ignored. I'm going to poke upstream if there is an audit and or future plans. But I want to stay on an official upstream release which is also used by other distros. > Thanks, > Guillem Sebastian
Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded
On 2024-04-03 19:16:25 [+0200], Carsten Schoenert wrote: > I did a few more working on some of the packages I maintain and I did not > encounter similar problems with wrong hash ids like a few days back. Given > the troubled times around the liblzma versions I'm not sure the initial > issue about the report topic years back is still solved as we are back to a > version before 5.6.0 again. 5.6.0+ did -T0 by default while the current 5.4.x series does -T1 by default. You could set the enviroment variable XZ_DEFAULTS=-T0 to get the same defaults since (based on my understanding) gbp relies on xz's defaults. I recommend to use multiple threads for compression/ decompression for the speed boost. > My typical "problematic" packages are thunderbird and especially > kicad-packages3d, I wasn't needed to package a newer version of any of these > source packages lately. Sebastian
Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2
On 2024-03-31 19:42:24 [+], tony mancill wrote: > Given what has unfolded over the past few days regarding xz-utils and > CVE-2024-3094 [0], should we revisit the patches applied here and for > #1063252? Are they still needed? Not with the fallback to pre 5.4.x series but *I* don't think this will remain forever. The requirement for the change was different default value for the -T parameter. Recording the -T parameter by default and relying on defaults is good. > Thank you, > tony Sebastian
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
On 30 March 2024 13:14:37 CET, Sean Whitton wrote: >Hello, Hi, >I downgraded, changed the password for my database to 'asdf', >changed it back to the password it had before, upgraded libssl3, >and the bug did not appear. > >I reverted to my original db, downgraded again, deleted an entry without >changing the password, upgraded, and the bug appeared. > >I can't really say more without compromising my opsec. But does the >above give any clues / further debugging ideas? I would look at the function yapet is using from openssl and compare the results. Could create a database from scratch an use similar patterns in terms number of entries and password (length, special characters) until you have something that you can share with me. I don't mind if throw it in my inbox without Cc: the bug. > >> Also, yapet is unchanged in unstable. Is the problem there, too? > >Unfortunately I do not have an unstable machine to hand right now, and >until we know more about the xz-utils situation I would want to set up >something air-gapped before copying my password db in there -- but can >do that if we can't otherwise make progress. The 5.6 xz is no more in unstable. But as you wish. I was just curious why this was not yet reported. > >Thanks for looking! > -- Sebastian
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
On 2024-03-30 09:25:27 [+0800], Sean Whitton wrote: > Package: libssl3 > Version: 3.0.13-1~deb12u1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: t...@security.debian.org > Control: affects -1 + yapet > > Dear maintainer, > > This version of libssl3 from bookworm-proposed-updates breaks YAPET. > When I try to open my passwords database, it claims the master password I type > is incorrect. But downgrading libssl3 fixes the problem. Can you give me more to go on? I installed yapet created a database, updated and it remains to work. Maybe supply a test database which works with the old but not with the new library. Also, yapet is unchanged in unstable. Is the problem there, too? Sebastian
Bug#1067708: new upstream versions as NMU vs. xz maintenance
On 26 March 2024 23:11:19 CET, Thorsten Glaser wrote: >Very much *not* a fan of NMUs doing large changes such as >new upstream versions. Most of the changes are part of current -2. Ppl complainted about valgrind reports which are addressed in the new upstream version. >But this does give us the question, what’s up with the >maintenance of xz-utils? I NMU maintained it for the last few years. Given that I consider taking over maintenance officially. I poked Jonathan about this. >Same as with the lack of security >uploads of git, which you also maintain, are you active? >Are you well? > >bye, >//mirabilos -- Sebastian
Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1
On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote: > On Mon, 2024-03-04 at 07:38 +0100, Sebastian Andrzej Siewior wrote: > > This is an update to the current stable OpenSSL release in the 3.0.x > > series. It addresses the following CVE reports which were postponed > > due to low severity: > [...] > > I'm not aware of a problems/ regression at this point. > > Sorry for not getting to this sooner. Is this still the case? Yes. > Regards, > > Adam Sebastian
Bug#1067636: nodejs: Testsuite fails with openssl 3.2
Package: nodejs Version: 18.19.1+dfsg-6 Severity: important Tags: sid control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.2 Hi, I rebuilt nodejs in unstable against openssl 3.2 in experimental an a few tests failed: | Failed tests: | ./node /<>/test/parallel/test-crypto-rsa-dsa.js | ./node /<>/test/parallel/test-tls-alert-handling.js | ./node /<>/test/parallel/test-tls-client-auth.js | ./node /<>/test/parallel/test-tls-empty-sni-context.js | ./node --expose-internals /<>/test/parallel/test-tls-enable-trace.js | ./node --expose-internals /<>/test/parallel/test-tls-enable-trace-cli.js | ./node /<>/test/parallel/test-tls-getcipher.js | ./node /<>/test/parallel/test-tls-junk-server.js | ./node /<>/test/parallel/test-tls-psk-circuit.js | ./node /<>/test/parallel/test-tls-set-ciphers.js | ./node /<>/test/parallel/test-tls-junk-closes-server.js Any idea how to proceed? I've been reading https://github.com/nodejs/node/issues/51152 but I don't think 3.2 support has been integrated somewhere as they just discussed their fork part and so on. I've been looking at the errors and some are "error code changed". I *think* the trace errors changed also slightly. I don't know why get/set-ciphers failed. Sebastian
Bug#1067572: rust-parsec-tool
Package: rust-parsec-tool
Version: 0.7.0-3
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2
The testsuite fails with openssl 3.2. Please find attached upstream
commit 8948077e106a0 ("parsec-cli-tests.sh: adapt to new serialNumber
output") which fixes the issue.
Sebastian
From: Mikko Rapeli
Date: Wed, 3 Jan 2024 12:30:38 +
Subject: [PATCH] parsec-cli-tests.sh: adapt to new serialNumber output
openssl 3.2.0 from yocto prints serialNumber to output
without spaces so support both that and the old with
spaces output to pass the test. Not using regular
expressions to work on simpler grep implementations.
Signed-off-by: Mikko Rapeli
---
tests/parsec-cli-tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/parsec-cli-tests.sh b/tests/parsec-cli-tests.sh
index 91ec321ca0598..3fbb961ec2400 100755
--- a/tests/parsec-cli-tests.sh
+++ b/tests/parsec-cli-tests.sh
@@ -231,7 +231,7 @@ test_csr() {
run_cmd $OPENSSL req -text -noout -verify -in ${MY_TMP}/${KEY}.csr >${MY_TMP}/${KEY}.txt
debug cat ${MY_TMP}/${KEY}.txt
-if ! cat ${MY_TMP}/${KEY}.txt | grep "Subject:" | grep "serialNumber = ${TEST_SERIAL}"; then
+if ! cat ${MY_TMP}/${KEY}.txt | grep "Subject:" | grep -e "serialNumber = ${TEST_SERIAL}" -e "serialNumber=${TEST_SERIAL}"; then
echo "Error: The CSR does not contain the serialNumber field of the Distinguished Name"
EXIT_CODE=$(($EXIT_CODE+1))
fi
--
2.43.0
Bug#1066576: nagios-plugins-contrib: FTBFS: check_memcached.l:339:37: error: implicit declaration of function ‘asprintf’; did you mean ‘vsprintf’? [-Werror=implicit-function-declaration]
control -1 tags patch
the patch attached fixes the warnings in check_memcached.l.
Sebastian
>From 155e35ace12f41bbaa42e4ea19bfea6de416bd95 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Fri, 22 Mar 2024 19:48:09 +0100
Subject: [PATCH] Compile warnings.
Address various compile warnings in check_memcached.
Signed-off-by: Sebastian Andrzej Siewior
---
check_memcached/check_memcached.l | 14 +++---
common.mk |2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
--- a/check_memcached/check_memcached.l
+++ b/check_memcached/check_memcached.l
@@ -152,7 +152,7 @@ cmd_set= { save_to = &obj_cmd_set; }
%%
/* */
-yywrap() {
+int yywrap(void) {
return 1;
}
@@ -343,7 +343,7 @@ int check_memcached() {
}
if ( nagios_service_output == NULL ) {
- str_bytes = asprintf(&nagios_service_output,"");
+ str_bytes = asprintf(&nagios_service_output," ");
}
/* - */
/* Analyze the stats, return 0,1,2 as required */
@@ -351,7 +351,7 @@ int check_memcached() {
if ( obj_time == 0 ) {
nagios_service_tmp = nagios_service_output;
str_bytes = asprintf(&nagios_service_output,
-"%sno stats available yet. Come back in %d minutes; ",
+"%sno stats available yet. Come back in %" PRIu64 " minutes; ",
nagios_service_tmp,
min_stats_interval - (stats.time - obj_time_oldest ) / 60
);
@@ -362,7 +362,7 @@ int check_memcached() {
nagios_result|=1;
nagios_service_tmp = nagios_service_output;
str_bytes = asprintf(&nagios_service_output,
- "%sToo many evictions: %d; ",
+ "%sToo many evictions: %llu; ",
nagios_service_tmp,
stats.evictions - obj_evictions
);
@@ -399,7 +399,7 @@ int check_memcached() {
nagios_service_tmp = nagios_service_output;
str_bytes = asprintf(&nagios_service_output,
- "%shits=%llu misses=%llu evictions=%llu interval=%lu mins",
+ "%shits=%llu misses=%llu evictions=%llu interval=%u mins",
nagios_service_tmp,
stats.get_hits - obj_get_hits,
stats.get_misses - obj_get_misses,
@@ -453,7 +453,7 @@ int check_memcached() {
nagios_perfdata = "";
} else {
str_bytes = asprintf(&nagios_perfdata,
- "%s delta_time=%lu delta_cmd_get=%llu delta_cmd_set=%llu delta_get_hits=%llu delta_get_misses=%llu delta_evictions=%llu",
+ "%s delta_time=%u delta_cmd_get=%llu delta_cmd_set=%llu delta_get_hits=%llu delta_get_misses=%llu delta_evictions=%llu",
current_stats_str,
(uint32_t) ( stats.time - obj_time ),
stats.cmd_get - obj_cmd_get,
@@ -600,7 +600,7 @@ void usage() {
printf("\t-n ... Keep up to this many items in the history object in memcached (default: %u)\n",max_n_stats);
printf("\t-T ... Minimum time interval (in minutes) to use to analyse stats. (default: %u)\n",min_stats_interval);
printf("\t-w ... Generate warning if quotient of hits/misses falls below this value (default: %1.1f)\n",min_hit_miss);
- printf("\t-E ... Generate warning if number of evictions exceeds this threshold. 0=disable. (default: %llu)\n",max_evictions);
+ printf("\t-E ... Generate warning if number of evictions exceeds this threshold. 0=disable. (default: %" PRIu64 ")\n",max_evictions);
printf("\t-t ... timeout in seconds (default: %1.1f)\n",timeout);
printf("\t-k ... key name for history object (default: %s)\n",memcached_key);
printf("\t-K ... expiry time in seconds for history object (default: %u)\n",memcache_stats_object_expiry_time);
--- a/common.mk
+++ b/common.mk
@@ -1,6 +1,6 @@
# import buildflags
-CFLAGS += $(shell dpkg-buildflags --get CFLAGS)
+CFLAGS += $(shell dpkg-buildflags --get CFLAGS) -D_GNU_SOURCE
CPPFLAGS += $(shell dpkg-buildflags --get CPPFLAGS)
CXXFLAGS += $(shell dpkg-buildflags --get CXXFLAGS)
LDFLAGS += $(shell dpkg-buildflags --get LDFLAGS)
Bug#1067532: nagios-plugins-contrib: Testsuite fails with openssl 3.2
Package: nagios-plugins-contrib
Version: 45.20231212
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2
The package fails the debci testsuite with OpenSSL 3.2 due to output on
stderr. The patch attached is a backport from upstream which avoids
output on stderr.
Sebastian
From: Matteo Corti
Date: Fri, 24 Nov 2023 13:20:59 +0100
Subject: [PATCH] First fix for the STDIN warning on OpenSSL 3.2.0
Applied-Upstream: https://github.com/matteocorti/check_ssl_cert/commit/2c2795860adc165c35f5948116261cb76a94c954
---
check_ssl_cert/check_ssl_cert_2.75.0/check_ssl_cert | 72 ++--
1 file changed, 36 insertions(+), 36 deletions(-)
--- a/check_ssl_cert/check_ssl_cert_2.75.0/check_ssl_cert
+++ b/check_ssl_cert/check_ssl_cert_2.75.0/check_ssl_cert
@@ -1557,8 +1557,8 @@ extract_cert_attribute() {
# shellcheck disable=SC2086,SC2016
case $1 in
cn)
-if echo "${cert_content}" | "${OPENSSL}" x509 -noout ${OPENSSL_PARAMS} -subject 2>/dev/null | "${GREP_BIN}" -F -q 'CN' >/dev/null; then
-echo "${cert_content}" | "${OPENSSL}" x509 -noout ${OPENSSL_PARAMS} -subject |
+if echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout ${OPENSSL_PARAMS} -subject 2>/dev/null | "${GREP_BIN}" -F -q 'CN' >/dev/null; then
+echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout ${OPENSSL_PARAMS} -subject |
sed -e "s/^.*[[:space:]]*CN[[:space:]]=[[:space:]]//" -e 's/\/[[:alpha:]][[:alpha:]]*=.*$//' -e "s/,.*//"
else
echo 'CN unavailable'
@@ -1567,76 +1567,76 @@ extract_cert_attribute() {
;;
subject)
# the Subject could contain UTF-8 characters
-echo "${cert_content}" | "${OPENSSL}" x509 -noout ${OPENSSL_PARAMS} -subject -nameopt utf8
+echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout ${OPENSSL_PARAMS} -subject -nameopt utf8
;;
serial)
-echo "${cert_content}" | "${OPENSSL}" x509 -noout -serial | sed -e "s/^serial=//"
+echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout -serial | sed -e "s/^serial=//"
;;
fingerprint)
-echo "${cert_content}" | "${OPENSSL}" x509 -noout -fingerprint -sha1 | sed -e "s/^SHA1 Fingerprint=//"
+echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout -fingerprint -sha1 | sed -e "s/^SHA1 Fingerprint=//"
;;
oscp_uri)
-echo "${cert_content}" | "${OPENSSL}" "${OPENSSL_COMMAND}" -noout ${OPENSSL_PARAMS} -ocsp_uri
+echo "${cert_content}" | "${OPENSSL}" "${OPENSSL_COMMAND}" -in /dev/stdin -noout ${OPENSSL_PARAMS} -ocsp_uri
;;
oscp_uri_single)
extract_cert_attribute 'oscp_uri' "${cert_content}" | head -n 1
;;
hash)
-echo "${cert_content}" | "${OPENSSL}" x509 -noout -hash
+echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout -hash
;;
modulus)
-echo "${cert_content}" | "${OPENSSL}" x509 -noout -modulus
+echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout -modulus
;;
issuer)
# see https://unix.stackexchange.com/questions/676776/parse-comma-separated-string-ignoring-commas-between-quotes
-echo "${cert_content}" | "${OPENSSL}" "${OPENSSL_COMMAND}" -noout -nameopt sep_multiline,utf8,esc_ctrl -issuer |
+echo "${cert_content}" | "${OPENSSL}" "${OPENSSL_COMMAND}" -in /dev/stdin -noout -nameopt sep_multiline,utf8,esc_ctrl -issuer |
tail -n +2 |
sed 's/^ *//'
;;
issuer_uri)
-echo "${cert_content}" | "${OPENSSL}" "${OPENSSL_COMMAND}" -noout ${OPENSSL_PARAMS} -text | "${GREP_BIN}" -F "CA Issuers" | "${GREP_BIN}" -F -i "http" | sed -e "s/^.*CA Issuers - URI://" | tr -d '"!|;${}<>`&'
+echo "${cert_content}" | "${OPENSSL}" "${OPENSSL_COMMAND}" -in /dev/stdin -noout ${OPENSSL_PARAMS} -text | "${GREP_BIN}" -F "CA Issuers" | "${GREP_BIN}" -F -i "http" | sed -e "s/^.*CA Issuers - URI://" | tr -d '"!|;${}<>`&'
;;
issuer_uri_single)
extract_cert_attribute 'issuer_uri' "${cert_content}" | head -n 1
;;
issuer_hash)
-echo "${cert_content}" | "${OPENSSL}" x509 -noout -issuer_hash
+echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -noout -issuer_hash
;;
org)
-cert_subject=$(echo "${cert_content}" | "${OPENSSL}" x509 -nameopt utf8 -noout -subject)
+cert_subject=$(echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -nameopt utf8 -noout -subject)
parse_subject "O" "${cert_subject}"
;;
org_unit)
-cert_subject=$(echo "${cert_content}" | "${OPENSSL}" x509 -nameopt utf8 -noout -subject)
+cert_subject=$(echo "${cert_content}" | "${OPENSSL}" x509 -in /dev/stdin -nameopt utf8 -noout -subject)
parse_subject "OU" "${cert_subject}"
;;
ke
Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded
On 2019-03-08 22:10:10 [+0100], Carsten Schoenert wrote: > Hello Guido, Hi, > On Tue, Jan 30, 2018 at 07:19:48AM +0100, Carsten Schoenert wrote: > > > We should not do more options. Multi threaded should be on when: > > > > > > - not using pristine-tar > > > - iff pristine-tar can handle it > > > > > > The first one is simple but what about the second? > > the mentioned issue #888572 was closed some time ago so pristine-tar > shouldn't be a problem here anymore. > > I will try to tweak gbp locally now again while working on a new version > of kicad-packages3d which will be about 5GB now to archive. ;) I got pointed here by Amin. As mentioned, pristine-tar can handle multi-block xz images so this is not an issue. Further xz-utils v5.6.0+ (currently in unstable/ testing) is using multi threaded compression by default. So this *might* be considered fixed. > Regards > Carsten Sebastian
Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2
On 2024-03-12 09:26:32 [-0400], Jeremy Bícha wrote: > > Could someone check this, please? > > Did you try running autopkgtests on this version? The autopkgtests fail for > me. autopkgtests were the first thing that pointed me here and they passed. If you say they fail for you then I may have used the wrong xz version… > I assume that the largest use of pristine-tar in Debian is with > git-buildpackage. The 1.50+nmu1 upload **caused** pristine-tar to > break in many cases for me. If I revert back to 1.50, I no longer get > mismatched tarballs errors. Here are some test cases to demonstrate: > > Test Case 1 > == > gbp clone --add-upstream-vcs https://salsa.debian.org/jbicha/pangomm2.48 > > cd pangomm2.48 > > gbp import-orig --uscan > > gbp buildpackage > > What happens > -- > The exact hashes will probably vary but I get an error like this: > > gbp:error: Pristine-tar couldn't verify > "pangomm2.48_2.50.2.orig.tar.xz": pristine-tar: > /home/jeremy/build-area/pangomm2.48_2.50.2.orig.tar.xz does not match > stored hash (expected > e99b6a9c89e9c284bf44f5ae8125c06515d6ab8f8577d75d2887726dacb5a372, got > 826ad52f53ac8e15c9ceba4dc6e616efddae5e089f36bf4e60081c177d80d4b6) | (sid)bigeasy@debbuildd:~/pristine$ gbp clone --add-upstream-vcs https://salsa.debian.org/jbicha/pangomm2.48 | gbp:info: Cloning from 'https://salsa.debian.org/jbicha/pangomm2.48' | gbp:info: Adding upstream vcs at https://gitlab.gnome.org/GNOME/pangomm.git as additional remote | (sid)bigeasy@debbuildd:~/pristine$ cd pangomm2.48 | (sid)bigeasy@debbuildd:~/pristine/pangomm2.48$ gbp import-orig --uscan | gbp:info: Launching uscan... | Newest version of pangomm2.48 on remote site is 2.50.2, local version is 2.50.1 | => Newer package available from: | => https://download.gnome.org/sources/pangomm/2.50/pangomm-2.50.2.tar.xz | Successfully repacked ../pangomm-2.50.2.tar.xz as ../pangomm2.48_2.50.2.orig.tar.xz, deleting 416 files from it. | gbp:info: Using uscan downloaded tarball ../pangomm2.48_2.50.2.orig.tar.xz | What is the upstream version? [2.50.2] | gbp:info: Importing '../pangomm2.48_2.50.2.orig.tar.xz' to branch 'upstream/latest'... | gbp:info: Source package is pangomm2.48 | gbp:info: Upstream version is 2.50.2 | gbp:info: Replacing upstream source on 'debian/latest' | gbp:info: Running Postimport hook | dch warning: neither DEBEMAIL nor EMAIL environment variable is set | dch warning: building email address from username and FQDN | dch: Did you see those 2 warnings? Press RETURN to continue... | | git commit -m 'New upstream release' | [debian/latest f5c4f6d14a78] New upstream release | 1 file changed, 5 insertions(+), 2 deletions(-) | gbp:info: Successfully imported version 2.50.2 of ../pangomm2.48_2.50.2.orig.tar.xz passed. > Other info > - > pangomm2.48 uses Files-Excluded in debian/copyright so uscan will > rebuild a tarball and its hash will vary depending on the time it was > created. (Perhaps the hash should be reproducible but that's not > relevant to this bug.) > > Test Case 2 > = > gbp clone https://salsa.debian.org/gnome-team/gtk4 > cd gtk4 > gbp buildpackage > > What happens > > gbp:error: Pristine-tar couldn't verify "gtk4_4.12.5+ds.orig.tar.xz": > pristine-tar: > /home/jeremy/devel/pkg-gnome/temp/build-area/gtk4_4.12.5+ds.orig.tar.xz > does not match stored hash (expected > 3338a691d774ae031af65299e9a1c6207f543f13b256539717a1970f752358cb, got > 70ac33e0f37dc1b657d6560f1b8a40b3f4b67e956936633ced495d8b880d3fb0) | (sid)bigeasy@debbuildd:~/pristine$ gbp clone https://salsa.debian.org/gnome-team/gtk4 | gbp:info: Cloning from 'https://salsa.debian.org/gnome-team/gtk4' | (sid)bigeasy@debbuildd:~/pristine$ cd gtk4 | (sid)bigeasy@debbuildd:~/pristine/gtk4$ gbp buildpackage | gbp:info: Creating /home/bigeasy/pristine/gtk4_4.12.5+ds.orig.tar.xz | gbp:info: Performing the build | dpkg-buildpackage -us -uc -ui -i -I | dpkg-buildpackage: info: source package gtk4 | dpkg-buildpackage: info: source version 4.12.5+ds-4 passed. > Other info > > This pristine-tar tarball was committed January 19 so it did not use > either the new xz-utils or pristine-tar. > > Test Case 3 > = > gbp clone https://salsa.debian.org/gnome-team/pango > cd pango > gbp buildpackage > > What happens > --- > gbp:error: Pristine-tar couldn't verify > "pango1.0_1.52.1+ds.orig.tar.xz": pristine-tar: > /home/jeremy/devel/pkg-gnome/temp/build-area/pango1.0_1.52.1+ds.orig.tar.xz > does not match stored hash (expected > 12d67d8182cbb2ae427406df9bab5ce2ff5619102bf2a0fc6331d80a9914b139, got > a641d29d2d7df7843e44762a0733987dc8220d238b697b382dd96fafe5fc890a) | (sid)bigeasy@debbuildd:~/pristine$ gbp clone https://salsa.debian.org/gnome-team/pango | gbp:info: Cloning from 'https://salsa.debian.org/gnome-team/pango' | (sid)bigeasy@debbuildd:~/pri
Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2
On 2024-03-11 21:23:03 [+], Amin Bandali wrote: > Hi, Hi, > On Mon, Mar 11, 2024 at 05:55:31PM +0100, Sebastian Andrzej Siewior wrote: > > On 2024-03-11 00:05:54 [+], Amin Bandali wrote: > > > Hi Sebastian, all, > > Hi, > > > > > Will this fix be enough for addressing all cases, though? > > > > I think so. Do you have a test case for me to check? > > Not about pristine-xz specifically; I meant more in the context of > other devel tools like gbp et al. ah okay. pristine-tar was the only tool that had CI failures during the upload of new xz-utils to exp. I wouldn't know other tools that require to recreate the same binary file. > > Who is handling the compression in the first place here? > > In the case of "gbp import-orig --uscan", gbp invokes uscan, part of > the devscripts package which has several perl modules including > Devscripts::Compression which is a sort of a wrapper around dpkg's > Dpkg::Compression, which will ultimately run the 'xz' executable. > > In some other cases like "gbp import-orig --filter" mentioned by > Andrey, gbp does the compression itself. Which is why I suggested > that 'Opts' in gbp.pkg.compressor may need to be updated to add '-T1' > for calls to 'xz'. okay. I wouldn't recomment doing -T1. This forces xz doing a single block and using a signle thread. The default (without passing the -T argument) will allow xz to use multiple threads and compress into multiple blocks which in turn can be decompressed using multiple threads. Forcing -T1 will force single threaded compression and decompression. pristine-tar can handle both cases. > > The idea is to pass -T1 to xz if nothing was recorded in pristine-tar's > > delta information. If the -T argument then everything keeps working > > as-is. If you use gbp to repack the tar archive then I would recommend > > to no pass -T1 and to use multi-threaded compression. pristine-tar > > will recongnise this and record this information. > > Sorry I don't think I fully understood this bit. Could you please > explain again, perhaps a bit more verbosely? If you do "pristine-tar gendelta" then pristine tar creates a .delta file which is tar.gz file containing a few files including the actual delta from `xdelta' and a file called `wrapper'. The `wrapper' file is also a tar.gz file including files regarding the invocation of the compressing tool which includes the arguments required to produce the exact output of the resulting .xz (from the tar input). Prior 1.50+nmu1 pristine-tar didn't record here the -T argument unless multi-threaded compression was used and pristine-tar used -Tcpus and recorded this. Since 1.50+nmu1 I made pristine-tar to always record the -T argument in the wrapper file, either -Tcpus in the multi threaded case as it did or by using -T1 in the single threaded one block case. That means the reproduce case has always the fitting -T argument. If you get an older archive which lacks the -T argument, pristine-tar will assume -T1 which was the old default. > To clarify, the use-cases described earlier involving gbp and > devscripts aren't necessarily related to pristine-xz, used for > regenerating pristine xz files; rather, about the generation or > repacking of xz files *before* they are handed to pristine-xz for > processing and storage in the repo. I was trying to imply that > similarly to how you sent patches for pristine-tar to adapt it for > changes in xz-utils, that similar patches are probably also needed > for gbp and devscripts. Does that make sense? So gbp and descripts should be able to deal with xz as-is since they don't have any expectation in the resulting binary file. They are happy once the input compressed/ decompressed. pristine-tar is the only tool, to my best knowledge, that requires binary identical output. Therefore I would keep gbp and devscripts as-is and prefer the multi-threaded compression & decompression. dpkg uses multi-threaded compression since a while and decompression since Bookworm. > Thanks, > -amin Sebastian
Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Bug#1065424: Can't connect to Active Directory with openssl
On 2024-03-11 13:29:10 [+0100], Maciej Bogucki wrote: > Hi, Hi, > When I use stiati compiled openssl form different system I can have the > connection > > root@nsd-sdproxy1:~# /tmp/openssl version > OpenSSL 1.0.1t 3 May 2016 that is stone age. > root@nsd-sdproxy1:~# /tmp/openssl s_client -connect 192.168.92.95:636 > -CAfile /etc/ssl/certs/ca-certificates.crt What happens if you add -cipher DEFAULT:@SECLEVEL=0 > On teh remote side is Windows 2008 with Active Directory over SSL/TLS. My condolences. If you can, get rid of it. It will haunt you! > Pozdrawiam serdecznie > Maciej Bogucki Sebastian
Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2
On 2024-03-11 00:05:54 [+], Amin Bandali wrote: > Hi Sebastian, all, Hi, > Will this fix be enough for addressing all cases, though? I think so. Do you have a test case for me to check? > I'm thinking specifically of cases where tarball repacking > is involved, for example when using git-buildpackage's > "gbp import-orig --uscan" where uscan is used to download and > repack the upstream tarball, because the package at hand has > a Files-Excluded field in its debian/copyright header stanza. > As far as I can tell, Devscripts::Compression would need to be > updated to specify -T1 for xz compressions. > > I believe there are also some cases where git-buildpackage > itself does repacking, so we'd probably want to update its > gbp.pkg.compressor's Opts to pass in -T1 for xz. Who is handling the compression in the first place here? The idea is to pass -T1 to xz if nothing was recorded in pristine-tar's delta information. If the -T argument then everything keeps working as-is. If you use gbp to repack the tar archive then I would recommend to no pass -T1 and to use multi-threaded compression. pristine-tar will recongnise this and record this information. > Thanks, > -a Sebastian
Bug#1063252: Proposed fix broke pristine-tar for me
On 2024-03-10 00:12:46 [+0100], Andrea Pappacoda wrote: > Hi, thanks for your fix! Hi, > Unfortunately it seems that your patch has broke tarball generation for one > of the packages I maintain, dynarmic. > >$ gbp export-orig >gbp:info: Creating /home/tachi/dev/deb/dynarmic_6.5.0+ds.orig.tar.xz >gbp:error: Pristine-tar couldn't verify "dynarmic_6.5.0+ds.orig.tar.xz": > pristine-tar: /home/tachi/dev/deb/dynarmic/../dynarmic_6.5.0+ds.orig.tar.xz > does not match stored hash (expected > 46a18274c7d15c9bcc9eced74d050af412728ebf03083b76fb650b70acf8, got > 7b56e580ab2c12003490dc2e2708106f37d51ebe4588b377f7557d5f7db34a6b) > > I've been able to solve this issue locally by manually editing the `if > (!$threads_set)` check to push `-T2` instead of `-T1` if no `-T` option was > previously set, but I don't fully understand why this solves the issue. Could you check the fix in #1065751? > Wouldn't it be better to unconditionally pass `-T0` and depend on xz-utils > >= 5.3.0 so that the multi-threaded compressor is always used and the output > format is the same regardless of the machine used to generate the compressed > archive? I told pristine-tar to pass -T argument if none was found but forgot a check and this didn't work. The update should work. And the -T argument will be recorded conditionally from now on. You can't always pass -T0 because the orig tarball may have been created without threadding and this would break it. > Thanks again! Sebastian
Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2
Control: tags 1065751 + patch
Control: tags 1065751 + pending
Dear maintainer,
I've prepared an NMU for pristine-tar (versioned as 1.50+nmu2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Could someone check this, please?
Regards.
Sebastian
diff -Nru pristine-tar-1.50+nmu1/debian/changelog pristine-tar-1.50+nmu2/debian/changelog
--- pristine-tar-1.50+nmu1/debian/changelog 2024-02-25 12:18:32.0 +0100
+++ pristine-tar-1.50+nmu2/debian/changelog 2024-03-10 21:38:16.0 +0100
@@ -1,3 +1,11 @@
+pristine-tar (1.50+nmu2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Preoperly account -T parameter for xz. Thanks to Jia Tan for the hint.
+(Closes: #1065751).
+
+ -- Sebastian Andrzej Siewior Sun, 10 Mar 2024 21:38:16 +0100
+
pristine-tar (1.50+nmu1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pristine-tar-1.50+nmu1/pristine-xz pristine-tar-1.50+nmu2/pristine-xz
--- pristine-tar-1.50+nmu1/pristine-xz 2024-02-25 12:18:06.0 +0100
+++ pristine-tar-1.50+nmu2/pristine-xz 2024-03-10 21:38:12.0 +0100
@@ -416,11 +416,11 @@
next if $param eq '--check=crc64';
next if $param eq '--check=sha256';
next if $param =~ /^(--block-list=[0-9,]+)$/;
- next if $param =~ /^-T[0-9]+$/;
+
if ($param =~ /^-T[0-9]+$/) {
- $threads_set = 1;
- next;
- }
+ $threads_set = 1;
+ next;
+ }
} elsif ($delta->{program} eq 'pixz') {
next if $param eq '-t';
}
@@ -429,8 +429,10 @@
@params = split(' ', $delta->{params});
- if (!$threads_set) {
-push @params, '-T1';
+ if ($delta->{program} eq 'xz') {
+ if (!$threads_set) {
+push @params, '-T1';
+ }
}
doit($program, @params, $file);
Bug#1063621: bookworm-pu: package clamav/clamav_1.0.5+dfsg-1~deb12u1
On 2024-03-08 07:38:10 [+], Adam D. Barratt wrote: > On Fri, 2024-02-09 at 23:12 +0100, Sebastian Andrzej Siewior wrote: > > This is an update to the latest clamav release in the 1.0.x series. > > One small thing you may want to fix for any follow-up updates: > > +clamav (1.0.5+dfsg-1~deb12u1) bookworm; urgency=medium > + > + * Import 1.0.4 (Closes: #1063479). Indeed, thank you. > Regards, > > Adam Sebastian
Bug#1065529: interimap: Testsuite fails with openssl 3.2
On 2024-03-06 15:27:50 [+0100], Guilhem Moulin wrote: > Hi Sebastian, Hi, > Great to hear OpenSSL 3.2 will soon be entering sid! :-) > > On Wed, 06 Mar 2024 at 07:59:53 +0100, Sebastian Andrzej Siewior wrote: > > I'm currently puzzled where to look at. Could you please have a look? > > It seems openssl-req(1ssl) now generates X.509 version 3 certificates by > default. (A new flag `-509v1` was added to revert back to version 1.) > > interimap's test suite generates a transient CAs, but didn't pass any > X.509 v3 basic constraints as it assumed v1. The resulting “CA” was > therefore generated without CA:TRUE thereby failing peer validation. > > The fix is trivial, I'll simply change the test suite to generate a v3 > CA instead and pass CA:TRUE. But I thought it might be useful to spell > the fix out in case there are other affected packages. Thank for the explanation. > Cheers, Sebastian
Bug#1065529: interimap: Testsuite fails with openssl 3.2
Package: interimap Version: 0.5.7-2 Severity: important Tags: sid control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.2 interimap's testsuite fails with OpenSSL 3.2, which is currently in experimental, for the tests: SSL_CAfile/$SSL_CERT_FILE... FAILED TLS servername extension (SNI)... FAILED Full log at https://ci.debian.net/packages/i/interimap/unstable/amd64/43404948/ I'm currently puzzled where to look at. Could you please have a look? Sebastian
Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Acknowledgement (Can't connect to Active Directory with openssl)
On 2024-03-04 12:01:55 [+0100], Maciej Bogucki wrote: > I have just attached pcap file. the remote side rude. The client sent a "Client Hello". The remote side didn't like it and just closed the connection. Rude behaviour is rude. My guess is RSA+SHA1 is missing and is the only accepted signature_algorithms algorithm based on the successfull log. Sebastian
Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Can't connect to Active Directory with openssl
On 2024-03-04 11:16:14 [+0100], Maciej Bogucki wrote: > When I invoke `/usr/bin/openssl s_client -connect 192.168.92.95:636` So you get no reply? That is odd. There has to be reply. A "Connected" line is something I would have expected. If there is nothing then I would assume that the port is silently blocked. … > from latest rocky linux it is ok > > [bogucki@nsd-ansible ~]$ /usr/bin/openssl s_client -connect 192.168.92.95:636 > CONNECTED(0003) see, that line is missing. … > No client certificate CA names sent > Client Certificate Types: RSA sign, DSA sign, ECDSA sign > Requested Signature Algorithms: > RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1 > Shared Requested Signature Algorithms: > RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1 > Peer signing digest: SHA1 > Peer signature type: RSA The remote side looks limited. So from all the possibilities it decided to sign with RSA+SHA1. This is something openssl in bookworm rejects if I am not mistaken. But there has to be an error message about this. If *think* if you lower security level then it should work. Out of curiosity, what is the remote side running? Sebastian
Bug#1063621: bookworm-pu: package clamav/clamav_1.0.5+dfsg-1~deb12u1
On 2024-02-09 23:12:18 [+0100], To sub...@bugs.debian.org wrote: > Package: release.debian.org > Control: affects -1 + src:clamav > X-Debbugs-Cc: cla...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: pu > Tags: bookworm > Severity: normal > > This is an update to the latest clamav release in the 1.0.x series. This > update closes two CVEs: > > - CVE-2024-20290: Fixed a possible heap overflow read bug in the OLE2 file > parser that could cause a denial-of-service (DoS) condition. > > - CVE-2024-20328: Fixed a possible command injection vulnerability in the > "VirusEvent" feature of ClamAV's ClamD service. > > To fix this issue, we disabled the '%f' format string parameter. ClamD > administrators may continue to use the `CLAM_VIRUSEVENT_FILENAME` > environment > variable, instead of '%f'. But you should do so only from within an > executable, such as a Python script, and not directly in the clamd.conf > "VirusEvent" command. A friendly ping. Sebastian
Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1
Package: release.debian.org Control: affects -1 + src:openssl X-Debbugs-Cc: open...@packages.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: sebast...@breakpoint.cc Severity: normal This is an update to the current stable OpenSSL release in the 3.0.x series. It addresses the following CVE reports which were postponed due to low severity: - CVE-2023-5678 (Fix excessive time spent in DH check / generation with large Q parameter value) - CVE-2023-6129 (POLY1305 MAC implementation corrupts vector registers on PowerPC) - CVE-2023-6237 (Excessive time spent checking invalid RSA public keys) - CVE-2024-0727 (PKCS12 Decoding crashes) I'm not aware of a problems/ regression at this point. During the upload of 3.1.x release to upstable at the time m2crypto and nodejs failed to build. I verified that m2crypto in stable and nodejs in stable-security build against this version of openssl. Sebastian
Bug#1064856: dpkg: New xz-utils print warnings on stderr
On 2024-02-26 20:46:43 [+0100], Guillem Jover wrote: > > > Ignoring stderr could be a workaround, but I'd need to do something as > > > well for the libdpkg code and the perl code calling xz, which will get > > > very annoying. > > > > > > This is also going to get in the way of migrating both xz and dpkg > > > (which seems like would need to be uploaded today for the time64 > > > transition). > > > > > > Or perhaps that warning could be disabled for now in Debian until things > > > are sorted out with upstream? > > > > Falling back to -T1 in order to keep the previous is not an option? > > I'm not sure I understand what you are saying. Do you mean dpkg would > fallback to pass -T1 (maybe you mean -T+1, otherwise we might get > unreproducible output due to switching to single-threaded)? And > fallback on what condition? Yes. I *think* that error came from the decompress part but I'm not sure. > Ah, I think you mean to pass -T+1 to the xz invocations for the test > suite, right, that could workaround the issue there indeed. Thanks, I > think I'll do that for now. Thank you. > > Let me try to sell this "we move this warning to verbose" to upstream in > > the meantime… > > That would actually be great! > > > > (Had not seen this test suite failure yet, as I've got xz on hold due > > > to the breaks on pristine-tar, but would probably stumble over it > > > during the release process anyway I guess, so thanks for the heads up!) > > > > This poped up on xz debci only armel and armhf. > > Perhaps I'll not see it in my local tree then, but I think the dpkg > failure will at least block xz migration, but thinking about it now, > probably not dpkg's migration. So this might not be blocking for dpkg. > (Sorry if this sounded alarming, but didn't want to add new roadblocks > to the time64 transition from the dpkg side! :D) Understood ;) > Thanks, > Guillem Sebastian
Bug#1064856: dpkg: New xz-utils print warnings on stderr
On 2024-02-26 19:23:58 [+0100], Guillem Jover wrote: > Hi! Hi Guillem, > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the > > memory usage limit of 1400 MiB > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the > > memory usage limit of 1400 MiB > > | 89s 4. deb-format.at:511: FAILED (deb-format.at:518) > > > > Allowing output on stderr would be a possible tix. > > Hmm, that's warning is unfortunate, and a quick check at the xz code > didn't reveal a way to only suppress it. :/ > > For dpkg, I'd like to either not get the warning or being able to tell xz > that even if the threads are reduced, that's ok and it should not warn > about that (but that would then require depending on a new enough > version supporting that, perhaps that could be suppresses instead via > an envvar) so that? Could poke upstream. > Ignoring stderr could be a workaround, but I'd need to do something as > well for the libdpkg code and the perl code calling xz, which will get > very annoying. > > This is also going to get in the way of migrating both xz and dpkg > (which seems like would need to be uploaded today for the time64 > transition). > > Or perhaps that warning could be disabled for now in Debian until things > are sorted out with upstream? Falling back to -T1 in order to keep the previous is not an option? Let me try to sell this "we move this warning to verbose" to upstream in the meantime… > (Had not seen this test suite failure yet, as I've got xz on hold due > to the breaks on pristine-tar, but would probably stumble over it > during the release process anyway I guess, so thanks for the heads up!) This poped up on xz debci only armel and armhf. > Thanks, > Guillem Sebastian
Bug#1064857: unar: New xz-utils print warnings on stderr
Package: unar Version: 1.10.7+ds1+really1.10.1-2 Severity: important xz-utils 5.6.0 has been uploaded to unstable. A changed behaviour of `xz' is now that mutlti threaded compress/ decompression is now enabled by default. This in turn leads to warnings if the requested amount of memory exceeds the available amount. A snippet from https://ci.debian.net/packages/u/unar/testing/armel/43341293/ | 115s foo.tar.xz: Tar in XZ | 115s foo/ (dir)... OK. | 115s foo/bar (4 B)... OK. | 115s foo/baz (4 B)... OK. | 115s Successfully extracted to "foo". | 116s autopkgtest [10:53:54]: test tar: ---] | ▾ test tar: test results | 116s autopkgtest [10:53:54]: test tar: - - - - - - - - - - results - - - - - - - - - - | 116s tar FAIL stderr: xz: Reduced the number of threads from 16 to 8 to not exceed the memory usage limit of 1400 MiB | 116s autopkgtest [10:53:54]: test tar: - - - - - - - - - - stderr - - - - - - - - - - Allowing output on stderr would be a possible tix. Sebastian
Bug#1064856: dpkg: New xz-utils print warnings on stderr
Package: dpkg Version: 1.22.4 Severity: important xz-utils 5.6.0 has been uploaded to unstable. A changed behaviour of `xz' is now that mutlti threaded compress/ decompression is now enabled by default. This in turn leads to warnings if the requested amount of memory exceeds the available amount. A snippet from https://ci.debian.net/data/autopkgtest/testing/armel/d/dpkg/43341232/log.gz | 88s /tmp/autopkgtest-lxc.dumkcbm0/downtmp/build.4CO/src/src/at/deb-format.at:518: | 88s # Extract the base members | 88s xz -c control.tar >control.tar.xz | 88s xz -c data.tar >data.tar.xz | 88s | 89s --- /dev/null 2024-02-26 09:29:33.669234548 + | 89s +++ /tmp/autopkgtest-lxc.dumkcbm0/downtmp/autopkgtest_tmp/src/at/testsuite.dir/at-groups/4/stderr 2024-02-26 09:30:58.601386838 + | 89s @@ -0,0 +1,2 @@ | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the memory usage limit of 1400 MiB | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the memory usage limit of 1400 MiB | 89s 4. deb-format.at:511: FAILED (deb-format.at:518) Allowing output on stderr would be a possible tix. Sebastian
Bug#1064853: RM: r-bioc-rhtslib [armel armhf i386] -- ANAIS; No longer built
Package: ftp.debian.org Control: affects -1 + src:r-bioc-rhtslib X-Debbugs-Cc: r-bioc-rhts...@packages.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Hi, starting with 2.4.1+dfsg-2 the r-bioc-rhtslib package no longer builds for 32bit archs. The previously built 32bit packages prevents migration to testing and debci tests fail for other packages, too. Sebastian
Bug#1063874: m2crypto: Testsuite fails with OpenSSL 3.2
Package: m2crypto Version: 0.40.1-1 Severity: important Tags: sid patch control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.2 OpenSSL had an optimisation for PKCS7_verify() where it kept the memory BIO around. This optimisation is gone in OpenSSL 3.2 and so the test for verify fails because the memory BIO "ended". The attached patch fixes the issue. Sebastian >From 08308043d7ce8bb645996c8cb29655a23ead43a4 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Tue, 13 Feb 2024 17:47:22 +0100 Subject: [PATCH] test/smime: Rewind BIO before repeadetly invoking verify. OpenSSL had an optimisation for PKCS7_verify() where it kept the memory BIO around. This optimisation is gone in OpenSSL 3.2 and so the test for verify fails because the memory BIO "ended". Rewind the BIO before invoking verify again on the same data. Signed-off-by: Sebastian Andrzej Siewior --- tests/test_smime.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/test_smime.py b/tests/test_smime.py index 6014315353824..1fe7e954fcb89 100644 --- a/tests/test_smime.py +++ b/tests/test_smime.py @@ -162,10 +162,12 @@ from tests import unittest with self.assertRaises(SMIME.PKCS7_Error): s.verify(p7, data) +data.seek(0) st.set_verify_cb(verify_cb_dummy_function) v = s.verify(p7, data) self.assertEqual(v, self.cleartext) +data.seek(0) st.set_verify_cb() v = s.verify(p7, data) self.assertEqual(v, self.cleartext) -- 2.43.0
Bug#1063621: bookworm-pu: package clamav/clamav_1.0.5+dfsg-1~deb12u1
rom within
+ an executable, such as a Python script, and not directly in the `clamd.conf`
+ `VirusEvent` command.
+
+ Affected versions:
+ - 0.104 (all patch versions)
+ - 0.105 (all patch versions)
+ - 1.0.0 through 1.0.4 (LTS)
+ - 1.1 (all patch versions)
+ - 1.2.0 and 1.2.1
+
+ Thank you to Amit Schendel for identifying this issue.
+
+## 1.0.4
+
+ClamAV 1.0.4 is a patch release with the following fixes:
+
+- Eliminate security warning about unused "atty" dependency.
+ - GitHub pull request: https://github.com/Cisco-Talos/clamav/pull/1035
+
+- Upgrade the bundled UnRAR library (libclamunrar) to version 6.2.12.
+ - GitHub pull request: https://github.com/Cisco-Talos/clamav/pull/1054
+
+- Windows: libjson-c 0.17 compatibility fix. with ssize_t type definition.
+ - GitHub pull request: https://github.com/Cisco-Talos/clamav/pull/1064
+
+- Freshclam: Removed a verbose warning printed for each Freshclam HTTP request.
+ - GitHub pull request: https://github.com/Cisco-Talos/clamav/pull/1042
+
+- Build system: Fix link error with Clang/LLVM/LLD version 17.
+ Patch courtesy of Yasuhiro Kimura.
+ - GitHub pull request: https://github.com/Cisco-Talos/clamav/pull/1058
+
+- Fix alert-exceeds-max feature for files > 2GB and < max-filesize.
+ - GitHub pull request: https://github.com/Cisco-Talos/clamav/pull/1041
+
+Special thanks to the following people for code contributions and bug reports:
+- Yasuhiro Kimura
+
## 1.0.3
ClamAV 1.0.3 is a critical patch release with the following fixes:
diff --git a/clamav-config.h.cmake.in b/clamav-config.h.cmake.in
index b21af87..4f3b837 100644
--- a/clamav-config.h.cmake.in
+++ b/clamav-config.h.cmake.in
@@ -587,11 +587,22 @@
#define inline @INLINE_KEYWORD@
#endif
-/* Define to `long int' if does not define. */
-#cmakedefine off_t @off_t@
-
/* Define to `int' if does not define. */
-#cmakedefine ssize_t @ssize_t@
+#ifndef SSIZE_T_DEFINED
+ #if defined(_MSC_VER)
+ #include
+ typedef SSIZE_T ssize_t;
+ #else
+ @SSIZE_T_DEF@
+ #endif
+ # define SSIZE_T_DEFINED
+#endif
+
+/* Define to `long int' if does not define. */
+#ifndef OFF_T_DEFINED
+ @OFF_T_DEF@
+ #define OFF_T_DEFINED
+#endif
/* Define to the equivalent of the C99 'restrict' keyword, or to
nothing if this is not supported. Do not define if restrict is
diff --git a/clamd/clamd_others.c b/clamd/clamd_others.c
index 23f3b02..32d0701 100644
--- a/clamd/clamd_others.c
+++ b/clamd/clamd_others.c
@@ -101,6 +101,8 @@ void virusaction(const char *filename, const char *virname,
#define VE_FILENAME "CLAM_VIRUSEVENT_FILENAME"
#define VE_VIRUSNAME "CLAM_VIRUSEVENT_VIRUSNAME"
+#define FILENAME_DISABLED_MESSAGE "The filename format character has been disabled due to security concerns, use the 'CLAM_VIRUSEVENT_FILENAME' environment variable instead."
+
void virusaction(const char *filename, const char *virname,
const struct optstruct *opts)
{
@@ -145,7 +147,7 @@ void virusaction(const char *filename, const char *virname,
}
len = strlen(opt->strarg);
buffer_cmd =
-(char *)calloc(len + v * strlen(virname) + f * strlen(filename) + 1, sizeof(char));
+(char *)calloc(len + v * strlen(virname) + f * strlen(FILENAME_DISABLED_MESSAGE) + 1, sizeof(char));
if (!buffer_cmd) {
if (path)
xfree(env[0]);
@@ -160,8 +162,8 @@ void virusaction(const char *filename, const char *virname,
j += strlen(virname);
i++;
} else if (i + 1 < len && opt->strarg[i] == '%' && opt->strarg[i + 1] == 'f') {
- strcat(buffer_cmd, filename);
-j += strlen(filename);
+strcat(buffer_cmd, FILENAME_DISABLED_MESSAGE);
+j += strlen(FILENAME_DISABLED_MESSAGE);
i++;
} else {
buffer_cmd[j++] = opt->strarg[i];
diff --git a/common/optparser.c b/common/optparser.c
index a7bdbee..1be7afe 100644
--- a/common/optparser.c
+++ b/common/optparser.c
@@ -333,7 +333,7 @@ const struct clam_option __clam_options[] = {
{"DisableCache", "disable-cache", 0, CLOPT_TYPE_BOOL, MATCH_BOOL, 0, NULL, 0, OPT_CLAMD | OPT_CLAMSCAN, "This option allows you to disable clamd's caching feature.", "no"},
-{"VirusEvent", NULL, 0, CLOPT_TYPE_STRING, NULL, -1, NULL, 0, OPT_CLAMD, "Execute a command when a virus is found. In the command string %v will be\nreplaced with the virus name and %f will be replaced with the file name.\nAdditionally, two environment variables will be defined: $CLAM_VIRUSEVENT_FILENAME\nand $CLAM_VIRUSEVENT_VIRUSNAME.", "/usr/bin/mailx -s \"ClamAV VIRUS ALERT: %v\" alert < /dev/null"},
+{"VirusEvent", NULL, 0, CLOPT_TYPE_STRING, NULL, -1, NULL, 0, OPT_CLAMD, "Execute a command when virus is found.\nUse the
Bug#1062654: openjdk-17-jre-headless: Segfault in jspawnhelper
On 2024-02-06 12:52:51 [-0500], Hubert Pineault wrote: > I got the same problem on bullseye. > > the package was upgraded from 17.0.9+9-1~deb11u1 to 17.0.10+7-1~deb11u1 > on the 6th of february (with unattended-upgrades). It broke my jenkins > instance because it could not fetch git repo anymore. > > Downgrading to 17.0.7+7-1~deb11u1 solve the problem. You can install the upgrade and then you need to restart everything java related that is still running and using the old java version. Reboot the machine to be safe. After that, everything works as intended. Sebastian
Bug#1063252: pristine-tar: Always set the -T parameter for xz
Package: src:pristine-tar
Version: 1.50
Severity: important
Tags: sid
control: affects -1 src:xz-utils
xz-utils 5.5.1alpha is currently in experimental.
A user visible change is that xz will by default use the "multi threaded
mode" (-T1 -> -T0). This means that the archive will contain the block
size information (cu flag in xz -lvv) and so the resulting archive is no
longer binary identical comparing with the previous versions.
The patch attached adds -T1 argument if nothing was set. It also tries
to set the paramter while creating the delta (I hope it does that).
Sebastian
>From ea404fcd433147bd8328836fe96928b8643a56f6 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Mon, 5 Feb 2024 22:10:07 +0100
Subject: [PATCH] pristine-xz: Add -T1 if nothing was specified.
Signed-off-by: Sebastian Andrzej Siewior
---
pristine-xz | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/pristine-xz b/pristine-xz
index 48f9fd363391..2046578db82a 100755
--- a/pristine-xz
+++ b/pristine-xz
@@ -256,11 +256,12 @@ sub predict_xz_args {
# (even when --block-size or --block-list is specified)
if ($xz->{summary}->{size_in_blocks} eq 'yes') {
# All -T values >1 produce the same output.
- # 0 behaves the same as 1 on single core systems.
# Use as many threads as we have CPU affinities, with a minimum of 2.
my @affinities = Sys::CpuAffinity::getAffinity($$);
my $threads = @affinities > 2 ? @affinities : 2;
push @$common, "-T$threads";
+} else {
+ push @$common, "-T1";
}
}
my $possible_args = [];
@@ -402,6 +403,7 @@ sub genxz {
}
my @params = split(' ', $delta->{params});
+ my $threads_set = 0;
while (@params) {
my $param = shift @params;
@@ -415,13 +417,22 @@ sub genxz {
next if $param eq '--check=sha256';
next if $param =~ /^(--block-list=[0-9,]+)$/;
next if $param =~ /^-T[0-9]+$/;
+ if ($param =~ /^-T[0-9]+$/) {
+ $threads_set = 1;
+ next;
+ }
} elsif ($delta->{program} eq 'pixz') {
next if $param eq '-t';
}
die "paranoia check failed on params from delta ($param)";
}
+
@params = split(' ', $delta->{params});
+ if (!$threads_set) {
+push @params, '-T1';
+ }
+
doit($program, @params, $file);
}
--
2.43.0
Bug#1062072: [Pkg-clamav-devel] Bug#1062072: clamav: NMU diff for 64-bit time_t transition
On 2024-01-31 09:16:02 [+], Steve Langasek wrote: > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. I'm curious what your plans are here exactly. Is it just a rename to libclamav11t64 or do I need to add compiler switches with it? Experimental has currently a higher version sitting which should be uploaded to unstable once I resolve the docs issue I created… Sebastian
Bug#1062002: ngircd: Testsuite fails with openssl 3.2
On 2024-01-31 20:37:18 [+0100], Christoph Biedl wrote: > Thanks. As upstream is about to do another release, this issue will > resolve automatically. If however you plan to upload to unstable > really soon, making ngircd FTBFS, go ahead and drop me a line, I'll > do what's necessary then. Don't worry. I have a few packages left to tackle before I can do the upload. I will let you know before rendring your package FTBFS. > Christoph Sebastian
Bug#1062235: wireless-regdb: debci test fails with OpenSSL 3.2.
Package: wireless-regdb Version: 2022.06.06-1 Severity: important Tags: sid control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.2 OpenSSL 3.2 adds output on stderr if no input file as been specified and input from stdin is expected. This additional output on stderr causes the debci test to fail. Please add either "Restrictions: allow-stderr" to debian/tests/control in order to allow output on stderr or add "-in /dev/stdin" as an argument to the "openssl x509" invocation (convert_cert_der_to_pem). Sebastian
Bug#1062003: easy-rsa: Testsuite breaks with OpenSSL 3.2
Package: src:easy-rsa
Version: 3.1.7-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2
The default value for the -nameopt option changed in OpenSSL 3.2 from
`oneline' to `utf8'. The `oneline' option also included a space around
the fields which is not the case for `utf8'.
Patch attaches fixes the issue for OpenSSL 3.2 while it still works with
earlier versions.
Sebastian
From: Sebastian Andrzej Siewior
Date: Tue, 30 Jan 2024 22:03:19 +0100
Subject: [PATCH] debian/tests: Pass -nameopt to openssl.
The default value for the -nameopt option changed in OpenSSL 3.2 from
`oneline' to `utf8'. The `oneline' option also included a space around
the fields which is not the case for `utf8'. This means that
CN = domain.tld
changed to
CN=domain.tld
and is now longer recognized, leading to test failure.
This can be fixed by either going back to `oneline' or keeping `utf8'
and adding additionally `space_eq'. Anoter way would be to teach the
expect that the space is optional.
Add explicit -nameopt option with `utf8,space_eq' which is understood by
by OpenSSL 3.2 and earlier to make it explicit.
Signed-off-by: Sebastian Andrzej Siewior
---
debian/tests/basic-usage | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/tests/basic-usage b/debian/tests/basic-usage
index c9af11767c3a..6b633703ee26 100755
--- a/debian/tests/basic-usage
+++ b/debian/tests/basic-usage
@@ -89,7 +89,7 @@ cert_pubkey_size() {
| sed -n -e '/Public-Key: /s/^[[:space:]]*Public-Key:[[:space:]]*(\([0-9]*\) bit)$/\1/p'
}
cert_subject() {
- openssl x509 -noout -subject -in "${1:?}" | sed 's/^subject=//'
+ openssl x509 -noout -nameopt utf8,space_eq -subject -in "${1:?}" | sed 's/^subject=//'
}
--
2.43.0
Bug#1062002: ngircd: Testsuite fails with openssl 3.2
Package: src:ngircd
Version: 26.1-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2
The testsuite fails with openssl 3.2. Please find attached upstream
commit 287770666008b ("Test suite: Update for OpenSSL 3.x") which fixes
the issue.
Sebastian
>From 287770666008b5487d7c857aff273d517f82f49d Mon Sep 17 00:00:00 2001
From: Alexander Barton
Date: Mon, 8 Jan 2024 23:11:33 +0100
Subject: [PATCH] Test suite: Update for OpenSSL 3.x
---
src/testsuite/connect-ssl-cert1-test.e | 2 +-
src/testsuite/connect-ssl-cert2-test.e | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/testsuite/connect-ssl-cert1-test.e b/src/testsuite/connect-ssl-cert1-test.e
index e692110922a0e..5eb998b323a02 100644
--- a/src/testsuite/connect-ssl-cert1-test.e
+++ b/src/testsuite/connect-ssl-cert1-test.e
@@ -4,7 +4,7 @@
spawn openssl s_client -quiet -connect 127.0.0.1:6790
expect {
timeout { exit 1 }
-"*CN = my.first.domain.tld"
+"*CN*=*my.first.domain.tld"
}
sleep 2
diff --git a/src/testsuite/connect-ssl-cert2-test.e b/src/testsuite/connect-ssl-cert2-test.e
index eea4245d441db..cc10a1ed98408 100644
--- a/src/testsuite/connect-ssl-cert2-test.e
+++ b/src/testsuite/connect-ssl-cert2-test.e
@@ -4,7 +4,7 @@
spawn openssl s_client -quiet -connect 127.0.0.1:6790
expect {
timeout { exit 1 }
-"*CN = my.second.domain.tld"
+"*CN*=*my.second.domain.tld"
}
sleep 2
--
2.43.0
Bug#1061869: sssd: Drop -extensions from openssl command if there is no -x509.
Package: src:sssd
Version: 2.9.4-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
control: forwarded -1 https://github.com/SSSD/sssd/pull/7151
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2
tests: Drop -extensions from openssl command if there is no -x509
The 'openssl req' ignores the '-extensions' option without '-x509'.
OpenSSL versions prior 3.2 simply ignored it. Starting with version 3.2
an error is generated.
There are two patches attached: One against sssd and one against
debian/tests for debci.
Sebastian
From: Sebastian Andrzej Siewior
Date: Wed, 24 Jan 2024 23:03:04 +0100
Subject: [PATCH] tests: Drop -extensions from openssl command if there is no
-x509
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The 'openssl req' ignores the '-extensions' option without '-x509'.
OpenSSL versions prior 3.2 simply ignored it. Starting with version 3.2
an error is generated:
| /usr/bin/openssl req -batch -config
| ../../../../../src/tests/test_CA/intermediate_CA/SSSD_test_intermediate_CA.config
| -new -nodes -key
| …/build/../src/tests/test_CA/intermediate_CA/SSSD_test_intermediate_CA_key.pem
-sha256 -extensions v3_ca -out SSSD_test_intermediate_CA_req.pem
| Error adding request extensions from section v3_ca
| 003163BAB27F:error:1179:X509 V3 routines:v2i_AUTHORITY_KEYID:no issuer certificate:../crypto/x509/v3_akid.c:156:
| 003163BAB27F:error:1180:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=v3_ca, name=authorityKeyIdentifier, value=keyid:always,issuer:always
|
Remove the '-extensions' option.
Signed-off-by: Sebastian Andrzej Siewior
---
src/tests/test_CA/intermediate_CA/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tests/test_CA/intermediate_CA/Makefile.am b/src/tests/test_CA/intermediate_CA/Makefile.am
index b439f82cb03e5..50fcddb8d2221 100644
--- a/src/tests/test_CA/intermediate_CA/Makefile.am
+++ b/src/tests/test_CA/intermediate_CA/Makefile.am
@@ -33,7 +33,7 @@ ca_all: clean SSSD_test_intermediate_CA.pem SSSD_test_intermediate_CA_full_db.pe
ln -s $(builddir)/../$@
SSSD_test_intermediate_CA_req.pem: $(openssl_intermediate_ca_key) $(openssl_intermediate_ca_config) SSSD_test_CA.pem
- $(OPENSSL) req -batch -config ${openssl_intermediate_ca_config} -new -nodes -key $< -sha256 -extensions v3_ca -out $@
+ $(OPENSSL) req -batch -config ${openssl_intermediate_ca_config} -new -nodes -key $< -sha256 -out $@
SSSD_test_intermediate_CA.pem: SSSD_test_intermediate_CA_req.pem $(openssl_root_ca_config) $(openssl_root_ca_key)
cd .. && $(OPENSSL) ca -config ${openssl_root_ca_config} -batch -notext -keyfile $(openssl_root_ca_key) -in $(abs_builddir)/$< -days 200 -extensions v3_intermediate_ca -out $(abs_builddir)/$@
--
2.43.0
From: Sebastian Andrzej Siewior
Date: Mon, 29 Jan 2024 23:18:39 +0100
Subject: [PATCH] debian: tests: Drop -extensions from openssl command if there
is no -x509.
The 'openssl req' ignores the '-extensions' option without '-x509'.
OpenSSL versions prior 3.2 simply ignored it. Starting with version 3.2
an error is generated.
Remove the '-extensions' option.
Signed-off-by: Sebastian Andrzej Siewior
---
debian/tests/sssd-softhism2-certificates-tests.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/debian/tests/sssd-softhism2-certificates-tests.sh b/debian/tests/sssd-softhism2-certificates-tests.sh
index a0676740e11d..2c3d167414a6 100644
--- a/debian/tests/sssd-softhism2-certificates-tests.sh
+++ b/debian/tests/sssd-softhism2-certificates-tests.sh
@@ -222,7 +222,6 @@ openssl req \
-key "$tmpdir/test-intermediate-CA-key.pem" \
-passout "$root_ca_key_pass" \
-sha256 \
- -extensions v3_ca \
-out "$tmpdir/test-intermediate-CA-certificate-request.pem"
openssl req -text -noout -in "$tmpdir/test-intermediate-CA-certificate-request.pem"
@@ -311,7 +310,6 @@ openssl req \
-key "$tmpdir/test-sub-intermediate-CA-key.pem" \
-passout "$intermediate_ca_key_pass" \
-sha256 \
- -extensions v3_ca \
-out "$tmpdir/test-sub-intermediate-CA-certificate-request.pem"
openssl req -text -noout -in "$tmpdir/test-sub-intermediate-CA-certificate-request.pem"
--
2.43.0
Bug#1061458: gdm3: Testsuite breaks with openssl 3.2
Package: src:gdm3 Version: 45.0.1-2 Severity: important Tags: sid patch control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.2 The argument "-extensions v3_ca" for req is invalid and not considered. Earlier versions of openssl silently ignored that argument, openssl 3.2 throws an error now, see https://ci.debian.net/packages/g/gdm3/unstable/amd64/ https://ci.debian.net/packages/g/gdm3/unstable/amd64/41875309/ Sebastian From: Sebastian Andrzej Siewior Date: Wed, 24 Jan 2024 21:32:49 +0100 Subject: [PATCH] debian: Adapt tests for openssl3.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The argument "-extensions v3_ca" for req is invalid and not considered. Earlier versions of openssl silently ignored that argument, openssl 3.2 throws an error now: | openssl req -batch -new -nodes … -extensions v3_ca … | Error adding request extensions from section v3_ca | 0071DD54987F:error:1179:X509 V3 routines:v2i_AUTHORITY_KEYID:no issuer certificate:../crypto/x509/v3_akid.c:156: | 0071DD54987F:error:1180:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=v3_ca, name=authorityKeyIdentifier, value=keyid:always,issuer:always Remove the not relevant argument "-extensions v3_ca". Signed-off-by: Sebastian Andrzej Siewior --- debian/tests/sssd-softhism2-certificates-tests.sh | 2 -- 1 file changed, 2 deletions(-) diff --git a/debian/tests/sssd-softhism2-certificates-tests.sh b/debian/tests/sssd-softhism2-certificates-tests.sh index 00c533f127dd..a68812673983 100644 --- a/debian/tests/sssd-softhism2-certificates-tests.sh +++ b/debian/tests/sssd-softhism2-certificates-tests.sh @@ -217,7 +217,6 @@ openssl req \ -key "$tmpdir/test-intermediate-CA-key.pem" \ -passout "$root_ca_key_pass" \ -sha256 \ - -extensions v3_ca \ -out "$tmpdir/test-intermediate-CA-certificate-request.pem" openssl req -text -noout -in "$tmpdir/test-intermediate-CA-certificate-request.pem" @@ -306,7 +305,6 @@ openssl req \ -key "$tmpdir/test-sub-intermediate-CA-key.pem" \ -passout "$intermediate_ca_key_pass" \ -sha256 \ - -extensions v3_ca \ -out "$tmpdir/test-sub-intermediate-CA-certificate-request.pem" openssl req -text -noout -in "$tmpdir/test-sub-intermediate-CA-certificate-request.pem" -- 2.43.0
Bug#1060889: [Pkg-clamav-devel] Bug#1060889: Bug#1060889: clamav cannot be cross-arch installed?
On 2024-01-17 22:00:49 [+0100], To Trent W. Buck wrote: > > 2. clamav's Depends/Conflicts/Replaces are subtly bugged, and should be > > "fixed"; or > > The multi-arch fields could be wrong. Let me check that. I fixed this in unstable. Given that the memory on i386 are almost the same as on amd64 I assume you don't need this fixed in stable/bookworm? Sebastian
Bug#1060889: [Pkg-clamav-devel] Bug#1060889: clamav cannot be cross-arch installed?
On 2024-01-16 17:59:21 [+1100], Trent W. Buck wrote: > Package: clamav-base > Version: 1.0.3+dfsg-1~deb12u1 > Severity: minor > > When trying to install clamav for non-default architecture, > I get this error from apt: > > The following packages have unmet dependencies: > clamav-daemon:i386 : Depends: clamav-base:i386 (= 1.0.3+dfsg-1~deb12u1) > but it is not installable > clamav-freshclam:i386 : Depends: clamav-base:i386 (>= > 1.0.3+dfsg-1~deb12u1) but it is not installable > > This is really weird and confusing, because clamav-base is > an Architecture: all package, not > an Architecture: any package. > > I speculate that either: > > 1. apt has a bug that clamav happens to trigger; or > 2. clamav's Depends/Conflicts/Replaces are subtly bugged, and should be > "fixed"; or > 3. I've misunderstood something fundamental about how to use multiple > architectures in apt. The multi-arch fields could be wrong. Let me check that. > PS: while not really relevant to this bug report, > the original context was: > > grr, clamd keeps getting OOM-killed because >it loads all definitions into RAM (not mmaped or anything) which >is 1300MB on this 4000MB system. 1.3GiB is what I see here, too. Keep in mind, there is this ConcurrentDatabaseReload which is enabled by default. This will load a new database (after signature update) from scratch while keeping the old around. The old is removed once the new is completly loaded. Assuming the DB requires 1GiB of memory then it will consume another 1GiB until it is fully loaded. > /var/lib/clamav/ is only 223M, not 1300MB! Probably compressed content, data structurs and so on. > I wonder if clamav:i386 halves the RAM usage? > > dpkg --add-architecture=i386; >apt update; >apt install clamav:i386 clamav-daemon:i386 >[doesn't work, start investigating] On i386 I see 1,1GiB after clamav-daemon started and got idle (after loading the database). Sebastian
Bug#1060306: [Pkg-clamav-devel] Bug#1060306: clamav on debian oldstable outdated
On 2024-01-09 10:09:46 [+0100], p-berger wrote: > Package: clamav > Version: 0.103.10+dfsg-0+deb11u1 > > > The daily logs tell that clamav installation is outdated. I suggest to > bump the oldstable version to a current version like 0.103.11 which is > suggested in the error message. > > Here is the error log: > > WARNING: Your ClamAV installation is OUTDATED! > WARNING: Local version: 0.103.10 Recommended version: 0.103.11 Thank you for the report. I saw that, I just didn't get around. I try to take care of this over the weekend. Sebastian
Bug#1058700: nmu: dar_2.7.13-2
Package: release.debian.org Control: affects -1 + src:dar User: release.debian@packages.debian.org Usertags: binnmu Severity: normal Hi, if I see this correctly then dar 2.7.13-2 won't migrate to testing because it was built using openssl 3.0.12-1. This version isn't in testing and if everything goes according to then plan then openssl 3.1.4-2 will migrate to testing in ~3days. Therefore I suggest to binNMU dar to pickup current openssl so it can migrate: nmu dar_2.7.13-2 . ANY . unstable . -m "Update Built-Using for openssl" Sebastian
