----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review67656 -----------------------------------------------------------
Great, it's been ... bugging me that the bug reporter hasn't been able to do its final step since quite some time already. Not to diminish the importance of your work, but someone really ought to provide a means (or document how) to upload a finished bug report without copy/pasting it in bits and pieces. An import button and a shortcut to the last page when launching the reporter manually would be all that's needed once the login step is moved to that page. After all there are other reasons why the final upload in the reported failed. > The passwords-only part of my patch is currently storing the password in > clear. Suggestions re encryption are welcomed --- or the code could be > changed to make use of KWalletD mandatory (but that might not be fully > portable to all platforms). Is that really a concern? I suppose no one uses his or her bank account password on a bug reporting site and it's not like open source software will contain industrial secrets either. Make sure the sensitive information is not stored in static memory, make sure regular builds will not contain debug info, and it ought to be hard enough to obtain a password from a memory image. The reporter would normally not be running for a long time anyway. Also, while not an expert on the matter I'm guessing that whatever argument you can forward why caching creds in unencrypted RAM is a bad idea can be extended to every kind of purely in-memory encryption. (Including kwallet if the user doesn't set it to lock after each transaction.) - René J.V. Bertin On Sept. 30, 2014, 9:30 a.m., Ian Wadham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120431/ > ----------------------------------------------------------- > > (Updated Sept. 30, 2014, 9:30 a.m.) > > > Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley. > > > Bugs: 337742 > http://bugs.kde.org/show_bug.cgi?id=337742 > > > Repository: kde-runtime > > > Description > ------- > > When bugs.kde.org changed over to Bugzilla 4.4.5 in July 2014, the security > method used by Bugzilla changed from cookies to tokens that had to be > supplied as parameters with every secure remote-procedure call. Further > changes to security methods have been announced by Bugzilla and are > documented for unstable 4.5.x versions of Bugzilla software. Tokens will be > deprecated and then discontinued. When this happens, Dr Konqi will need to > supply a user-login name and a password with every secure remote-procedure > call. Furthermore, the traditional "User.login" call presently used by Dr > Konqi will be deprecated and discontinued. > > This patch fixes the tokens problem, which has given rise to several bug > reports https://bugs.kde.org/show_bug.cgi?id=337742 and duplicates. It also > provides for automatic switching to passwords-only security as and when the > Bugzilla version changes again. This uses > a general data-driven approach which can be easily updated, ahead of time, > next time Bugzilla announces a change that affects Dr Konqi, whether it be in > security methods or some other feature. > > NOTES: > 1. This patch is intended to be forward-portable to Frameworks/KF5, but I > work on Apple OS X, where it is not yet possible to run Frameworks/KF5 and do > the porting and testing. So could someone else please do it? > 2. Another Review Request https://git.reviewboard.kde.org/r/120376/ addresses > the tokens issue only, but it should be reviewed and shipped as a matter of > urgency, both in KDE 4 and Frameworks, the next bug-fixing release for KDE > 4.14 being due for tagging on Thursday, 9 October. That will leave more time > for this review (120431) of my more long-term and more general patch. > 3. The passwords-only part of my patch is currently storing the password in > clear. Suggestions re encryption are welcomed --- or the code could be > changed to make use of KWalletD mandatory (but that might not be fully > portable to all platforms). > 4. When the Bugzilla call "User.login" is discontinued, some re-sequencing of > the flow of KAssistantDialog pages will be needed. I have not attempted to do > that at this stage. Probably the entry of the user name and password should > be delayed until the report has been accepted by the Dr Konqi logic and it is > just about to be sent to bugs.kde.org or attached to an existing bug report. > > REFERENCES: > http://www.bugzilla.org/docs/ > http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN > Bugzilla 4.5.x (future) API doco re security > http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService.html#LOGGING_IN > Bugzilla 4.4.5 (current) API doco re security > http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/User.html#login > User.login will be DEPRECATED in 4.5.x > > > Diffs > ----- > > drkonqi/bugzillalib.h 570169b > drkonqi/bugzillalib.cpp f74753c > drkonqi/reportassistantpages_bugzilla.h b7af5b8 > drkonqi/reportassistantpages_bugzilla.cpp 22183f0 > > Diff: https://git.reviewboard.kde.org/r/120431/diff/ > > > Testing > ------- > > Used the bugstest.kde.org database and KDE 4 master on KDE/kde-runtime > repository. > > Tested a range of version numbers (see commented-out test data) against a > range of 5 or 6 hypothetical and real Bugzilla versions at which things could > or will change. This was to test the basic version-checking and > feature-choosing algorithm. > > Tested submitting both full reports and attached reports, using both the > token method and the passwords-only method. > > Also tested with KWalletD supplying the username and password on Dr Konqi's > login dialog. > > > Thanks, > > Ian Wadham > >
