yapet-2.6 does not accept (correctly typed) password with openssl-3.2.0

[ursjoss]

On Archlinux, yapet-2.6 worked like a charm until the system was updated from openssl-3.1.4-1-x86_64 to openssl-3.2.0-1-x86_64.

Since the upgrade, when starting yapet, the login screen appears, I can seemingly enter the password, but it is declined.

After downgrading to openssl-3.1.4, the password is accepted.

Not sure if this is of any importance - the NEWS.md in the openssl project reports significant/incompatible changes:

• The default SSL/TLS security level has been changed from 1 to 2.
• The x509, ca, and req apps now always produce X.509v3 certificates.
• Subject or issuer names in X.509 objects are now displayed as UTF-8 strings by default.

[lucatrv]

Same here...

[lucatrv]

This is an advice for everyone who, like myself, has all his passwords locked due to this issue. Once you have temporarily reinstalled OpenSSL 3.1, you can convert your password pet file into a csv file using the yapet2csv tool, see yapet2csv -h for help.

[ursjoss]

My way of working around the issue on archlinux is the following:

sudo pacman -U /var/cache/pacman/pkg/openssl-3.1.4-1-x86_64.pkg.tar.zst && yapet && sudo pacman -Syu

If you don't have the package anymore in your local pacman cache, you can download it from here: https://archive.archlinux.org/packages/o/openssl/

[ursjoss]

I was digging a bit. My yapet file was still a yapet 10 file, The issue occurred here:

yapet/src/libs/crypt/cryptofactoryhelper.cc

Line 59 in 48cecb2

return std::shared_ptr<AbstractCryptoFactory>{

However, I noticed that yapet had no problem encrypting and decrypting a new file (which subsequently was created as yapet 20 file).

Hence, my permanent workaround was to install openssl-3.1.4 (as described in the previous comment), use yapet2csv to export my passwords to csv, bump openssl to 3.2.0 and create a new yapet file from csv using csv2yapet. This resolves it for me.

Not sure if this workaround is a general good strategy. If yapet was my project, I might even consider instructing users to use yapet2csv/csv2yapet to migrate their password files and subsequently dropping the yapet 10 suport entirely (thus simplifying the code).

[lucatrv]

Not sure if this workaround is a general good strategy. If yapet was my project, I might even consider instructing users to use yapet2csv/csv2yapet to migrate their password files and subsequently dropping the yapet 10 suport entirely (thus simplifying the code).

I completely agree, yapet 10 format should be deprecated, documenting the command to upgrade to yapet 20 format:

yapet2csv passwords_old.pet passwords_tmp.csv
csv2yapet passwords_tmp.csv passwords_new.pet
rm passwords_tmp.csv

It would also be very useful to add stdout / stdin support to the yapet2csv / csv2yapet tools, which would allow for instance to write:

yapet2csv -stdout passwords_old.pet | csv2yapet -stdin passwords_new.pet