Created attachment 570682 [details] emerge --info When i upgrade to app-admin/keepassxc-2.4.0 it cannot open database created be earlier versions. It shows error that databse is broken or key invalid hovever when i revert back to keepassxc-2.3.4-r1 everything is ok.
Can you please post the output that you refer to, redacted if needed of course.
Where is your keepassxc database located? If it's on some external storage (USB-device, CIFS- or NFS-mount), does this error message still appear if you copy the database to your ${HOME} directory and open it from there?
Created attachment 570706 [details] info from keepassxc 2.4.0 The error presented by keepassxc 2.4.0
I attached screenshoot form keepassxc 2.4.0. Location of database is subfolder at home directory on ext4
Created attachment 570708 [details] by hand build shows some strange info about snapshoot I took keepassxc-2.4.0.tar.gz from distfiles usr/portage/distfiles $ ls -la keepassxc-2.4.0.tar.gz -rw-rw-r-- 1 portage portage 4790634 03-20 12:52 keepassxc-2.4.0.tar.gz and build it by hand and then run. It shows that this file keepassxc-2.4.0.tar.gz in distfiles is not release one but some snapshoot ..
Created attachment 570710 [details] additional info about snapshoot
(In reply to artbx from comment #5) > Created attachment 570708 [details] > by hand build shows some strange info about snapshoot > > I took keepassxc-2.4.0.tar.gz from distfiles > > usr/portage/distfiles $ ls -la keepassxc-2.4.0.tar.gz > -rw-rw-r-- 1 portage portage 4790634 03-20 12:52 keepassxc-2.4.0.tar.gz > > and build it by hand and then run. > It shows that this file keepassxc-2.4.0.tar.gz in distfiles is not release > one but some snapshoot .. That is just some inconvenience in the build system of keepassxc. Add -DOVERRIDE_VERSION="2.4.0" to your build flags and that warning is gone.
I've checked custom release builds with clang/gcc, debug with clang, without luck, same as ebuild one. Nothing in debug info except ./src/keepassxc QObject::startTimer: Timers cannot have negative intervals QWidgetWindow(0x5645473a0060, name="centralwidgetWindow") must be a top level window. QWidgetWindow(0x5645473a0060, name="centralwidgetWindow") must be a top level window.
Are you using a keyfile?
yes, it was shown on screenshots.
I've checked it on second machine aarch64 and kpxc 2.4.0 doesn't work too, while 2.3 works ok, same behavior as on amd64. I can add info that this database begining was quite a long time ago, it was first created in 2013-10-18, and used successfully with all earlier keepass, keepassx, keepassxc versions. Last update to database was with keepassxc 2.3.4-r1. Propably i found a reson. On aarch 2.3.4-r1 showed me info that im using dperecated key format that would not be supported in the future. This become more understandable to me what's going on with 2.4, but KPXC 2.4 should present info that key is no longer supported instead of giving info that database is broken or key invalid, and give a clue how to upgrade it. Btw I i've noidea how to upgrade key.
https://github.com/keepassxreboot/keepassxc/issues/2037
From an IRC conversation I had about your bug: 14:35:11 <@phoerious> If it's just the warning, then tell him to ignore it or create a new keyfile. If it's an error, then it's a bug and you should tell him to generate a new keyfile as well. 14:35:44 <@phoerious> Open it in KeePassXC 2.3.4, generate a new key file, save db.
I understand i can create new keyfile, however i don't see a reson to do so. If only the keyformat is becomong unsppported it should allow me to upgrade the keyformat instead of requiring me to generate a new keyfile and distribute in on all may machines which is a bit rudiculus, time consuming, and im going to stay with 3.4.1 as long as it will be possible. People from keepass have a good point of view on that: Dominik Reichl - 6 days ago "As soon as the support for some of the key file formats would be removed (i.e. no warning anymore), these users wouldn't be able to open their databases anymore, which is unacceptable." [..] "Therefore, I think that full backward compatibility here is more important than a small complexity reduction. So, I'm not going to deprecate any of the formats. " https://sourceforge.net/p/keepass/feature-requests/2434/
(In reply to artbx from comment #14) > I understand i can create new keyfile, however i don't see a reson to do so. > If only the keyformat is becomong unsppported it should allow me to upgrade > the keyformat instead of requiring me to generate a new keyfile and > distribute in on all may machines which is a bit rudiculus, time consuming, > and im going to stay with 3.4.1 as long as it will be possible. > > People from keepass have a good point of view on that: > > Dominik Reichl - 6 days ago > "As soon as the support for some of the key file formats would be removed > (i.e. no warning anymore), these users wouldn't be able to open their > databases anymore, which is unacceptable." > [..] > "Therefore, I think that full backward compatibility here is more important > than a small complexity reduction. So, I'm not going to deprecate any of the > formats. " > > https://sourceforge.net/p/keepass/feature-requests/2434/ It's not up to me as package maintainer to judge keppassxc upstream decisions. If you really wanna have that fixed, please go to their GitHub page [1] and file a support request or comment on the already existing issue 2037 [1]: https://github.com/keepassxreboot/keepassxc/issues
Sure.
I've checked code, and debugged keppassxc 2.4.0 - Leagcy code is still present and enabled by efault - there is a bug in regexp that causing -- not to laod xml data from key -- at next if process it as binary hash In code the line Tools::isBase64(rawData) returns false for valid base64 data from XML node, thus causing to fail loading my key as xml and then treating it as binary hash. When I comment it out like below everyting works ok with leagcy key in 2.4.0 keepassxc-2.4.0/src/keys/FileKey.cpp QByteArray FileKey::loadXmlKey(QXmlStreamReader& xmlReader) { QByteArray data; while (!xmlReader.error() && xmlReader.readNextStartElement()) { if (xmlReader.name() == "Data") { QByteArray rawData = xmlReader.readElementText().toLatin1(); // if (Tools::isBase64(rawData)) { data = QByteArray::fromBase64(rawData); // } } } - So the buggy code is 2.4.0 bool isBase64(const QByteArray& ba) { constexpr auto pattern = R"(^(?:[a-z0-9+]{4})*(?:[a-z0-9+]{3}=|[a-z0-9+]{2}==)?$)"; QRegExp regexp(pattern, Qt::CaseInsensitive, QRegExp::RegExp2); QString base64 = QString::fromLatin1(ba.constData(), ba.size()); return regexp.exactMatch(base64); } - and 2.3.4 working one bool isBase64(const QByteArray& ba) { QRegExp regexp("^(?:[a-z0-9+/]{4})*(?:[a-z0-9+/]{3}=|[a-z0-9+/]{2}==)?$", Qt::CaseInsensitive, QRegExp::RegExp2); QString base64 = QString::fromLatin1(ba.constData(), ba.size()); return regexp.exactMatch(base64); } return data; }
Except the literal R witch means raw data, there are missing / and propably author make an error and tought about them as escape characters \ which would not be required with literal R"()" sequence and removed them. R"(^(?:[a-z0-9+]{4})*(?:[a-z0-9+]{3}=|[a-z0-9+]{2}==)?$)"; "^(?:[a-z0-9+/]{4})*(?:[a-z0-9+/]{3}=|[a-z0-9+/]{2}==)?$"
Should be fixed with >=app-admin/keepassxc-2.4.1
Yes, it is.
