Bug 1282825

Correct link: http://koji.fedoraproject.org/koji/taskinfo?taskID=11883149

KeePassX 2.0 is here. https://www.keepassx.org/news/2015/12/533

It's still using Qt 4 (>= 4.6), so my patch is not (yet) valid.

Created attachment 1108938 [details]
Patch for 2.0.0 (stable)

Here's the patch for KeePassX 2.0.0.0. It seems to work as expected.

Project moved from sourceforge to github, it requires qt >= 4.6 (qt 4 only, qt 5 is needed for master branch) and new format used (.kdbx, but it can still import .kdb).
Spec files reflect those changes, it removes every old patch, some old code, it includes a new %check section, and some parts are now cleaned/upgraded.

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=12293498

In order to build master with Qt 5, you just need to change BuildRequires/Requires (and Version tag/stuff of course).

Created attachment 1108974 [details]
Patch for 2.0.0 (stable) - sources updated

Sourcecode uploaded

*** Bug 1294528 has been marked as a duplicate of this bug. ***

In addition to 2.0 for rawhide, please update to 0.4.4 in all stable and EPEL releases: https://www.keepassx.org/news/2015/12/551

Taking this bug as I'm now co-maintainer for keepassx for Fedora (yay!)
I'm not able to release upgrade for EPEL (EPEL maintainer unresponsive).

I think that 2.0.0 should be used for F22/F23 while rawhide could use 2.0.0 or the development version with Qt5, while EPEL should use 0.4.4.
2.0.0 is backward compatible and it still requires Qt 4, so it should not be a disruptive change.

I'll push 2.0.0 to rawhide and updates-testing for Fedora. Please test it and use bodhi/karma points to let me now if everything is ok or if there are regressions.

keepassx-2.0.0-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d5cca74851

keepassx-2.0.0-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c8b51748fa

I'll update EPEL.

2.0.0 works well, but the import is one-way.

keepassx-0.4.4-1.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7601108cdf

keepassx-0.4.4-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-43613cf75a

(In reply to Jon Ciesla from comment #11)
> I'll update EPEL.
> 
> 2.0.0 works well, but the import is one-way.

Thanks for your feedback and for EPEL updates :)

keepassx-2.0.0-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d5cca74851

keepassx-2.0.0-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c8b51748fa

keepassx-2.0.0-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

keepassx-0.4.4-1.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7601108cdf

keepassx-0.4.4-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-43613cf75a

Update and database conversion seem to work. 

Given that database conversion requires manual steps from user and is not backwards compatible, I'd like to ask for rationale for updating to version 2 on stable releases instead of providing separate keepassx2 packages.

KeePassX 1 is a dead end. You can't even submit bug reports against KeePassX 1.0 anymore. It wouldn't make much sense to maintain a package downstream that upstream no longer maintains.

(In reply to kakoskin from comment #20)
> Given that database conversion requires manual steps from user and is not
> backwards compatible, I'd like to ask for rationale for updating to version
> 2 on stable releases instead of providing separate keepassx2 packages.

Thanks for your feedback.

As far as I know, is not possible to submit new packages for stable: you can only rename it or change subpackages (python-stuff -> python2-stuff). The option was between upgrading to 0.4.4 (security only fix) and 2.0.0 (security+features update).

Here's is why I proposed an upgrade from 0.4 to 2.0 for F22/23:
 - 0.4 is 5 years old
 - 0.4 branch is for critical security fixes only (not for general bugfixes)
 - Many users are really looking for 2.0 on Fedora (in few hours we had karma +4/0/0 for F23 update)
 - KeePassX is a leaf node, no package depends on it
 - KeePassX has no plugin interface, so no external plugin could be affected
 - 2.0 still uses Qt 4.x (only git master users Qt 5)
 - User experience is usually not affected, if not during migration (ABI/API/user experience changes should be avoided on stable, but it's not a must)
 - Breaking compatibility (even if providing an effective one-way migration) could be an issue, but Firefox updates are not so different (https/websites/extensions/...)
 - Fedora is usually less conservative about updates (features/first)

What it could have been improved:
 - Wait for comments about 0.4 vs 2.0 (another week maybe?)
 - Disable autokarma push (so we could had a whole week before pushing to stable?)
 - Ask for FESCo help/comments/suggestions

What it looks good to me:
 - spec file was really outdated, with broken links, old macros, non-standard way to do things, and %check section was missing: now it's fine and it doesn't need any custom patch
 - 2.0 and the new spec are working as expected (many positive karma points)
 - Many users are satisfied with this upgrade
 - I made experience and I'm going to be more careful in the future

Your feedback is important, especially in this kind of borderline decisions. Feel free to make your points and give negative karma points if necessary, as we are community and collaboration is critical in order to grew together. Next time this kind thing will happen I'll handle in a better way ;)

By the way, thank you all for your help.

Forcing users to upgrade - or rather, even worse: sneakily upgrading the installed keepassx to an incompatible version is a dead end for everyone who needs interoperability with other clients: it forces the new db format upon you.

This is an outrageous thing to do on a release branch, in clear violation of the packaging guidelines. I caught the botched update just by accident, or else I would have had to look for new clients on my other platforms.

(In reply to Michael J Gruber from comment #23)
> Forcing users to upgrade - or rather, even worse: sneakily upgrading the
> installed keepassx to an incompatible version is a dead end for everyone who
> needs interoperability with other clients: it forces the new db format upon
> you.

It maintains backward compatibility with a very old version with a simple DB migration.

> This is an outrageous thing to do on a release branch, in clear violation of
> the packaging guidelines.

I don't think so (look at SHOULD/MUST/if at all possible):
https://fedoraproject.org/wiki/Updates_Policy#All_other_updates

Firefox and KDE upgrades are not so different (FF upgrades on stable could even break compatibility with websites/extensions and it's not considered a bug).

> I caught the botched update just by accident, or
> else I would have had to look for new clients on my other platforms.

I'm sorry about that.

My comment #23 collided midway with comment #22, by the way, i.e. #23 was written before being able to read comment #22 which I do appreciate.

That being said: keepassx 2 seemed to import the v1 file correctly (Fedora 23) and I was lucky in the sense that my Android client reads v2 dbs.

Still, this is out of place for F22 and, really, also for F23. Now that it is in there is no way back out.

For rawhide the upgrade is OK, of course. For released branches, copr would have been a way to provide upgrades to anyone who wants them before F24.

(In reply to Michael J Gruber from comment #25)
> My comment #23 collided midway with comment #22, by the way, i.e. #23 was
> written before being able to read comment #22 which I do appreciate.

Thank you Michael.

> That being said: keepassx 2 seemed to import the v1 file correctly (Fedora
> 23) and I was lucky in the sense that my Android client reads v2 dbs.

I'm glad to hear it.
While I've probably underestimated how db migration could affect the workflow of some users, I tested this procedure and basic functionality many times.

> Still, this is out of place for F22 and, really, also for F23. Now that it
> is in there is no way back out.

F23 update was pushed really quickly by early positive karma feedback (F22 update is still in testing and can be blocked). Please feel free to downvote it and/or leave your comments.

> For rawhide the upgrade is OK, of course. For released branches, copr would
> have been a way to provide upgrades to anyone who wants them before F24.

Thanks for your suggestion. Yes, it could have been a good compromise for everyone. Sorry for the inconvenient.

(In reply to Francesco Frassinelli (frafra) from comment #8)
> 2.0.0 is backward compatible and it still requires Qt 4, so it should not be
> a disruptive change.

No it isn't backwards-compatible. I can't share a keepassx DB between current and previous releases. Why is this change happening in stable releases, not just in rawhide? Is maintenance actually required, or could the old version have juyst stayed on the F22 and F23 releases without being touched?

(In reply to Francesco Frassinelli (frafra) from comment #22)
> Here's is why I proposed an upgrade from 0.4 to 2.0 for F22/23:
>  - 0.4 is 5 years old

So what? If it works age doesn't matter.

>  - 0.4 branch is for critical security fixes only (not for general bugfixes)

That's fine, only update it for critical fixes then.

>  - Many users are really looking for 2.0 on Fedora (in few hours we had
> karma +4/0/0 for F23 update)

How many people using keepassx in Fedora didn't even know there was an update coming? The people who gave positive karma were probably CC'd on this bug and waiting for the new version. The people who would have given negative karma didn't get a chance to test it.

>  - KeePassX is a leaf node, no package depends on it

USERS depend on it.

>  - KeePassX has no plugin interface, so no external plugin could be affected

Users are affected.

>  - 2.0 still uses Qt 4.x (only git master users Qt 5)

Not a problem for F22 and F23.

>  - User experience is usually not affected, if not during migration
> (ABI/API/user experience changes should be avoided on stable, but it's not a
> must)
>  - Breaking compatibility (even if providing an effective one-way migration)
> could be an issue, but Firefox updates are not so different
> (https/websites/extensions/...)

Typical use of Firefox doesn't involve a database file that can be shared between different machines running different versions of the software. Comparing it to a web browser is not relevant.

>  - Fedora is usually less conservative about updates (features/first)

That's fine when incompatible changes go to rawhide first and the fact they're coming is announced.
 
> What it could have been improved:
>  - Wait for comments about 0.4 vs 2.0 (another week maybe?)
>  - Disable autokarma push (so we could had a whole week before pushing to
> stable?)
>  - Ask for FESCo help/comments/suggestions

It should have been announced somewhere other than bugzilla!

(In reply to Michael J Gruber from comment #25)
> Still, this is out of place for F22 and, really, also for F23. Now that it
> is in there is no way back out.

Indeed. The "announcement" of this change should have been on the mailing list, not just here in bugzilla.

I'm going to downgrade to 0.4.3 because the two vulnerabilities fixed in 0.4.4 don't affect me, then I might create a copr for 0.4.4.

(In reply to Jonathan Wakely from comment #28)
> (In reply to Francesco Frassinelli (frafra) from comment #22)
> > Here's is why I proposed an upgrade from 0.4 to 2.0 for F22/23:
> >  - 0.4 is 5 years old
> 
> So what? If it works age doesn't matter.

It's old and unsupported. I'm not sure if this matches with the spirit of Fedora.

> >  - 0.4 branch is for critical security fixes only (not for general bugfixes)
> 
> That's fine, only update it for critical fixes then.

It's a bit worse than that: KeePassX developers suggest to upgrade to 2.0 because they don't fix any bug (you can't even submit bug reports against KeePassX, comment #21) and they are going to stop providing any security support.

> >  - Many users are really looking for 2.0 on Fedora (in few hours we had
> > karma +4/0/0 for F23 update)
> 
> How many people using keepassx in Fedora didn't even know there was an
> update coming? The people who gave positive karma were probably CC'd on this
> bug and waiting for the new version. The people who would have given
> negative karma didn't get a chance to test it.

This happens all the time, in every project.
The fact that there's a such strong support to have 2.0 in Fedora stable doesn't justify my mistakes, but it shows that many people, including keepass devs, think this update is important. Even upgrading to 0.4.4 could have been criticized.

As I said before: probably a copr for 2.0.0 F22/F23 and 0.4.4 in stable would have been the best compromise.

> Indeed. The "announcement" of this change should have been on the mailing
> list, not just here in bugzilla.

You're right.

(In reply to Francesco Frassinelli (frafra) from comment #29)
> (In reply to Jonathan Wakely from comment #28)
> > (In reply to Francesco Frassinelli (frafra) from comment #22)
> > >  - 0.4 branch is for critical security fixes only (not for general bugfixes)
> > 
> > That's fine, only update it for critical fixes then.
> 
> It's a bit worse than that: KeePassX developers suggest to upgrade to 2.0
> because they don't fix any bug (you can't even submit bug reports against
> KeePassX, comment #21) and they are going to stop providing any security
> support.

Their website says:

"We will still provide security support for the 0.4 series for some time but please consider updating to version 2.0 instead."

So it's likely that 0.4 will still get security fixes for the lifetime of F23 and the new version could have gone to rawhide.

It's reasonable to force an update if upstream have abandoned the old version and are not even making security fixes, but that isn't the case here.

(In reply to Jonathan Wakely from comment #30)

As I said before, I'm sorry if I caused troubles trying to improve a spec file and providing the update that many users were waiting for. I got your critics, and I accept them. I'm just a volunteer and I'm still learning. Next time I'm going to handle updates better and better. Please help me doing so, as you did during last days.

You could handle those updates better by rolling the release back, and pushing a major update like this in the next release, not mid-cycle of the current one. You could provide this as a "keepassx2" package in F23 if you really want to get it into users' hands sooner.

You can fix this, even now. Bump the epoch and push 0.4.x back out.

(and, obviously, send email to the mailing list, so users are actually notified this time rather than getting a surprise breaking upgrade out of the blue)

(In reply to Ed Marshall from comment #32)
> You could handle those updates better by rolling the release back, and
> pushing a major update like this in the next release, not mid-cycle of the
> current one. You could provide this as a "keepassx2" package in F23 if you
> really want to get it into users' hands sooner.
> 
> You can fix this, even now. Bump the epoch and push 0.4.x back out.

Update for Fedora 23 has already been pushed and presumably users are currently updating to it. They wil have converted heir databases to version 2 format by the time new update back to 0.4 arrives breaking their databases again. This time they just will not have automatic converter available. So how many of those users have backup of their original database to revert to?

(In reply to Ed Marshall from comment #33)
> (and, obviously, send email to the mailing list, so users are actually
> notified this time rather than getting a surprise breaking upgrade out of
> the blue)

I can't downgrade keepassx because many people upgraded their database (comment #34).
I could provide a keepassx2 subpackage which replaces keepassx = 2.0.0, but I'm not sure about how to handle Obsoletes/Provides in this case.

I've seen the mail on devel. Let's see if it's possible to mitigate this issue.

Another thing to consider is that there's an open fatal bug in Keepassx 2.0 that destroys databases:

https://www.keepassx.org/dev/issues/392

I've already lost one.

This was a really rude change. I had to downgrade all of my clients and block keepassx from being updated in dnf.conf. My use case is this. I use the same database file crossplatform, synced to different devices. A few clients in some devices only have version 1.x database support. Until all different clients supports 2.x database, I cannot upgrade. You should really have made this a parallel package.

(In reply to Johan Heikkila from comment #37)
> This was a really rude change. I had to downgrade all of my clients and
> block keepassx from being updated in dnf.conf. My use case is this. I use
> the same database file crossplatform, synced to different devices. A few
> clients in some devices only have version 1.x database support. Until all
> different clients supports 2.x database, I cannot upgrade. You should really
> have made this a parallel package.

I'm in the same situation, and agree with Johan.

(In reply to Cott Lang from comment #36)
> Another thing to consider is that there's an open fatal bug in Keepassx 2.0
> that destroys databases:
> 
> https://www.keepassx.org/dev/issues/392
> 
> I've already lost one.

Ouch.

You can get keepassx 0.4.4 from https://copr.fedorainfracloud.org/coprs/jwakely/keepassx1/ (rawhide packages are building now).

Thanks Jonathan. This worked for my F23. I had to use 'dnf copr enable jwakely/keepassx1' (with a slash instead of a dash) and still need to keep 'exclude=keepassx' in my dnf.conf to prevent 0.4.4 from being upgraded to 2.0.0.

keepassx-0.4.4-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

keepassx-0.4.4-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.

Adding to comments #37 and #38, the worst thing is that it impacts users like me using RHEL + EPEL and Fedora in parallel (aka work vs. home).