Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Mon 08 Apr 2024 at 07:15pm +02, Salvatore Bonaccorso wrote: > Hi Sebastian, > > On Mon, Apr 08, 2024 at 06:43:01PM +0200, Sebastian Andrzej Siewior wrote: >> 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 ;) > > Thanks for the investigation and bringing the fixes to upstream > already: https://github.com/RafaelOstertag/yapet/pull/29 >> >> I can NMU if needed just yell. > > No need for that, will take it with my maintainers hat on from here. Many thanks both. -- Sean Whitton
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hi Sebastian, On Mon, Apr 08, 2024 at 06:43:01PM +0200, Sebastian Andrzej Siewior wrote: > 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 ;) Thanks for the investigation and bringing the fixes to upstream already: https://github.com/RafaelOstertag/yapet/pull/29 > > I can NMU if needed just yell. No need for that, will take it with my maintainers hat on from here. Regards, Salvatore
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
Hello, 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. > That said: You are right, opening 1.0 format databases should still > work that said, but is regressing with the openssl update. And as per > manpage: YAPET 2.0 will read and write pre YAPET 2.0 files. Pre YAPET > 2.0 files are converted to YAPET 2.0 files when changing the master > password. Once converted, the files can no longer be read by pre YAPET > 2.0 versions. > > I can ask upstream, but currently yapet will FTBFS with problems in > the testsuite anyway, and the problems are related. > > And yapet FTBFS with the new openssl in bookworm-pu in same way as in > unstable (but not with the old version). > > Thus I believe #1068045 and #1064724 are actually related. Thanks for the info. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 06 Apr 2024 at 09:30pm +02, Sebastian Andrzej Siewior wrote: > 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? Sorry! It's 'asdf'. -- Sean Whitton
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#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hi Sean, On Sat, Apr 06, 2024 at 04:54:14PM +0800, Sean Whitton wrote: > control: reassign -1 libssl3,yapet > control: found -1 libssl3/3.1.5-1 > control: found -1 yapet/2.6-1 > control: retitle -1 libssl3,yapet: YAPET cannot decrypt YAPET1.0-format DB > > Hello, > > On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote: > > >> > >>> Also, yapet is unchanged in unstable. Is the problem there, too? > >> > > I have now confirmed that the problem is in unstable too. 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). That said: You are right, opening 1.0 format databases should still work that said, but is regressing with the openssl update. And as per manpage: YAPET 2.0 will read and write pre YAPET 2.0 files. Pre YAPET 2.0 files are converted to YAPET 2.0 files when changing the master password. Once converted, the files can no longer be read by pre YAPET 2.0 versions. I can ask upstream, but currently yapet will FTBFS with problems in the testsuite anyway, and the problems are related. And yapet FTBFS with the new openssl in bookworm-pu in same way as in unstable (but not with the old version). Thus I believe #1068045 and #1064724 are actually related. Regards, Salvatore
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote: > On 30 March 2024 13:14:37 CET, Sean Whitton wrote: > >>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. 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. Thanks again. -- Sean Whitton yapet1.0.pet Description: Binary data signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
control: reassign -1 libssl3,yapet control: found -1 libssl3/3.1.5-1 control: found -1 yapet/2.6-1 control: retitle -1 libssl3,yapet: YAPET cannot decrypt YAPET1.0-format DB Hello, On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote: >> >>> Also, yapet is unchanged in unstable. Is the problem there, too? >> I have now confirmed that the problem is in unstable too. -- Sean Whitton signature.asc Description: PGP signature
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
Hello, On Sat 30 Mar 2024 at 09:29am +01, Sebastian Andrzej Siewior wrote: > 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. 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? > 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. Thanks for looking! -- Sean Whitton signature.asc Description: PGP signature
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
