> On Okt. 5, 2014, 7:43 vorm., Ben Cooksley wrote:
> > As this is needed to restore the functionality of Dr Konqi, can someone 
> > familiar with the codebase please review it so we can get this in?
> 
> Ian Wadham wrote:
>     Perhaps I am the person most familiar with the codebase of Dr Konqi, 
> having worked on it for a few months now.
>     
>     So, if nobody else steps forward within the next 24 hours, I will do my 
> own "Ship It" and commit to KDE 4 kde-runtime master in time for Thursday's 
> close of the KDE 4.14.2 bugfix release.
>     
>     If KDE core developers want the Dr Konqi bugs fixed in KF5, they will 
> have to forward-port this change and my earlier changes themselves. I cannot 
> do that. I work on Apple OS X and we do not have KF5 and Qt 5 building there 
> yet.
>     
>     I do not propose to address Thomas's comments. I have more important 
> things to do.
> 
> Albert Astals Cid wrote:
>     With my release team hat:
>      - Sure commit to master if you can't find someone else to review and you 
> *know* your code is right and you're going to fix it when/if it break
>      - No, don't commit to KDE/4.14 this is a huuuuuuuuuuuuuge change and I 
> don't feel like it is guaranteed to go in, you can be a good guy and review 
> https://git.reviewboard.kde.org/r/120376/ since it seems that one fixes the 
> immediate problems people are having, no? (you say you're the one that knows 
> the code more yet have not reviewed it, why?)
>      - Your obsession to not contribute to KF5 based versions will byte you 
> again when you decide to move to KF5, you should really rethink it. Because  
> we do have KF5 and Qt5 building on MacOsX according to at least one of the 
> members of the MacOSX team, no?
> 
> Marko Käning wrote:
>     I wouldn not phrase it an "obsession to not to contribute to KF5". ;)
>     
>     In fact, it has been pointed out multiple times on KDE-MAC, in pm as well 
> as in various RRs, that the "MacOSX team" at the moment mainly tries to get 
> KDE4 into a working state, which is why Ian wants to push this forward.
>     
>     And yes, we have KF5 on Qt5 in a state where my OSX/CI(/Jenkins) systems 
> are able to build and install many projects successfully.
>     BUT, unfortunately, this does NOT mean that I am able to RUN every of 
> these apps successfully, as the OSX/CI system's specifics (being that all 
> frameworks, libs and apps live in their own install roots) in conjunction 
> with a (still missing) working QStandardPaths patch lead to the problem that 
> most of the apps can't find their config and data files at runtime at this 
> point in time. :(
>     
>     As I am *alone* on KF5, I haven't managed to proceed with the 
> QStandardPaths issue, since many other things kept me far too busy (like the 
> inclusion of new projects on OSX/CI, dealing with Jenkins master [also for 
> Linux], tending project dependencies, creating a KDE4.13 branch on our 
> macports-kde git repo, testing KDE4 applications, etc...).
>     
>     Eventually I conclude herewith that the "MacOSX team":
>     
>     - does contribute directly to Qt5/KF5 big time - althought it is only me 
> ATM,
>     
>     - does indirectly contribute to Qt5/KF5, as many RRs can be modified 
> easily for inclusion into KF5, as it has happened already for e.g. 
> https://git.reviewboard.kde.org/r/119847/ and 
> https://git.reviewboard.kde.org/r/119848/ 
>     
>     - believes that 1st priority should be to get KDE4 in good shape on OSX, 
> which is why Nicolas wants to release KDE 4.13.3 this week and will proceed 
> with 4.14.x right afterwards,
>      
>     - needs decent user feedback with valuable backtraces which is why a 
> non-dysfunctional DrKonqi is required on all OSX versions, hence this RR.

Screw OSX ;-)

Afaiu DrKonqui is dysfunctional due to bugzilla server changes atm. (bug 
#337742) what means either this or review 
https://git.reviewboard.kde.org/r/120376/ more or less *has* to go into KDE SC4 
- regardless on whether it's required for exotic OS' or not.

@Ian, please attach Jekyll Wu, George Kiagiadakis, Matthias Fuchs and Dario 
Andres Rodriguez, they've been the main submitters to bugzillalib.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120431/#review67946
-----------------------------------------------------------


On Okt. 5, 2014, 4:27 vorm., Ian Wadham wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120431/
> -----------------------------------------------------------
> 
> (Updated Okt. 5, 2014, 4:27 vorm.)
> 
> 
> 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
> 
>

Reply via email to