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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1031896: [Pkg-clamav-devel] Bug#1031896: Bug#1031896: Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
On 25 February 2023 16:20:45 UTC, Scott Kitterman wrote: >True. > >I'm not a C programmer, so I may be unduly concerned about the maintenance >load. I'll defer to your judgement. I'm going to throw this on my machine to get more testing - more than just the test suite. What about going through NEW with tfm? I would make it provide libtfm1-4k and clamav would need a binnmu to pick up the change. > >I do wonder if we should make a stab at switching the rust bits to using >Debian packages instead of the embedded copies. If we could manage it, then >any security issues in the rust libraries can be fixed in clamav with a >binNMU, no upload needed. That sounds good. I need to educate myself about rust to figure out how that works. Right now it is all magic. I just hope that they did not adapt any packages to their needs and that they don't rely on a newer version of something than what we have in the archive. > >Scott K -- Sebastian
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
On 25 February 2023 14:57:28 UTC, Scott Kitterman wrote: >Generally favorably, but I'd rather wait for upstream to agree on it, >otherwise it may be a patch we have to maintain forever. Now we maintain the tfm bits. >What's their reaction to the change? No reply so far. The first few patches from early January got the response "it was a chaotic week, we get to it soon" and the tfm patch got no response since I posted it last week. Maybe you need to walk around their office and throw a stone with pull request number written on it :-) > >It's also late in the release cycle to do it (not definitely a problem, but >calls for caution). > >Scott K -- Sebastian
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
On 2023-02-24 21:00:43 [+], Scott Kitterman wrote: > I don't know of anything. I'd go ahead and upload the fix. how do you feel about replacing libtfm with openssl? > Scott K Sebastian
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
On 2023-02-24 12:44:49 [-0800], Nye Liu wrote: > On Fri, Feb 24, 2023 at 09:39:03PM +0100, Sebastian Andrzej Siewior wrote: > > Can you re-install libtfm1 and ensure that both point to that lib? > > libtfm1 0.13-4.1 fixed the problem. Should probably be version bumped in the > pkg dependency, 0.13.1-1 seems broken. Why did I say that you version looks since it clearly did not. Hmm. This may break upgrades as it seems. Scott? Just this tiny change or do we have something else pending? Sebastian
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
On 2023-02-24 12:21:48 [-0800], Nye Liu wrote: > Feb 24 12:19:44 ln clamd[1537504]: LibClamAV debug: in cli_cvdload() > Feb 24 12:19:44 ln clamd[1537504]: LibClamAV debug: MD5(.tar.gz) = > f7eaac9ce4a83cc4c2526fe8f7d669db > Feb 24 12:19:44 ln clamd[1537504]: LibClamAV debug: cli_versig: Decoded > signature: Can you re-install libtfm1 and ensure that both point to that lib? | # ldd /lib/x86_64-linux-gnu/libclamav.so.11 | grep tfm | libtfm.so.1 => /lib/x86_64-linux-gnu/libtfm.so.1 (0x7f2d37989000) | # ldd /usr/sbin/clamd |grep tfm | libtfm.so.1 => /lib/x86_64-linux-gnu/libtfm.so.1 (0x7f2c277a8000) | # grep tfm /proc/clamd_pid/maps | 7f76e6fc6000-7f76e6fc8000 r--p 08:01 8536033 /usr/lib/x86_64-linux-gnu/libtfm.so.1.0.0 | 7f76e6fc8000-7f76e7039000 r-xp 2000 08:01 8536033 /usr/lib/x86_64-linux-gnu/libtfm.so.1.0.0 | 7f76e7039000-7f76e703b000 r--p 00073000 08:01 8536033 /usr/lib/x86_64-linux-gnu/libtfm.so.1.0.0 | 7f76e703b000-7f76e703c000 r--p 00075000 08:01 8536033 /usr/lib/x86_64-linux-gnu/libtfm.so.1.0.0 | 7f76e703c000-7f76e703d000 rw-p 00076000 08:01 8536033 /usr/lib/x86_64-linux-gnu/libtfm.so.1.0.0 That 0…0 in decoded signature looks like badly computed. Sebastian
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
On 2023-02-24 11:22:12 [-0800], Nye Liu wrote: > Tried mirroring working cvds from another machine > > $ md5sum * > 09c62fbb8d2de9cfeca516b3927347ba bytecode.cvd > 7294b378c7bd3bf86314365d96aea3e4 daily.cvd > a7bd2fc1eafcb260e76769a5821cb204 freshclam.dat > 3a42e5027c90fba0e54d2abdaa9e86b4 main.cvd on a production box I have | # md5sum * | 6cfebae5fcddb7b948bc4cd8b0f37601 bytecode.cld | 731d8081d1f1b16bf878629091422717 daily.cld | 0c358509cd3252b93d4d2ce2ad12b7f6 main.cld However on my devel VM I installed it fresh, dowloaded the DB and have also: | 09c62fbb8d2de9cfeca516b3927347ba bytecode.cvd | 7294b378c7bd3bf86314365d96aea3e4 daily.cvd | 3a42e5027c90fba0e54d2abdaa9e86b4 main.cvd and here clamav starts up. > Architecture: amd64 (x86_64) > Foreign Architectures: i386 have this, too. > Kernel: Linux 5.8.3-x86_64-linode137 (SMP w/4 CPU threads; PREEMPT) Is this a debian box or do you have other additions? > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages libclamav11 depends on: > ii libtfm1 0.13-4.1 This looks good, too. You could set Debug true in /etc/clamav/clamav.conf and check what the additionial debug says. Sebastian
Bug#1031509: [Pkg-clamav-devel] Bug#1031509: ETA on Patch for Buster
+LTS On 2023-02-20 12:22:48 [+0200], Andries Malan wrote: > Hi There Hi, > Would you be so kind as to provide an ETA for the above mentioned bug that > was reported. > This would be greatly appreciated. I Cced the LTS team because Buster is LTS territory. > Regards Sebastian
Bug#1031509: [Pkg-clamav-devel] Bug#1031509: clamav: 2 RCE bugs in ClamAV
On 2023-02-18 08:58:57 [+], Laura Smith wrote: > Could you confirm when the Debian Bullseye updates are due to be uploaded ? https://bugs.debian.org/1031536 > Thanks ! Sebastian
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
On 2023-02-10 20:22:54 [+], Thorsten Glaser wrote: > Sebastian Andrzej Siewior dixit: > > >Good. So unless Thorsten disagrees this is done ;) > > Please also test the upgrade with 4.16.0-1~bpo11+1 installed > on bullseye instead of 4.17.0-2~bpo11+1 (since that is a valid > upgrade path), without going via 4.17.0-2~bpo11+1. I would expect that people upgrade to 4.17.0-2~bpo11+1 before going to the next stable. This whole procedure follows then case #9 from https://wiki.debian.org/PackageTransition where manpages-fr is A and xz-utils is B. How is this getting to work without manpages-fr contributing to it? > bye, > //mirabilos Sebastian
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
On 2023-02-10 20:43:01 [+0100], Helge Kreutzmann wrote: > Hello Sebastian, Hi Helge, > From the manpages-l10n side everything is in place, I would then also > properly close #1028233. (Uploads to bpo do not manipulate the BTS). Good. So unless Thorsten disagrees this is done ;) > Greetings > > Helge Sebastian
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
On 2023-02-01 17:59:57 [+], Thorsten Glaser wrote: > > xz-utils (5.4.1-0.1) unstable; urgency=medium > > . > > * Non-maintainer upload. > > * Update pt_BR translations. > > * Add lintian overrides and an override for blhc. > > This is missing the updated Breaks+Replaces for manpages-l10n though. That is correct, I wanted to wait until the bpo packages gets accepted as discussed with Helge. Now with the bpo package accepted I did a test from bullseye -> sid and from the log: | $ grep -E 'manpages-fr|xz-utils' screenlog.0 | dpkg -l manpages-fr xz-utils | ii manpages-fr4.17.0-2~bpo11+1 all French man pages | ii xz-utils 5.2.5-2.1~deb11u1 amd64XZ-format compression utilities | logrotate logsave lsb-base lsb-release lsof mailcap man-db manpages manpages-fr manpages-fr-dev mawk media-types mount nano ncurses-base ncurses-bin ncurses-term netbase | util-linux-locales vim-common vim-tiny wamerican wget whiptail xauth xdg-user-dirs xkb-data xxd xz-utils zlib1g | Get:277 http://httpredir.debian.org/debian sid/main amd64 manpages-fr all 4.17.0-2 [1,926 kB] | Get:278 http://httpredir.debian.org/debian sid/main amd64 xz-utils amd64 5.4.1-0.1 [468 kB] | Get:279 http://httpredir.debian.org/debian sid/main amd64 manpages-fr-dev all 4.17.0-2 [2,489 kB] | dpkg: considering removing manpages-fr in favour of xz-utils ... | dpkg: yes, will remove manpages-fr in favour of xz-utils | Preparing to unpack .../066-xz-utils_5.4.1-0.1_amd64.deb ... | Unpacking xz-utils (5.4.1-0.1) over (5.2.5-2.1~deb11u1) ... | Removing manpages-fr (4.17.0-2~bpo11+1), to allow configuration of xz-utils (5.4.1-0.1) ... | Selecting previously unselected package manpages-fr. | Preparing to unpack .../067-manpages-fr_4.17.0-2_all.deb ... | Unpacking manpages-fr (4.17.0-2) ... | Preparing to unpack .../068-manpages-fr-dev_4.17.0-2_all.deb ... | Unpacking manpages-fr-dev (4.17.0-2) over (4.17.0-2~bpo11+1) ... | Setting up manpages-fr-dev (4.17.0-2) ... | Setting up xz-utils (5.4.1-0.1) ... | Setting up manpages-fr (4.17.0-2) ... So it works as intended. Therefore I would close this bug report. Any disagreement? > bye, > //mirabilos Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 31 January 2023 08:00:23 UTC, Thorsten Glaser wrote: >Sebastian Andrzej Siewior dixit: > >>Then I will update the versions as suggested. My understanding was the >>problem persists because the bpo version was not yet updated. The >>version in sid did not ship the man-pages. > >The bpo version was once in both sid and testing and this >is therefore a problem for people updating incrementally. It is bpo but if you look I'd you look at the files for the same version in bpo and sid you will see that sid skipped a few man pages while bpo created them. > >bye, >//mirabilos -- Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 2023-01-30 21:57:28 [+], Thorsten Glaser wrote: > Sebastian Andrzej Siewior dixit: > > >Okay. So I do nothing and just wait for the bpo package to appear which > >will then solve the problem? > > No, you must fix the problem in xz-utils in bookworm/sid as well. > It also exists outside of backports. Then I will update the versions as suggested. My understanding was the problem persists because the bpo version was not yet updated. The version in sid did not ship the man-pages. > bye, > //mirabilos Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 2023-01-30 21:51:11 [+0100], Helge Kreutzmann wrote: > Hello Sebastian, Hi Helge, > On Mon, Jan 30, 2023 at 07:53:51PM +0100, Sebastian Andrzej Siewior wrote: > > On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote: > > > reopen 1028375 > > > found 1028375 5.4.1-0.0 > > > thanks > > > > > > Patrice Duroux dixit: > > > > > > >Was this supposed to be closed? Or will it be with another manpages-fr > > > >bpo? > > So far the manpages-fr bpo has not yet happend. My sponsor intends to > upload it today and then we need to wait for NEW processing. okay. > > > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) > > > so the upload did not fix the problem. > > > > > > As far as I can tell it must be (<< 4.17.0-1~) instead. > > > (Also do note the tilde, it breaks bpo otherwise.) > > > > Okay. So I add this new suggested version and close 1028375? > > The problem is that we both upload (conflicting) packages to > backports. I'm not sure a good solution exists here. > > If the freeze continues for quite some time, even 4.18.0-1~ might hit > backports. (In the last freeze it was the case.). > > This is rather tricky. Okay. So I do nothing and just wait for the bpo package to appear which will then solve the problem? > Greetings > > Helge Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote: > reopen 1028375 > found 1028375 5.4.1-0.0 > thanks > > Patrice Duroux dixit: > > >Was this supposed to be closed? Or will it be with another manpages-fr bpo? > > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) > so the upload did not fix the problem. > > As far as I can tell it must be (<< 4.17.0-1~) instead. > (Also do note the tilde, it breaks bpo otherwise.) Okay. So I add this new suggested version and close 1028375? > bye, > //mirabilos Sebastian
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
On 2023-01-11 21:01:11 [+0100], To Helge Kreutzmann wrote: > > For your update you should use as version "<< 4.1.0-1". > > (and remember to put it in for both manpages-de and manpages-fr) > > Okay, will do. Just to double check: This is what I did: https://salsa.debian.org/debian/xz-utils/-/commit/6d608a9e56921abbad77f07e9e0fe4bc78e93854 and you say that this is okay, right? I'm just checking that you really meant 4.1.0-1 and not 4.10.0-1. Sebastian
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
On 2023-01-11 21:53:14 [+0100], Helge Kreutzmann wrote: > Hello Sebastian, Hello Helge, > Well, this is not correct. See, e.g., > https://packages.debian.org/bullseye-backports/all/manpages-de/filelist > > The man pages are there. yes, in backports. Not in the "regular" package. > Of course, only those we have (had) in manpages-l10n, but de > definitely. > > We just took our probably final "snapshot". I.e. in the next backport > version, the man page as it was on monday in backports (or stable, if > backports was empty) is used as base. So this will be the final > release in bullseye-backports from our side. > > I don't know what the best solution is here. I see several options, > all not very nice: > > 1. xz-utils does not ship translated man pages in backports. But then >the translated man page is out of sync with the package (it is a >pity that the upload to backports has not been done, already). > > 2. I manually remove the translations in my final backport. Then there >is no file conflict. For this case, please tell me which man pages >I should delete. And the final version shipping it in backports >from my side would be "4.16.0-3~bpo11+1". > >Please tell me which version is the first backport version of your >package containing the translations, and I will set the appropriate >file relationships myself; however, I don't know if all upgrade paths >will work, but we can try. > >With "all upgrade paths" I mean the user can have backports for >either package or none. Okay. Let me get to this and then I will talk to you again once the release team gives an ack. Sebastian
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
On 2023-01-10 09:36:04 [+0100], Helge Kreutzmann wrote: > Hello Sebastian, Hi Helge, > On Mon, Jan 09, 2023 at 09:38:31PM +0100, Sebastian Andrzej Siewior wrote: > Sorry, I was really tired yesterday evening and just wanted to send a > short "ack". no worries. Just warning before I get all the credit ;) > > Oki. That means if I intend to upload xz-utils to Buster with translated > > man-pages than I need to check with you first? > > Let's separate this: > For buster I don't think anyone will care anymore. > > For bookworm: Yes, see: > https://wiki.debian.org/PackageTransition > Case #9: xz-utils is B, manpages-fr / manpages-de is A > > For some reason I did not realize this, it is now prepared for > manpages-l10n for the next release (slated next week, pending > upstream release). I did not create a bug for this (but please > do so, if you think it is necessary). > > For your update you should use as version "<< 4.1.0-1". > (and remember to put it in for both manpages-de and manpages-fr) Okay, will do. > This will note prevent this bug, but see below for this case. However, > it will fix peoples systems not using backports and upgrading from > bullseye to bookworm after release. > > And this also explains why this bug was not seen on our side: During > this time maintainership both for upstream and for the Debian package > transitioned to new persons. And when I got responsible, I simply did > not realise this one was forgotten. > > For bullseye: > Do you want to publish a backport for xz-utils? Then it gets > complicated. I planned to upload the latest v5.2.X release to bullseye. Code wise it contains only fixes. Feature wise it contains more translations. There is a bug open in xz-utils that the man-page for xz vanished in xz-utils. It was provided by manpages-de but the release in Bullseye does not have it. The release team does not know about it and I have no idea if they allow so I'm checking with you first before i collides somehow with manpages-fr ;) > > > Technically, we treat debian-unstable and debian-backport as if they > > > were two different distributions (say arch and fedora). > > > > > > What got lost (and I will investigate this later this week, maybe > > > tomorrow) are the correct package relations. I have a vague idea, but > > > I will check. And the next upload (including the one to bpo) will have > > > the correct ones. > > > > Since "recently" xz provides translated man-pages and sid is not > > affected. My understaning is that the bpo version of man-pages gets a > > breaks statement against xz. If so that would >= 5.2.7. > > Should I reassing the bug to manpages-l10n or do you do it yourself? > > Will be done, see above. And given that upstream got the translated man > pages in April 2020, I understand the quotes around "recently". > > From your changelog I gathered the version "(<< 5.3.3alpha-0.0)". The man-pages started to appear in 5.2.7 which I uploaded to unstable at the time. It was later superseded by the 5.3-beta series which become 5.4 (non-beta) and was cooked at the same time in experimental. … > As a side note: > We have man page translations for several other languages as well. > Over time, they will disappear, so I suggest to move them to xz-utils > as well. I can send the po files to you and inform the translators > about this, if you want. Then you can include them in your next upload > (to fix bug "-1") as well. I would forward them to upstream if there is anything. Right now there are man pages in ro/de/fr. > Greetings > >Helge > Sebastian
Bug#1022336: xz-utils: FTBFS: Can't exec "cmake": No such file or directory at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 526.
On 2022-10-23 15:12:35 [+0200], Lucas Nussbaum wrote: > Relevant part (hopefully): > > debian/rules build > > dh build --parallel > > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) > >dh_update_autotools_config -O--parallel > >dh_auto_configure -O--parallel > > dh_auto_configure: warning: Compatibility levels before 10 are deprecated > > (level 9 in use) > > cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr > > -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc > > -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON > > -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF > > -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON > > -DFETCHCONTENT_FULLY_DISCONNECTED=ON "-GUnix Makefiles" > > -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. > > Can't exec "cmake": No such file or directory at > > /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 526. It autodetects cmake but shouldn't. It built fine a few days ago, not sure what changed. Aynway, I'm going to fix the hurd build and this, too. Sebastian
Bug#1020592: [Pkg-javascript-devel] Bug#1020592: nodejs: Testsuite is using smoil keys
On 23 September 2022 21:18:26 UTC, "Jérémy Lal" wrote: >I'll upload nodejs 18.9.1 this week-end, along with a/your fix for that >issue. Thank you. > >Jérémy -- Sebastian
Bug#1020592: [Pkg-javascript-devel] Bug#1020592: nodejs: Testsuite is using smoil keys
control: found -1 odejs/18.7.0+dfsg-5 On 2022-09-23 22:55:23 [+0200], Jérémy Lal wrote: > Thanks, I'm already aware of the need to run nodejs testsuite using > their own specific openssl.cnf. > It seems you are reporting a bug against a version of nodejs that has never > made it > to debian. Did you mean to report to ubuntu or some other distribution > instead ? > If that's the case please close this bug and open a new one at the right > place. Ehm. It seems I forgot a 1 while copy paste. The current openssl version in unstable is blocked due that reason: | autopkgtest for nodejs/18.7.0+dfsg-5: amd64: Regression so I think I am at the right place ;) > Thanks, > Jérémy Sebastian
Bug#1020592: nodejs: Testsuite is using smoil keys
Package: nodejs Version: 8.7.0+dfsg-5 Severity: serious control: tags -1 patch The last OpenSSL upload moved the default security level from the openssl.cnf file to build-time default so I don't have to fiddle with the config file anymore. Unfortunately nodejs is using smoil keys in its testsuite so the testsuite fails now. Previously it didn't because it used the "default" openssl.cnf which did not specify any of this so the security level was never changed from its default - 1. Now it is 2 and nodejs needs either to increase the default key size or lower security level via the config file. A patch for the latter has been attached. Sebastian From: Sebastian Andrzej Siewior Date: Fri, 23 Sep 2022 22:39:50 +0200 Subject: [PATCH] Add a CipherString for nodejs If the default security level is overwritten at build time of openssl then it is needed to lower it again for nodejs in order to pass the testsuite because it is using smoil keys. Signed-off-by: Sebastian Andrzej Siewior --- deps/openssl/openssl/apps/openssl.cnf | 10 ++ 1 file changed, 10 insertions(+) diff --git a/deps/openssl/openssl/apps/openssl.cnf b/deps/openssl/openssl/apps/openssl.cnf index 03330e0120a2..65ae201e44aa 100644 --- a/deps/openssl/openssl/apps/openssl.cnf +++ b/deps/openssl/openssl/apps/openssl.cnf @@ -15,6 +15,7 @@ HOME = . # Use this in order to automatically load providers. openssl_conf = openssl_init +nodejs_conf = nodejs_init # Comment out the next line to ignore configuration errors config_diagnostics = 1 @@ -388,3 +389,12 @@ oldcert = $insta::certout # insta.cert.pem # Certificate revocation cmd = rr oldcert = $insta::certout # insta.cert.pem + +[nodejs_init] +ssl_conf = ssl_sect + +[ssl_sect] +system_default = system_default_sect + +[system_default_sect] +CipherString = DEFAULT:@SECLEVEL=1 -- 2.37.2
Bug#1020308: openssl: Test 90-test_threads.t fails randomly.
Package: openssl Version: 3.0.5-3 Severity: serious control: forwarded -1 https://github.com/openssl/openssl/issues/19243 After touching test/default.cnf in the last upload, the 90-test_threads.t test fails randomly on the last step (test_lib_ctx_load_config()). Sometimes "malloc(): unaligned tcache chunk detected" is visible. On amd64 it just segfaulted on the buildd, the retry succeeded. Sebastian
Bug#1017637: havp: Not working anymore since linux-image-* v5.15.
On 2022-08-18 19:36:28 [+], Scott Kitterman wrote: Hi Scott, > I agree. It's been dead upstream for a long time. I think this is a > logical point to put an end to trying to keep it alive in Debian. nice to hear from you! Sorry for not replying earlier but I'm kind of busy… Anyway, I managed to fill a RM bug for this. > Scott K Sebastian
Bug#1017637: havp: Not working anymore since linux-image-* v5.15.
Source: havp Version: 0.93-2 Severity: grave While testing havp before uploading I noticed that starting havp ends quickly with: | Starting HAVP Version: 0.93 | Filesystem not supporting mandatory locks! | On Linux, you need to mount filesystem with "-o mand" The so called "mandatory locks" have been removed from the Linux kernel in v5.15 [0]. havp is compiled to use it and fails to continue if it is not working. We have to options now: - Remove havp from unstable. - Pass --disable-locking to configure and build it without it. This forces havp to download everything scan it first. I'm not a user of havp so I can't tell if disabling locking is an option. There is a script with loopback mount and everything just to use the locking without enabling it on the main partition. The first 5.15 kernel was uploaded by the end of 2021 and this went unnoticed until now. Probably even longer if it wasn't for #1016270. Given that and the dropping popcon numbers, I lean towards RM. Anyone? [0] https://git.kernel.org/torvalds/c/f7e33bdbd6d1bdf9c3df8bba5abcf3399f957ac3 Sebastian
Bug#1016290: openssl: EC code appears to be broken on s390x
Package: openssl Version: 3.0.5-1 Severity: serious Control: forward -1 https://github.com/openssl/openssl/issues/18912 Control: affects -1 libnet-dns-sec-perl It appears the EC code is broken for ed25519/ed448 on s390x. Sebastian
Bug#1011101: nodejs: FTBFS on mipsel: multiple failures with openssl 3.0
On 2022-05-16 22:38:44 [+0200], Jérémy Lal wrote: > Last time so many openssl-related test failures happened, > OPENSSL_CONF env was set to a relative path, and nodejs/openssl3 > expected an absolute path. I don't understand why mipsel is different here. The init looks okay. I copied the .cnf from 3.0 cp /etc/ssl/openssl.cnf deps/openssl/openssl/apps/openssl.cnf and then removed the protocol/ sec-level override: --- /etc/ssl/openssl.cnf2022-05-13 21:25:01.0 + +++ deps/openssl/openssl/apps/openssl.cnf 2022-05-25 20:58:47.602964293 + @@ -52,7 +52,6 @@ [openssl_init] providers = provider_sect -ssl_conf = ssl_sect # List of providers to load [provider_sect] @@ -389,10 +388,3 @@ # Certificate revocation cmd = rr oldcert = $insta::certout # insta.cert.pem - -[ssl_sect] -system_default = system_default_sect - -[system_default_sect] -MinProtocol = TLSv1.2 -CipherString = DEFAULT:@SECLEVEL=2 with this change the suite passed on mipsel. You could move that file to debian/ for the testsuite and I keep thinking about not touching that file at all. I could keep investigating why mipsel is different here but I'm short on time right now and eller isn't exactly a fast beast. Side note: I built it with -j3 and I hope that the build time reduced compared to the initial -j1 (I had to build a few times because -nc didn't skip anything…). Sebastian
Bug#1006585: tpm2-tss-engine: FTBFS with OpenSSL 3.0
On 2022-02-27 23:37:35 [+], Luca Boccassi wrote: > This is known and expected, this package is an engine for OpenSSL 1.x. > The 3.x version is shipped as a separate and different project, already > uploaded to experimental: > > https://tracker.debian.org/pkg/tpm2-openssl > > Once OpenSSL 3.x is uploaded to unstable, I will upload that too. That happend. Could you fill a removal bug for tpm2-tss-engine? There is no point in keeping that, right? Sebastian
Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu
control: forward -1 https://github.com/openssl/openssl/issues/18334 On 2022-05-17 16:01:35 [+0200], Wolfgang Walter wrote: > > Yes, with libssl3_3.0.3-4.noendbr_i386.deb this is fixed. perfect, thank you for the confirmation. I forwarded it upstream and I hope to have something for the next upload. > Thanks Sebastian
Bug#1011127: [Pkg-openssl-devel] Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu
On 2022-05-17 12:53:07 [+0200], Wolfgang Walter wrote: > Systems with VIA Nehemiah cpu break after upgrading unstable. All commands > using libssl3 fail with … > lscpu shows: > > Architecture:i686 > CPU op-mode(s): 32-bit … > Flags: fpu vme de pse tsc msr cx8 sep mtrr pge > cmov pat mmx fxsr sse cpuid rng rng_en ace ace_en My guess is that your CPU lacks sse2, which in turn doesn't support multi-byte nops, which in turn does not support the endbr opcode / CET. I built i386 packages without endbr and uploaded everything to https://people.debian.org/~bigeasy/openssl-3-noendbr/ Could you please give a try report if this is correct? Sebastian
Bug#1006568: rauc: FTBFS with OpenSSL 3.0
On 2022-05-11 17:58:22 [+0200], Uwe Kleine-König wrote: > I just confirmed that. I built libp11 in sid + openssl3. With the > resulting packages installed rauc just builds fine against openssl3. > > So I'm unsure what I should do about this bug. Close it? Reassign to > libp11? Just wait until it resolves itself? If that the case, then the package will build fine if the binNMUs happen in the right order. In that case, feel free to close the bug. Thank you for checking. > Best regards > Uwe Sebastian
Bug#1010698: stunnel4: debci testsuite fails after openssl version update.
On 2022-05-07 20:52:41 [+0200], Paul Gevers wrote: > Hi Sebastian, Hi Paul, > On 07-05-2022 18:22, Sebastian Andrzej Siewior wrote: > > Usertags: flaky > > Why do you conclude that? Normally we call something flaky if it has a > reasonable amount of failures in pure testing environments (so no migration > runs). I'm not seeing that for tunnel4 on amd64, nor arm64. Maybe I missunderstood. According to the tracking page, it failed everywhere: | autopkgtest for stunnel4/3:5.63-1: | amd64: Regression ♻ (reference ♻), | arm64: Regression ♻ (reference ♻), | armhf: Regression ♻ (reference ♻), | i386: Regression ♻ (reference ♻), | ppc64el: Regression ♻ (reference ♻), | s390x: Regression ♻ (reference ♻) Does this mean flaky or is this something in case it fails _always_ and not just randomly swi-prolog/8.4.2+dfsg-2 on i386 while it passed on other arches. > > that the error is that it was compiled against one version (1.1.1n) > > and then tested against another version (1.1.1o)? > > stunnel4 -version reports: > > | Compiled with OpenSSL 1.1.1n 15 Mar 2022 > > | Running with OpenSSL 1.1.1o 3 May 2022 > > > > and it is fine, the ABI is stable. > > If your claim is true (and I trust it is), I do agree that it seems that the > test (and I guess this comes from a runtime check) is too strict. Retitling > accordingly. Oki, thanks. > Paul Sebastian
Bug#1010698: stunnel4: debci testsuite fails after openssl version update.
Package: stunnel4 Version: 3:5.63-1 Severity: serious User: debian...@lists.debian.org Usertags: flaky The debci testsuite failed for all architectures after the recent openssl upload https://ci.debian.net/data/autopkgtest/testing/amd64/s/stunnel4/21436404/log.gz Am I right to assume as per | logs/results.log:DEBUG: 2022-05-07 04:07:41,445: [get_version] Trying to obtain the version of /tmp/autopkgtest-lxc.algiqp59/downtmp/build.oOV/src/tests/../src/stunnel | logs/results.log:DEBUG: 2022-05-07 04:07:41,446: [get_version] Started `/tmp/autopkgtest-lxc.algiqp59/downtmp/build.oOV/src/tests/../src/stunnel -version` as process 1544 | logs/results.log:CRITICAL: 2022-05-07 04:07:41,449: [main] Something went wrong: Stunnel was compiled and run with various OpenSSL versions … | autopkgtest [04:07:41]: test upstream: ---] | upstream FAIL non-zero exit status 1 | autopkgtest [04:07:41]: test upstream: - - - - - - - - - - results - - - - - - - - - - | autopkgtest [04:07:41]: summary | debian-pythonPASS | upstream FAIL non-zero exit status 1 that the error is that it was compiled against one version (1.1.1n) and then tested against another version (1.1.1o)? stunnel4 -version reports: | Compiled with OpenSSL 1.1.1n 15 Mar 2022 | Running with OpenSSL 1.1.1o 3 May 2022 and it is fine, the ABI is stable. Sebastian
Bug#907691: petri-foo: License incompatibility: links with OpenSSL
On 2018-08-31 15:03:38 [+0300], Yavor Doganov wrote: > Package: petri-foo > Version: 0.1.87-4 > Severity: serious > > This package is licensed under GPLv2 only but links with the OpenSSL > library which makes it impossible for distribution as the licenses are > incompatible. See > > https://www.gnu.org/licenses/license-list.html#OpenSSL > https://people.gnome.org/~markmc/openssl-and-the-gpl.html > > You either have to ask the copyright holders to release it under GPL + > OpenSSL exception or modify it to link with another cryptographic > library such as GnuTLS. OpenSSL is considered as a system library so there should no license restriction, see #924937. OpenSSL 3 in experimantal is licensed under the Apache-2 license. Sebastian
Bug#990228: [Pkg-openssl-devel] Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a regular file:../crypto/rand/randfile.c:
On 2021-06-23 14:46:37 [+0200], Andreas Beckmann wrote: > Writing new private key to '/etc/ssl/private/ssl-cert-snakeoil.key' > - > Warning: No -copy_extensions given; ignoring any extensions in the request > Cannot write random bytes: > 8022CB35777F:error:127A:random number generator:RAND_write_file:Not > a regular file:../crypto/rand/randfile.c:190:Filename=/dev/urandom … > Hmm, well, yes, /dev/urandom is not a regular file. It's a character device > node. This is from -config $file -> RANDFILE= /dev/urandom The reject of file nodes is new in the 3.0.0 release. In the past openssl used to have its .rnd where it keept track of a random state. So it read the RANDFILE to seed and wrote it back to avoid having the state on the next invocation. This is gone since 1.1.0 (I think) and openssl uses getrandom() to initialize its random generator. It is no longer needed to specify /dev/urandom as RANDFILE to seed it initially. In this case it will read urandom and use additionally getrandom() and both provide pseude-random data from exactly the same pool. And then after the operation, openssl will write it back… I would argue to remove RANDFILE from the template. On the other hand there is nothing wrong with writting it back to a device node file. Kurt? > > cheers, > > Andreas Sebastian
Bug#986622: [Pkg-clamav-devel] Bug#986622: Bug#986622: fixes
On 2021-04-21 08:17:53 [+0100], Athanasius wrote: > So long as any Debian update of the packages both addresses the > outstanding CVEs *and* quiets this logging I'll be happy. Be aware that I am following the process to get an update into Buster. Sebastian
Bug#986622: [Pkg-clamav-devel] Bug#986622: fixes
On 2021-04-13 16:08:17 [+0530], Utkarsh Gupta wrote: > Hi Sebastian, Hi, > Sebastian Andrzej Siewior wrote: > > My plan is to get 103.2 into Buster after I spent the day today > > to look what should be backported and what not. > > Do we not generally backport clamav as-is to buster (of course, after > thoroughly checking) so as to get the latest release there? Usually yes, I let it slide (unfortunatelly) and was checking best options moving forward. After all I need reasons to present to the release team. > I ask/confirm because I'd like to further backport this to > stretch/jessie for LTS/ELTS as well. We generally wait for buster to > be updated and then we backport to stretch and then jessie. > > Also, once you get the update prepared for buster and plan to release, > could you also let me know so I get a heads up and thus plan > accordingly for stretch and jessie? Sure. My plan for now is to prepare today the release for Buster, deploy it on one my machines and if nothing breaks open the pu tomorrow. > Thanks. > > > - u Sebastian
Bug#980592: [Pkg-clamav-devel] Bug#980592: clamav: diff for NMU version 0.103.0+dfsg-3.1
On 2021-02-21 16:07:37 [+0100], Sebastian Ramacher wrote: > Control: tags 980592 + pending > > Dear maintainer, > > I've prepared an NMU for clamav (versioned as 0.103.0+dfsg-3.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. I clearly missed that part that it affects current testing. I saved it internally as Bullseye+1. I also planned to upload 0.103.1 which didn't happend. Anyway. Feel free to NMU it right away if you want to and I try upload 103.1 this week or next… > Cheers > -- > Sebastian Ramacher Sebastian
Bug#983013: [Pkg-openssl-devel] Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack
On 2021-02-18 08:15:15 [+0100], Paul Gevers wrote: > > I copied some of the output at the bottom of this report. I *think* > this may be related to CVE-2020-25657 "bleichenbacher timing attacks in > the RSA decryption API" against m2crypto, hence I file this bug against > m2crypto. The openssl side is aware of the situtation. Currently we want to clarify the documentation in openssl https://github.com/openssl/openssl/issues/14216 and then report this m2crypto upstream what should be done instead. The bug fix triggered the problem :) Sebastian
Bug#979865: m2crypto FTBFS on IPV6-only buildds
control: found -1 0.31.0-1 On 2021-01-24 23:08:27 [+0200], Adrian Bunk wrote: > > The release team considers these bugs release critical. it would be easier to enforce to have all buildds configured equally so the package does not fail on a random buildd. > > and let it migrate to > > testing. After all this bug did not first appear in 0.37.1-1, > >... > > If this is true, then the proper action would be a found indicating the > first broken version. Ah. Looking at all the ipv6 testsuite bugs I saw so far, all of them were there from the very beginning. My guess is that it isn't any different here. I reassigned it to the first upload of 31 which is in stable because 0.31.0-4+deb10u1 failed to build on amd64 for the same reason. A retry passed. > cu > Adrian Sebastian
Bug#979865: m2crypto FTBFS on IPV6-only buildds
On 2021-01-12 08:22:05 [+0200], Adrian Bunk wrote: > Source: m2crypto > Version: 0.37.1-1 > Severity: serious > Tags: ftbfs I suggest to lower the severity to important and let it migrate to testing. After all this bug did not first appear in 0.37.1-1, it has been exposed after it hit buildd that is IPv6 only. The package built on all release architectures by now. Sebastian
Bug#979146: gnat-gps: FTBFS because BD can not be installed (gnat-9 vs 10)
Package: src:gnat-gps Version: 19.2-3 Severity: serious Tags: sid ftbfs Hi, some BD of gnat-gps depend on packages which were built by gnat-9 others moved to gnat-10. libgnatcoll-db and libgnatcoll-bindings changed their binary packages and the old ones are by built by gnat-9, the new ones are built by gnat-10. The old binary packages are no longer built. The package does not build anymore because the BD can not be installed. Sebastian
Bug#973955: bind9: flaky autopkgtest: DNS query rootserver
Source: bind9 Version: 1:9.16.6-3 Severity: serious Tags: sid bullseye User: debian...@lists.debian.org Usertags: flaky Hi, the autopkg test validates DNSSEC of internetsociety.org for it requires unrestricted internet access. For this it is needed to specify Restrictions: needs-internet in the testfile as other worker may not provide internet access. Please see https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst search for "needs-internet" and the note about "Network access". The failed test: https://ci.debian.net/data/autopkgtest/testing/amd64/b/bind9/8020050/log.gz Sebastian
Bug#972974: [Pkg-clamav-devel] Bug#972974: Bug#972974: clamav-freshclam start faild.
On 2020-10-28 23:52:05 [-0500], ari...@despayre.org wrote: > I have checked the apparmor profile for clamav-daemon at /usr/sbin/clamd > > and > > | capability dac_override, > > exists. The bug report is about freshclam not clamd. > I had to install apparmor-utils to aa-disable the usr.sbin.clamd profile in > order to get the process to load. Sebastian
Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.
On 2020-10-27 07:22:22 [+], Michael Borgelt wrote: > I have tried different permissions for the file and the directory without > success. The obove permissions are after a clean reinstall off clamav > package. The problem appears to be the apparmor or freshclam's profile for it. So disabling apparmor should make freshclam work again. Probably adding | capability dac_override, to the profile will help, too. I will test it later today… Sebastian
Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.
On 2020-10-26 19:02:58 [+0100], Michael Borgelt wrote: > clamav-freshclam start faild with: > Okt 26 18:44:41 host freshclam[31527]: ERROR: initialize: libfreshclam init > failed. > Okt 26 18:44:41 host freshclam[31527]: ERROR: Initialization error! > Okt 26 18:44:41 bert freshclam[31527]: ERROR: Can't open > /var/log/clamav/freshclam.log in append mode (check permissions!). > Okt 26 18:44:41 host systemd[1]: clamav-freshclam.service: Main process > exited, > code=exited, status=2/INVALIDARGUMENT > Okt 26 18:44:41 host systemd[1]: clamav-freshclam.service: Failed with result > 'exit-code'. > > clamav-freshcalm was installed for the first time on this host. Could you please tell the permissions for /var/log/clamav/ /var/log/clamav/freshclam.log ? Sebastian
Bug#963853: [Pkg-clamav-devel] Bug#963853: clamav: FTBFS on IPv6-only environments
On 2020-06-28 12:48:20 [+0100], Dominic Hargreaves wrote: > Source: clamav > Version: 0.102.3+dfsg-1 > Severity: serious > Justification: FTBFS (when it built before) > > During archive-wide test rebuilding of an IPv6-only environment (which Is this decision blessed by the release team? If so where is it documented? Sebastian
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On 2020-04-09 14:32:07 [+0100], Dimitri John Ledkov wrote: > Here is the debdiff that makes everything work for me. > > It smells like a subtle breakage in detecting/parsing makefile > targets, or like make regression. > > It is still odd, i.e. there is build target, then binary target, which > then via dependencies calls binary-arch & binary-all. So not sure if > the results are correct or not. I suggested already something in [0]. Back then we were hoping for some feedback from the debhelper team. Now I was just asking if Jonathan is handling this and/or if we could also bump to current upstream version while at it. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945961#10 Sebastian
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On 2019-12-03 20:18:20 [-0800], Jonathan Nieder wrote: > Hi, Hi, > Let's track down the cause first, before pursuing workarounds. Nothing happened here so far and I almost forgot about it. xz 5.2.5 has been released in the meantime. Do you want me to help you out in anyway? I could add the fix I suggested and prepare the new release. > Thanks much, > Jonathan Sebastian
Bug#955535: httping: flaky autopkgtest: PING google.com:80
Source: httping Version: 2.5-5 Severity: serious Tags: sid bullseye User: debian...@lists.debian.org Usertags: flaky The test for httping passed on amd64[0] and failed on arm64[1]. Looking at the failed log |autopkgtest [17:03:58]: test command3: httping -F -c 4 http://google.com |autopkgtest [17:03:58]: test command3: [--- |PING google.com:80 (/): |connect time out | |connect time out | |connect time out | |connect time out | |--- http://google.com/ ping statistics --- |4 connects, 0 ok, 100.00% failed, time 124118ms |autopkgtest [17:06:02]: test command3: ---] |autopkgtest [17:06:02]: test command3: - - - - - - - - - - results - - - - - - - - - - |command3 FAIL non-zero exit status 127 |autopkgtest [17:06:02]: summary |command1 PASS |command2 PASS |command3 FAIL non-zero exit status 127 it seems to have failed because the test is not allowed to connect to the internet (or google itself). Could it be verified what the test policy is in regard to network access and then - run the test again once CI enabled network access on all nodes - removed that test from CI. [0] https://ci.debian.net/data/autopkgtest/testing/amd64/h/httping/4779756/log.gz [1] https://ci.debian.net/data/autopkgtest/testing/arm64/h/httping/4780569/log.gz Sebastian
Bug#954402: OpenSSL EOF handling, severity import
Control: severity -1 important OpenSSL 1.1.1f is in unstable now which reverts the unexpected EOF reporting via SSL_ERROR_SSL. In the OpenSSL 3.0 release it will be reported again as SSL_ERROR_SSL with reason code SSL_R_UNEXPECTED_EOF_WHILE_READING. Therefore the severity is downgraded to `important' because it no longer leads to an error during build but will later. Sebastian
Bug#954371: [Pkg-openssl-devel] Bug#954371: Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
On 2020-03-31 21:49:51 [+0200], Salvatore Bonaccorso wrote: > Hi Kurt, Hi Salvatore, > I see, but then I prefer to loop in Steffen Ullrich into the loop > (upstream of IO::Socket::SSL). Steffen, see the above comment from > Kurt in the Debian bug, so it looks we cannot close > https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e > as broken only. What do you think? we have openssl f in unstable so the visibile problem is gone for now. Can this bug be assigned back to libio-socket-ssl-perl? > Regards, > Salvatore Sebastian
Bug#955442: [Pkg-openssl-devel] Bug#955442: openssl breaks libio-socket-ssl-perl autopkgtest: 20 times "not ok"
On 2020-03-31 21:41:12 [+0200], Paul Gevers wrote: >passfail > opensslfrom testing1.1.1e-1 > libio-socket-ssl-perl from testing2.067-1 > all others from testingfrom testing there is more than just this. OpenSSL upstream released a new version today which brings back the old behaviour where openssl did not reporting an error (properly). I opened #954371 for libio-socket-ssl-perl but this has been reassigned which is … Anyway. With the upload the bug(s) could be downgraded to important but should be addressed. Sebastian
Bug#954402: m2crypto: FTBFS since openssl 1.1.1e
On 2020-03-26 23:57:24 [-0400], Sandro Tosi wrote: > > So the test expects no error. Since the commit mention there is an > > error where earlier there was none. From the Changes file: > > > > | *) Properly detect EOF while reading in libssl. Previously if we hit an > > EOF > > |while reading in libssl then we would report an error back to the > > |application (SSL_ERROR_SYSCALL) but errno would be 0. We now add > > |an error to the stack (which means we instead return SSL_ERROR_SSL) and > > |therefore give a hint as to what went wrong. > > > > OpenSSL 1.1.1d with the commit question leads to this behaviour. > > isnt this a regression in openssl then? why there's no RC bug filed > against openssl and you filed this bug against a downstream package? > i'm still not clear what you expect us to do with regards to m2crypto: > should we skip the failing test? The situation is a bit complicated as it seems. The EOF condition was not properly detected by openssl. Now it does (and sets an error code) and applications fail (including this test case I'm not not sure how the application behaves). It appears that there are also poorly implemented Web servers [0] leading to other problems. I will downgrade the bug's severity because this change is reverted in openssl 1.1.1 stable series: https://github.com/openssl/openssl/commit/0cd2ee64bffcdece599c3e4b5fac3830a55dc0fa If I'm not fast enough, feel free to downgrade it yourself. This change will come back in 3.0 series of openssl (that is why I'm not closing it). [0] https://github.com/openssl/openssl/issues/11378 Sebastian
Bug#954402: m2crypto: FTBFS since openssl 1.1.1e
On 2020-03-21 23:33:34 [-0400], Sandro Tosi wrote:
> > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > > testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> > > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > > which introduced the changed behaviour.
> > >
> > > [0] https://github.com/openssl/openssl/pull/10882
> > > [1] https://github.com/openssl/openssl/issues/10880
> >
> > what should i do about it on the m2crypto side?
>
> is this the failure you're referring to?
Yes.
> === FAILURES
> ===
> ___ MiscSSLClientTestCase.test_makefile_err
>
>
> self =
>
>def test_makefile_err(self):
>pid = self.start_server(self.args)
>try:
>ctx = SSL.Context()
>s = SSL.Connection(ctx)
>try:
>s.connect(self.srv_addr)
>except SSL.SSLError as e:
>self.fail(e)
>f = s.makefile()
>data = self.http_get(s)
>s.close()
>del f
>del s
>err_code = Err.peek_error_code()
>self.assertEqual(err_code, 0,
> >'Unexpected error: %s' % err_code)
> EAssertionError: 336154918 != 0 :
> Unexpected error: 336154918
>
> tests/test_ssl.py:858: AssertionError
So the test expects no error. Since the commit mention there is an
error where earlier there was none. From the Changes file:
| *) Properly detect EOF while reading in libssl. Previously if we hit an EOF
|while reading in libssl then we would report an error back to the
|application (SSL_ERROR_SYSCALL) but errno would be 0. We now add
|an error to the stack (which means we instead return SSL_ERROR_SSL) and
|therefore give a hint as to what went wrong.
OpenSSL 1.1.1d with the commit question leads to this behaviour.
Sebastian
Bug#954419: ruby2.7: FTBFS since openssl 1.1.1e
Package: ruby2.7
Version: 2.7.0-4
Severity: serious
control: forwarded -1 https://bugs.ruby-lang.org/issues/16696
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
Bug#954418: python2.7: FTBFS since openssl 1.1.1e
Package: python2.7
Version: 2.7.17-1
Severity: serious
control: forwarded -1 https://bugs.python.org/issue40018
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
Bug#954417: python3.7: FTBFS since openssl 1.1.1e
Package: python3.7
Version: 3.7.7-1
Severity: serious
control: forwarded -1 https://bugs.python.org/issue40018
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
Bug#954416: python3.8: FTBFS since openssl 1.1.1e
Package: python3.8
Version: 3.8.2-1
Severity: serious
control: forwarded -1 https://bugs.python.org/issue40018
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
Bug#954402: m2crypto: FTBFS since openssl 1.1.1e
Package: m2crypto
Version: 0.31.0-9
Severity: serious
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
Bug#954401: libnet-ssleay-perl: FTBFS since openssl 1.1.1e
Package: libnet-ssleay-perl
Version: 1.88-2
Severity: serious
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Package: libio-socket-ssl-perl
Version: 2.067-1
Severity: serious
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
Bug#948859: coccinelle: Package is uninstallable
On 2020-01-16 15:11:42 [+0100], Stéphane Glondu wrote: > > The following packages have unmet dependencies: > > coccinelle : Depends: libpcre-ocaml-2h5n2 but it is not installable > > Depends: ocaml-base-nox-4.05.0 but it is not installable > > E: Unable to correct problems, you have held broken packages. > > This is known; the package currently FTBFS in unstable. I've fixed it in > git, but wonder if it is worth an upload because of #885267, which I've > not fixed. In its current state, the package will never migrate to > testing because of #885267. Could we please get something working into unstable? I can install neither the package from unstable nor from experimental. I failed to build package from the git repo. Sebastian
Bug#948987: libssl: libssl1.1 segfaults when kopete is using it (libjingle-call)
control: reassing -1 kopete 4:17.08.3-2.1 control: retitle -1 kopete: segfaults when is using it (libjingle-call) On 2020-01-16 13:55:17 [+0100], Jens Schmidt wrote: > Dear Sebastion, > > yes, it seems that way. > I dit not look at the kopete package for the bug, since libssl was the thing > that is crashing. verry well. It seems that the library is used wrongly. Let me reassing the bug then to the proper department. I used version 4:17.08.3-2.1 since this is what is in Buster and you used the Buster version for your bug. If you have another version please let the bug know. > Cheers Jens Sebastian
Bug#948987: libssl: libssl1.1 segfaults when kopete is using it (libjingle-call)
On 2020-01-15 17:12:29 [+0100], Jens Schmidt wrote: > Package: libssl1.1 > Version: 1.1.1d-0+deb10u2 > Severity: critical > File: libssl > Justification: breaks unrelated software > > Dear Maintainer, > > when using kopete, dmesg shows a shitload of: > [timestamp] libjingle-call[11878]: segfault at 48 ip 7f693f599ed3 sp > 7fff4db27280 error 4 in libcrypto.so.1.1[7f693f561000+19e000] > [timestamp] Code: 40 24 01 00 00 00 4c 89 e2 c7 40 50 01 00 00 00 0f ae f0 e8 > af 83 fc ff 85 c0 74 6c e8 76 9a fc ff 48 89 43 70 48 85 c0 74 2d <48> 8b 45 > 48 48 85 c0 74 74 48 89 df ff d0 85 c0 0f 84 a7 00 00 00 > > I assume this is not intended behaviour. > > This is reproduceable on all (7) of our workstations. Same hardware, same > software. Isn't this the same report as #913679 ? > Regards > Jens Sebastian
Bug#946359: pg-snakeoil: Selftest apears to be broken
On 2019-12-19 10:04:48 [+0100], Christoph Berg wrote: > Re: Sebastian Andrzej Siewior 2019-12-18 > <20191218225837.qttuxpwrbo5ukpr3@flow> > > > $ sudo -u clamav freshclam --verbose > > > > what happens if you strip the sudo part? One of the first thing is to > > change to the clamav user (well so is my memory and the /var/…/clamav is > > owned by clamav so…)? However after I install sudo in my chroot and try > > this it still works :/ > > Now it just works, both with "sudo freshclam --verbose" and "sudo -u > clamav freshclam --verbose": I meant without sudo but here you go. > Thu Dec 19 10:00:36 2019 -> *updatedb: Running g_cb_download_complete > callback... and now out of the sudden it is no longer outdated. > > > Time: 2.4s, ETA; 0.0s [===>] > > > 52.81MiB/52.81MiB > > > * Connection #0 to host database.clamav.net left intact > > > Wed Dec 18 11:56:13 2019 -> ^Mirror https://database.clamav.net is not > > > synchronized. > > > > So I don't have this. And for that to happen you need an out-dated > > database. And somehow you have that and the ci host. Reproducible. > > Maybe there was one bad server in the mirror list... right. And the same server is used ci.debian.net. For days. The database server sits behind cloudflare's CDN [0]. Which means something would bad with the CDN. But then it appears to work with the old freshclam while new one throws the problem. So it might be a problem somewhere else. [0] https://blog.clamav.net/2018/09/want-to-improve-your-clamav-experience.html > > If the `sudo' part makes no difference, can you stash me your chroot or > > the other way around? There must be something that is different. > > One bit that could have been relevant is that I'm running on schroot > with tmpfs on an overlay fs. But that part is transparent. I would expect a transparent proxy, dns-preload library or an odd package which somehow influeces curl/freshclam. > Christoph Sebastian
Bug#946359: pg-snakeoil: Selftest apears to be broken
On 2019-12-18 11:59:50 [+0100], Christoph Berg wrote: > Nothing special, and the test started failing on ci.debian.net as well > as in my local sid chroot. Yes and this is absolute mystery to me. My up-to-date sid chroot I use in schroot for sbuild does not show this problem. If I install freshclam only without recommends I can't download anything because ca-certificate is missing. With this packages installed it works then… > > Could you start `freshclam' by hand with --verbose (not sure if --debug > > works) and provide more output? It appears that the version downloaded > > is one less than available and that is where things go south. > > In the sid chroot, with an empty /var/lib/clamav/: > > $ sudo -u clamav freshclam --verbose what happens if you strip the sudo part? One of the first thing is to change to the clamav user (well so is my memory and the /var/…/clamav is owned by clamav so…)? However after I install sudo in my chroot and try this it still works :/ > Time: 2.4s, ETA; 0.0s [===>] > 52.81MiB/52.81MiB > * Connection #0 to host database.clamav.net left intact > Wed Dec 18 11:56:13 2019 -> ^Mirror https://database.clamav.net is not > synchronized. So I don't have this. And for that to happen you need an out-dated database. And somehow you have that and the ci host. Reproducible. If the `sudo' part makes no difference, can you stash me your chroot or the other way around? There must be something that is different. > Christoph Sebastian
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On 2019-12-01 11:35:08 [-0800], Daniel Schepler wrote: > ... > debian/rules build > dh build --parallel >dh_update_autotools_config -O--parallel >dh_auto_configure -O--parallel >dh_auto_build -O--parallel >dh_auto_test -O--parallel > fakeroot debian/rules binary > dh binary --parallel >debian/rules install > make[1]: Entering directory '/build/xz-utils-5.2.4' > dh install --parallel >debian/rules build > make[2]: Entering directory '/build/xz-utils-5.2.4' > dh build --parallel > make[2]: Leaving directory '/build/xz-utils-5.2.4' >dh_testroot -O--parallel >dh_prep -O--parallel >debian/rules override_dh_auto_install > make[2]: Entering directory '/build/xz-utils-5.2.4' > dh_auto_install --builddirectory debian/xzdec-build > dh_auto_install --builddirectory debian/normal-build > dh_auto_install --builddirectory debian/static-build I don't know what changed but I think it is debhelper. We have now: |(sid)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act | debian/rules install | dh_installdeb | dh_gencontrol | dh_md5sums | dh_builddeb and that "debian/rules build" gets inlined we skip to install. This was once |(buster)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act | debian/rules install | debian/rules binary-arch | debian/rules binary-indep The install rule used to expand to other targets, to build the package but not anymore. If I use sid and downgrade to debhelper 12.5.3 then it still expands the same way. Buhhh. According to the overview in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xz-utils.html it FTBFS in bullseye on AMD64 but succeeds on ARM64. The build on ARM64 is from "2019-08-20 11:36:00 UTC" while the ADM64 is from "at 2019-11-26 05:14:00 UTC" so something might not migrated yet. Anyway. xz has this line in its rule file: | #!/usr/bin/make -f | | build clean install binary-arch binary-indep binary: | +dh $@ --parallel $(opt_no_act) and if I replace it with | #!/usr/bin/make -f | | %: | dh $@ --parallel $(opt_no_act) then it builds again. Should the rules be adjusted for xz? Sebastian
Bug#940547: python-cryptography: diff for NMU version 2.6.1-3.1
Control: tags 940547 + patch
Control: tags 940547 + pending
Dear maintainer,
I've prepared an NMU for python-cryptography (versioned as 2.6.1-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
Sebastian
diff -Nru python-cryptography-2.6.1/debian/changelog python-cryptography-2.6.1/debian/changelog
--- python-cryptography-2.6.1/debian/changelog 2019-03-09 12:25:47.0 +0100
+++ python-cryptography-2.6.1/debian/changelog 2019-09-24 21:10:32.0 +0200
@@ -1,3 +1,12 @@
+python-cryptography (2.6.1-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport two patches to fix the testsute with newer openssl.
+ * Ignore test_load_ecdsa_no_named_curve in the testsuite because it known to
+break with newer openssl (Closes: #940547).
+
+ -- Sebastian Andrzej Siewior Tue, 24 Sep 2019 21:10:32 +0200
+
python-cryptography (2.6.1-3) unstable; urgency=medium
* Fix autopkgtest dependencies.
diff -Nru python-cryptography-2.6.1/debian/patches/series python-cryptography-2.6.1/debian/patches/series
--- python-cryptography-2.6.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/series 2019-09-24 20:38:45.0 +0200
@@ -0,0 +1,3 @@
+update-our-test-to-be-more-robust-wrt-some-changes-f.patch
+use-a-random-key-for-these-tests-4887.patch
+tests-Skip-test_load_ecdsa_no_named_curve.patch
diff -Nru python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch
--- python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch 1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/tests-Skip-test_load_ecdsa_no_named_curve.patch 2019-09-24 20:38:23.0 +0200
@@ -0,0 +1,31 @@
+From: Sebastian Andrzej Siewior
+Date: Tue, 24 Sep 2019 11:18:27 +0200
+Subject: [PATCH] tests: Skip test_load_ecdsa_no_named_curve
+
+The test_load_ecdsa_no_named_curve breaks with OpenSSL 1.1.1d which is
+due to to commit 9a43a733801bd ("[ec] Match built-in curves on
+EC_GROUP_new_from_ecparameters").
+
+Upstream is aware of the issue and it is tracked at
+ https://github.com/pyca/cryptography/issues/4998
+
+Signed-off-by: Sebastian Andrzej Siewior
+---
+ tests/x509/test_x509.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/tests/x509/test_x509.py b/tests/x509/test_x509.py
+index 07a6019bd1394..c553636f27efe 100644
+--- a/tests/x509/test_x509.py
b/tests/x509/test_x509.py
+@@ -4122,6 +4122,7 @@ ParsedCertificate = collections.namedtuple(
+ ec.ECDSA(cert.signature_hash_algorithm)
+ )
+
++@pytest.mark.skip(reason="Breaks with openssl 1.1.1d, https://github.com/pyca/cryptography/issues/4998;)
+ def test_load_ecdsa_no_named_curve(self, backend):
+ _skip_curve_unsupported(backend, ec.SECP256R1())
+ cert = _load_cert(
+--
+2.23.0
+
diff -Nru python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch
--- python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch 1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/update-our-test-to-be-more-robust-wrt-some-changes-f.patch 2019-09-24 08:34:23.0 +0200
@@ -0,0 +1,35 @@
+From e575e3d482f976c4a1f3203d63ea0f5007a49a2a Mon Sep 17 00:00:00 2001
+From: Paul Kehrer
+Date: Wed, 11 Sep 2019 12:12:30 +0800
+Subject: [PATCH] update our test to be more robust wrt some changes from
+ upstream (#4993)
+
+---
+ tests/hazmat/primitives/test_dh.py | 11 +--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/tests/hazmat/primitives/test_dh.py b/tests/hazmat/primitives/test_dh.py
+index c667cd16e1a6b..43f2ce5c0318b 100644
+--- a/tests/hazmat/primitives/test_dh.py
b/tests/hazmat/primitives/test_dh.py
+@@ -157,8 +157,15 @@ from ...utils import load_nist_vectors, load_vectors_from_file
+ dh.generate_parameters(7, 512, backend)
+
+ def test_dh_parameters_supported(self, backend):
+-assert backend.dh_parameters_supported(23, 5)
+-assert not backend.dh_parameters_supported(23, 18)
++valid_p = int(
++b"907c7211ae61aaaba1825ff53b6cb71ac6df9f1a424c033f4a0a41ac42fad3a9"
++b"bcfc7f938a269710ed69e330523e4039029b7900977c740990d46efed79b9bbe"
++b"73505ae878808944ce4d9c6c52daecc0a87dc889c53499be93db8551ee685f30"
++b"349bf1b443d4ebaee0d5e8b441a40d4e8178f8f612f657a5eb91e0a8e"
++b"107755f", 16
++)
++assert backend.dh_parameters_supported(valid_p, 5)
++assert not backend.dh_parameters_supported(23, 22)
+
+ @pytest.mark.parametrize(
+ &q
Bug#940547: python-cryptography: Testsuite fails with OpenSSL 1.1.1d
Package: python-cryptography
Version: 2.6.1-3
Severity: serious
The upload of latest openssl 1.1.1d triggert three testsuite failures in
python-cryptography [0]
- _ test_buffer_protocol_alternate_modes[mode5]
__
|mode =
|backend =
|
|@pytest.mark.parametrize(
|"mode",
|[
|modes.CBC(bytearray(b"\x00" * 16)),
|modes.CTR(bytearray(b"\x00" * 16)),
|modes.OFB(bytearray(b"\x00" * 16)),
|modes.CFB(bytearray(b"\x00" * 16)),
|modes.CFB8(bytearray(b"\x00" * 16)),
|modes.XTS(bytearray(b"\x00" * 16)),
|]
|)
|@pytest.mark.requires_backend_interface(interface=CipherBackend)
|def test_buffer_protocol_alternate_modes(mode, backend):
|data = bytearray(b"sixteen_byte_msg")
|cipher = base.Cipher(
|algorithms.AES(bytearray(b"\x00" * 32)), mode, backend
|)
|> enc = cipher.encryptor()
|
|tests/hazmat/primitives/test_aes.py:495:
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_
|/usr/lib/python2.7/dist-packages/cryptography/hazmat/primitives/ciphers/base.py:121:
in encryptor
|self.algorithm, self.mode
|/usr/lib/python2.7/dist-packages/cryptography/hazmat/backends/openssl/backend.py:295:
in create_symmetric_encryption_ctx
|return _CipherContext(self, cipher, mode, _CipherContext._ENCRYPT)
|/usr/lib/python2.7/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py:116:
in __init__
|self._backend.openssl_assert(res != 0)
|/usr/lib/python2.7/dist-packages/cryptography/hazmat/backends/openssl/backend.py:125:
in openssl_assert
|return binding._openssl_assert(self._lib, ok)
This is due to commit 2a5f63c9a61be ("Allow AES XTS decryption using duplicate
keys.").
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2a5f63c9a61be
- _ TestDH.test_dh_parameters_supported
__
|self =
|backend =
|
|def test_dh_parameters_supported(self, backend):
|assert backend.dh_parameters_supported(23, 5)
|> assert not backend.dh_parameters_supported(23, 18)
|E assert not True
|E+ where True = >(23, 18)
|E+where > = .dh_parameters_supported
|
|tests/hazmat/primitives/test_dh.py:161: AssertionError
This is due to commit ddd16c2fe988e ("Change DH parameters to generate the
order q subgroup instead of 2q").
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=ddd16c2fe988e
- _ TestECDSACertificate.test_load_ecdsa_no_named_curve
__
|self =
|backend =
|
|def test_load_ecdsa_no_named_curve(self, backend):
|_skip_curve_unsupported(backend, ec.SECP256R1())
|cert = _load_cert(
|os.path.join("x509", "custom", "ec_no_named_curve.pem"),
|x509.load_pem_x509_certificate,
|backend
|)
|with pytest.raises(NotImplementedError):
|> cert.public_key()
|E Failed: DID NOT RAISE
|
|tests/x509/test_x509.py:3722: Failed
This is due to commit 9a43a733801bd ("[ec] Match built-in curves on
EC_GROUP_new_from_ecparameters").
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a43a733801bd
The first two changes in OpenSSL have been made on purporse and I'm not
sure about the last one.
Could someone please comment?
[0]
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-cryptography/2969575/log.gz
Sebastian
Bug#929903: m2crypto: prosposed patch
Control: tags 929903 + patch
Dear maintainer,
please find attached a proposed NMU to address this problem.
Regards.
Sebastian
diff -Nru m2crypto-0.31.0/debian/changelog m2crypto-0.31.0/debian/changelog
--- m2crypto-0.31.0/debian/changelog 2019-03-11 19:44:01.0 +0100
+++ m2crypto-0.31.0/debian/changelog 2019-06-08 12:35:11.0 +0200
@@ -1,3 +1,11 @@
+m2crypto (0.31.0-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add a few patches from upstream to avoid a testsuite regression while
+testing for bug which was fixed in OpenSSL 1.1.1c (Closes: #929903).
+
+ -- Sebastian Andrzej Siewior Sat, 08 Jun 2019 12:35:11 +0200
+
m2crypto (0.31.0-3) unstable; urgency=medium
* add 0002-tests-test_ssl-use-ciphercuites-for-TLS1.3-cipher-in.patch
diff -Nru m2crypto-0.31.0/debian/patches/0003-Remove-duplicate-call-of-the-error-code.patch m2crypto-0.31.0/debian/patches/0003-Remove-duplicate-call-of-the-error-code.patch
--- m2crypto-0.31.0/debian/patches/0003-Remove-duplicate-call-of-the-error-code.patch 1970-01-01 01:00:00.0 +0100
+++ m2crypto-0.31.0/debian/patches/0003-Remove-duplicate-call-of-the-error-code.patch 2019-06-08 12:34:05.0 +0200
@@ -0,0 +1,25 @@
+From 83d4d9bc3aa4466e540fa00f8cc6891c0301ec82 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Mat=C4=9Bj=20Cepl?=
+Date: Fri, 31 May 2019 17:00:14 +0200
+Subject: [PATCH] Remove duplicate call of the error code.
+
+---
+ tests/test_rsa.py | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/tests/test_rsa.py b/tests/test_rsa.py
+index 308b1b180445d..875b59c6844b5 100644
+--- a/tests/test_rsa.py
b/tests/test_rsa.py
+@@ -126,8 +126,6 @@ log = logging.getLogger('test_RSA')
+ ctxt = priv.public_encrypt(self.data, RSA.sslv23_padding)
+ with self.assertRaises(RSA.RSAError):
+ priv.private_decrypt(ctxt, RSA.sslv23_padding)
+-with self.assertRaises(RSA.RSAError):
+-priv.private_decrypt(ctxt, RSA.sslv23_padding)
+
+ # no_padding
+ with self.assertRaises(RSA.RSAError):
+--
+2.20.1
+
diff -Nru m2crypto-0.31.0/debian/patches/0004-Limit-tests.test_rsa.RSATestCase.test_public_encrypt.patch m2crypto-0.31.0/debian/patches/0004-Limit-tests.test_rsa.RSATestCase.test_public_encrypt.patch
--- m2crypto-0.31.0/debian/patches/0004-Limit-tests.test_rsa.RSATestCase.test_public_encrypt.patch 1970-01-01 01:00:00.0 +0100
+++ m2crypto-0.31.0/debian/patches/0004-Limit-tests.test_rsa.RSATestCase.test_public_encrypt.patch 2019-06-08 12:33:53.0 +0200
@@ -0,0 +1,42 @@
+From 0b22d79082afd7c564b2ac07fb0ef5d76d692586 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Mat=C4=9Bj=20Cepl?=
+Date: Fri, 7 Jun 2019 11:43:03 +0200
+Subject: [PATCH] Limit tests.test_rsa.RSATestCase.test_public_encrypt just
+ to OpenSSL which sustains it.
+
+Fixes #258
+---
+ tests/test_rsa.py | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/tests/test_rsa.py b/tests/test_rsa.py
+index 875b59c6844b5..7028b6085788e 100644
+--- a/tests/test_rsa.py
b/tests/test_rsa.py
+@@ -113,6 +113,8 @@ log = logging.getLogger('test_RSA')
+ with self.assertRaises(TypeError):
+ priv.private_encrypt(self.gen_callback, RSA.pkcs1_padding)
+
++@unittest.skipIf(m2.OPENSSL_VERSION_NUMBER < 0x1010103f,
++ 'Relies on fix which happened only in OpenSSL 1.1.1c')
+ def test_public_encrypt(self):
+ priv = RSA.load_key(self.privkey)
+ # pkcs1_padding, pkcs1_oaep_padding
+@@ -124,11 +126,11 @@ log = logging.getLogger('test_RSA')
+
+ # sslv23_padding
+ ctxt = priv.public_encrypt(self.data, RSA.sslv23_padding)
+-with self.assertRaises(RSA.RSAError):
+-priv.private_decrypt(ctxt, RSA.sslv23_padding)
++res = priv.private_decrypt(ctxt, RSA.sslv23_padding)
++self.assertEqual(res, self.data)
+
+ # no_padding
+-with self.assertRaises(RSA.RSAError):
++with six.assertRaisesRegex(self, TypeError, 'data too small'):
+ priv.public_encrypt(self.data, RSA.no_padding)
+
+ # Type-check the data to be encrypted.
+--
+2.20.1
+
diff -Nru m2crypto-0.31.0/debian/patches/0005-tests.test_rsa-Fix-typo-to-match-for-proper-exceptio.patch m2crypto-0.31.0/debian/patches/0005-tests.test_rsa-Fix-typo-to-match-for-proper-exceptio.patch
--- m2crypto-0.31.0/debian/patches/0005-tests.test_rsa-Fix-typo-to-match-for-proper-exceptio.patch 1970-01-01 01:00:00.0 +0100
+++ m2crypto-0.31.0/debian/patches/0005-tests.test_rsa-Fix-typo-to-match-for-proper-exceptio.patch 2019-06-08 12:35:11.0 +0200
@@ -0,0 +1,25 @@
+From: Sebastian Andrzej Siewior
+Date: Sat, 8 Jun 2019 14:13:59 +
+Subject: [PATCH] tests.test_rsa: Fix typo to match for proper exception
+
+Signed-off-by: Sebastian Andrzej Siewior
+---
+ tests/test_rsa.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/test_rsa.py b/tests/test_rsa.py
+index 7028b60857
Bug#929903: openssl: m2crypto test case regression
On 2019-06-08 10:28:38 [+0200], Matěj Cepl wrote:
> Sebastian Andrzej Siewior píše v Út 04. 06. 2019 v 23:10 +0200:
> > It did not if I understand the python correctly:
> > >with self.assertRaises(RSA.RSAError):
> > >priv.private_decrypt(ctxt, RSA.sslv23_padding)
> >
> > you expect that `priv.private_decrypt()' raised an RSA.RSAError
> > exception which it did before c (due to that bug) and did not since c.
>
> I believe M2Crypto 0.35.1 is what you are looking for. Thank you
> very much for finding the problem.
I see
0b22d79082afd ("Limit tests.test_rsa.RSATestCase.test_public_encrypt just to
OpenSSL which sustains it.")
83d4d9bc3aa44 ("Remove duplicate call of the error code.")
which are ontop of 0.34. I don't see 0.35.1 but I think those two should
fix my problem.
> Best,
>
> Matěj
Sebastian
Bug#929903: openssl: m2crypto test case regression
On 2019-06-04 14:24:12 [+0200], Matěj Cepl wrote: > Sebastian Andrzej Siewior píše v Út 04. 06. 2019 v 14:15 +0200: > > Let me ping upstream: Matěj, could you please take a look at > > https://bugs.debian.org/929903 > > > > and check if it is okay the test no longer fails or if openssl suddenly > > eats up the error code. Afterall: > > OK, I have this commit now in the master > https://gitlab.com/m2crypto/m2crypto/commit/f287d7145b5f but I am > still not certain that sslv23_padding and especially no_padding > should lead to error, shouldn't it? > > Why did the test passed before otherwise? It did not if I understand the python correctly: |with self.assertRaises(RSA.RSAError): |priv.private_decrypt(ctxt, RSA.sslv23_padding) you expect that `priv.private_decrypt()' raised an RSA.RSAError exception which it did before c (due to that bug) and did not since c. > Best, > > Matěj Sebastian
Bug#929903: openssl: m2crypto test case regression
On 2019-06-04 12:12:35 [+0200], Kurt Roeckx wrote:
> On Tue, Jun 04, 2019 at 12:46:07AM +0200, Sebastian Andrzej Siewior wrote:
> >
> > So if I decoded it right, it does
> >
> > | fbuf = sha1("The magic words are squeamish ossifrage."); /* 0xbf,
> > 0xf0, 0x04 … */
> > | flen = RSA_public_encrypt(20, fbuf, tobuf, )
> > | /* flen -> 128 */
> > | r = RSA_private_decrypt(128, tobuf, tobuf2, )
> >
> > before the change, RSA_private_decrypt() used to return an error
> > r -> -1, rsa routines|rsa_ossl_private_decrypt|padding check failed>
> >
> > after that, it return `20' and probably passes. Would it be likely that
> > m2crypto tested that an openssl bug existed which got fixed?
>
> I have no idea what they're testing, but I expect that if you just
> encrypt something, that decryting that should work.
But it didn't.
Let me ping upstream: Matěj, could you please take a look at
https://bugs.debian.org/929903
and check if it is okay the test no longer fails or if openssl suddenly
eats up the error code. Afterall:
--- tests/test_rsa.py 2019-06-03 21:16:33.84000 +
+++ tests/test_rsa.py.new 2019-06-04 12:14:21.16800 +
@@ -124,10 +124,10 @@
# sslv23_padding
ctxt = priv.public_encrypt(self.data, RSA.sslv23_padding)
-with self.assertRaises(RSA.RSAError):
-priv.private_decrypt(ctxt, RSA.sslv23_padding)
-with self.assertRaises(RSA.RSAError):
-priv.private_decrypt(ctxt, RSA.sslv23_padding)
+ptxt = priv.private_decrypt(ctxt, RSA.sslv23_padding)
+self.assertEqual(ptxt, self.data)
+ptxt = priv.private_decrypt(ctxt, RSA.sslv23_padding)
+self.assertEqual(ptxt, self.data)
# no_padding
with self.assertRaises(RSA.RSAError):
passes now and the result is `equal'.
> Kurt
Sebastian
Bug#929903: openssl: m2crypto test case regression
On 2019-06-02 23:39:22 [+0200], Kurt Roeckx wrote:
> > So, I added a small test for RSA_SSLV23_PADDING, as an extra commit,
> > since it will likely not cherry-pick in stable branches.
>
> It's about this change:
> -good &= constant_time_lt(threes_in_row, 8);
> +good &= constant_time_ge(threes_in_row, 8);
>
> (That should probably have been a separate commit.)
>
> Can you confirm that that is the reason for the change in
> behaviour?
yes, I confirm that this is the change that makes the testcase fail.
> I don't understand the m2crypto code, so I have no idea what it's
> testing.
So if I decoded it right, it does
| fbuf = sha1("The magic words are squeamish ossifrage."); /* 0xbf, 0xf0,
0x04 … */
| flen = RSA_public_encrypt(20, fbuf, tobuf, )
| /* flen -> 128 */
| r = RSA_private_decrypt(128, tobuf, tobuf2, )
before the change, RSA_private_decrypt() used to return an error
r -> -1, rsa routines|rsa_ossl_private_decrypt|padding check failed>
after that, it return `20' and probably passes. Would it be likely that
m2crypto tested that an openssl bug existed which got fixed?
> Kurt
Sebastian
