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 = _cmd_set; }
%%
/* */
-yywrap() {
+int yywrap(void) {
return 1;
}
@@ -343,7 +343,7 @@ int check_memcached() {
}
if ( nagios_service_output == NULL ) {
- str_bytes = asprintf(_service_output,"");
+ str_bytes = asprintf(_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(_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(_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(_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(_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}"
;;
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' |
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
e 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 following environment variables to identify the file and virus names:\n- $CLAM_VIRUSEVENT_FILENAME\n- $CLAM_VIRUSEVENT_VIRUSNAME\nIn the command string, '%v' will also be replaced with the virus name.\nNote: The '%f' filename format character has been disabled and will no longer\nbe replaced with the file name, due to command injection security concerns.\nUse the 'CLAM_VIRUSEVENT_FILENAME' environment variable i
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
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
control: tags -1 patch fixed-upstream
On 2023-10-02 17:12:53 [+0200], Julian Andres Klode wrote:
> Being subscribed to the mailing list, grabbing the patch and applying
> it and shipping it isn't hard, but if you were wondering why it's
There are different views here. But Daniel was nice enough to Cc me so I
had all I needed to test it.
> not fixed, it hasn't been merged or received a Reviewed-By yet;
> and I don't really want to carry file system (parser) patches
> outside of upstream for security reasons, needing separate
> revocation if that is broken.
The following patches were merged into grub upstream:
ad7fb8e2e02bb ("fs/xfs: Incorrect short form directory data boundary check")
07318ee7e11a0 ("fs/xfs: Fix XFS directory extent parsing")
would you mind to cherry pick those for the next upload?
Sebastian
Bug#1002056: Fedora plans to transition to Zlib-ng
On 2023-10-25 23:17:06 [+0200], Guillem Jover wrote: > Hi! Hi, > Ah, thanks! I had in my mind getting back to this ITP, given that the > zlib-ng project has continued to gain traction and seems to have > consolidated most of the other forks around it. > > So I'll draft another mail to Mark and probably to debian-devel to > discuss this. Do you want me to join your efforts? This looks interrestig. I may have time ;) > Thanks, > Guillem Sebastian
Bug#1055416: nodejs: Testsuite failure in test-crypto-dh since OpenSSL 3.0.12/3.1.4.
Package: nodejs
Version: 18.13.0+dfsg1-1
Severity: Serious
Tags: patch
control: affects -1 src:openssl
OpenSSL 3.0.12 and 3.1.4 changed the error response resulting a failure
in test parallel/test-crypto-dh.
This has been addressed in the master branch in commit
8eea2d3709090 ("test: fix crypto-dh error message for OpenSSL 3.x")
An additional problem is that the check compares OpenSSL from compile
time not runtime. Which means I couldn't test upstream's version as-is.
The attached version takes always the 3.0.12/3.1.4 variant. Given that
the new upload picks up the new OpenSSL vesion then it should be okay to
apply the original commit.
Sebastian
From: Sebastian Andrzej Siewior
Date: Sun, 5 Nov 2023 13:08:23 +0100
Subject: [PATCH] test: Alter error message.
This is variant of upstream's commit
8eea2d3709090 ("test: fix crypto-dh error message for OpenSSL 3.x")
It does not work as-is in Debian because the testsuite may run against a
different version than the compiled once and the constant version check
does not apply.
Signed-off-by: Sebastian Andrzej Siewior
---
test/parallel/test-crypto-dh.js | 4 +---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/test/parallel/test-crypto-dh.js b/test/parallel/test-crypto-dh.js
index 18721fcf289e..506780db4cbe 100644
--- a/test/parallel/test-crypto-dh.js
+++ b/test/parallel/test-crypto-dh.js
@@ -165,9 +165,7 @@ if (common.hasOpenSSL3) {
assert.throws(() => {
dh3.computeSecret('');
-}, { message: common.hasOpenSSL3 ?
- 'error:02800080:Diffie-Hellman routines::invalid secret' :
- 'Supplied key is too small' });
+}, { message: 'Supplied key is too small' });
// Invalid test: curve argument is undefined
assert.throws(
--
2.42.0
Bug#1007559: [Pkg-clamav-devel] Bug#1007559: clamsmtp: please consider upgrading to 3.0 source format
On October 28, 2023 1:05:06 PM GMT+02:00, Bastian Germann wrote: >I am uploading a NMU to DELAYED/10 in order to fix this. >Please find the debdiff attached. Hi, I am team clamav but I don't feel responsible for clamsmtp. The last upload was a NMU. That said, I don't mind if you reschudule it to 0-day. -- Sebastian
Bug#1054546: openssl: The engine interface seems to be broken.
Package: openssl Version: 3.0.12-1 Severity: serious Control: affects -1 + src:libp11 Control: forwarded -1 https://github.com/openssl/openssl/issues/22508 At least for libp11 the engine interface seems to be broken. Sebastian
Bug#1054180: openssl: FTBFS on loong64
On 2023-10-20 13:49:01 [+0800], WANG Xuerui wrote: > Hi, Hi, > This is likely upstream issue > https://github.com/openssl/openssl/issues/21340, manifesting on Debian due > to the packaged binutils not having Loongson SIMD support yet, and fixed by > upstream commit 160f48941d143cf2682df4e938ba953c96ac3c7a. > > I'd suggest including the upstream patch so we don't have to touch anywhere > else. So submitting patches for projects before having the upstream in the building tools. Nobody can build this then. What about uploading a custom binutils with the needed support to ports until it is merged upstream? Sebastian
Bug#1052470: [Pkg-javascript-devel] Bug#1052470: nodejs: Please fix testsuite for openssl-3.1
On 2023-10-17 22:08:07 [+0200], Jérémy Lal wrote: > I did not forget about this. Really sorry for the delay. > Currently I'd be more willing to help someone maintain nodejs than doing it > myself. > However, I'll probably deal with the next 18.x update very soon, including > your patch. Thank you. I just uploaded m2crypto to delayed-5 queue which is the other blocker. And I might be busy otherwise the next week and week after so no need to rush ;) > Jérémy Sebastian
Bug#1054180: openssl: FTBFS on loong64
Package: openssl Version: 3.1.2-1 Severity: wishlist Tags: ftbfs User:debian-de...@lists.debian.org Usertags: loongarch64 OpenSSL 3.1.x in experimental FTBFS on loong64: |crypto/aes/vpaes-loongarch64.S: Assembler messages: |crypto/aes/vpaes-loongarch64.S:24: Error: no match insn: vori.b $vr1,$vr9,0 |crypto/aes/vpaes-loongarch64.S:26: Error: no match insn: vld $vr2,$r12,0 |crypto/aes/vpaes-loongarch64.S:27: Error: no match insn: vandn.v $vr1,$vr1,$vr0 … Latest build log https://buildd.debian.org/status/fetch.php?pkg=openssl=loong64=3.1.3-1=1695145526=0 My guess is that either binutils support is missing or a flag/ CPU switch is missing to recognise the vector opcodes. Sebastian
Bug#1051795: m2crypto: diff for NMU version 0.38.0-4.1
Control: tags 1051795 + patch
Control: tags 1051795 + pending
Dear maintainer,
I've prepared an NMU for m2crypto (versioned as 0.38.0-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
Sebastian
diff -Nru m2crypto-0.38.0/debian/changelog m2crypto-0.38.0/debian/changelog
--- m2crypto-0.38.0/debian/changelog 2022-11-17 03:32:27.0 +0100
+++ m2crypto-0.38.0/debian/changelog 2023-10-17 21:44:49.0 +0200
@@ -1,3 +1,10 @@
+m2crypto (0.38.0-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Adapt testsuite to OpenSSL 3.1 error codes (Closes: #1051795).
+
+ -- Sebastian Andrzej Siewior Tue, 17 Oct 2023 21:44:49 +0200
+
m2crypto (0.38.0-4) unstable; urgency=high
[ Stefano Rivera ]
diff -Nru m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch
--- m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch 2022-11-17 03:32:27.0 +0100
+++ m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch 2023-10-17 21:44:49.0 +0200
@@ -16,7 +16,7 @@
with warnings.catch_warnings():
warnings.simplefilter('ignore', DeprecationWarning)
ctx = SSL.Context('tlsv1')
-+ctx.set_cipher_list('DEFAULT@SECLEVEL=1')
++ctx.set_cipher_list('DEFAULT@SECLEVEL=0')
s = SSL.Connection(ctx)
with six.assertRaisesRegex(self, SSL.SSLError,
r'version|unexpected eof'):
Bug#1052470: [Pkg-javascript-devel] Bug#1052470: nodejs: Please fix testsuite for openssl-3.1
On 2023-09-22 22:52:48 [+0200], Jérémy Lal wrote: > Thanks, will include it soon. Thanks. Any update on this? I added two patches. The first one is a cherry-pick from upstream, the second has been forwarded upstream via https://github.com/nodejs/node/pull/49885 but upstream has no interest in applying it. So you could apply it and drop it after new openssl migrated to testing. Another option would be to binNMU later on, don't want to cause too much trouble here ;) Sebastian
Bug#1051884: bullseye-pu: package openssl/1.1.1w-0~deb11u1
On 2023-10-02 13:41:17 [+0200], Cyril Brulebois wrote: > Adam D. Barratt (2023-10-02): > > Unfortunately, the version format change from -0+deb11uX to -0~deb11uX > > has broken the installer. > > > > The udebs end up with dependencies of the form ">= 1.1.1w", which > > 1.1.1w-0~deb11u1 doesn't fulfil. Assuming I'm not missing anything, > > could we have an upload that uses the -0+ style of versioning ASAP, > > please? > > Trying to understand the reasons behind the versioning scheme switch, it > seems the debian/bullseye branch is still at 1.1.1v-0~deb11u1 (without a > tag). Sorry for that. Just uploaded 1.1.1w-0+deb11u1 which solves that. > Cheers, Sebastian
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On 2023-09-27 21:45:03 [-0400], Jon DeVree wrote: > I posted an updated v3 version of the patch: > > https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html Just rebuilt grub with v3 of the patch and I can confirm that it works. Thank you. Referencing the message-id or the link to lore https://lore.kernel.org/all/20230928004354.32685-1-n...@vault24.org makes it easier to grab the patch. The GNU list archive contains html encoding among other things which make it imposible… Sebastian
Bug#1053001: bookworm-pu: package openssl/3.0.11-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 of the openssl package to the 3.0.11 version, a patch
release (bug and security fixes). This version contains no security
updates.
The 3.0.11 version is since 2023-09-19 in unstable. The migration to
testing was delayed due to a "bug" in a testsuite of another package
which led to CI failures. Once this was fixed, the both packages
migrated. The package causing the delay is not part of bookworm. I am
not aware of any other fallout.
Sebastian
diff -Nru openssl-3.0.10/apps/cmp.c openssl-3.0.11/apps/cmp.c
--- openssl-3.0.10/apps/cmp.c 2023-08-01 15:47:24.0 +0200
+++ openssl-3.0.11/apps/cmp.c 2023-09-19 15:02:31.0 +0200
@@ -2512,7 +2512,7 @@
}
break;
case OPT_CSR:
-opt_csr = opt_arg();
+opt_csr = opt_str();
break;
case OPT_OUT_TRUSTED:
opt_out_trusted = opt_str();
diff -Nru openssl-3.0.10/apps/lib/apps.c openssl-3.0.11/apps/lib/apps.c
--- openssl-3.0.10/apps/lib/apps.c 2023-08-01 15:47:24.0 +0200
+++ openssl-3.0.11/apps/lib/apps.c 2023-09-19 15:02:31.0 +0200
@@ -944,7 +944,7 @@
BIO *bio;
if (!maybe_stdin) {
-BIO_printf(bio_err, "No filename or uri specified for loading");
+BIO_printf(bio_err, "No filename or uri specified for loading\n");
goto end;
}
uri = "";
@@ -960,10 +960,8 @@
ctx = OSSL_STORE_open_ex(uri, libctx, propq, get_ui_method(), ,
params, NULL, NULL);
}
-if (ctx == NULL) {
-BIO_printf(bio_err, "Could not open file or uri for loading");
+if (ctx == NULL)
goto end;
-}
if (expect > 0 && !OSSL_STORE_expect(ctx, expect))
goto end;
@@ -1948,16 +1946,17 @@
nid = OBJ_txt2nid(typestr);
if (nid == NID_undef) {
BIO_printf(bio_err,
- "%s: Skipping unknown %s name attribute \"%s\"\n",
+ "%s warning: Skipping unknown %s name attribute \"%s\"\n",
opt_getprog(), desc, typestr);
if (ismulti)
BIO_printf(bio_err,
- "Hint: a '+' in a value string needs be escaped using '\\' else a new member of a multi-valued RDN is expected\n");
+ "%s hint: a '+' in a value string needs be escaped using '\\' else a new member of a multi-valued RDN is expected\n",
+ opt_getprog());
continue;
}
if (*valstr == '\0') {
BIO_printf(bio_err,
- "%s: No value provided for %s name attribute \"%s\", skipped\n",
+ "%s warning: No value provided for %s name attribute \"%s\", skipped\n",
opt_getprog(), desc, typestr);
continue;
}
diff -Nru openssl-3.0.10/apps/req.c openssl-3.0.11/apps/req.c
--- openssl-3.0.10/apps/req.c 2023-08-01 15:47:24.0 +0200
+++ openssl-3.0.11/apps/req.c 2023-09-19 15:02:31.0 +0200
@@ -990,10 +990,10 @@
else
tpubkey = X509_REQ_get0_pubkey(req);
if (tpubkey == NULL) {
-fprintf(stdout, "Modulus is unavailable\n");
+BIO_puts(bio_err, "Modulus is unavailable\n");
goto end;
}
-fprintf(stdout, "Modulus=");
+BIO_puts(out, "Modulus=");
if (EVP_PKEY_is_a(tpubkey, "RSA") || EVP_PKEY_is_a(tpubkey, "RSA-PSS")) {
BIGNUM *n = NULL;
@@ -1002,9 +1002,9 @@
BN_print(out, n);
BN_free(n);
} else {
-fprintf(stdout, "Wrong Algorithm type");
+BIO_puts(out, "Wrong Algorithm type");
}
-fprintf(stdout, "\n");
+BIO_puts(out, "\n");
}
if (!noout && !gen_x509) {
diff -Nru openssl-3.0.10/apps/s_server.c openssl-3.0.11/apps/s_server.c
--- openssl-3.0.10/apps/s_server.c 2023-08-01 15:47:24.0 +0200
+++ openssl-3.0.11/apps/s_server.c 2023-09-19 15:02:31.0 +0200
@@ -789,7 +789,7 @@
"second server certificate chain file in PEM format"},
{"dkey", OPT_DKEY, '<',
"Second private key file to use (usually for DSA)"},
-{"dkeyform", OPT_DKEYFORM, 'F',
+{"dkeyform", OPT_DKEYFORM, 'f',
"Second key file format (ENGINE, other values ignored)"},
{"dpass", OPT_DPASS, 's',
"Second private key and cert file pass phrase source"},
diff -Nru openssl-3.0.10/appveyor.yml openssl-3.0.11/appveyor.yml
--- openssl-3.0.10/appveyor.yml 2023-08-01 15:47:24.0 +0200
+++ openssl-3.0.11/appveyor.yml 1970-01-01 01:00:00.0 +0100
@@ -1,82 +0,0 @@
-image:
-- Visual Studio 2017
-
-platform:
-- x64
-- x86
-
Bug#1052070: bookworm-pu: package mutt/2.2.12-0.1~deb12u1
On 2023-09-23 20:39:32 [+0100], Adam D. Barratt wrote: > Please go ahead. Thanks, done. > Regards, > > Adam Sebastian
Bug#1052470: nodejs: Please fix testsuite for openssl-3.1
On 2023-09-22 17:59:51 [+0200], To sub...@bugs.debian.org wrote: > Now I'm about to test this… But it looks promising ;) Okay, builds. Sebastian
Bug#1052470: nodejs: Please fix testsuite for openssl-3.1
Package: nodejs
Version: 18.13.0+dfsg1-1
Severity: important
Tags: patch
The nodejs version in unstable FTBFS against openssl 3.1 due to the
testsuite. I had something working and then looked in the upstream git
and backported their against the packaging master-18.x branch. Hopefully
this makes less work for everyone. One patch is for upstream, one I made
myself.
Now I'm about to test this… But it looks promising ;)
Sebastian
From 85aa9556000424fcde6748bed969a01e864be266 Mon Sep 17 00:00:00 2001
From: OttoHollmann
Date: Thu, 1 Jun 2023 16:52:53 +0200
Subject: [PATCH 1/2] test: adapt tests for OpenSSL 3.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
PR-URL: https://github.com/nodejs/node/pull/47859
Reviewed-By: Tobias Nießen
Reviewed-By: Richard Lau
(cherry picked from commit 5f283722072e400234d3e15f1f2caa2ca2fd8d60)
Signed-off-by: Sebastian Andrzej Siewior
---
test/common/index.js | 6 +-
.../test-https-agent-session-eviction.js | 1 +
test/parallel/test-tls-alert.js | 1 +
test/parallel/test-tls-getprotocol.js| 16 +---
test/parallel/test-tls-min-max-version.js| 3 +++
test/parallel/test-tls-session-cache.js | 1 +
6 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/test/common/index.js b/test/common/index.js
index e0c6e7aa0c996..35c3eac6481b3 100644
--- a/test/common/index.js
+++ b/test/common/index.js
@@ -56,7 +56,10 @@ const hasCrypto = Boolean(process.versions.openssl) &&
!process.env.NODE_SKIP_CRYPTO;
const hasOpenSSL3 = hasCrypto &&
-require('crypto').constants.OPENSSL_VERSION_NUMBER >= 805306368;
+require('crypto').constants.OPENSSL_VERSION_NUMBER >= 0x3000;
+
+const hasOpenSSL31 = hasCrypto &&
+require('crypto').constants.OPENSSL_VERSION_NUMBER >= 0x3010;
const hasQuic = hasCrypto && !!process.config.variables.openssl_quic;
@@ -899,6 +902,7 @@ const common = {
hasIntl,
hasCrypto,
hasOpenSSL3,
+ hasOpenSSL31,
hasQuic,
hasMultiLocalhost,
invalidArgTypeHelper,
diff --git a/test/parallel/test-https-agent-session-eviction.js b/test/parallel/test-https-agent-session-eviction.js
index 940c43cc40bf1..36c360a96503d 100644
--- a/test/parallel/test-https-agent-session-eviction.js
+++ b/test/parallel/test-https-agent-session-eviction.js
@@ -54,6 +54,7 @@ function faultyServer(port) {
function second(server, session) {
const req = https.request({
port: server.address().port,
+ciphers: (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT'),
rejectUnauthorized: false
}, function(res) {
res.resume();
diff --git a/test/parallel/test-tls-alert.js b/test/parallel/test-tls-alert.js
index 31b07104c241a..04000771aa977 100644
--- a/test/parallel/test-tls-alert.js
+++ b/test/parallel/test-tls-alert.js
@@ -42,6 +42,7 @@ const server = tls.Server({
cert: loadPEM('agent2-cert')
}, null).listen(0, common.mustCall(() => {
const args = ['s_client', '-quiet', '-tls1_1',
+'-cipher', (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT'),
'-connect', `127.0.0.1:${server.address().port}`];
execFile(common.opensslCli, args, common.mustCall((err, _, stderr) => {
diff --git a/test/parallel/test-tls-getprotocol.js b/test/parallel/test-tls-getprotocol.js
index d45287d671d8a..7da2f60676d00 100644
--- a/test/parallel/test-tls-getprotocol.js
+++ b/test/parallel/test-tls-getprotocol.js
@@ -11,9 +11,18 @@ const tls = require('tls');
const fixtures = require('../common/fixtures');
const clientConfigs = [
- { secureProtocol: 'TLSv1_method', version: 'TLSv1' },
- { secureProtocol: 'TLSv1_1_method', version: 'TLSv1.1' },
- { secureProtocol: 'TLSv1_2_method', version: 'TLSv1.2' },
+ {
+secureProtocol: 'TLSv1_method',
+version: 'TLSv1',
+ciphers: (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT')
+ }, {
+secureProtocol: 'TLSv1_1_method',
+version: 'TLSv1.1',
+ciphers: (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT')
+ }, {
+secureProtocol: 'TLSv1_2_method',
+version: 'TLSv1.2'
+ },
];
const serverConfig = {
@@ -30,6 +39,7 @@ const server = tls.createServer(serverConfig, common.mustCall(clientConfigs.leng
tls.connect({
host: common.localhostIPv4,
port: server.address().port,
+ ciphers: v.ciphers,
rejectUnauthorized: false,
secureProtocol: v.secureProtocol
}, common.mustCall(function() {
diff --git a/test/parallel/test-tls-min-max-version.js b/test/parallel/test-tls-min-max-version.js
index 5cea41ca7e0bd..ab351558a4c8b 100644
--- a/test/parallel/test-tls-min-max-version.js
+++ b/test/parallel/test-tls-min-max-version.js
@@ -22,6 +22,9 @@ function test(cmin, cmax, cprot, smin, smax, sprot, proto, cerr, serr) {
if (serr !== 'ERR_SSL_UNSUPPORTED_PROTOCOL')
ciphers = 'ALL@SECLE
Bug#1052331: libcrypt-openssl-pkcs12-perl
Package: libcrypt-openssl-pkcs12-perl Version: 1.9-2 severity: serious I reported FTBFS against openssl 3.0 in #1006386 and now it kind of falls apart again. The check in patch is | $major eq "3.1" and $minor <= 2) or ($major eq "3.0" and $minor <= 10) and I have now 3.1.3 in experimental and 3.0.11 in unstable leading to ci failures and FTBFS for libcrypt-openssl-pkcs12-perl itself. Could we please extend the version check to all major 3.0 and 3.1 versions? It looks unlikely that the password thingy will be changed within 3.0/3.1 series based on the linked bug report. And maybe even add 3.2 because from what I see in the current alpha version is, that it is ABI compatible with the current 3.0/3.1 releases. But then maybe limit the test to less than 3.0 series of openssl and enable it again once it is known that it works again. Whatever feels like less work ;) Sebastian
Bug#1052070: bookworm-pu: package mutt/2.2.12-0.1~deb12u1
Package: release.debian.org Control: affects -1 + src:mutt X-Debbugs-Cc: m...@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 mutt package as provided by upstream to version 2.2.12 which also available in unstable since 10th September. The 2.2.x series are bug fix only releases. The 2.2.10 release changed the message-id generation by using the base64 url-safe dictionary instead of base64 for encoding "random" characters. The usage of the '/' character in the message-id leads to a problem with online-archives if the message-id is part of the URL and then '/' gets interpreted as a "folder delimiter" instead a "file". This is a real problem for the lore archiver. The 2.2.11 release listed only build issue on MacOS. The 2.2.12 release listed only two "crash bugs" which were fixed recently via the d-security. The whole history from git: | a60b22fe2a250 Filter U+200C in pager. | 2f35d2fdb99de Reset header color after mutt_set_flag(). | ba5e0dc2bcadd Add doc note to MuttLisp about boolean config vars. | d0faf2d44455b Remove reference to $mark_old inside $mail_check_recent. | ef2abed29fe02 Fix counters for external maildir 'T' flag changes. | 16d8ad647bd17 Move MuttLisp boolean config note. | 7c4fa47888d0d mutt_oauth2: Print access token request message | cecddeac3be3d base64val: Add support to decode base64 safe URL. | 5df86199463b5 Use base64 URL safe alphabet for message id generation. | 216dd145d41dd Improve smtp oauth authentication. | 9f01d4ab0b8af Abort imap_fast_trash() if previously checkpointed. | 33f8b7cee857d Update copyright notices. | 9138232d8daa4 Update UPDATING files for 2.2.10 release. | e0e92c31228e3 (tag: mutt-2-2-10-rel) automatic post-release commit for mutt-2.2.10 | 50954c4ab7408 Fix behavior for sort=reverse-threads. | a5423c403381e Updated Japanese translation. | d52c6115b074d Fix GPGME build failure on MacOS. | d619496e99899 Update UPDATING file for 2.2.11 release. | 6b538297bc0ba (tag: mutt-2-2-11-rel) automatic post-release commit for mutt-2.2.11 | 7eb9c18f27d14 Add a documentation note that aliases are case insensitive. | 452ee330e094b Fix rfc2047 base64 decoding to abort on illegal characters. | 4cc3128abdf52 Check for NULL userhdrs. | a4752eb0ae0a5 Fix write_one_header() illegal header check. | 6a155b4933b4b Update UPDATING file for 2.2.12 release. | 0a81a2a7ca2b4 (mutt-2-2-12-rel) automatic post-release commit for mutt-2.2.12 Sebastian
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On 2023-09-15 15:51:51 [+0200], Felix Zielcke wrote: > Hi Sebastian, Hi Felix, > there's now a patch from Jon DeVree upstream, which might fix this for > you. Is it possible for you to test his patch? > > https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html Yes it sovles the issue, the box boots. Sebastian
Bug#1050639: bookworm-pu: package clamav/1.0.2+dfsg-1~deb12u1
On 2023-09-14 21:52:25 [+0100], Adam D. Barratt wrote: > > That's now out, as SUA-240-1. Thank you Adam. > Regards, > > Adam Sebastian
Bug#1050639: bookworm-pu: package clamav/1.0.2+dfsg-1~deb12u1
On 2023-09-14 06:31:26 [+0100], Adam D. Barratt wrote: > On Wed, 2023-09-13 at 22:01 +0200, Sebastian Andrzej Siewior wrote: > > On 2023-09-13 17:26:46 [+0100], Adam D. Barratt wrote: > > > How does this sound for an SUA? > [...] > > This sounds entirely fine to me. I don't think that it is needed to > > point out that bullseye is not affected by the second issue. > > > > Great, thanks. > > > There is also this thing regarding libclamunrar and the update to > > v6.2.10 of the bundled libbrary. I *think* it is related to > > CVE-2023-40477. Since unrar itself is only in -pu I think it is okay > > for libclamunar to follow the same fate. > > > > Just to be completely sure, "follow the same fate" here means leaving > libclamunrar in (o-)p-u until the point releases? I mean there is no reason to push libclamunrar via d/updates if the unrar package isn't. Therefore I don't mind keeping libclamunrar in o-)p-u until the point release. It is non-free after all. > I assume the bundled library isn't used as-is in the Debian packaging, > that being why libclamunrar exists. The last time I looked the src:unrar package either didn't provide the library or something else was different. So I tried to replace it with libarchive but upstream wasn't pleased because it did not support some "newer" rar formats. But now (as of the recent CVE) I was looking again, noticed the library and noticed that clamav upstream already fiddled with their in-tree copy. However I will spent some cycles to see if the in-tree library can be used. If it works then it will lower the amount of swearing needed during packaging of a new version. > Regards, > > Adam Sebastian
Bug#1051884: bullseye-pu: package openssl/1.1.1w-0~deb11u1
l-1.1.1w/crypto/poly1305/asm/poly1305-x86_64.pl 2023-09-11 16:08:11.0 +0200
@@ -1,5 +1,5 @@
#! /usr/bin/env perl
-# Copyright 2016-2020 The OpenSSL Project Authors. All Rights Reserved.
+# Copyright 2016-2023 The OpenSSL Project Authors. All Rights Reserved.
#
# Licensed under the OpenSSL license (the "License"). You may not use
# this file except in compliance with the License. You can obtain a copy
@@ -193,7 +193,7 @@
bt \$`5+32`,%r9 # AVX2?
cmovc %rax,%r10
___
-$code.=<<___ if ($avx>3);
+$code.=<<___ if ($avx>3 && !$win64);
mov \$`(1<<31|1<<21|1<<16)`,%rax
shr \$32,%r9
and %rax,%r9
@@ -2722,7 +2722,7 @@
.cfi_endproc
.size poly1305_blocks_avx512,.-poly1305_blocks_avx512
___
-if ($avx>3) {
+if ($avx>3 && !$win64) {
# VPMADD52 version using 2^44 radix.
#
diff -Nru openssl-1.1.1v/crypto/rsa/rsa_ameth.c openssl-1.1.1w/crypto/rsa/rsa_ameth.c
--- openssl-1.1.1v/crypto/rsa/rsa_ameth.c 2023-08-01 15:51:35.0 +0200
+++ openssl-1.1.1w/crypto/rsa/rsa_ameth.c 2023-09-11 16:08:11.0 +0200
@@ -1,5 +1,5 @@
/*
- * Copyright 2006-2020 The OpenSSL Project Authors. All Rights Reserved.
+ * Copyright 2006-2023 The OpenSSL Project Authors. All Rights Reserved.
*
* Licensed under the OpenSSL license (the "License"). You may not use
* this file except in compliance with the License. You can obtain a copy
@@ -82,13 +82,16 @@
if (!rsa_param_encode(pkey, , ))
return 0;
penclen = i2d_RSAPublicKey(pkey->pkey.rsa, );
-if (penclen <= 0)
+if (penclen <= 0) {
+ASN1_STRING_free(str);
return 0;
+}
if (X509_PUBKEY_set0_param(pk, OBJ_nid2obj(pkey->ameth->pkey_id),
strtype, str, penc, penclen))
return 1;
OPENSSL_free(penc);
+ASN1_STRING_free(str);
return 0;
}
diff -Nru openssl-1.1.1v/debian/changelog openssl-1.1.1w/debian/changelog
--- openssl-1.1.1v/debian/changelog 2023-08-26 13:17:12.0 +0200
+++ openssl-1.1.1w/debian/changelog 2023-09-13 21:21:33.0 +0200
@@ -1,3 +1,9 @@
+openssl (1.1.1w-0~deb11u1) bullseye; urgency=medium
+
+ * Import 1.1.1w
+
+ -- Sebastian Andrzej Siewior Wed, 13 Sep 2023 21:21:33 +0200
+
openssl (1.1.1v-0~deb11u1) bullseye; urgency=medium
* Import 1.1.1v
diff -Nru openssl-1.1.1v/doc/man3/CMS_sign.pod openssl-1.1.1w/doc/man3/CMS_sign.pod
--- openssl-1.1.1v/doc/man3/CMS_sign.pod 2023-08-01 15:51:35.0 +0200
+++ openssl-1.1.1w/doc/man3/CMS_sign.pod 2023-09-11 16:08:11.0 +0200
@@ -95,7 +95,7 @@
suitable for many purposes. For finer control of the output format the
B, B and B parameters can all be B and the
B flag set. Then one or more signers can be added using the
-function CMS_sign_add1_signer(), non default digests can be used and custom
+function CMS_add1_signer(), non default digests can be used and custom
attributes added. CMS_final() must then be called to finalize the
structure if streaming is not enabled.
@@ -119,7 +119,7 @@
=head1 COPYRIGHT
-Copyright 2008-2016 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2008-2023 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the OpenSSL license (the "License"). You may not use
this file except in compliance with the License. You can obtain a copy
diff -Nru openssl-1.1.1v/include/openssl/opensslv.h openssl-1.1.1w/include/openssl/opensslv.h
--- openssl-1.1.1v/include/openssl/opensslv.h 2023-08-01 15:51:35.0 +0200
+++ openssl-1.1.1w/include/openssl/opensslv.h 2023-09-11 16:08:11.0 +0200
@@ -39,8 +39,8 @@
* (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
* major minor fix final patch/beta)
*/
-# define OPENSSL_VERSION_NUMBER 0x1010116fL
-# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.1v 1 Aug 2023"
+# define OPENSSL_VERSION_NUMBER 0x1010117fL
+# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.1w 11 Sep 2023"
/*-
* The macros below are to be used for shared library (.so, .dll, ...)
diff -Nru openssl-1.1.1v/NEWS openssl-1.1.1w/NEWS
--- openssl-1.1.1v/NEWS 2023-08-01 15:51:35.0 +0200
+++ openssl-1.1.1w/NEWS 2023-09-11 16:08:11.0 +0200
@@ -5,6 +5,11 @@
This file gives a brief overview of the major changes between each OpenSSL
release. For more details please read the CHANGES file.
+ Major changes between OpenSSL 1.1.1v and OpenSSL 1.1.1w [11 Sep 2023]
+
+ o Fix POLY1305 MAC implementation corrupting XMM registers on Windows
+(CVE-2023-4807)
+
Major changes between OpenSSL 1.1.1u and OpenSSL 1.1.1v [1 Aug 2023]
o Fix excessive time spent checking DH q parameter value (CVE-2023-3817)
diff -Nru openssl-1.1.1v/README openssl-1.1.1w/README
--- openssl-1.1.1v/README 2023-08-01 15:51:35.0 +0200
+++ openssl-1.1.1w/README 2023-09-11 16:08:11
Bug#1050639: bookworm-pu: package clamav/1.0.2+dfsg-1~deb12u1
On 2023-09-13 17:26:46 [+0100], Adam D. Barratt wrote: > How does this sound for an SUA? > > === > Package : clamav > Version : 1.0.3+dfsg-1~deb12u1 [bookworm] >0.103.10+dfsg-0+deb11u1 [bullseye] > Importance : medium > > ClamAV is an AntiVirus toolkit for Unix. > > Upstream published versions 1.0.3 and 0.103.10. > > This is a bug-fix release and an upstream LTS release. The changes are not > currently required for operation, but upstream strongly recommends that users > update. > > Changes since 1.0.1 and 0.103.8 currently in bookworm and bullseye include > fixes for a security issue: > > CVE-2023-20197: Possible denial of service vulnerability in the HFS+ > file parser. > > The update for bookworm also includes a fix for a second security issue: > > CVE-2023-20212: Possible denial of service vulnerability in the AutoIt > module. > > If you use clamav, we recommend that you install this update. > === > > I'm not entirely happy with the CVE section, but not sure how else to > present it, given that both updates fix one issue but aiui the second > only applies to bookworm. This sounds entirely fine to me. I don't think that it is needed to point out that bullseye is not affected by the second issue. There is also this thing regarding libclamunrar and the update to v6.2.10 of the bundled libbrary. I *think* it is related to CVE-2023-40477. Since unrar itself is only in -pu I think it is okay for libclamunar to follow the same fate. > Regards, > > Adam Sebastian
Bug#1051795: m2crypto: Fails testsuite with OpenSSL 3.1
Package: m2crypto
Version: 0.38.0-4
Severity: important
Control: affects -1 + src:openssl
Control: tags -1 + upstream patch fixed-upstream
Hi,
As far as I can tell, m2crypto compiles and passes the testsuite if
compiled and run against openssl 3.0 or 3.1. What currently fails is if
m2crypto is compiled against 3.0 adn the testsuite run against 3.1. This
can be seen
https://release.debian.org/britney/pseudo-excuses-experimental.html
https://ci.debian.net/data/autopkgtest/unstable/amd64/m/m2crypto/37743405/log.gz
I did a little testing and noticed that upstream already took care of
this with commit
957df43e0e16e ("OpenSSL changed error message yet again.")
https://gitlab.com/m2crypto/m2crypto/-/commit/957df43e0e16e6649bf4834c21ae63d0a80d9095
I can confirm that this change fixes the problem.
The commit in question is part of m2crypto 0.39.0. Could you please
upload m2crypto 0.39.0? :)
Sebastian
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On 2023-09-12 15:43:34 [+0200], Daniel Kiper wrote: > Hey, Hi, > Adding Lidong... > > Sebastian, Lidong is working on a fix for this issue. ach great. > Lidong, please keep Sebastain in the loop. > > Daniel Sebastian
Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875
Hi Antonio! On 2023-09-10 15:57:58 [+0200], Antonio Radici wrote: > On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote: > > Hi Antonio, > > > > FWIW, I have done the bookworm-security upload already to > > security-master, and still working on the bullseye-security one (with > > plan to release the DSA tonight ideally). > > Ack, thanks for the update, I assume this was a particularly serious issue > that > had to be handled immediately! I pinged Salvatore on IRC about this and he was working on stable/old-stable fix of the version at the time. So I suggest to help out and prepare latest upstream from upstream for unstable (which was in opinion only fixes). Unfortunately I saw your reply to the bug after performing the update. I'm sorry if I overstepped here. In the meantime I prepared a pull on salsa for the changes I made. As a matter of fact, I noticed that I somehow missed the latest changelog from the package which I noticed while I tried to open the pull request. After looking at it again, it looks like I just missed the changelog entry. Once again, I'm sorry for any trouble I may have caused. Sebastian
Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875
On 2023-09-10 15:57:13 [+0200], Antonio Radici wrote: Hi Antonio, > On Sun, Sep 10, 2023 at 01:47:30PM +0200, Salvatore Bonaccorso wrote: > > Hi Antonio, > > > > On Sun, Sep 10, 2023 at 01:24:10PM +0200, Antonio Radici wrote: > > > On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote: > > > > Thanks for raising this, I'm uploading the new packages with the fixes > > > > today. > > > > > > apparently someone else did a NMU with the new version and incorrectly > > > closed > > > the bug. > > > > You mean the NMU by Sebastian? > > Yes The new version addressed the CVEs so closing the bug isn't incorrect? > > > > > I reopened the bug because stable needs to be addressed (which I will do > > > today > > > as I just wrote) and then it's probably worth investigating how to > > > integrate > > > those NMU into the git repo > > > > Actually you do not need to reopen. A bug can be closed with mutliple > > versions, that is 2.2.12-0.1 closes it, but as well so does then the > > 2.2.9-1+deb12u1 upload and the 2.0.5-4.1+deb11u3 one. > > > > I think that was not the case several years ago, but nowdays BTS can > > handle that, and will reflect it nicely as well in the version graph. > > > > Or were you meaning something different? > > Ah ok good, then I will add the extra versions if they are not there already Right, here is an example for the bug closed in stable, and experimental. https://bugs.debian.org/1034720 Sebastian
Bug#1050639: bookworm-pu: package clamav/1.0.2+dfsg-1~deb12u1
On 2023-08-27 13:20:01 [+0200], To sub...@bugs.debian.org wrote:
> Package: release.debian.org
> Control: affects -1 + src:clamav
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: bookworm
> Severity: normal
This is a quick update that I updated to 1.0.3+dfsg-1~deb12u1 as of
today. The diff mostly a version update. I additionally removed a log
line from freshclam which logged harmless 304 "not modified" requests.
This line was added in 1.0.0 and people complained, it got in as of
1.0.0 and is already removed in 1.1.x and later.
The main reason for 1.0.3 was the unrar update and I updated so clamav
does not complain about the lower version.
It would be nice if this could be made available via d/updates.
Sebastian
diff -Nru clamav-1.0.2+dfsg/CMakeLists.txt clamav-1.0.3+dfsg/CMakeLists.txt
--- clamav-1.0.2+dfsg/CMakeLists.txt 2023-08-16 00:24:07.0 +0200
+++ clamav-1.0.3+dfsg/CMakeLists.txt 2023-08-25 23:18:34.0 +0200
@@ -22,7 +22,7 @@
set(VERSION_SUFFIX "")
project( ClamAV
- VERSION "1.0.2"
+ VERSION "1.0.3"
DESCRIPTION "ClamAV open source email, web, and end-point anti-virus toolkit." )
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
diff -Nru clamav-1.0.2+dfsg/debian/changelog clamav-1.0.3+dfsg/debian/changelog
--- clamav-1.0.2+dfsg/debian/changelog 2023-08-27 11:35:11.0 +0200
+++ clamav-1.0.3+dfsg/debian/changelog 2023-09-09 16:36:13.0 +0200
@@ -1,3 +1,10 @@
+clamav (1.0.3+dfsg-1~deb12u1) bookworm; urgency=medium
+
+ * Import 1.0.3
+ * Remove unnecessary warning messages in freshclam during update.
+
+ -- Sebastian Andrzej Siewior Sat, 09 Sep 2023 16:36:13 +0200
+
clamav (1.0.2+dfsg-1~deb12u1) bookworm; urgency=medium
* Import 1.0.2 (Closes: #1050057)
diff -Nru clamav-1.0.2+dfsg/debian/.git-dpm clamav-1.0.3+dfsg/debian/.git-dpm
--- clamav-1.0.2+dfsg/debian/.git-dpm 2023-08-27 11:35:11.0 +0200
+++ clamav-1.0.3+dfsg/debian/.git-dpm 2023-09-09 16:35:33.0 +0200
@@ -1,8 +1,8 @@
# see git-dpm(1) from git-dpm package
-de9cef7ab6e5a57247f9598340a0e64869429870
-de9cef7ab6e5a57247f9598340a0e64869429870
-7b4b490a9f8c93c9ef66c8d34be648796dd9f7bd
-7b4b490a9f8c93c9ef66c8d34be648796dd9f7bd
-clamav_1.0.2+dfsg.orig.tar.xz
-c845d2c777adda943e7421c601924e1bee1864a8
-14134372
+b6798c1c1c1bd4e43f1ffbc36748adb5cf07787a
+b6798c1c1c1bd4e43f1ffbc36748adb5cf07787a
+6aeff1ef1ff425a1a201d8e3f2c5b8b1f8a60fdb
+6aeff1ef1ff425a1a201d8e3f2c5b8b1f8a60fdb
+clamav_1.0.3+dfsg.orig.tar.xz
+329456b2e5930a422859b00ed0e08cc8ab53e2b3
+14191252
diff -Nru clamav-1.0.2+dfsg/debian/libclamav11.symbols clamav-1.0.3+dfsg/debian/libclamav11.symbols
--- clamav-1.0.2+dfsg/debian/libclamav11.symbols 2023-08-27 11:35:11.0 +0200
+++ clamav-1.0.3+dfsg/debian/libclamav11.symbols 2023-09-09 16:36:13.0 +0200
@@ -1,25 +1,25 @@
libclamav.so.11 libclamav11 #MINVER#
* Build-Depends-Package: libclamav-dev
- CLAMAV_PRIVATE@CLAMAV_PRIVATE 1.0.2
+ CLAMAV_PRIVATE@CLAMAV_PRIVATE 1.0.3
CLAMAV_PUBLIC@CLAMAV_PUBLIC 1.0.0
- __cli_strcasestr@CLAMAV_PRIVATE 1.0.2
- __cli_strndup@CLAMAV_PRIVATE 1.0.2
- __cli_strnlen@CLAMAV_PRIVATE 1.0.2
- __cli_strnstr@CLAMAV_PRIVATE 1.0.2
- base64Flush@CLAMAV_PRIVATE 1.0.2
- blobAddData@CLAMAV_PRIVATE 1.0.2
- blobCreate@CLAMAV_PRIVATE 1.0.2
- blobDestroy@CLAMAV_PRIVATE 1.0.2
- cl_ASN1_GetTimeT@CLAMAV_PRIVATE 1.0.2
+ __cli_strcasestr@CLAMAV_PRIVATE 1.0.3
+ __cli_strndup@CLAMAV_PRIVATE 1.0.3
+ __cli_strnlen@CLAMAV_PRIVATE 1.0.3
+ __cli_strnstr@CLAMAV_PRIVATE 1.0.3
+ base64Flush@CLAMAV_PRIVATE 1.0.3
+ blobAddData@CLAMAV_PRIVATE 1.0.3
+ blobCreate@CLAMAV_PRIVATE 1.0.3
+ blobDestroy@CLAMAV_PRIVATE 1.0.3
+ cl_ASN1_GetTimeT@CLAMAV_PRIVATE 1.0.3
cl_always_gen_section_hash@CLAMAV_PUBLIC 1.0.0
- cl_base64_decode@CLAMAV_PRIVATE 1.0.2
- cl_base64_encode@CLAMAV_PRIVATE 1.0.2
- cl_cleanup_crypto@CLAMAV_PRIVATE 1.0.2
+ cl_base64_decode@CLAMAV_PRIVATE 1.0.3
+ cl_base64_encode@CLAMAV_PRIVATE 1.0.3
+ cl_cleanup_crypto@CLAMAV_PRIVATE 1.0.3
cl_countsigs@CLAMAV_PUBLIC 1.0.0
cl_cvdfree@CLAMAV_PUBLIC 1.0.0
cl_cvdhead@CLAMAV_PUBLIC 1.0.0
cl_cvdparse@CLAMAV_PUBLIC 1.0.0
- cl_cvdunpack@CLAMAV_PRIVATE 1.0.2
+ cl_cvdunpack@CLAMAV_PRIVATE 1.0.3
cl_cvdverify@CLAMAV_PUBLIC 1.0.0
cl_debug@CLAMAV_PUBLIC 1.0.0
cl_engine_addref@CLAMAV_PUBLIC 1.0.0
@@ -28,7 +28,7 @@
cl_engine_get_num@CLAMAV_PUBLIC 1.0.0
cl_engine_get_str@CLAMAV_PUBLIC 1.0.0
cl_engine_new@CLAMAV_PUBLIC 1.0.0
- cl_engine_set_clcb_engine_compile_progress@CLAMAV_PRIVATE 1.0.2
+ cl_engine_set_clcb_engine_compile_progress@CLAMAV_PRIVATE 1.0.3
cl_engine_set_clcb_file_inspection@CLAMAV_PUBLIC 1.0.0
cl_engine_set_clcb_file_props@CLAMAV_PUBLIC 1.0.0
cl_engine_set_clcb_hash@CLAMAV_PUBLIC 1.0.0
@@ -37,7 +37,7 @@
cl_engine_set_clcb_pre_cache@CLAMAV_PUBLIC 1.0.0
cl_engine_set_clcb_pre_scan@CLAMAV_PUBLIC 1.0.0
cl_engine_set_clcb_sigload@
Bug#1050638: bullseye-pu: package clamav/0.103.9+dfsg-0+deb11u1
uot;\`\$]/&/g'`" ac_cs_version="\\ -ClamAV config.status 0.103.9 +ClamAV config.status 0.103.10 configured by $0, generated by GNU Autoconf 2.69, with options \\"\$ac_cs_config\\" diff -Nru clamav-0.103.9+dfsg/configure.ac clamav-0.103.10+dfsg/configure.ac --- clamav-0.103.9+dfsg/configure.ac 2023-08-27 11:44:51.0 +0200 +++ clamav-0.103.10+dfsg/configure.ac 2023-09-09 16:39:23.0 +0200 @@ -22,7 +22,7 @@ dnl For a release change [devel] to the real version [0.xy] dnl also change VERSION below -AC_INIT([ClamAV], [0.103.9], [https://github.com/Cisco-Talos/clamav/issues], [clamav], [https://www.clamav.net/]) +AC_INIT([ClamAV], [0.103.10], [https://github.com/Cisco-Talos/clamav/issues], [clamav], [https://www.clamav.net/]) dnl put configure auxiliary into config AC_CONFIG_AUX_DIR([config]) diff -Nru clamav-0.103.9+dfsg/debian/changelog clamav-0.103.10+dfsg/debian/changelog --- clamav-0.103.9+dfsg/debian/changelog 2023-08-27 11:57:11.0 +0200 +++ clamav-0.103.10+dfsg/debian/changelog 2023-09-09 17:25:07.0 +0200 @@ -1,3 +1,9 @@ +clamav (0.103.10+dfsg-0+deb11u1) bullseye; urgency=medium + + * Import 0.103.10 + + -- Sebastian Andrzej Siewior Sat, 09 Sep 2023 17:25:07 +0200 + clamav (0.103.9+dfsg-0+deb11u1) bullseye; urgency=medium * Import 0.103.9 diff -Nru clamav-0.103.9+dfsg/debian/.git-dpm clamav-0.103.10+dfsg/debian/.git-dpm --- clamav-0.103.9+dfsg/debian/.git-dpm 2023-08-27 11:51:51.0 +0200 +++ clamav-0.103.10+dfsg/debian/.git-dpm 2023-09-09 17:20:39.0 +0200 @@ -1,8 +1,8 @@ # see git-dpm(1) from git-dpm package -399cd45b987e0c25de2d54d23bbe9c043d7a6aad -399cd45b987e0c25de2d54d23bbe9c043d7a6aad -a13348d8210b0066d32493c325eb3f7d7df44fef -a13348d8210b0066d32493c325eb3f7d7df44fef -clamav_0.103.9+dfsg.orig.tar.xz -cad4f441d66f57747575542534b27ac133a1e4b6 -7141568 +db5f3da8cd11befe230cc11e2fbebf61f26416ac +db5f3da8cd11befe230cc11e2fbebf61f26416ac +74e7333802c041f37048b27ce29a2da8c669301c +74e7333802c041f37048b27ce29a2da8c669301c +clamav_0.103.10+dfsg.orig.tar.xz +2a46a0a56992290dfe49774af46db4937c7dccac +7142116 diff -Nru clamav-0.103.9+dfsg/debian/libclamav9.symbols clamav-0.103.10+dfsg/debian/libclamav9.symbols --- clamav-0.103.9+dfsg/debian/libclamav9.symbols 2023-08-27 11:57:11.0 +0200 +++ clamav-0.103.10+dfsg/debian/libclamav9.symbols 2023-09-09 17:25:07.0 +0200 @@ -1,20 +1,20 @@ libclamav.so.9 libclamav9 #MINVER# * Build-Depends-Package: libclamav-dev - CLAMAV_PRIVATE@CLAMAV_PRIVATE 0.103.9 + CLAMAV_PRIVATE@CLAMAV_PRIVATE 0.103.10 CLAMAV_PUBLIC@CLAMAV_PUBLIC 0.101.0 - __cli_strcasestr@CLAMAV_PRIVATE 0.103.9 - __cli_strndup@CLAMAV_PRIVATE 0.103.9 - __cli_strnlen@CLAMAV_PRIVATE 0.103.9 - __cli_strnstr@CLAMAV_PRIVATE 0.103.9 - base64Flush@CLAMAV_PRIVATE 0.103.9 - blobAddData@CLAMAV_PRIVATE 0.103.9 - blobCreate@CLAMAV_PRIVATE 0.103.9 - blobDestroy@CLAMAV_PRIVATE 0.103.9 - cl_ASN1_GetTimeT@CLAMAV_PRIVATE 0.103.9 + __cli_strcasestr@CLAMAV_PRIVATE 0.103.10 + __cli_strndup@CLAMAV_PRIVATE 0.103.10 + __cli_strnlen@CLAMAV_PRIVATE 0.103.10 + __cli_strnstr@CLAMAV_PRIVATE 0.103.10 + base64Flush@CLAMAV_PRIVATE 0.103.10 + blobAddData@CLAMAV_PRIVATE 0.103.10 + blobCreate@CLAMAV_PRIVATE 0.103.10 + blobDestroy@CLAMAV_PRIVATE 0.103.10 + cl_ASN1_GetTimeT@CLAMAV_PRIVATE 0.103.10 cl_always_gen_section_hash@CLAMAV_PUBLIC 0.101.0 - cl_base64_decode@CLAMAV_PRIVATE 0.103.9 - cl_base64_encode@CLAMAV_PRIVATE 0.103.9 - cl_cleanup_crypto@CLAMAV_PRIVATE 0.103.9 + cl_base64_decode@CLAMAV_PRIVATE 0.103.10 + cl_base64_encode@CLAMAV_PRIVATE 0.103.10 + cl_cleanup_crypto@CLAMAV_PRIVATE 0.103.10 cl_countsigs@CLAMAV_PUBLIC 0.101.0 cl_cvdfree@CLAMAV_PUBLIC 0.101.0 cl_cvdhead@CLAMAV_PUBLIC 0.101.0 @@ -54,19 +54,19 @@ cl_fmap_close@CLAMAV_PUBLIC 0.101.0 cl_fmap_open_handle@CLAMAV_PUBLIC 0.101.0 cl_fmap_open_memory@CLAMAV_PUBLIC 0.101.0 - cl_get_pkey_file@CLAMAV_PRIVATE 0.103.9 - cl_get_x509_from_mem@CLAMAV_PRIVATE 0.103.9 - cl_hash_data@CLAMAV_PRIVATE 0.103.9 + cl_get_pkey_file@CLAMAV_PRIVATE 0.103.10 + cl_get_x509_from_mem@CLAMAV_PRIVATE 0.103.10 + cl_hash_data@CLAMAV_PRIVATE 0.103.10 cl_hash_destroy@CLAMAV_PUBLIC 0.101.0 - cl_hash_file_fd@CLAMAV_PRIVATE 0.103.9 - cl_hash_file_fd_ctx@CLAMAV_PRIVATE 0.103.9 - cl_hash_file_fp@CLAMAV_PRIVATE 0.103.9 + cl_hash_file_fd@CLAMAV_PRIVATE 0.103.10 + cl_hash_file_fd_ctx@CLAMAV_PRIVATE 0.103.10 + cl_hash_file_fp@CLAMAV_PRIVATE 0.103.10 cl_hash_init@CLAMAV_PUBLIC 0.101.0 cl_init@CLAMAV_PUBLIC 0.101.0 - cl_initialize_crypto@CLAMAV_PRIVATE 0.103.9 + cl_initialize_crypto@CLAMAV_PRIVATE 0.103.10 cl_load@CLAMAV_PUBLIC 0.101.0 - cl_load_cert@CLAMAV_PRIVATE 0.103.9 - cl_load_crl@CLAMAV_PRIVATE 0.103.9 + cl_load_cert@CLAMAV_PRIVATE 0.103.10 + cl_load_crl@CLAMAV_PRIVATE 0.103.10 cl_retdbdir@CLAMAV_PUBLIC 0.101.0 cl_retflevel@CLAMAV_PUBLIC 0.103.8 cl_retver@CLAMAV_PUBLIC 0.101.0 @@ -76,196 +76,196 @@ cl_scanfile_callback@CLAMAV_PUBLIC 0.101.0 cl_scanmap_callback@CLAMAV_PUBLIC
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
Package: grub2
Version: 2.12~rc1-9
Severity: Serious
control: forwarded -1 https://savannah.gnu.org/bugs/?64376
I have a single XFS partition which contains the root filesystem and the
boot partition. Since the recent upgrade to the 2.12 series I can't boot
anymore because grub complains that it can't find normal.mod and remains in
the rescue shell.
The ls command kind of works. A ls in /boot/grub/i386-pc/ (where the
normal.mod should be) shows a few files and then abort with the error
message: 'error: invalid XFS directory entry'.
I figured out that if I remove that directory and create a new one only
with normal.mod then it was able to find it and complained about onother file.
I then repeated the game until I had more files… The invocation of grub-install
copied all files and broke it again.
I then looked at various places and stumbled uppon
https://savannah.gnu.org/bugs/?64376 and this indeed matches what I see.
I rebuilt the grub2 package with commit ef7850c757fb3 ("fs/xfs: Fix
issues found while fuzzing the XFS filesystem") reverted, installed from
a rescue system and voila it boots again.
My xfs filesystem is a normal v5 as in:
| # xfs_info /dev/sdb1
| meta-data=/dev/sdb1 isize=512agcount=4, agsize=655360 blks
| = sectsz=512 attr=2, projid32bit=1
| = crc=1finobt=1, sparse=1, rmapbt=1
| = reflink=1bigtime=0 inobtcount=0 nrext64=0
| data = bsize=4096 blocks=2621440, imaxpct=25
| = sunit=0 swidth=0 blks
| naming =version 2 bsize=4096 ascii-ci=0, ftype=1
| log =internal log bsize=4096 blocks=3693, version=2
| = sectsz=512 sunit=0 blks, lazy-count=1
| realtime =none extsz=4096 blocks=0, rtextents=0
Sebastian
Bug#1050638: bullseye-pu: package clamav/0.103.9+dfsg-0+deb11u1
On 2023-09-04 21:18:35 [+0200], To Adam D. Barratt wrote: > > The next point release for both bullseye and bookworm is in a month. > > Were you looking to have the clamav updates published via -updates > > before that point? > > I almost started preparing 0.103.10 I think it will be easier to go with > that one instead… So I managed to prepare the libclamunrar bits. The clamav diff 9 .. 10 is only the update update of the unrar bits (same for Bookworm version). Regardless of this zero diff of the clamav bits I'm going to prepare a new version anyway because I *think* people will complain because will point out the outdated version… However not today but tomorrow is also a day… > > Regards, > > > > Adam Sebastian
Bug#1050573: bullseye-pu: package openssl/1.1.1v-0~deb11u1
On 2023-08-26 14:50:09 [+0200], To sub...@bugs.debian.org wrote: > This is an update of the openssl package to the 1.1.1v version, a patch > release Upstream announced to release 1.1.1w on 11th September. They said it is a "security-fix" with the highest severity defined as "low". This is also the case for the current two CVEs. Therefore I assume that they don't have to be fixed asap (i.e. via -security). Also it will be the last 1.1.1 release since it will reach EOL on the 11th. I will prepare an update… The upstream announcement: https://mta.openssl.org/pipermail/openssl-announce/2023-September/000271.html: Sebastian
Bug#1051084: bookworm-pu: package kernelshark/2.2.1-1~deb12u1
On 2023-09-05 17:36:41 [+0100], Jonathan Wiltshire wrote: > > Please go ahead. Thanks, done. > Thanks, Sebastian
