Bug 22398 - qtpass only has 1000 possible passwords
Summary: qtpass only has 1000 possible passwords
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2018-01-16 12:06 CET by David Walser
Modified: 2018-06-06 20:16 CEST (History)
5 users (show)

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


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.


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

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

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.
$ 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

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

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.
Comment 8 David Walser 2018-05-16 04:04:12 CEST
This can go back to QA now.

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

Comment 9 Herman Viaene 2018-05-18 16:06:51 CEST
MGA6-32 on IBM Thinkpad R50e Xfce
No installation issues.
Launching qtpass at CLI gives proper window asking for parameters, but after confirming the choices, I get a spinning wheel that didn't stop after some 20 min. running.
Feedback at the CLI:
$ qtpass 
util.cpp: 104 "/usr/local/bin/pass"
util.cpp: 104 "/usr/bin/pass"
util.cpp: 104 "/usr/local/bin/git"
util.cpp: 104 "/usr/bin/git"
util.cpp: 104 "/usr/local/bin/gpg2"
util.cpp: 104 "/usr/bin/gpg2"
util.cpp: 104 "/usr/local/bin/pwgen"
util.cpp: 104 "/usr/bin/pwgen"
mainwindow.cpp: 306 assuming fresh install
configdialog.cpp: 564 ()
pass.cpp: 34 "/usr/bin/gpg2" ("--gen-key", "--no-tty", "--batch")
pass.cpp: 201 Unhandled process type 10
claire robinson 2018-05-19 03:40:30 CEST

Whiteboard: (none) => feedback

Comment 10 Buchan Milne 2018-05-20 22:15:26 CEST
It looks like you didn't have a pre-existing GPG key (and it is generating a new keypair).

I have only tried using pass/qtpass with pre-existing keys.

I will have to test later (tomorrow) without keys.
Comment 11 Dave Hodgins 2018-06-06 09:54:09 CEST
There is a problem with the key generation, however this is not a regression.

After generating a gpg2 key and using "pass init <keyid>", the program works before
and after the update.

bug 23118 created for the gen/init problem. Advisory committed to svn.

Validating the update.

Whiteboard: feedback => MGA6-64-OK
Keywords: (none) => advisory, validated_update
CC: (none) => davidwhodgins, sysadmin-bugs

Comment 12 Mageia Robot 2018-06-06 20:16:39 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

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