Bug 1282825 - update keepassx to 2.0.0 (was: KeePassX 2.0 is coming!)
Summary: update keepassx to 2.0.0 (was: KeePassX 2.0 is coming!)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: keepassx
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Francesco Frassinelli (frafra)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1294528 (view as bug list)
Depends On: 1295449
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-17 14:36 UTC by Francesco Frassinelli (frafra)
Modified: 2016-02-27 15:37 UTC (History)
18 users (show)

Fixed In Version: keepassx-2.0.0-1.fc23 keepassx-0.4.4-1.el7 keepassx-0.4.4-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-26 00:44:22 UTC


Attachments (Terms of Use)
Patch (to be applied with: $ git apply keepassx-2.0dev.patch) (5.21 KB, patch)
2015-11-17 14:36 UTC, Francesco Frassinelli (frafra)
no flags Details | Diff
Patch for 2.0.0 (stable) (5.63 KB, patch)
2015-12-23 11:01 UTC, Francesco Frassinelli (frafra)
no flags Details | Diff
Patch for 2.0.0 (stable) - sources updated (6.07 KB, patch)
2015-12-23 14:20 UTC, Francesco Frassinelli (frafra)
no flags Details | Diff

Description Francesco Frassinelli (frafra) 2015-11-17 14:36:18 UTC
Created attachment 1095498 [details]
Patch (to be applied with: $ git apply keepassx-2.0dev.patch)

Hi!

KeePassX 2.0 is coming and it will be Qt 5 based. Build process switched from qmake to cmake. Patches are no more needed. They also changed their website and moved to GitHub.

I've updated the specfile and it builds correctly on F23. The program seems to work correctly: icons, menù, file associations, basic operations tested.

http://koji.fedoraproject.org/koji/taskinfo?taskID=11882794

I propose to push this update to rawhide and update on every Fedora branch when 2.0 stable will be released (2.0beta2 is the latest release, but it requires Qt 4).

Comment 1 Francesco Frassinelli (frafra) 2015-11-17 14:46:40 UTC
Correct link: http://koji.fedoraproject.org/koji/taskinfo?taskID=11883149

Comment 2 Sudhir Khanger 2015-12-07 19:14:01 UTC
KeePassX 2.0 is here. https://www.keepassx.org/news/2015/12/533

Comment 3 Francesco Frassinelli (frafra) 2015-12-07 22:16:55 UTC
It's still using Qt 4 (>= 4.6), so my patch is not (yet) valid.

Comment 4 Francesco Frassinelli (frafra) 2015-12-23 11:01:35 UTC
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).

Comment 5 Francesco Frassinelli (frafra) 2015-12-23 14:20:15 UTC
Created attachment 1108974 [details]
Patch for 2.0.0 (stable) - sources updated

Sourcecode uploaded

Comment 6 Francesco Frassinelli (frafra) 2015-12-29 09:02:20 UTC
*** Bug 1294528 has been marked as a duplicate of this bug. ***

Comment 7 Gwyn Ciesla 2016-01-07 17:23:20 UTC
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

Comment 8 Francesco Frassinelli (frafra) 2016-01-09 12:04:26 UTC
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.

Comment 9 Fedora Update System 2016-01-09 12:20:43 UTC
keepassx-2.0.0-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d5cca74851

Comment 10 Fedora Update System 2016-01-09 12:28:51 UTC
keepassx-2.0.0-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c8b51748fa

Comment 11 Gwyn Ciesla 2016-01-09 16:01:07 UTC
I'll update EPEL.

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

Comment 12 Fedora Update System 2016-01-09 17:42:37 UTC
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

Comment 13 Fedora Update System 2016-01-09 17:42:38 UTC
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

Comment 14 Francesco Frassinelli (frafra) 2016-01-09 17:46:36 UTC
(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 :)

Comment 15 Fedora Update System 2016-01-09 18:20:40 UTC
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

Comment 16 Fedora Update System 2016-01-09 18:21:43 UTC
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

Comment 17 Fedora Update System 2016-01-10 19:23:21 UTC
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.

Comment 18 Fedora Update System 2016-01-10 19:48:06 UTC
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

Comment 19 Fedora Update System 2016-01-10 19:49:57 UTC
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

Comment 20 kakoskin 2016-01-11 09:21:39 UTC
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.

Comment 21 Sudhir Khanger 2016-01-11 09:57:43 UTC
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.

Comment 22 Francesco Frassinelli (frafra) 2016-01-11 10:45:06 UTC
(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.

Comment 23 Michael J Gruber 2016-01-11 10:53:06 UTC
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.

Comment 24 Francesco Frassinelli (frafra) 2016-01-11 11:25:41 UTC
(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.

Comment 25 Michael J Gruber 2016-01-11 11:26:25 UTC
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.

Comment 26 Francesco Frassinelli (frafra) 2016-01-11 11:40:46 UTC
(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.

Comment 27 Jonathan Wakely 2016-01-11 13:45:54 UTC
(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?

Comment 28 Jonathan Wakely 2016-01-11 14:02:23 UTC
(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.

Comment 29 Francesco Frassinelli (frafra) 2016-01-11 14:45:50 UTC
(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.

Comment 30 Jonathan Wakely 2016-01-11 15:10:09 UTC
(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.

Comment 31 Francesco Frassinelli (frafra) 2016-01-11 15:49:43 UTC
(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.

Comment 32 Ed Marshall 2016-01-12 09:18:23 UTC
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.

Comment 33 Ed Marshall 2016-01-12 09:41:44 UTC
(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)

Comment 34 kakoskin 2016-01-12 09:46:28 UTC
(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?

Comment 35 Francesco Frassinelli (frafra) 2016-01-12 09:56:53 UTC
(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.

Comment 36 Cott Lang 2016-01-16 17:19:32 UTC
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.

Comment 37 Johan Heikkila 2016-01-22 14:22:49 UTC
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.

Comment 38 Roel van de Kraats 2016-01-25 08:31:52 UTC
(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.

Comment 39 Jonathan Wakely 2016-01-25 10:46:28 UTC
(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).

Comment 40 Roel van de Kraats 2016-01-25 11:02:26 UTC
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.

Comment 41 Fedora Update System 2016-01-26 00:44:14 UTC
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.

Comment 42 Fedora Update System 2016-01-26 01:32:18 UTC
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.

Comment 43 Eric Lavarde 2016-02-27 15:37:17 UTC
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).


Note You need to log in before you can comment on or make changes to this bug.