Bug 22398 - qtpass only has 1000 possible passwords
Summary: qtpass only has 1000 possible passwords
Status: ASSIGNED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Buchan Milne
QA Contact: Sec team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-16 12:06 CET by David Walser
Modified: 2018-02-12 23:24 CET (History)
3 users (show)

See Also:
Source RPM: qtpass-1.1.6-1.mga6.src.rpm
CVE:
Status comment: Fixed upstream in 1.2.1


Attachments

David Walser 2018-02-02 18:31:32 CET

Status comment: (none) => Fixed upstream in 1.2.1

Comment 1 Buchan Milne 2018-02-08 14:43:53 CET
Will look at this today.

Status: NEW => ASSIGNED

Comment 2 Buchan Milne 2018-02-08 21:23:37 CET
1.2.1 is now in cauldron, and has been submitted to updates_testing for 6:

URL: svn+ssh://svn.mageia.org/svn/packages/updates/6/qtpass
Commit: 1199795 | buchan | New version 1.2.1 Fixes #22398 
Package submitted!

I have done basic testing of normal functionality on a build from the checkout built on my local machine running Mageia 6, and everything seems to work as well as (or better than) before.

Backporting the patches in question seemed to be a bit excessive for a leaf package, where one or two other issues were also addressed, e.g. password leaking (to stdout): https://github.com/IJHack/QtPass/issues/334

Assignee: bgmilne => qa-bugs
CC: (none) => bgmilne

Comment 3 Herman Viaene 2018-02-09 11:59:29 CET
MGA6-32 on Dell Latitude D600 Mate with kernel 4.14.18
No installation issues.
At CLI:
$ qtpass 
qtpass: relocation error: /lib/libQt5Widgets.so.5: symbol _ZTV13QInputControl, version Qt_5_PRIVATE_API not defined in file libQt5Gui.so.5 with link time reference

CC: (none) => herman.viaene

Comment 4 Thomas Backlund 2018-02-09 12:02:24 CET
Ah, this is another package getting screwed by the in-progress qt/plasma update

CC: (none) => tmb

Comment 5 Thomas Backlund 2018-02-09 12:03:54 CET
If you want to get it to work now, a proper set of buildrequires/conflicts should force the use of stuff not in testing
David Walser 2018-02-10 22:05:18 CET

CC: bgmilne => qa-bugs
Assignee: qa-bugs => bgmilne

Comment 6 Buchan Milne 2018-02-12 20:12:43 CET
If the Qt maintainer is going to push changes which result in ABI conflicts to updates_testing, there should be useful macros provided to ensure ABI compatibility.

Or, we need to ensure that updates go through the entire QA process in serial with any build deps.

Otherwise, we're going to be endlessly chasing artefacts of a poor process.

(If this *really* is the only option, and we want qtpass to go out sooner than the Qt update can go out, I can do the work, but it seems very counter-productive).
Comment 7 David Walser 2018-02-12 23:24:19 CET
I agree with Buchan.  This is one of the major shortcomings of our build system.  It would have been much better if the Qt and Plasma update could have been done in its own repository.  Hopefully we can get the Qt update out sooner rather than later, as it is holding up other updates besides just this one.  I would say let's just wait for now.

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