Re: Aw: Re: KDE inclusion
* Joachim Eibl [2018-01-12 01:21:02 +0100]: > I had a try at it myself, but was quite overwhelmed about the big > changes in KF5. > > > > You have my blessing to use the name KDiff3. > Great news for a very useful tool! After having ported it to KDE4, I was also overwhelmed by the changes for KF5. Today I'm unfortunately forced to use the Qt version. Perhaps we should stick with that version and simply have it hosted and maintained as a KDE extragear project. -- Valentin Rusu IRC: valir
Re: Review Request 125056: Fix build on OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125056/#review88111 --- Ship it! Ship It! - Valentin Rusu On Oct. 26, 2015, 2:20 p.m., Samuel Gaist wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125056/ > --- > > (Updated Oct. 26, 2015, 2:20 p.m.) > > > Review request for kde-workspace, Jonathan Riddell and Valentin Rusu. > > > Repository: kwallet-pam > > > Description > --- > > Added implementation of pam_syslog and pam_vsyslog for OS X > > Added include dir setup to FindLibGcrypt > > add reviewboardrc > > > Diffs > - > > .reviewboardrc PRE-CREATION > CMakeLists.txt bfdcfda71ef5ba3b5e4247afe02af1c23d064783 > cmake/modules/FindLibGcrypt.cmake 27de0b46a82e92a24734476ea32401bef01a8ca8 > pam_darwin.h PRE-CREATION > pam_darwin.c PRE-CREATION > pam_kwallet.c a84585ef1fc3f4aeac728e707d52479ec85b5300 > > Diff: https://git.reviewboard.kde.org/r/125056/diff/ > > > Testing > --- > > Build on OS X 10.8 > > > Thanks, > > Samuel Gaist > >
Re: kwallet-query moved to kdereview
* Luigi Toscano [2015-06-14 13:32:26 +0200]: > Valentin Rusu ha scritto: > > > The kwallet-query tool is now part of KF5::Wallet. I'll now request > > kdereview/kwallet-query repository removal. > > src/runtime/kwallet-query/src/querydriver.cpp:153:47: error: ‘class > QByteArray’ has no member named ‘toStdString’ > std::cout << QJsonDocument(json).toJson().toStdString() << std::endl; > > Testing on Qt 5.3; as Frameworks is supposed to work with Qt 5.2, can you > please fix it? Fixed ! -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
* Valentin Rusu [2015-05-29 22:32:46 +0200]: > * David Narvaez [2015-05-28 09:53:55 -0400]: > > > On Sun, May 24, 2015 at 3:39 PM, Valentin Rusu wrote: > > > Hello, > > > > > > Seems to me that quite some time passed since my request and nobody > > > replied. Perhaps kde-utils is not the right place to put this small > > > utility in? > > > > > > Alternatively, I could include it in the runtime part of KWallet > > > framework. > > > > > > What would be right choice? > > > > Included it as part of the runtime of KWallet. There shouldn't be a > > need to get another repo with potentially irrelevant things to get a > > query tool for the KWallet framework. > > Well, I also think that this should be the right choice. I'll take care > of this if no-one is against it. The kwallet-query tool is now part of KF5::Wallet. I'll now request kdereview/kwallet-query repository removal. -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
* David Narvaez [2015-05-28 09:53:55 -0400]: > On Sun, May 24, 2015 at 3:39 PM, Valentin Rusu wrote: > > Hello, > > > > Seems to me that quite some time passed since my request and nobody > > replied. Perhaps kde-utils is not the right place to put this small > > utility in? > > > > Alternatively, I could include it in the runtime part of KWallet > > framework. > > > > What would be right choice? > > Included it as part of the runtime of KWallet. There shouldn't be a > need to get another repo with potentially irrelevant things to get a > query tool for the KWallet framework. Well, I also think that this should be the right choice. I'll take care of this if no-one is against it. > > David E. Narvaez > > PS.: Awesome tool. Thanks! -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
Hello, Seems to me that quite some time passed since my request and nobody replied. Perhaps kde-utils is not the right place to put this small utility in? Alternatively, I could include it in the runtime part of KWallet framework. What would be right choice? * Valentin Rusu [2015-05-03 23:17:06 +0200]: > Hello Raphael, > > The two weeks review period elapsed and meanwhile I did all the > suggested changes to the kwallet-query utility project. > > This utility may now be included into kdeutils. > > Do you agree with this inclusion? May I file the corresponding sysadmin > request? > > Thanks, > > * Valentin Rusu [2015-04-23 22:25:20 +0200]: > > > Hello, > > > > Please be advised sysadmins moved kwallet-query to kdereview for your > > constructive critics. > > > > You may found more informations about it here: > > https://barlog.rusu.info/valentin/blog/?p=386 > > > > This is a rather simple script and I think it should go to kde-utils. > > I'd like to write a manpage for it, buy AFAICT that's not the KDE way of > > doing it. On the other hand, the target users would not need the > > handbook, in my opinion. But I may be wrong. > > > > PS: > > I3 users may also be interested about this: > > https://github.com/valir/kwallet-dmenu > > > > -- > > Valentin Rusu > > IRC: valir > > -- > Valentin Rusu > IRC: valir -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
Hello Raphael, The two weeks review period elapsed and meanwhile I did all the suggested changes to the kwallet-query utility project. This utility may now be included into kdeutils. Do you agree with this inclusion? May I file the corresponding sysadmin request? Thanks, * Valentin Rusu [2015-04-23 22:25:20 +0200]: > Hello, > > Please be advised sysadmins moved kwallet-query to kdereview for your > constructive critics. > > You may found more informations about it here: > https://barlog.rusu.info/valentin/blog/?p=386 > > This is a rather simple script and I think it should go to kde-utils. > I'd like to write a manpage for it, buy AFAICT that's not the KDE way of > doing it. On the other hand, the target users would not need the > handbook, in my opinion. But I may be wrong. > > PS: > I3 users may also be interested about this: > https://github.com/valir/kwallet-dmenu > > -- > Valentin Rusu > IRC: valir -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
* Allen Winter [2015-04-23 17:32:32 -0400]: > On Thursday, April 23, 2015 10:25:20 PM Valentin Rusu wrote: > > Hello, > > > > This is a rather simple script and I think it should go to kde-utils. > > I'd like to write a manpage for it, buy AFAICT that's not the KDE way of > > doing it. > > But it is the old-timer way of doing it and I would very much appreciate a > manpage. manpage added -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
* Scott Kitterman [2015-04-23 17:10:12 -0400]: > Also, please add COPYING.LIB for LGPL 2, since that's the license you're > using > for the project. Added! -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
* Allen Winter [2015-04-23 17:32:32 -0400]: > On Thursday, April 23, 2015 10:25:20 PM Valentin Rusu wrote: > > This is a rather simple script and I think it should go to kde-utils. > > I'd like to write a manpage for it, buy AFAICT that's not the KDE way of > > doing it. > > But it is the old-timer way of doing it and I would very much appreciate a > manpage. I'd also like very much adding it. Can I use asciidoc for that? -- Valentin Rusu IRC: valir
Re: kwallet-query moved to kdereview
Thanks for the review! * Albert Astals Cid [2015-04-23 22:55:17 +0200]: > El Dijous, 23 d'abril de 2015, a les 22:25:20, Valentin Rusu va escriure: > > This is a rather simple script and I think it should go to kde-utils. > > I'd like to write a manpage for it, buy AFAICT that's not the KDE way of > > doing it. > > Yes there is. See for example > http://quickgit.kde.org/?p=dragon.git&a=tree&h=bd7c7b5b35d317843ca3f377be1d3c64d0af1087&hb=8fea297d688e63d379197344c7f1c0a265c146bd&f=doc AFAICT, that repo has a *KDE handbook*, and not a manpage one could read using the Unix *man* command. And I was suggesting the Unix manpage here. And BTW, what's the tool for authoring docbook files? > > You're missing a Messages.sh file. Added! I also added the catalog loading call. > > Cheers, > Albert > Cheers, -- Valentin Rusu IRC: valir
kwallet-query moved to kdereview
Hello, Please be advised sysadmins moved kwallet-query to kdereview for your constructive critics. You may found more informations about it here: https://barlog.rusu.info/valentin/blog/?p=386 This is a rather simple script and I think it should go to kde-utils. I'd like to write a manpage for it, buy AFAICT that's not the KDE way of doing it. On the other hand, the target users would not need the handbook, in my opinion. But I may be wrong. PS: I3 users may also be interested about this: https://github.com/valir/kwallet-dmenu -- Valentin Rusu IRC: valir
Re: Killing kdelibs master branch
On 11/08/14 00:23:15, Albert Astals Cid wrote: > Any objection? None from me. That would make it clear for everybody that the applications should start using KF5. > > Cheers, > Albert
Re: Review Request 117157: Unlock session via DBus
On Friday, April 04, 2014 10:08:36 PM Thomas Lübking wrote: > On Freitag, 4. April 2014 02:42:32 CEST, Michael Pyne wrote: > > Of course if an attacker is running code they'd probably just > > find it easier > > to open the .kwl directly and read the folder and key names, > > since apparently > > those are stored unencrypted, if the API docs are to be believed. > > Apparently is is changed with KSS and I frankly would have hoped that only > hashes are stored for this test? Only hashes are stored for this test - see my answer next to this message. > > Cheers, > Thomas -- Valentin Rusu irc: valir signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
On Thursday, April 03, 2014 08:42:32 PM Michael Pyne wrote: > On Fri, April 4, 2014 02:20:28 Valentin Rusu wrote: > > On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote: > > > In fact the list of folders and keys present in KWallet (though > > > not their values) can be queried without unlocking KWallet, or even > > > causing > > > it to prompt to unlock. > > > > Could you please elaborate more on the possibility to enumerate the keys > > without opening the wallet? > > From the KWallet::Wallet API docs: That's right, folder and entry names can be queried. However, KWallet data is entirely encrypted in the .kwl files. Only folder and entry name hashes are stored as-is, when using the classic backend. If using the GPG backend, all of the file contents is encrypted using QGPGME. > > bool Wallet::keyDoesNotExist(...): > > > > Determine if an entry in a folder does not exist in a wallet. > > > > This does not require decryption of the wallet. This is a handy > > optimization to avoid prompting the user if your data is certainly not in > > the wallet. > Wallet::folderDoesNotExist() has similar verbiage. > > "enumerating" is overstating the case here since there's no direct support > for enumerating folders or keys. But all the same, it's not hard at all to > brute- force potential folder or key names using the same method used to > guess valid Coinbase user identities that just hit the news. > > Of course if an attacker is running code they'd probably just find it easier > to open the .kwl directly and read the folder and key names, since > apparently those are stored unencrypted, if the API docs are to be > believed. Only folder and entry name hashes are to be found in the classic format .kwl file, as I described above. GPG wallets, on the other hand, are entirely encrypted. > > Note that there is a valid use case for this feature: It would be > tremendously annoying for a user to have to open their wallet just so an > application can verify if it does or does not have an entry stored in the > wallet. Instead the application can defer opening the wallet (and forcing > the password prompt0 until the value is actually needed. Well, that's true. That's why kwalletd compares key and folder names by hash value, for the classic backend. With GPG, the wallet is literally opened then queried. This won't prompt the password dialog though, courtesy gpg-agent. -- Valentin Rusu irc: valir signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote: > In fact the list of folders and keys present in KWallet (though > not their values) can be queried without unlocking KWallet, or even causing > it to prompt to unlock. > AFAIK, all data access operations on KWallet require it to be opened first (KWallet::openWallet). That will surely trigger password prompt for legacy encrypted wallets. The GPG back-end wallets only trigger pin entry the first time, subsequent requests would simply open the wallet, as GPG private key is already unlocked. Could you please elaborate more on the possibility to enumerate the keys without opening the wallet? -- Valentin Rusu irc: valir signature.asc Description: This is a digitally signed message part.
Re: KF5 Update Meeting Minutes 2014-w10
Hello, Catching up with KF5 progress... On Tuesday, March 04, 2014 04:59:58 PM Kevin Ottens wrote: > * Repository merges for kwallet and kdnssd still reported as pending... What's that? Is that about merging 4.xx repository with the KF5 one? > * afiestas has kwallet patches in need of review, valir being unresponsive > help is welcome; Reviewed! Nice piece of work, thanks! Regards, Valentin signature.asc Description: This is a digitally signed message part.
Re: Review Request 116555: Add support for pam-kwallet in kwalletd
> On March 3, 2014, 11:57 p.m., Albert Astals Cid wrote: > > The Beta 1 of 4.13 is on Wednesday. Can the maintainer of the code affected > > by this give a evaluation of how "dangerous" this patch is and his > > recommendation for the Freeze exception? Oh, I only see this now. Is it too late? - Valentin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116555/#review51842 --- On March 2, 2014, 11:33 p.m., Àlex Fiestas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116555/ > --- > > (Updated March 2, 2014, 11:33 p.m.) > > > Review request for KDE Runtime, Release Team and Valentin Rusu. > > > Repository: kde-runtime > > > Description > --- > > This patch adds support for pam-kwallet (in my scratch right now, to be > released soon). > > This is how the new pam works, and why this patch is needed: > > In order to open the wallet in a secure way we have to try hard to not send > the hash on an > insecure manner. This is how we achieve that: > > -pam_kwallet creates a pipe. > -pam_kwallet opens a local socket listening somewhere (/tmp/foo.socket for > example). > -pam_kwallet forks+execv kwallet, passing via arguments the sockets (pipe and > local socket). > -pam_kwallet sends the hash via the pipe. > -kwalletd gets the hash and waits for the environment. > -startkde uses "socat" to send the environment to kwalletd. > -kwalletd setups the environment before any Qt code is executed. > -kwalletd resumes execution. > > With this way of executing kwallet we get: > -pam_kwallet knows to who it is sending the hash (its on child). > -hash is never revealed on shared memory (dbus), since pipes are private to > the apps. > -ptrace is usually disabled so only root can see the hash on the app memory > -no Qt code is executed without the proper environment (same as startkde) > -if kwalletd is executed normally (not from pam_kwallet) then it is business > as usual. > > The patch also comes with integration tests that simulate how kwalletd is > executed in the pam module. > > For the release team, I would love to add this to 4.13, after all it is > innocuous if kwalletd is not executed via pam_module. > > > Diffs > - > > kwalletd/CMakeLists.txt e9aef16 > kwalletd/autotests/CMakeLists.txt PRE-CREATION > kwalletd/autotests/kdewallet.kwl PRE-CREATION > kwalletd/autotests/kwalletexecuter.h PRE-CREATION > kwalletd/autotests/kwalletexecuter.cpp PRE-CREATION > kwalletd/autotests/qtest_kwallet.h PRE-CREATION > kwalletd/autotests/testpamopen.cpp PRE-CREATION > kwalletd/autotests/testpamopennofile.cpp PRE-CREATION > kwalletd/main.cpp f9af414 > > Diff: https://git.reviewboard.kde.org/r/116555/diff/ > > > Testing > --- > > > Thanks, > > Àlex Fiestas > >
Re: Review Request 116555: Add support for pam-kwallet in kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116555/#review52218 --- Ship it! Ship It! - Valentin Rusu On March 2, 2014, 11:33 p.m., Àlex Fiestas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116555/ > --- > > (Updated March 2, 2014, 11:33 p.m.) > > > Review request for KDE Runtime, Release Team and Valentin Rusu. > > > Repository: kde-runtime > > > Description > --- > > This patch adds support for pam-kwallet (in my scratch right now, to be > released soon). > > This is how the new pam works, and why this patch is needed: > > In order to open the wallet in a secure way we have to try hard to not send > the hash on an > insecure manner. This is how we achieve that: > > -pam_kwallet creates a pipe. > -pam_kwallet opens a local socket listening somewhere (/tmp/foo.socket for > example). > -pam_kwallet forks+execv kwallet, passing via arguments the sockets (pipe and > local socket). > -pam_kwallet sends the hash via the pipe. > -kwalletd gets the hash and waits for the environment. > -startkde uses "socat" to send the environment to kwalletd. > -kwalletd setups the environment before any Qt code is executed. > -kwalletd resumes execution. > > With this way of executing kwallet we get: > -pam_kwallet knows to who it is sending the hash (its on child). > -hash is never revealed on shared memory (dbus), since pipes are private to > the apps. > -ptrace is usually disabled so only root can see the hash on the app memory > -no Qt code is executed without the proper environment (same as startkde) > -if kwalletd is executed normally (not from pam_kwallet) then it is business > as usual. > > The patch also comes with integration tests that simulate how kwalletd is > executed in the pam module. > > For the release team, I would love to add this to 4.13, after all it is > innocuous if kwalletd is not executed via pam_module. > > > Diffs > - > > kwalletd/CMakeLists.txt e9aef16 > kwalletd/autotests/CMakeLists.txt PRE-CREATION > kwalletd/autotests/kdewallet.kwl PRE-CREATION > kwalletd/autotests/kwalletexecuter.h PRE-CREATION > kwalletd/autotests/kwalletexecuter.cpp PRE-CREATION > kwalletd/autotests/qtest_kwallet.h PRE-CREATION > kwalletd/autotests/testpamopen.cpp PRE-CREATION > kwalletd/autotests/testpamopennofile.cpp PRE-CREATION > kwalletd/main.cpp f9af414 > > Diff: https://git.reviewboard.kde.org/r/116555/diff/ > > > Testing > --- > > > Thanks, > > Àlex Fiestas > >
Re: Review Request 115497: Replace SHA with PBKDF2-SHA512+Salt
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115497/#review49490 --- Ship it! One the issue around minor version check is done, feel free to commit it! - Valentin Rusu On Feb. 10, 2014, 5:43 p.m., Àlex Fiestas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115497/ > --- > > (Updated Feb. 10, 2014, 5:43 p.m.) > > > Review request for KDE Runtime, Teo Mrnjavac and Valentin Rusu. > > > Repository: kde-runtime > > > Description > --- > > Uses the MINOR_VERSION (which until now it was 0) to upgrade the hash from > SHA to PBKDF2-SHA512+salt. > I would have loved to completely replace it once the wallet is ported to the > new hashing but because > of kwalletd code that is not possible without a bigger rewrite. > > There are 2 reasons for this patch: > 1-We avoid using our own implementation of SHA > 2-We use a modern hashing technique > > I'm cooking more patches to use the system user password to open the wallet, > we want that password to be > hashed using PBKDF2_SHA512 for security reasons. > > > Diffs > - > > CMakeLists.txt 275a6c7 > cmake/modules/FindLibGcrypt.cmake PRE-CREATION > kwalletd/backend/CMakeLists.txt 5a5837c > kwalletd/backend/backendpersisthandler.cpp bdef6ca > kwalletd/backend/kwalletbackend.h 83ebf7f > kwalletd/backend/kwalletbackend.cc e4d461c > > Diff: https://git.reviewboard.kde.org/r/115497/diff/ > > > Testing > --- > > > Thanks, > > Àlex Fiestas > >
Re: Review Request 115497: Replace SHA with PBKDF2-SHA512+Salt
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115497/#review49487 --- kwalletd/backend/kwalletbackend.cc <https://git.reviewboard.kde.org/r/115497/#comment34903> The error logic should be more strict here, I think. In fact we loose the "unknown version" return code. - Valentin Rusu On Feb. 10, 2014, 5:43 p.m., Àlex Fiestas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115497/ > --- > > (Updated Feb. 10, 2014, 5:43 p.m.) > > > Review request for KDE Runtime, Teo Mrnjavac and Valentin Rusu. > > > Repository: kde-runtime > > > Description > --- > > Uses the MINOR_VERSION (which until now it was 0) to upgrade the hash from > SHA to PBKDF2-SHA512+salt. > I would have loved to completely replace it once the wallet is ported to the > new hashing but because > of kwalletd code that is not possible without a bigger rewrite. > > There are 2 reasons for this patch: > 1-We avoid using our own implementation of SHA > 2-We use a modern hashing technique > > I'm cooking more patches to use the system user password to open the wallet, > we want that password to be > hashed using PBKDF2_SHA512 for security reasons. > > > Diffs > - > > CMakeLists.txt 275a6c7 > cmake/modules/FindLibGcrypt.cmake PRE-CREATION > kwalletd/backend/CMakeLists.txt 5a5837c > kwalletd/backend/backendpersisthandler.cpp bdef6ca > kwalletd/backend/kwalletbackend.h 83ebf7f > kwalletd/backend/kwalletbackend.cc e4d461c > > Diff: https://git.reviewboard.kde.org/r/115497/diff/ > > > Testing > --- > > > Thanks, > > Àlex Fiestas > >
Re: Review Request 115497: Replace SHA with PBKDF2-SHA512+Salt
> On Feb. 5, 2014, 7:18 p.m., Michael Pyne wrote: > > kwalletd/backend/kwalletbackend.cc, line 635 > > <https://git.reviewboard.kde.org/r/115497/diff/1/?file=242022#file242022line635> > > > > Seems to be no error checking here, if this fails and we overwrite the > > hashed passwords on disk, couldn't there be data loss when we try to > > re-open them (when the user can't guess the key)? > > Àlex Fiestas wrote: > Added a runtime check to decide if we shuold swap or not the hashes, also > checking it in BlowfishPersistHandler::write. > > This will fix the following usecase: > -KWallet uses SHA1 to read > -KWallet uses PBKDF2 to write, but BKDF2 hash is null > > For other cases we can't add much fallback since Backend::setPassword > returns void, and no other code using it checks for errors in anyway. feel free to add a return value to it, if that's needed. - Valentin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115497/#review49065 --- On Feb. 10, 2014, 5:43 p.m., Àlex Fiestas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115497/ > --- > > (Updated Feb. 10, 2014, 5:43 p.m.) > > > Review request for KDE Runtime, Teo Mrnjavac and Valentin Rusu. > > > Repository: kde-runtime > > > Description > --- > > Uses the MINOR_VERSION (which until now it was 0) to upgrade the hash from > SHA to PBKDF2-SHA512+salt. > I would have loved to completely replace it once the wallet is ported to the > new hashing but because > of kwalletd code that is not possible without a bigger rewrite. > > There are 2 reasons for this patch: > 1-We avoid using our own implementation of SHA > 2-We use a modern hashing technique > > I'm cooking more patches to use the system user password to open the wallet, > we want that password to be > hashed using PBKDF2_SHA512 for security reasons. > > > Diffs > - > > CMakeLists.txt 275a6c7 > cmake/modules/FindLibGcrypt.cmake PRE-CREATION > kwalletd/backend/CMakeLists.txt 5a5837c > kwalletd/backend/backendpersisthandler.cpp bdef6ca > kwalletd/backend/kwalletbackend.h 83ebf7f > kwalletd/backend/kwalletbackend.cc e4d461c > > Diff: https://git.reviewboard.kde.org/r/115497/diff/ > > > Testing > --- > > > Thanks, > > Àlex Fiestas > >
Re: Review Request 115497: Replace SHA with PBKDF2-SHA512+Salt
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115497/#review49485 --- - Valentin Rusu On Feb. 10, 2014, 5:43 p.m., Àlex Fiestas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115497/ > --- > > (Updated Feb. 10, 2014, 5:43 p.m.) > > > Review request for KDE Runtime, Teo Mrnjavac and Valentin Rusu. > > > Repository: kde-runtime > > > Description > --- > > Uses the MINOR_VERSION (which until now it was 0) to upgrade the hash from > SHA to PBKDF2-SHA512+salt. > I would have loved to completely replace it once the wallet is ported to the > new hashing but because > of kwalletd code that is not possible without a bigger rewrite. > > There are 2 reasons for this patch: > 1-We avoid using our own implementation of SHA > 2-We use a modern hashing technique > > I'm cooking more patches to use the system user password to open the wallet, > we want that password to be > hashed using PBKDF2_SHA512 for security reasons. > > > Diffs > - > > CMakeLists.txt 275a6c7 > cmake/modules/FindLibGcrypt.cmake PRE-CREATION > kwalletd/backend/CMakeLists.txt 5a5837c > kwalletd/backend/backendpersisthandler.cpp bdef6ca > kwalletd/backend/kwalletbackend.h 83ebf7f > kwalletd/backend/kwalletbackend.cc e4d461c > > Diff: https://git.reviewboard.kde.org/r/115497/diff/ > > > Testing > --- > > > Thanks, > > Àlex Fiestas > >
Re: KF5 Update Meeting Minutes 2014-w5
On Tuesday, January 28, 2014 04:40:51 PM Kevin Ottens wrote: > * teo is planning to help on the kwallet and secret service front; > * he's waiting to hear back from valentin rusu; teo already contacted me, suggesting IRC meeting during working hours. Unfortunately, I won't be able to attend, as I'm also working during these hours, at my job where I don't have IRC (perhaps I should try IRC on my android?) I'm also being happy to see him tinkering KDE during working hours! > * he's also looking into QtKeyChain; That would be great! -- Valentin Rusu irc: valir signature.asc Description: This is a digitally signed message part.
Re: Review request: kde-runtime/kwalletd branch kwalletd-gpg
On 08/17/2013 03:31 PM, Albert Astals Cid wrote: > El Dissabte, 17 d'agost de 2013, a les 14:22:35, Valentin Rusu va escriure: >> Hello, >> >> kwalletd now supports GPG encryption. The code is fully functional, at >> least on my system, and I pushed it to the kwalletd-gpg branch of >> kde-runtime. >> See my blog post for more information: >> http://www.rusu.info/wp/?p=248 >> >> I'd like now to ask you to review the code before merging it to the >> master. And speaking about the master, I'd also like to know what would >> be the good timing to do it, as 4.11 is a long-term support version. > > If the review goes fine, just merge it for kde-runtime 4.12(master). Well, I finally merged it to the master, so it'll get into 4.12. Any comments welcome. I'll also be there for the bugreports. But on my system this backend works quite well. Regards, Valentin signature.asc Description: OpenPGP digital signature
Re: KF5 kwallet, kwalletd and wallet manager questions
On 08/28/2013 07:05 PM, Christoph Feck wrote: > On Saturday 24 August 2013 12:31:20 Valentin Rusu wrote: >> Hello, >> >> Now that frameworks splitting is almost done ;-) with some people >> even running KF5-based sessions on their systems, I'd like to plan >> kwallet porting and integration. BTW, I'd like also to announce >> that I agreed with Michael Leupold to take over the maintainership >> [...] > > Nice to see you stepping up to the plate :) Could you please inform > bugzilla maintainers to change the default assignee address for > kwalletmanager and kdelibs/kwallet? OK, I filed a sysadmin request for this. Regards, Valentin signature.asc Description: OpenPGP digital signature
Re: KF5 kwallet, kwalletd and wallet manager questions
On 08/24/2013 01:43 PM, Albert Astals Cid wrote: > El Dissabte, 24 d'agost de 2013, a les 12:31:20, Valentin Rusu va escriure: >> >> * Another piece of software related to kwallet is KWalletManager from >> kdeutils. I think that component should also be detached from kdeutils >> and attached under kwallet/src/manager. I can also handle this task if >> that's OK (Aron, David, Kevin but also Raphael?) > > Not sure this bundling makes sense. KWalletManager is a tool that if i am a > developer for Windows that wants to use the kwallet framework I don't need. > Actually it's a utility a regular user should probably never need unless you > use it to manually store stuff (I do) or you want to inspect what apps store > (I do). I also use the KWalletManager on windows as a secret storing tool, at my workplace. The other KDE components I use at work do not seem to use the kwalletd. Chrome for Windows do not detect kwallet as it does under Linux. So, AFAICT, Windows users are interested by using KWalletManager, and this requires kwalletd, which is packaged separately. I think that even for this case we should bundle these components together. That would also help other contributors better understand kwallet's structure and allow them contribute more easily. > > Of course I don't have much of a decision power on this but wanted to express > my concerns ;-) > > Cheers and congratulations for your new maintainership, > Albert > Thanks signature.asc Description: OpenPGP digital signature
Re: KF5 kwallet, kwalletd and wallet manager questions
On 08/24/2013 02:32 PM, Kevin Krammer wrote: > On Saturday, 2013-08-24, Albert Astals Cid wrote: >> El Dissabte, 24 d'agost de 2013, a les 12:31:20, Valentin Rusu va escriure: >>> >>> * AFAIK, frameworks should be independent and self-contained. kwallet >>> depends on kde-runtime/kwalletd. This component should be detached from >>> kde-runtime sources and attached inside kwallet/src/kwalletd, preserving >>> history if possible. I can handle this task if that's OK for you (Aron, >>> David, Kevin?) >> >> This makes sense and AFAIK is what is intended with frameworks, i.e. if a >> lib needs a binary, that binary and the lib should be shipped together > > One thing that could be put into consideration is whether the library/API > would work with any SecretService implementation or require kwalletd > specifically. The kwallet API is only implemented by kwalletd AFAIK. So for this API's cas, we should provide kwalletd along with it. The new secret service API, on the other hand, is likely to have several implementation. In that cas, the daemon should not be systematically tied-in. I think that future versions of the kwallet framework will have configure options, to let packagers/users choose what to install. signature.asc Description: OpenPGP digital signature
KF5 kwallet, kwalletd and wallet manager questions
Hello, Now that frameworks splitting is almost done ;-) with some people even running KF5-based sessions on their systems, I'd like to plan kwallet porting and integration. BTW, I'd like also to announce that I agreed with Michael Leupold to take over the maintainership of KWallet and I'm now committed to do that. I also plan to add new features to kwallet, as some of you may remember from our Randa discussions. But I'll make another announcement(s) regarding these new features and ksecretsservice. Here are my questions about kwallet in KF5: * what tier will kwallet end-in? Note that kwallet.h is included only by khtml, whose tier is not yet defined * AFAIK, frameworks should be independent and self-contained. kwallet depends on kde-runtime/kwalletd. This component should be detached from kde-runtime sources and attached inside kwallet/src/kwalletd, preserving history if possible. I can handle this task if that's OK for you (Aron, David, Kevin?) * Another piece of software related to kwallet is KWalletManager from kdeutils. I think that component should also be detached from kdeutils and attached under kwallet/src/manager. I can also handle this task if that's OK (Aron, David, Kevin but also Raphael?) * kwallet is now in staging ; should I wait for it to go to it's final tier? I can do this tier adjusting changing task and I'd also like to start these tasks as quick as possible. Thanks for reading and I'd be grateful for a quick reply on these topics. Regards, -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement) signature.asc Description: OpenPGP digital signature
Review request: kde-runtime/kwalletd branch kwalletd-gpg
Hello, kwalletd now supports GPG encryption. The code is fully functional, at least on my system, and I pushed it to the kwalletd-gpg branch of kde-runtime. See my blog post for more information: http://www.rusu.info/wp/?p=248 I'd like now to ask you to review the code before merging it to the master. And speaking about the master, I'd also like to know what would be the good timing to do it, as 4.11 is a long-term support version. But let's do things one after another and let's start with the feedback I'll welcome from all of you. I'm also wondering if I should I use reviewboard for this feature, knowing that's best to actually clone and run the code in order to test it, and reviewboard only let us read the code? Regards, -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement) signature.asc Description: OpenPGP digital signature
Re: KF5 Update Meeting 2013-w20
On Wednesday 15 May 2013 21:07:43 Alexander Neundorf wrote: > On Wednesday 15 May 2013, Kevin Ottens wrote: > > Hello all, > > > > So yesterday 4pm (Paris timezone :p) as planned we had the first update > > is it planned to have those meetings sometimes also later in the day ? > At 4pm I'm at work, and so can't attend. Same for me. At 4pm I'm at work. And my regular job is not for KDE ;-) -- Valentin Rusu (vrusu) IRC: valir
macro_log_feature : setting max version
Hello, This issue is triggered by kopete's OTR plugin that stopped compiling with LibOTR 4.0.0 because it undergone some imported structure changes. Pali Rohar managed to modify the FindLibOTR.cmake, we now set-up a version range starting with 3.2.0 (initial requirement) to 4.0.0 and kopete compiles by excluding the offending, too recent, LibOTR. However, the final cmake status outputs this : - -- The following OPTIONAL packages could NOT be located on your system. -- Consider installing them to enable more features from this software. - * libotr (3.2.0 or *higher*) <http://www.cypherpunks.ca/otr> A library to encrypt messages with Off-the-Record encryption (versions 3.2.0 to 4.0.0) Required for the Kopete otr plugin. I think tat a more elegant output message would state : * libotr (3.2.0 to 4.0.0) But the macro does not have a _maxVersion parameter. How about adding it? Would it be OK to add such a parameter? -- Valentin Rusu (vrusu) IRC: valir
Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace
On Friday 03 May 2013 14:39:31 Aaron J. Seigo wrote: > On Friday, May 3, 2013 14:11:02 Kevin Kofler wrote: > > project works (as a distro patch), KSecrets never got finished after the > > kdelibs patch was rejected. > > a completely workable approach was suggested. the work on ksecrets started > and stopped a couple times. at one point it was tested for inclusion and > apparently it did not work in some configurations (i forget the exact > issue; it was quite a while ago and the discussion iirc was on > kde-packager?). but usefully, it progressed quite far. KSecrets is on hold and I was asked to help with KF5 development. I'll resume it's development when I'll get a working KF5-based environement. The plug-in approach was OK, but why develop something for a platform set ready for deprecation? -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Tuesday 05 February 2013 00:28:37 Till Schäfer wrote: > 2. While typing a search phrase the tree elements are collapsed and need to > be opened by hand. This leads to three more clicks: > - - open the folder > - - the category (passwords, pairs, binary data, ...) > - - select the entry > I suggest to directly select the first item that matches the search phrase > and open all folders which contain matching entries. > > 3. The search field does not have the focus when opening a wallet. You need > to click in the field to start typing. It may be a good thing to have the > focus directly in the search field, so that you can start typing > immediately. These two items are now implemented. The code is still in the ui-refactor branch of kdeutils/kwallet. I plan to request ui-refactor branch review soon. Hopefully we'll get this refactoring out in time for 4.11. Best regards, -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Tuesday 12 February 2013 14:10:23 Aurélien Gâteau wrote: > Le Wednesday 06 February 2013 23:14:59 Valentin Rusu a écrit : > > > Thanks, I understand it better now. Assuming it was also possible to > > > get > > > a list of the authorized applications, I created a new revision of the > > > mockups which show the list of currently connected applications as well > > > as the list of authorized applications: > > > > > > http://agateau.com/tmp/kwalletmanager/3/ > > > > > > I think it is good to create a separate tab for those because this way > > > the application can provide an explanation of the list(s). Being not > > > intimate with the way KWalletManager works, I didn't understand what > > > the > > > "Disconnect" button would do. This may happen to others as well :) > > > > Nice proposal. I'll stick with your sketch as it'll provide also for the > > future, when we'll switch to ksecretsservice. Thanks. > > Great! Well, you can now see the results in kdeutils/kwallet:ui-refactor branch. Any feedback? Oh, in order to get the menus correctly built, you may want to do the "make install" from the ui-refactor branch. However, don't be afraid as the code is pretty stable - I'm already using it on my system. :) -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Sunday 03 February 2013 17:50:05 Andrei Sebastian Cîmpean wrote: On Sunday 03 February 2013 16:40:04 Anders Lund wrote: > Søndag den 3. februar 2013 14:50:33 skrev Valentin Rusu: > Great to get rid of that extra window! What I think is why even the > graphical representation of it? How many people have more than one wallet? > And would they loose functionality if the option to switch was represented > by a menu (Files->Wallet->)? > > Anders > Or just show the pane if there are more than one wallets. This is now done, e.g. the wallet list only shows when user has more than one wallet. The code is not yet merged to master, but you can check the "ui-refactor" branch if you're feeling adventurous :) -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: Introducing a plugin loading approach inside of the KWallet convenience API
Sorry for the late reply. I only see this message now. On Monday 14 January 2013 17:07:50 Alex Fiestas wrote: > Is this Frameworks5 material only? Or could be backported to kdelibs master? > > I know that kdelibs master is frozen, but I remember that we talked months > ago to do an exception, but I don't remember if we decided to do it or not. Well, it was decided to look to the future, and to bring this to KF5. Currently there are no plans to put this new feature in KDE4.x -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: Review Request 108237: [Bug 286768] Duplicate entries in KWallet default wallet comboBox
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108237/#review27022 --- Ship it! Ship It! - Valentin Rusu On Jan. 21, 2013, 10:35 p.m., Maciej Sitarz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108237/ > --- > > (Updated Jan. 21, 2013, 10:35 p.m.) > > > Review request for kdelibs. > > > Description > --- > > Fix for Bug 286768 > This patch fixes duplicate entries in "Default wallet" combobox. > > "Local Wallet" combobox could be also wrong as it used currentIndex of > "Default Wallet" combobox > > > Diffs > - > > konfigurator/konfigurator.cpp 3cc1b3f08feb0feb1aa70028508ce5041fefd9f3 > > Diff: http://git.reviewboard.kde.org/r/108237/diff/ > > > Testing > --- > > Tested on Archlinux and KDE 4.9.5 > > > Thanks, > > Maciej Sitarz > >
Re: kwalletmanager ui refactor
On Wednesday 06 February 2013 14:28:17 Aurélien Gâteau wrote: > On 05.02.2013 21:34, Valentin Rusu wrote: > >> > >> I assumed the "Disconnect" button listed applications authorized to > >> access > >> the wallet. The "Authorized applications" tab was thus another way > >> to show > >> its content. But it seems I got it wrong. What does the "Disconnect" > >> button > >> really list? > > > > kwalletd keeps track of the applications that open wallets. It's dbus > > interface provide a command to selectively disconnect an application > > from it. > > kwalletmanager obtains the list of the applications connected to the > > current > > wallet and build from it the popup menu under the "disconnect" > > button. > > Thanks, I understand it better now. Assuming it was also possible to > get > a list of the authorized applications, I created a new revision of the > mockups which show the list of currently connected applications as well > as the list of authorized applications: > > http://agateau.com/tmp/kwalletmanager/3/ > > I think it is good to create a separate tab for those because this way > the application can provide an explanation of the list(s). Being not > intimate with the way KWalletManager works, I didn't understand what > the > "Disconnect" button would do. This may happen to others as well :) > Nice proposal. I'll stick with your sketch as it'll provide also for the future, when we'll switch to ksecretsservice. Thanks. > It's worth asking however if users really need a list of the > applications currently accessing the wallet. I have the feeling users > are more concerned about which applications are allowed to read their > wallet than which applications are currently doing so, but maybe I am > missing a situation in which one would want to disconnect applications? Well, it's also about providing application information for hackers. Why hide information if it's freely available? :-) -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Tuesday 05 February 2013 10:49:55 Aurélien Gâteau wrote: > > > 2. The disconnect button should be kept, in my opinnion. Here is a screen > > capture with the disconnect menu for my main wallet: > > http://imgur.com/JG6rr8b > > > > And here is another one showing the capture for another test wallet: > > http://imgur.com/UsKIfwH > > > > The menu entries are obtained from kwalletd which keeps track of it's > > clients. > > > > 4. Autorized applications tab - well I think that's not a bad idea to get > > it from kwallet settings here. This would be simply about managing access > > rights, isn't it :-) > > I assumed the "Disconnect" button listed applications authorized to access > the wallet. The "Authorized applications" tab was thus another way to show > its content. But it seems I got it wrong. What does the "Disconnect" button > really list? kwalletd keeps track of the applications that open wallets. It's dbus interface provide a command to selectively disconnect an application from it. kwalletmanager obtains the list of the applications connected to the current wallet and build from it the popup menu under the "disconnect" button. > > > Finally, here is my slightly adjusted sketch version: > > http://www.rusu.info/kwalletmanager/ > > As you said, this looks closely like my second version :) Nice! -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Monday 04 February 2013 22:08:49 Aurélien Gâteau wrote: > Le Monday 04 February 2013 20:55:12 Albert Astals Cid a écrit : > > El Dilluns, 4 de febrer de 2013, a les 19:28:42, Aurélien Gâteau va > > escriure: > > > Le Sunday 03 February 2013 14:50:33 Valentin Rusu a écrit : > > Having said so, the current mockup does not really need so much vertical > space and the line where I put the "More..." button is not really a > toolbar, so I think a classic menubar can be used here. I just pushed a new > mockup (in http://agateau.com/tmp/kwalletmanager/2 ) Oh! I oversaw your message, but finally the results was almost the same when I posted my update in this thread :) http://www.rusu.info/kwalletmanager/ So this starts settling. I'll come back here when this new design will be done. -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Monday 04 February 2013 19:28:42 Aurélien Gâteau wrote: > Le Sunday 03 February 2013 14:50:33 Valentin Rusu a écrit : > > A screen capture is far better than a hundred words so here it is: > > http://imgur.com/MD3GDxO > > Hey, > > Nice work! Thanks! > I put together a mockup which reorganize the buttons and split > the "Wallet" menu. I think it make things easier to understand. You can > find it here: > > http://agateau.com/tmp/kwalletmanager/ OK, I get the idea. Thanks for the sketches! Here is my feedback : 1. The main problem is about the two buttons "new folder" and "delete folder". Just take a look to the existing wallet editor. Right clicking in the tree list, the one wich shows the folders, have a contextual menu, depending on what it's right clicked: - on folders you get "new folder" and "delete this folder", - on folder items you get "new ..." - on passwords you get "new", "rename". If right clicking in this list seems not to be obvious for the users, maybe we could put a text hint saying "right click the list above" instead of the buttons? However, I doubt users will not try right click, as this is largely used by all the applications out-there. And it'll keep the ui less cluttered. 2. The disconnect button should be kept, in my opinnion. Here is a screen capture with the disconnect menu for my main wallet: http://imgur.com/JG6rr8b And here is another one showing the capture for another test wallet: http://imgur.com/UsKIfwH The menu entries are obtained from kwalletd which keeps track of it's clients. 3. The "more" button, which is the "wallet..." button in my proposal, should be removed as per Albert's suggestion, and the actions should be merged to the existing "file" menu. I'd keep only the "open/close" and "disconnect" buttons. 4. Autorized applications tab - well I think that's not a bad idea to get it from kwallet settings here. This would be simply about managing access rights, isn't it :-) Finally, here is my slightly adjusted sketch version: http://www.rusu.info/kwalletmanager/ Cheers, -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Monday 04 February 2013 03:03:13 Matthew Dawson wrote: > On February 3, 2013 04:51:49 PM Thomas Lübking wrote: > > Btw: does anybody actually use the systray thing? > > I need to see that window ~ once a week and then just launch the > > walletmanager (so the systray icon is disabled, but that's afaik not the > > default, is it?) > > Is it really necessary to have a systray icon anyways? Or would it better > to use some alternate way to deal with wallets? The icon seems to provide > only three options: > > 1) Configure KWallet > 2) Close all wallets > 3) Launch the main UI. > > Instead of launching an extra program in the background for those functions, > would we be better serviced by a plasmoid applet for dealing with 1+2+3 (or > just 2+3) and using an application shortcut for 3? Well, I actually plan to put in some QML UI, especially for the moment when ksecretsservice will become available. > > Having an extra program running in the background seems like a waste of > resources for such a simple task. Instead it could be launched only when > necessary, and the applet would handle the quick use cases. I'd think in > the long run that would be the best solution for all. The wallet manager is not necessary to run in background. As a matter of fact, it's even not needed most of the time. For that to happen, it's enough to uncheck the "show manager in system tray" in system settings/account details/kde wallet. > > Matthew -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Sunday 03 February 2013 13:34:24 Michael Pyne wrote: > On Sunday, February 03, 2013 14:50:33 Valentin Rusu wrote: > > > > During last days I finally sat down and did a ui-refactor and now > > kwalletmanager handles all the wallets inside a single, KPageWidget based > > design. A screen capture is far better than a hundred words so here it is: > > http://imgur.com/MD3GDxO > > It looks great! One thing I'd add is that it seemed to inherit the old > kwalletmanager size, which is too small for the new layout; perhaps ignore > the old saved size and prefer sizeHint if the old size is < sizeHint (or > just have a kconf_update script which removes the old saved size?) Oh, that's not really the case. It's a size I arbitrarily decided :) However, I'll add code to save window size to the rc file. I don't intend to save window position though, to avoid troubles on multiple screens. Or perhaps should I? > > P.S. For those wondering how best to review in the face of the source code > being moved around, try this git command line: > > $ git diff -M -C origin/master..origin/ui-refactor > > -M tries to find renames, -C tries to find copies (not that there should be > any here). > > If you just want to see a summary you can put add --stat (but you might want > to try --stat=120 to use more width, other you'll only see partial renames) Wonderful git tip! However, the reviewer should keep in mind I started the ui-refactor just after master commit f7ef5aa7cf2b35b3c942acc879 and since then I see two new commits to master. Thanks -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Sunday 03 February 2013 16:51:49 Thomas Lübking wrote: > On Sonntag, 3. Februar 2013 16:40:04 CEST, Anders Lund wrote: > > Great to get rid of that extra window! What I think is why even > > the graphical > > representation of it? How many people have more than one wallet? And would > > they loose functionality if the option to switch was represented by a menu > > (Files->Wallet->)? > > One could maybe conditionally hide the pageview (because the majortiy of > ppl. will not be interested in > 1 wallets but those who are will then > likely prefer a more direct access?) > > Btw: does anybody actually use the systray thing? I'm actually using it. I prefer clicking the tray icon if it's present instead of keying-in ALT+F2. > I need to see that window ~ once a week and then just launch the > walletmanager (so the systray icon is disabled, but that's afaik not the > default, is it?) Yes, that's not the default, but one could disable the tray icon in wallet system settings. Cheers, -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Sunday 03 February 2013 16:40:04 Anders Lund wrote: > Søndag den 3. februar 2013 14:50:33 skrev Valentin Rusu: > > > > During last days I finally sat down and did a ui-refactor and now > > kwalletmanager handles all the wallets inside a single, KPageWidget based > > design. A screen capture is far better than a hundred words so here it is: > > http://imgur.com/MD3GDxO > > Great to get rid of that extra window! What I think is why even the > graphical representation of it? How many people have more than one wallet? > And would they loose functionality if the option to switch was represented > by a menu (Files->Wallet->)? Well, you're perhaps right. I personnaly don't use more than wallet also. However, care should be taken not to induce regressions for those who use several wallets. And the code is already there :) -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
kwalletmanager ui refactor
Hello, Lots of us are frequently using kwalletmanager to get/store the secrets for the ever extending sensitive information. We click it's icon to pop the main window, then double click the main wallet icon to pop another window, that will eventually go to the second display (that's my case). Perhaps you put aside a quick thought that this should be changed, but return to the task under hand. And then forget about this until you'll next need to use kwalletmanager. :-) During last days I finally sat down and did a ui-refactor and now kwalletmanager handles all the wallets inside a single, KPageWidget based design. A screen capture is far better than a hundred words so here it is: http://imgur.com/MD3GDxO As you may see, the ancien kwalleteditor window moved inside a KPageWidgetItem. All the legacy code was left untouched. Only slight adjustements were done, to allow ui objects reference changes. I tried to preserve as much code history as possible. This also prevents regressions. The sources layout was also slightly changed to be more KF5 compliant. There's now a src subdirectory that has a manager and a konfigurator subdirectory. All this refactoring was done in a dedicated branch named "ui-refactor" I just pushed to the main repository. The application is fully functional and you can just checkout that branch, compile and replace your current kwalletmanager ;-) Next things to be done are: - review these changes - here I need your precious feedback - implementing features you may suggest - update the handbook - merge the code to the main branch when decided Thanks, PS I'd like to say a big *thank you* to the *gammaray* team who did a really great tool that showed very handy when analysing existing ui layout. -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: Introducing a plugin loading approach inside of the KWallet convenience API
On 10/29/2012 07:07 PM, Albert Astals Cid wrote: Can we please please plase be sure this time it works? Don't want to repeat the fiasco we had with ksecretservice that was introduced in 4.8 and then removed in 4.9 since it wasn't really working. Well, this time I'll do things more carefully, on a step-by-step basis. I cannot afford another "remove" step :-) This step is the first one, as decided at the time when we backed-up - see the link [2] below. It only takes the existing kwallet code in put it into a plugin. I'm currently running with this setup with no issues, on my system. Cheers, Albert Cheers, El Diumenge, 28 d'octubre de 2012, a les 19:42:29, Valentin Rusu va escriure: [2] http://mail.kde.org/pipermail/kde-utils-devel/2011-November/000705.html -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Introducing a plugin loading approach inside of the KWallet convenience API
On 10/28/2012 08:43 PM, Thiago Macieira wrote: On domingo, 28 de outubro de 2012 19.42.29, Valentin Rusu wrote: Any thoughts about this? Yes: why do you need plugins? From the description, you could do both with simple classes inside the library. Unless you need to link to the secret services library, if there's one. That's precisely the point. Actually, such a library do exists and it's intended to supersede KWallet. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Introducing a plugin loading approach inside of the KWallet convenience API
Hello, After quite a while of being busy with some other, "real world", tasks, I managed to finish the plugin loading logic inside the KWallet API. :-) ** The context ** Be able to switch from KWallet to KSecretsService, which is an implementation of the freedesktop.org secret service [1] This is quite a complex task to do, as existing applications must not be affected. In order to do that, it was proposed [2] to introduce a plugin loading approach inside the KWallet logic. ** The news ** First of all, I created a branch named "ksecretsservice" in kdelibs. All the preparatory work was (and will) be done inside that branch. I also merged the master branch into that branch from time time so today it's in sync with it. The Wallet logic was modified: - load a default plugin when first called, - all the Wallet API calls now delegate to the loaded plugin, excepting the following methods: * LocalWallet, * NetworkWallet, * PasswordFolder, * FormDataFolder. - some extra, internal, methods were added to the API to let the plugin trigger wallet signals [3]: * emitWalletOpened() * emitWalletClosed() * emitFolderUpdated(const QString&) * emitFolderListUpdated() * emitFolderRemoved(const QString&) - a new KDE service type was defined "KWallet/Plugin" via kdeui/util/kwallet-plugin.desktop * this is the type that the future wallet plugins should declare - new header was added : kdeui/util/kwalletplugin.h * this holds a base class named WalletPlugin that all wallet plugins must implement kdelibs/kwalletdefaultplugin was introduced : - it gets the original org.kde.KWallet.xml file from kdeui/util, - it gets the original code from kdeui/util/kwallet.cpp, - as it's name suggests, it's loaded by default when applications access KWallet API. I'm currently using this setup on my computer without problems. KWalletManager functions as usual, and the network manager plasmoid is continuing to load my wifi password, to only mention these applications. I also did a full rebuild of my KDE setup (94 kdesrc-build components), holding my kdelibs version, to ensure no issues were introduced into kwallet.h ** Next moves ** Any thoughts about this? The current ksecretsservice branch should now be merged with kdelibs master in order to bring in the plugin logic. I marked the commit that should be merged to master with the tag "plugin.ready". How should that be done? What would be the next steps to accomplish that? Who can help with that? Cheers, [1] http://standards.freedesktop.org/secret-service/ [2] http://mail.kde.org/pipermail/kde-utils-devel/2011-November/000705.html [3] This is the only way I managed to do that. Connecting signals did not work as some forum threads suggest. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [PATCH] KSecretsService Collection and Item property names
Hello Jakub, Kevin, Thanks for the patch. I'm now working on it. I'll also adjuste the client API then I'll commit all the changes asap for me. Cheers, Valentin On 08/07/2012 03:50 PM, Kevin Krammer wrote: Hi Jakub, thank you caring about our client implementation. The macro usage looks a bit weird to me, but it is Valentin's call :) Cheers, Kevin On Sunday, 2012-08-05, Jakub Filak wrote: The current implementation of KSecretsService accepts property names of Collection and Item without interface name. The Secret Service API standard says "Specify the property names in full interface.Property form" [1] The form required by the standard: "org.freedesktop.Secret.Item.Label" The accepted form in KSecretsService: "Label" (gnome-keyring accepts the properties only in full interface form) The patch changes the accepted name form from single name form to full interface name form. The patch simply adds an interface prefix to each occurrence of a property name. (I used a helper macros because of DRY.) The patch applies to the files: ksecretsserviced/frontend/secret/collection.cpp ksecretsserviced/frontend/secret/service.cpp ksecretsserviced/frontend/tests/servicetest.cpp Regards, Jakub [1] : http://standards.freedesktop.org/secret-service/re02.html -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: RFC: Moving KWallet Password dialog into Plasma
On 07/24/2012 02:20 PM, Aurélien Gâteau wrote: Le vendredi 20 juillet 2012 17:58:04 Martin Gräßlin a écrit : Providing a password safe and asking for the master password is also a "system" service and should belong into the workspace. So here my idea: let's move the password dialog into the desktop shell. Have it as a so-called "persistent" notification popping out of the panel and be shown on top of all other windows till the user either dismisses it or enters the password. I like the idea, but I have to ask the annoying question: what happens when an application which needs access to the wallet is running outside of Plasma? Ideally we could hook into the running workspace password safe (gnome keyring, mac os keychain, windows equivalent if any). If I am not mistaken this is what the FDO secret storage spec [1] is about, but is it in a state we can rely on for KDE SC 4.10? The ksecretsservice project (actually in playground) is the KDE implementation for this fd.o specification. And yes, the password prompt is actually handled by the specific daemon (ksecretsserviced). For the moment it's state is not stable enough to let it go in 4.10, but hopefully I'll have more time for it one that "real life" project would let me more energy. Aurélien [1]: http://www.freedesktop.org/wiki/Specifications/secret-storage-spec -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
[no subject]
set authenticate IXO13IqM set delivery off
Re: KDE Frameworks 5: Rhythm
Stephen Kelly wrote: > Kevin Ottens wrote: >> There's three main reasons for this rhythm: > * KAction/QAction stuff - Don't know what's needed. If QAction needs new > virtual method that would need to be determined soon. Is anyone driving > that? Again, needs subtask here if it's going to happen: > https://bugreports.qt.nokia.com/browse/QTBUG-20885 Well, I volunteered for this item but "real life/job" got a hold on me since the last meeting. But now I'm getting more time for hacking. I wasn't aware about the QTBUG you linked us to. Thanks for that. And I can tell I'm far from having a precise plan about KAction merge. But I'll try to have one in a couple of weeks. -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
KSecretsService Project information page on TechBase (and more)
Hello lists, Please be advised that the TechBase page of KSecretsService project just appeared: http://techbase.kde.org/Projects/Utils/ksecretsservice The project sources are now all located into the kdeutils/ksecrets repository: https://projects.kde.org/projects/kde/kdeutils/ksecrets The playground repository will soon be deleted. Next, I'll add more documentation into TechBase then continue testing/debugging in the new configuration. And BTW, I'll switch to the frameworks infrastructure, so some development time will also go from ksecretsservice to frameworks. Cheers, -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: This starts to become a dangerous path (Was: New Feature for kdelibs)
On 11/15/2011 10:16 PM, Alexander Neundorf wrote: "Minimizing the impact" means to align up- and downstream, ie. find a way to provide features *now* w/o really opening kdelibs to new features but at best accelerate frameworks development. (as you probably read in the rest and unfortunately not commented part of my original post) Hmm. AFAIK we have currently two cases. One is SecretService and the other one is something with cookies or so. How about "it is ok to add it to kdelibs if it is also added to frameworks" or something like this ? This would also be very different from "kdelibs is open". I fully understand that it makes a lof ot sense to feature freeze kdelibs for the frameworks effort in general. But nevertheless I don't see what the bad impact of allowing secretservice to go into kdelibs now would have, assuming Valentin ports it also to frameworks. Well, I just removed ksecretsservice from kdelibs and kderuntime (see latest mails exchanged with Kevin and Aaron). The code specific to it in KWallet is inactivated. After the release, KWallet code will have a plug-in support, loading if found the ksecretsservice daemon. And for me this infrastructure was intended from the beginning to go inside the frameworks. Valentin -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/14/2011 09:19 PM, Aaron J. Seigo wrote: Valentin: please let me know when ksecretservice is in its own repo, I just removed ksecretsservice from kdelibs and kde-runtime. Next move will be inclusion in ksecrets repository. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/14/2011 09:19 PM, Aaron J. Seigo wrote: On Monday, November 14, 2011 18:04:08 Kevin Ottens wrote: > * Introducing a plugin loading approach inside of the KWallet convenience > API * Make your current code for the KWallet convenience API a plugin for > the above mechanism (seeing your code right now, it'll even map fairly well > as in most places it's right now "if (m_secretServices)" else it uses the > old code path) and have this plugin installed at the same time than your > library. as a mea culpa, if Valentin is OK with it, i volunteer to write the plugin support. Ok, the mea culpa is enough for me :-) I prefer writing the plug-in myself, as I need to master this technique too. What would be the current "beautiful" plug-in implementation to take as an example? Valentin: please let me know when ksecretservice is in its own repo, and i'll take care of the kwallet integration ... technically it's a new feature that'll be dropping into 4.8's kdelibs, but it's a reasonable compromise imho. Ok, works for me. i will commit it after the 4.7.4 release so as not to interfere with that. Ok, I'll commit that after 4.7.4. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/14/2011 06:04 PM, Kevin Ottens wrote: On Saturday 12 November 2011 11:35:22 Valentin Rusu wrote: And the circular dependency will be there as long as kdecore (where KCompositeJob lives) and kdeui (where KWallet lives) are tied together. Here is the schema : - KWallet legacy code *needs* KSecretsService API that *needs* KCompositeJob ; - if KSecretsServiceAPI is not present, then exclude KWallet specific code, so KSecretsService API should be compiled first, but that requires KCompositeJob. OK, so the only proper way out I see from here would be the following: * Reverting your changes in kdelibs 4.7 branch, the whole lot is definitely not material for 4.7.4 IMO; * Moving the libs part in your repository with the rest of ksecretservices to keep it all together; The libs part would lead to a Tier2 library - I expected that and your other mail confirms it. May it contain the other ksecretsservice components such as the deamon and the sync tool (those who are already under kdeutils)? Depending on this answer, I'll either move the libs inside kdeutils/ksecrets or request a new git repo. * Introducing a plugin loading approach inside of the KWallet convenience API * Make your current code for the KWallet convenience API a plugin for the above mechanism (seeing your code right now, it'll even map fairly well as in most places it's right now "if (m_secretServices)" else it uses the old code path) and have this plugin installed at the same time than your library. I know it's a bit of extra work now and I'm sorry about that. No problem, I like the idea of a plug-in. It's better suited to this case and I should have thought of it from the start. That said, this compromise comes with the longer term advantage that with such an organization you're pretty much ready for the KDE Frameworks time, it'll mainly be about extra QA from there, but you won't need to re-split later (which will be the case in the KDE Frameworks world). It also allows you to release along KDE SC 4.8 with kdeutils. Indeed. Hope that helps solve the situation. Yes, it solves it quite right, thanks very much. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/12/2011 12:55 PM, Christoph Feck wrote: Since it was me who raised this issue on IRC, I should clarify: I have no problem with the ksecrets stuff in *kdelibs*, but I do not like that it has been added to *kdeui*. The only reason given was that kwallet API is also part of kdeui, but why should we make this mistake again? Ok, I'll then move it somewhere else. I'm very tempted by the kdecore module, the place where it's main dependency, KCompositeJob, lives. But I think the best place would be the *experimental* module. Ok for that? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/12/2011 11:55 AM, Alexander Neundorf wrote: And that's where my question comes from, I thought the consensus with the involved parties after that new discussion was for a new repository, but I might have missed something. So that was the intent of my previous email, now that the red flag got raised for inclusion in kdelibs master, Maybe the red flag for kdelibs can indeed be discussed again ? I mean, AFAIK, there will be a kdelibs 4.8 release, as stated by Dirk several times here and on other lists. If there is code right now which is working with the current kdelibs, reviewed and OKed (as ksecretsservice is), what exactly is the argument for not letting it in, and release it together with the kdelibs 4.8 ? It doesn't add extra work for the kdelibs 4.x branch, and it doesn't create extra work for integrating it with the frameworks branch. That's correct, thanks Alex. However, I should remove the ksecretsserviced from kde-runtime and let it go the the ksecrets repository, under kdeutils. And I'll do it later today. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/12/2011 11:24 AM, Kevin Ottens wrote: Please see my response to Aaron. And that's where my question comes from, I thought the consensus with the involved parties after that new discussion was for a new repository, but I might have missed something. Well, the discussion came *after* I merged the code in kdelibs, despite the messages I posted before that, that's what it's missing :-) So that was the intent of my previous email, now that the red flag got raised for inclusion in kdelibs master, why not going for a separate repository? That's exactly what I'm doing now. I'm only searching for the good location. At least contrary to inclusion in kdeutils it would avoid the circular dependency issue. Well, ksecrets is already a separate repository and it's located under the kdeutil parent classification. And the circular dependency will be there as long as kdecore (where KCompositeJob lives) and kdeui (where KWallet lives) are tied together. Here is the schema : - KWallet legacy code *needs* KSecretsService API that *needs* KCompositeJob ; - if KSecretsServiceAPI is not present, then exclude KWallet specific code, so KSecretsService API should be compiled first, but that requires KCompositeJob. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/12/2011 10:11 AM, Kevin Ottens wrote: On Saturday 12 November 2011 01:01:15 Valentin Rusu wrote: As you may already know, the ksecretsservice API merging to the kdelibs/4.7 branch was no longer an acceptable solution because of recent frameworks related decisions. It was suggested to put it into it's separate repository, alongside with the kde-runtime/ksecretsserviced I also merged yesterday. After thinking twice, I'd like to bring these components into the kdeutils/ksecrets repository. Are you ok with this? Sounds like a bad idea to me because... A possible issue if that's ok for you: the kdeutils/kwallet will depend on this repository and it contains guard code to exclude ksecretsservice-related code if qca not found - that will be extended to the case ksecrets repository will not be found. This raises the problem of module dependencies: kdelibs needs to be built first, but if ksecrets was not compiled first, the required headers will not be there and as such kwallet will not have the ksecretsservice-related code. That looks like a circular reference :-) ... it creates this type of situation. Any particular reason why you didn't stick to the separate repo solution as proposed earlier? For some reason I fail to see what motivated your change on that. Well, as I explained in other threads, the initial decision I understood was to have the components in kdelibs and kde-runtime then. And I did stick with that. Please see my response to Aaron. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
[proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
Hello, As you may already know, the ksecretsservice API merging to the kdelibs/4.7 branch was no longer an acceptable solution because of recent frameworks related decisions. It was suggested to put it into it's separate repository, alongside with the kde-runtime/ksecretsserviced I also merged yesterday. After thinking twice, I'd like to bring these components into the kdeutils/ksecrets repository. Are you ok with this? A possible issue if that's ok for you: the kdeutils/kwallet will depend on this repository and it contains guard code to exclude ksecretsservice-related code if qca not found - that will be extended to the case ksecrets repository will not be found. This raises the problem of module dependencies: kdelibs needs to be built first, but if ksecrets was not compiled first, the required headers will not be there and as such kwallet will not have the ksecretsservice-related code. That looks like a circular reference :-) I'll discuss this on the next frameworks irc meeting or maybe a solution for this kind of situation already exists? Cheers, -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [announce] KSecretsService into it's way to be released
On 11/11/2011 03:24 PM, Olivier Goffart wrote: Yes, I'll take that suggestion. But is the frameworks branch working right now? Is it possible to use it as the main desktop session on my computer, on a day-to-day basis? The frameworks branch is not meant to be used in the short term (it may work, but I don't know) But it is to be used for development. So, I may switch my desktop environment to it right now? There is a lot of work to do there, and little people to do the work. What's not helping is that lots of developer are like you and want to get their feature used as soon as possible (nothing to blame here). So they stick to 4.x rather than doing work in the framework branch. Well, I actually need this feature for my secrets management, and I'm not the only one who wants the secret sync tool I proposed. If the frameworks schedule is so far ahead, I think that'll be better to let it go into kdelibs, as I started it, then I'll start helping you with the frameworks. I'm very keen to help you, but I don't have the detailed knowledge you have on KDE core. That's the reason why kdelibs is frozen, it is to force developper like you to contribute (and hence tests) the framework. But I'm wiling to switch to frameworks. I'm also wiling to help develop it. Only I have quite a gap to escalate to reach to your level in KDE core knowledge and working on this API helped me a lot. Perhaps some guidance my help/task dispatching may help me getting into it. But I need my secret sync tool meanwhile :-) Because by running in frameworks, you will maybe see bugs in other areas of the framework, and i am sure people on irc are there to help. People on IRC are great. FYI, Telepathy team is waiting for this new feature to be released. They are my first "real" users and already provided some feedback/bug reports about the deamon. That's great. But as far as i know, Thelepathy is in the same situation as you. Meaning they can use the secretservice libraries without them to be within kdelibs. Ok - I'm adjusting my view while writing this mail. So here is my proposal: - remove all of the ksecretsservice code from kdelibs and kde-runtime, - do not remove kwallet.cpp code I added for the ksecretsservice infrastructure; also let the check box in the corresponding kcm - that will be easier for those wiling to test this new infrastructure and it has no effect by default, - continue maintaining ksecretsservice related code in kdelibs/4.8/kwallet.cpp, - create an extragear (or playground?) repository holding all the ksecretsservice related stuff ; I cannot use the old repo, as it's name is slightly different, - documentint it on techbase.kde.org site -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [announce] KSecretsService into it's way to be released
On 11/11/2011 09:52 AM, Aaron J. Seigo wrote: On Friday, November 11, 2011 00:26:23 Valentin Rusu wrote: Please be informed that KSecretsService components were included into the main repositories as follows: evidently there was a failure somewhere, and i'll take responsibility for it because probably i should have noticed this was going to be merged imminently and, as with all the other feature addition requests to the KDE/4.7 branch, said something. Ok for that. However, something must have changed "on route" (as discussed on IRC) as I formerly remember we even decided together by mail about kde-workspace vs kde-runtime for the daemon. Also, in Randa we clearly discussed about the new API being part of the kdelibs. However, I also have my part of responsibility in not being more close to the frameworks work. But please understand I'm working fulltime elsewhere and I try to keep my involvement to a controlled level in order not to disturb those working full-time on KDE, as you do. this functionality should not have been put into KDE/4.7. it should not have been put into kderuntime, either. all of the code should have appeared in a git repository of its own, lib and runtime requirements together. i do recall writing emails about this in previous threads requesting reviews on ksecretservice. what pains me is that one of the KSS authors was at the Randa meeting and well aware of what work is happening in kdelibs. :/ That's me. And, once again, our mail exchanges were not about putting it in a separate repo, sorry for that. And I'm not having a preference for not having a separate repo. I only want to get this new feature to the first testers, and hopefully moving along to providing the synchronization tool I initially wanted to do for KWallet. in any case, i'm not sure how to proceed from here. i don't want to demotivate you, and i would love to see KWallet start to use this ASAP (though with ksecretservice as a separate repo, i don't see how). what i would have suggested, had i been more on the ball on this one, is to put it in the frameworks branch (as this is definitely frameworks 5 work at this point in time) in a directory of its own, lib+runtime requirements. since it does not rely on libkdeui, it can be built before libkdeui even right now and kwallet can then use it. Yes, I'll take that suggestion. But is the frameworks branch working right now? Is it possible to use it as the main desktop session on my computer, on a day-to-day basis? If yes, I'll do that move, if not, I'll stay with the current setup until it'll become usable, then I'll do the switch. Please note I'm committed to maintain this feature. But I need more help with getting it tested/bug reports. later when libkdeui is separated out into its own repo, then ksecretservice can then follow as well. as i said, i'm not sure how to proceed in a way that will work best for those who have done so much hard work up to this point. please advise what would be workable for you and those working on ksecretservice, taking into consideration is you can what our goals are with frameworks 5 in terms of delivery schedule and focus. FYI, Telepathy team is waiting for this new feature to be released. They are my first "real" users and already provided some feedback/bug reports about the deamon. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [announce] KSecretsService into it's way to be released
On 11/11/2011 03:06 AM, Thiago Macieira wrote: On Friday, 11 de November de 2011 00.26.23, Valentin Rusu wrote: Hello, Please be informed that KSecretsService components were included into the main repositories as follows: *kdelibs/kdeui/ksecretsservice* API intented for the applications. Will replace KWallet API. commit id before was Please undo this. See the discussion on kdelibs 4.8. Is that discussion's title "remove libkactivites from kdelibs"? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
[announce] KSecretsService into it's way to be released
Hello, Please be informed that KSecretsService components were included into the main repositories as follows: *kdelibs/kdeui/ksecretsservice* API intented for the applications. Will replace KWallet API. commit id before was 6b6af2d3889ecd53ce1aa1a00b1befcbc244610c *kdelibs/kdeui/util/kwallet.cpp Depending on configuration, it uses the new API to go through KSecretsService *kde-runtime* Received the ksecretsserviced code formerly in playground/ksecretservice/daemon Commit id before was 6b6af2d3889ecd53ce1aa1a00b1befcbc244610c *ksecrets* Pending move to kde-utils Contains some utilities related to KSecretsService I'll prepare more documentation on techbase and community for this. Looking forward for the bug reports :-) PS: youpi! -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [discussion] KSecretsService API location
On 11/10/2011 10:30 PM, Alexander Neundorf wrote: On Thursday 10 November 2011, Valentin Rusu wrote: Hello, I just pushed the new API to kdelibs and kdepepo (Christoph Feck) has an IRC inquiry I find right. This new API's location was initially guided by the KWallet API location, that is kdeui. Is this location right ? It's easy for me to move it now, after next release (6 months) it will be more difficult. Possible locations might be: 1. kdelibs/kdecore/ksecretsservice 2. kdelibs/kutils/ksecretsservice Any thoughts? It depends on its dependencies... ;-) So, does it depend on stuff from kdeui ? No dependency on kdeui. However, the daemon which this API calls over the dbus pops some password dialogs. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
[discussion] KSecretsService API location
Hello, I just pushed the new API to kdelibs and kdepepo (Christoph Feck) has an IRC inquiry I find right. This new API's location was initially guided by the KWallet API location, that is kdeui. Is this location right ? It's easy for me to move it now, after next release (6 months) it will be more difficult. Possible locations might be: 1. kdelibs/kdecore/ksecretsservice 2. kdelibs/kutils/ksecretsservice Any thoughts? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Preparing to move ksecretsserviced to kde-runtime
Hello Olivier, Now that the KSecretsService API joined kdelibs, branch 4.7, I'm now preparing to move the ksecretsserviced from the playground to kde-runtime. The review request was posted several days ago @kde-core-devel. Cheers, -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Fwd: [Bug 286298] New: Please move ksecrets repo from kdereview to "KDE Utils"
FYI Original Message Subject: [Bug 286298] New: Please move ksecrets repo from kdereview to "KDE Utils" Date: Thu, 10 Nov 2011 20:46:40 +0000 From: Valentin Rusu Reply-To: bug-cont...@bugs.kde.org To: k...@rusu.info https://bugs.kde.org/show_bug.cgi?id=286298 Summary: Please move ksecrets repo from kdereview to "KDE Utils" Product: sysadmin Version: unspecified Platform: unspecified OS/Version: All Status: NEW Severity: normal Priority: NOR Component: git AssignedTo: sysad...@kde.org ReportedBy: k...@rusu.info CC: tsdg...@terra.es, d...@vidsolbach.de, nicolas.alva...@gmail.com Hello, In preparation for the upcoming release, please move kdereview/ksecrets to kdeutil module Thanks, Valentin -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
Re: Review request for KSecretsService components
On 11/10/2011 01:00 AM, Valentin Rusu wrote: On 11/10/2011 12:48 AM, Albert Astals Cid wrote: * createItem falls in the "let's use a bool instead of an enum because it> just have two values" trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo->createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo->createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter_Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Ok, I see. I'll change that. Well, In fact I changed my mind, as the enum must be a member of Collection class, but required to be used in the create job and nested enums cannot be forward declared. So that'll require to move the enum outside of the Collection class, leading to even uglier code. So I'll stay with the boolean, wich also corresponds to the freedesktop.org dbus interfaces spec, btw. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Review request for KSecretsService components
On 11/10/2011 12:48 AM, Albert Astals Cid wrote: A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Are you saying you don't have anything as simple as this in the new API? QString walletName = KWallet::Wallet::NetworkWallet(); KWallet::Wallet *wallet = KWallet::Wallet::openWallet(walletName, parentwid); if ( !wallet->hasFolder( "KPdf" ) ) wallet->createFolder( "KPdf" ); wallet->setFolder( "KPdf" ); wallet->readPassword( walletKey, retrievedPass ) Yes, your code isn't asynchrounous ! (boo) Well, I don't fully agree with this point of view, but in Randa they managed to convince me about the benefits. Take a look inside kwallet.cpp class to see how this new API should be used. Another example is the ksecrets API inside kdereview/ksecrets repository. * createItem falls in the "let's use a bool instead of an enum because it> just have two values" trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo->createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo->createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter_Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Ok, I see. I'll change that. Of course that is a minor thing and won't complain too much if you decide to disagree with me ;-) Albert -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Review request for KSecretsService components
Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: A Dimarts, 8 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Again, The freeze will come in less thant two days now and I'd like to know if anyone reviewed these components. Thanks, On 10/31/2011 11:48 PM, Valentin Rusu wrote: Hello, Please be advised three repostories need review before integration into the next release: 1. /kdereview/ksecretservice 2. kdelibs branch ksecretsservice 3. /kdereview/ksecrets *1. /kdereview/ksecretservice* The first one has several subdirectories. The only relevant one is the daemon subdirectory. Other directories contents was already moved to other repositories (see below). This daemon directory contains the sources of the future kde-runtime/ksecretsserviced It needs testing but it's quite usable. *2. kdelibs branch ksecretsservice* kdelibs/kdeui/ksecretsservice This is the API KDE applications will be supposed to use instead of KWallet class. Tools listed below already use this API. This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Or is this API for more complex apps like kwalletmanager? Well, the secrets service infrastructure, specified with GNOME's Stef Walter is intended to do more things thant KWallet was. For instance, the KWallet API won't let me do the synchronization tool I wanted without significant improvement. My comments on the kdelibs API: - ksecretsservice/ksecretsservicecodec.h * Seems to be installed but has no documentation at all It's indeed installed but it's an @internal class - I added the appropriate documentation. * Uses references for output parameters when KDE/Qt usually uses pointers * Does not use d-pointers thus maintaining ABI is going to be difficult Once again, it's an internal class, no breakage risk here as I'll maintain the API and the daemon together. - ksecretsservice/ksecretsservicecollection.h * I miss a note saying who belongs the ownsership of all those job that come as result of the getters. Do I have to delete them? Oh, I thought that'll not be needed. Usually jobs autodelete themselves. Note added. * createItem falls in the "let's use a bool instead of an enum because it just have two values" trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. * There are a few of spacing "glitches", e.g. const QVariantMap collectionProperties = QVariantMap(), const WId&promptParentWindowId =0 ); Added a space before the 0. * There are a few not implemented signals Yes, but they'll not be done before tommorrow, unfortunately. - ksecretsservice/ksecretsservicedbustypes.h Contains a plain struct and some inline functions, what if those have to change? Marked as @internal - ksecretsservice/ksecretsserviceitem.h * Same question about ownership of jobs Same note added. - ksecretsservice/ksecretsserviceitemjobs.h * Without having at all a clue on what it is used for, i miss a note saying to who belongs the ownership of the SecretItem passed to the constructor and returned in the secretItem() function, i.e. do i have to delete it myself? This class was marked as @internal and corresponding comment was added. * SecretItemJob does not have a d-pointer Oops! Added. * void finished( ItemJobError, const QString& msg =""); should probably be void finished( ItemJobError, const QString& msg = QString()); Right! - ksecretsservice/ksecretsservicesecret.h Is installed and has no documentation Documentation added. Albert kdelibs/kdeui/util/kwallet.cpp Contains code depending on a configuration flag that directs calls to ksecretsserviced instead of kwalletd, via the new API. *3. /kdereview/ksecrets* Contains several tools in a less or more mature state: a. kwl2kss - tool to import kwallet files to ksecretsservice, b. ksecrets - tool to list the contents of a ksecretsservice collection (e.g. wallet), c. kio - KIO slave in a just started state, intended to show collections in konqueror or dolphin, d. secretsync - this was the tool I initially wanted to do for KWallet, but drought me into ksecretsservice :-) It's half way implemented. The mandatory components for next release would be 1, 2, 3 (a, b), the others may wait, but releasing them may cause no harm if communication is done right (I'll take care of that). Thanks for your comments (any comments), -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement) -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Review Request: Fix crash when zombie taskbar buttons are left
> On Nov. 8, 2011, 9:01 p.m., Craig Drummond wrote: > > Ship It! > > Craig Drummond wrote: > Really KSysGuard::ProcessesLocal::getParentPid should be fixed to not > crash when passed pid of 0. Also, a similar fix will be needed in > getServiceLauncherUrl Ok, I also fixed getServiceLauncherUrl - Valentin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103085/#review8032 --- On Nov. 8, 2011, 8:57 p.m., Valentin Rusu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103085/ > --- > > (Updated Nov. 8, 2011, 8:57 p.m.) > > > Review request for KDE Runtime and Craig Drummond. > > > Description > --- > > This fixes a crash I had in the following scenario: > - Launched Thunderbird, the opened it's address book, creating a second > taskbar icon for it, after the main Thunderbird one, > - Close the address book - the taskbar button stayed there, despite > corresponding window has gone, > - Launch another application -> crash > > Thread 1 (Thread 0x7f2c87270760 (LWP 1206)): > [KCrash Handler] > #6 0x7f2c8383d965 in raise () from /lib/libc.so.6 > #7 0x7f2c8383eddb in abort () from /lib/libc.so.6 > #8 0x7f2c8587aff3 in qt_message_output (msgType=QtFatalMsg, > buf=0x31b7478 "ASSERT: \"pid != 0\" in file > /home/kde/src/kde-workspace/libs/ksysguard/processcore/processes_linux_p.cpp, > line 188") at global/qglobal.cpp:2255 > #9 0x7f2c8587b166 in qt_message(QtMsgType, const char *, typedef > __va_list_tag __va_list_tag *) (msgType=QtFatalMsg, msg=0x7f2c85a3c728 > "ASSERT: \"%s\" in file %s, line %d", ap=0x7fff0c2c2178) at > global/qglobal.cpp:2301 > #10 0x7f2c8587b8f6 in qFatal (msg=0x7f2c85a3c728 "ASSERT: \"%s\" in file > %s, line %d") at global/qglobal.cpp:2484 > #11 0x7f2c8587abb8 in qt_assert (assertion=0x7f2c670817e5 "pid != 0", > file=0x7f2c67081798 > "/home/kde/src/kde-workspace/libs/ksysguard/processcore/processes_linux_p.cpp", > line=188) at global/qglobal.cpp:1999 > #12 0x7f2c670767cc in KSysGuard::ProcessesLocal::getParentPid > (this=0x31b7610, pid=0) at > /home/kde/src/kde-workspace/libs/ksysguard/processcore/processes_linux_p.cpp:188 > #13 0x7f2c67070fad in KSysGuard::Processes::updateOrAddProcess > (this=0x7fff0c2c2370, pid=0) at > /home/kde/src/kde-workspace/libs/ksysguard/processcore/processes.cpp:291 > #14 0x7f2c672e1481 in TaskManager::getServicesViaPid (pid=0) at > /home/kde/src/kde-workspace/libs/taskmanager/taskitem.cpp:433 > #15 0x7f2c672e32ca in TaskManager::TaskItem::launcherUrl (this=0x38c1c80) > at /home/kde/src/kde-workspace/libs/taskmanager/taskitem.cpp:612 > #16 0x7f2c672e07b2 in TaskManager::TaskItem::taskName (this=0x38c1c80) at > /home/kde/src/kde-workspace/libs/taskmanager/taskitem.cpp:196 > #17 0x7f2c672c9bc9 in TaskManager::AlphaSortingStrategy::sortItems > (this=0x28b9ac0, items=...) at > /home/kde/src/kde-workspace/libs/taskmanager/strategies/alphasortingstrategy.cpp:89 > #18 0x7f2c672b7c1a in TaskManager::AbstractSortingStrategy::check > (this=0x28b9ac0, itemToCheck=0x38c1c80) at > /home/kde/src/kde-workspace/libs/taskmanager/abstractsortingstrategy.cpp:145 > #19 0x7f2c672b7a54 in TaskManager::AbstractSortingStrategy::handleItem > (this=0x28b9ac0, item=0x38c1c80) at > /home/kde/src/kde-workspace/libs/taskmanager/abstractsortingstrategy.cpp:115 > #20 0x7f2c672b7efb in > TaskManager::AbstractSortingStrategy::qt_static_metacall (_o=0x28b9ac0, > _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fff0c2c30d0) at > /home/kde/src/superbuild/kdebase/build/Build/kde-workspace/libs/taskmanager/abstractsortingstrategy.moc:55 > #21 0x7f2c859d75fa in QMetaObject::activate (sender=0x28bd590, > m=0x7f2c67517280, local_signal_index=1, argv=0x7fff0c2c30d0) at > kernel/qobject.cpp:3546 > #22 0x7f2c672df1ef in TaskManager::TaskGroup::itemAdded (this=0x28bd590, > _t1=0x38c1c80) at > /home/kde/src/superbuild/kdebase/build/Build/kde-workspace/libs/taskmanager/taskgroup.moc:187 > #23 0x7f2c672dc8a0 in TaskManager::TaskGroup::add (this=0x28bd590, > item=0x38c1c80, insertIndex=-1) at > /home/kde/src/kde-workspace/libs/taskmanager/taskgroup.cpp:250 > #24 0x7f2c672ce28e in TaskManager::ManualGroupingStrategy::handleItem > (this=0x28b98d0, item=0x38c1c80) at > /home/kde/src/kde-workspace/libs/taskmanager/str
Review Request: Fix crash when zombie taskbar buttons are left
_c=QMetaObject::InvokeMetaMethod, _id=7, _a=0x7fff0c2c37a0) at /home/kde/src/superbuild/kdebase/build/Build/kde-workspace/libs/taskmanager/taskmanager.moc:103 #31 0x7f2c859d75fa in QMetaObject::activate (sender=0x1ae8dc0, m=0x7f2c8706d7c0, local_signal_index=1, argv=0x7fff0c2c37a0) at kernel/qobject.cpp:3546 #32 0x7f2c86cef679 in KWindowSystem::windowAdded (this=0x1ae8dc0, _t1=96469055) at /home/kde/build/kdelibs/kdeui/kwindowsystem.moc:143 #33 0x7f2c86ceb568 in KWindowSystemPrivate::addClient (this=0x1b482e0, w=96469055) at /home/kde/work/kdelibs/kdeui/windowmanagement/kwindowsystem_x11.cpp:269 #34 0x7f2c86cf889c in NETRootInfo::update (this=0x1b48308, dirty_props=0x7fff0c2c3ae0) at /home/kde/work/kdelibs/kdeui/windowmanagement/netwm.cpp:2227 #35 0x7f2c86cf8141 in NETRootInfo::event (this=0x1b48308, event=0x7fff0c2c3df0, properties=0x7fff0c2c3b90, properties_size=5) at /home/kde/work/kdelibs/kdeui/windowmanagement/netwm.cpp:2099 #36 0x7f2c86cead63 in KWindowSystemPrivate::x11Event (this=0x1b482e0, ev=0x7fff0c2c3df0) at /home/kde/work/kdelibs/kdeui/windowmanagement/kwindowsystem_x11.cpp:172 #37 0x7f2c86b8da4a in KEventHackWidget::publicX11Event (this=0x1b482e0, e=0x7fff0c2c3df0) at /home/kde/work/kdelibs/kdeui/kernel/ksystemeventfilter.cpp:43 #38 0x7f2c86b8d6bc in KSystemEventFilterPrivate::filterEvent (this=0x1b44690, message=0x7fff0c2c3df0) at /home/kde/work/kdelibs/kdeui/kernel/ksystemeventfilter.cpp:102 #39 0x7f2c86b8d629 in _k_eventFilter (message=0x7fff0c2c3df0) at /home/kde/work/kdelibs/kdeui/kernel/ksystemeventfilter.cpp:91 #40 0x7f2c859a83a0 in QAbstractEventDispatcher::filterEvent (this=0x1a22bd0, message=0x7fff0c2c3df0) at kernel/qabstracteventdispatcher.cpp:536 #41 0x7f2c848e4001 in x11EventSourceDispatch (s=0x1a258f0, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:143 #42 0x7f2c7fd897fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #43 0x7f2c7fd89ff8 in ?? () from /usr/lib/libglib-2.0.so.0 #44 0x7f2c7fd8a1c9 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #45 0x7f2c859f54b3 in QEventDispatcherGlib::processEvents (this=0x1a22bd0, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #46 0x7f2c848e43bc in QGuiEventDispatcherGlib::processEvents (this=0x1a22bd0, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #47 0x7f2c859b6c3c in QEventLoop::processEvents (this=0x7fff0c2c4180, flags=...) at kernel/qeventloop.cpp:149 #48 0x7f2c859b6dc6 in QEventLoop::exec (this=0x7fff0c2c4180, flags=...) at kernel/qeventloop.cpp:204 #49 0x7f2c859b99f2 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1148 #50 0x7f2c8480a7c4 in QApplication::exec () at kernel/qapplication.cpp:3779 #51 0x7f2c6f661222 in kdemain (argc=1, argv=0x199e8e0) at /home/kde/src/kde-workspace/plasma/desktop/shell/main.cpp:120 #52 0x00407373 in launch (argc=1, _name=0x19ab8f8 "/home/kde/bin/plasma-desktop", args=0x19ab915 "", cwd=0x0, envc=0, envs=0x19ab91d "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40d80f "0") at /home/kde/work/kdelibs/kinit/kinit.cpp:734 #53 0x00408481 in handle_launcher_request (sock=8, who=0x40daac "launcher") at /home/kde/work/kdelibs/kinit/kinit.cpp:1226 #54 0x00408d34 in handle_requests (waitForPid=0) at /home/kde/work/kdelibs/kinit/kinit.cpp:1419 #55 0x0040a803 in main (argc=4, argv=0x7fff0c2c5028, envp=0x7fff0c2c5050) at /home/kde/work/kdelibs/kinit/kinit.cpp:1907 Diffs - libs/taskmanager/taskitem.cpp d3c336d Diff: http://git.reviewboard.kde.org/r/103085/diff/diff Testing --- This one is not easy to reproduce. Thanks, Valentin Rusu
Re: Review request for KSecretsService components
Hello Again, The freeze will come in less thant two days now and I'd like to know if anyone reviewed these components. Thanks, On 10/31/2011 11:48 PM, Valentin Rusu wrote: Hello, Please be advised three repostories need review before integration into the next release: 1. /kdereview/ksecretservice 2. kdelibs branch ksecretsservice 3. /kdereview/ksecrets *1. /kdereview/ksecretservice* The first one has several subdirectories. The only relevant one is the daemon subdirectory. Other directories contents was already moved to other repositories (see below). This daemon directory contains the sources of the future kde-runtime/ksecretsserviced It needs testing but it's quite usable. *2. kdelibs branch ksecretsservice* kdelibs/kdeui/ksecretsservice This is the API KDE applications will be supposed to use instead of KWallet class. Tools listed below already use this API. kdelibs/kdeui/util/kwallet.cpp Contains code depending on a configuration flag that directs calls to ksecretsserviced instead of kwalletd, via the new API. *3. /kdereview/ksecrets* Contains several tools in a less or more mature state: a. kwl2kss - tool to import kwallet files to ksecretsservice, b. ksecrets - tool to list the contents of a ksecretsservice collection (e.g. wallet), c. kio - KIO slave in a just started state, intended to show collections in konqueror or dolphin, d. secretsync - this was the tool I initially wanted to do for KWallet, but drought me into ksecretsservice :-) It's half way implemented. The mandatory components for next release would be 1, 2, 3 (a, b), the others may wait, but releasing them may cause no harm if communication is done right (I'll take care of that). Thanks for your comments (any comments), -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Review request for KSecretsService components
Hello, Please be advised three repostories need review before integration into the next release: 1. /kdereview/ksecretservice 2. kdelibs branch ksecretsservice 3. /kdereview/ksecrets *1. /kdereview/ksecretservice* The first one has several subdirectories. The only relevant one is the daemon subdirectory. Other directories contents was already moved to other repositories (see below). This daemon directory contains the sources of the future kde-runtime/ksecretsserviced It needs testing but it's quite usable. *2. kdelibs branch ksecretsservice* kdelibs/kdeui/ksecretsservice This is the API KDE applications will be supposed to use instead of KWallet class. Tools listed below already use this API. kdelibs/kdeui/util/kwallet.cpp Contains code depending on a configuration flag that directs calls to ksecretsserviced instead of kwalletd, via the new API. *3. /kdereview/ksecrets* Contains several tools in a less or more mature state: a. kwl2kss - tool to import kwallet files to ksecretsservice, b. ksecrets - tool to list the contents of a ksecretsservice collection (e.g. wallet), c. kio - KIO slave in a just started state, intended to show collections in konqueror or dolphin, d. secretsync - this was the tool I initially wanted to do for KWallet, but drought me into ksecretsservice :-) It's half way implemented. The mandatory components for next release would be 1, 2, 3 (a, b), the others may wait, but releasing them may cause no harm if communication is done right (I'll take care of that). Thanks for your comments (any comments), -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [Kde-cvs-announce] KDE SC 4.8 Soft Feature Freeze
On 10/31/2011 01:01 PM, Allen Winter wrote: [Release Team added to the discussion] [also adding kde-core] On Sunday 30 October 2011 5:09:47 PM Valentin Rusu wrote: Hello, May I ask some quesions about this announcement please? This is the first time I'll hopefully get some software in KDE SC. On 10/27/2011 03:30 PM, Allen Winter wrote: TODAY: Thursday, October 27, 2011: KDE SC 4.8 Soft Feature Freeze Trunk is frozen for feature commits that are not listed in the planned feature document [1]. The KSecretsService components are currently under development. I listed them on the document you reference. Only bugfixes and the code implementing the listed features are to be committed after this date. Does that mean that: 1. code under kdereview may get into the release? Yes. as long as the review is complete by 10 Nov. Well, the ksecretsserviced lives now in the playground. It's supposed to be part of kde-runtime. I suppose I should do a sysadmin bug-report to request it's move to kdereview repository. After that, I'll merge it into kde-runtime. Am I correct? 2. code under a kdelibs branch may be merged to the to be 4.8 branch? I don't know. We've never had this situation with kdelibs before. In theory, KSecretService is a new feature for kdelibs and as long as it passes review before 10 November it should be allowed in KDE SC 4.8. OTOH: we've been "unofficially" making noise that kdelibs is frozen except for bug fixes. I'm of the opinion that KSecretService can be released with kdelibs 4.8 as long as it passes review. I'd be glad to get it into 4.8, as others would start testing it and eventually (or better surely) filing bug reports. That would be very helpful. What do others think? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] KSecretsService components moving from playground
On 10/31/2011 03:48 PM, Aaron J. Seigo wrote: it's hallloween .. let's reanimate a dead thread to celebrate! ;) trick or treat! :-) in KSecretsService, metatypes are initialized like this: qRegisterMetaType(); This line comes from kdeui/ksecretsservice/dbusbackend.cpp or from other place? Because the .cpp file has the using namespace directive. And I'm already using the API without problems from the ksecrets and kwl2kss utilities. this is a problem because it does not include the namespace. which afaik means that code that wishes to use this needs to first do: using namespace KSecretsService; somewhere in the code before using these metatypes. this is not good as it pretty much destroys the point of having a namespace :) Take a look to ksecretsservicedebustypes.h and see the Q_DECLARE_METATYPE( KSecretsService::SecretStruct ) As you see, I already fought the namespace issue ;-) -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] KSecretsService components moving from playground
On 10/16/2011 03:30 PM, Will Stephenson wrote: On Wednesday 12 October 2011 00:24:00 Valentin Rusu wrote: Any thoughts? This all sounds good. A couple of questions: 1) Are the KWallet API changes additions, or will some parts of the kwallet api be deprecated? If so, when do you plan to add the deprecated tag? The KWallet API will stay unchanged. However, some functions will behave slightly different, but the priority for me is to keep the API implementation change as consistent as possible with the legacy version. The deprecated tag will be added with future releases, when the new KSecretsService API will become more stable and *more importantly* documented. 2) When and how is migration performed under this model? When the checkbox is changed? It's you that do check the box then click apply. From that moment on, the KWallet API in newly started applications will go through the KSecretsService API in kdelibs. Already running applications still use kwalletd, until session is restarted. Does this handle cases where a wallet request is already showing (on another desktop, for example) or when a wallet request comes in during the migration process? I think the above explanation answers this. To be more precise, the application that is already prompting for the password will get it's secrets from kwalletd. 3) When is migration performed during a mandatory migration? Is there a chance that migration will cause login to block? KDE session login? There is no incidence on that. The migration will become mandatory with some previous release, when decision will be made to drop kwalletd. Valentin -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] KSecretsService components moving from playground
On 10/13/2011 10:28 PM, Martin Koller wrote: On Wednesday, 12. October 2011 01:09:51 Valentin Rusu wrote: I personally have been looking forward to KSecretsService and I like the idea of leaving KSecretsService unused by default for now, but it should at least be stressed to downstream to leave it off by default and why you chose it to be off for this release, if you do decide to implement it for 4.8. I assume there is a reason you decided to leave it off by default? Yes, I decided that precisely to avoid pitfalls I saw when KDE 4 arrived. Let's put the code in for 4.8, voluntarily test it by voluntarily checking that box, then put it on by default with the next 2012 release. What about adding a "warning" text at the checkbox, e.g. "(experimental)" like with Linux kernel drivers when configuring which makes the status clear and brave people only will try to activate it ? Good idea! Thanks -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] KSecretsService components moving from playground
On 10/12/2011 12:53 AM, Steven Sroka wrote: The code is not yet fully mature, all the components are not yet finished, but the main parts are there and it is now possible to have secrets stored in KSecretsService and konqi or microblog successfully getting them upon session start. There is a checkbox in the KDE Wallet configuration tool that switch KWAllet API to KSecretsService when checked. It will be left unchecked for the next release. I sincerely don't mean to be an *ss and I do say this in good faith, but you say "The code is not yet fully mature, all the components are not yet finished". Given that downstream distros and users are still struggling with some rather bad bugs from previous versions of KDE, would it not be prudent to push the first release of KSecretsService until it is completed and all the components are finished? Components are finished when the bugs become seldom. In order to get bugs filled, the component must make it to the users. The statement I made applies today, october 12. By the date of the release, I think the code will become more stable, as I started using it as my main secrets storage (a few minutes ago ,google-chrome just made ksecretsserviced prompt for my password). This will be done starting with the daemon, which is the central part, then the KWallet API, which is critical for all the applications. These two pieces of code will be quite ok by the end of this month. The rest of the code will be not yet fully mature, but it'll be quite usable and I'll continue improving them. I'll eventually get more help if these components will make it into the main repositories, as it'll be easier to get them working. And BTW, "no yet mature" does not mean that they crash every second. It's more feature-wise oriented. I personally have been looking forward to KSecretsService and I like the idea of leaving KSecretsService unused by default for now, but it should at least be stressed to downstream to leave it off by default and why you chose it to be off for this release, if you do decide to implement it for 4.8. I assume there is a reason you decided to leave it off by default? Yes, I decided that precisely to avoid pitfalls I saw when KDE 4 arrived. Let's put the code in for 4.8, voluntarily test it by voluntarily checking that box, then put it on by default with the next 2012 release. Anyway that is just my 2cents, and I will follow whatever decision you make. You are a better judge of the quality of KSecretsService than me :) Kool -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
[proposal] KSecretsService components moving from playground
Hello, As KSecretsService becomes quite usable, I think it's time to prepare to get it integrated into the next release. http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule The code is not yet fully mature, all the components are not yet finished, but the main parts are there and it is now possible to have secrets stored in KSecretsService and konqi or microblog successfully getting them upon session start. There is a checkbox in the KDE Wallet configuration tool that switch KWAllet API to KSecretsService when checked. It will be left unchecked for the next release. Components are: 1. KWallet API - already in kdelibs branch ksecretsservice, 2. ksecretsserviced - still in playground, 3. kwl2kss - still in playground, 4. ksecrets - still in playground 5. secretsync - still in playground. 6. kio - still in playground Components needed for 4.8 are 1., 2., 3. and 4. Therefore I propose to move them out of the playground as following: 1. get merged into 4.7 branch before 4.8 branch is created 2. goes to kde-runtime, 3. make it part of kdeutils/kwallet [see complement below] 4. create a kdeutils/ksecrets repo for it and for 5. and 6. Complement: kdeutils/kwallet has a branch containing code specific to ksecretsservice (e.g. the checkbox to activate ksecretsservice infrastructure). This branch should also be merged when releasing 4.8. Any thoughts? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Review Request: Reset password field to be empty for subsequent attempts to open the wallet
On 09/27/2011 01:38 PM, Ralf Jung wrote: > Hi, > > On Tuesday 27 September 2011 12:15:47 Sebastian Kügler wrote: >> On Monday, September 26, 2011 21:59:04 Ralf Jung wrote: >>> http://git.reviewboard.kde.org/r/102714/ >>> >>> When the first attempt to open a wallet fails, clear the password field >>> for the second one >> What is the advantage of this over selecting the password? Typing a new one >> is exactly the same amount of keystrokes, and having the "wrong" password >> filled in gives a hint at what went wrong. I often see "ow, that many >> letters, then I mistyped this and that. It also makes it harder to correct >> mistakes by just editing a part. >> >> I might be missing something here, but not clearing (but selecting) seems >> like a better compromise. No? > Indeed, that would have the same result. And if I just tested correctly that > is already the default behaviour with KDE 4.7? I am still at 4.6 for my main > system, so I did not notice that this was changed... sorry. Now, that I committed Ralf's proposed solution, I'd like to know what would be your proposal: let it as is, or revert that commit? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Review Request: Reset password field to be empty for subsequent attempts to open the wallet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102714/#review6847 --- Ship it! Ship It! - Valentin Rusu On Sept. 26, 2011, 7:59 p.m., Ralf Jung wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102714/ > --- > > (Updated Sept. 26, 2011, 7:59 p.m.) > > > Review request for KDE Runtime. > > > Description > --- > > When the first attempt to open a wallet fails, clear the password field for > the second one > > > This addresses bug 245462. > http://bugs.kde.org/show_bug.cgi?id=245462 > > > Diffs > - > > kwalletd/kwalletd.cpp 1d1c277 > > Diff: http://git.reviewboard.kde.org/r/102714/diff/diff > > > Testing > --- > > Compile-tested and logged in to see if the reset happens properly > > > Thanks, > > Ralf Jung > >
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On 08/21/2011 09:31 AM, todd rme wrote: > On Sun, Aug 21, 2011 at 12:09 AM, Valentin Rusu wrote: >> On 08/20/2011 02:11 PM, Oswald Buddenhagen wrote: >>>> A cross-desktop specification, but we still use kwallet. There's no reason >>>> to >>>> dump it in favour of another implementation. So I see no arguments at all >>>> in >>>> favour of dropping it -- in fact, I see more in keeping it. >>>> >>> ksecretservice is a new implementation. dunno how much code was reused. >>> the arguments against two backends are easy: >>> - two backends means almost twice the work, including security auditing >>> - assuming the backends use different storage (it's not part of the >>> spec, after all), even after switching desktops you need to stick with >>> the now "alien" password manager. >> KSecretsService is a new implementation. It has a new backend that >> organizes secrets in collections and follows the freedesktop.org >> specification. KDE applications will use the new KSecretsService client >> library that'll replace KWallet API. I'm currently rewriting the KWallet >> class in order to get it use this new KSecretsService Client API. The >> backend (or daemon) will also be able to import kwallet files. So in the >> future the kwalletd will become useless. >> >> The KSecretsService Client API will be able to connect to whatever >> service will expose the freedesktop.org secrets service specification on >> the DBus. That means that KDE applications will be able to store >> passwords in gnome-keyring if present instead or ksecretsserviced (this >> is the name of the daemon exposing fd.o secrets specification currently >> under development). > Great! This should be very helpful > > A few general questions: > > 1. Will it be possible to add connections to password providers, like > online password management services or firefox, that allow those > passwords to be integrated with secretservice? Or is this something > that would need to be handled at the frontend (ksecretserviced) level? I already started a sync tool named SecretSync that'll allow password synchronization over several machines/terminals. Google Chrome works with KWallet so it'll also work with KSecretsService. Firefox KWallet plugin maintainship is stalled. All these should use KWallet API or better switch to KSecretsService Client. > 2. Is secretservice integrated with PAM so that the passwords can be > opened on login? Or is this also something that needs to be handled > at the ksecretserviced level? This is not yet defined. > 3. Will gnome-keyring and ksecretserviced by storing their passwords > in the same location or file(s), or will there need to be a separate > set of passwords for gnome-keyring and ksecretservicd? These are two different tools, each with it's own implementation and maintainers. > 4. If you are running gnome programs in a KDE workspace, or vice > versus, will they automatically connect to the right secretservice or > will they try to call their own backend? KDE KSecretsService API will connect to whatever daemon provides the right interfaces on the DBus. So it'll be possible for a KDE application to use gnome-keyring to store it's secrets. Ongoing work will define how users will choose the daemon they want. Valentin -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: kdeinit
On 08/20/2011 02:11 PM, Oswald Buddenhagen wrote: >> A cross-desktop specification, but we still use kwallet. There's no reason >> to >> dump it in favour of another implementation. So I see no arguments at all in >> favour of dropping it -- in fact, I see more in keeping it. >> > ksecretservice is a new implementation. dunno how much code was reused. > the arguments against two backends are easy: > - two backends means almost twice the work, including security auditing > - assuming the backends use different storage (it's not part of the > spec, after all), even after switching desktops you need to stick with > the now "alien" password manager. KSecretsService is a new implementation. It has a new backend that organizes secrets in collections and follows the freedesktop.org specification. KDE applications will use the new KSecretsService client library that'll replace KWallet API. I'm currently rewriting the KWallet class in order to get it use this new KSecretsService Client API. The backend (or daemon) will also be able to import kwallet files. So in the future the kwalletd will become useless. The KSecretsService Client API will be able to connect to whatever service will expose the freedesktop.org secrets service specification on the DBus. That means that KDE applications will be able to store passwords in gnome-keyring if present instead or ksecretsserviced (this is the name of the daemon exposing fd.o secrets specification currently under development). -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: One Free N900 (Re: Kontact Touch went 2nd place in Contest, one N900 to be given away)
I want it! I'll implement kwallet and new ksecretsservice tools on it! :-) Valentin Rusu (valir) KSecretsService (KWallet replacement) Bernhard Reiter wrote: Anyone that deserves or wants a free N900 from the KDE or KDE PIM community? Am Montag, 18. Juli 2011 11:45:14 schrieb Bernhard Reiter: > Kontact Touch - an application build on top of KDE Platform 4 - has won > the second place in the contest of porting applications to MeeGo! > The reward for being second place is an N900 smartphone. > Hey, what about that 'N900' device? > Who gets it? > Maybe you! > > We - the mentioned team - want to give this smartphone > to a person from our fellow community. > Please send suggestions and applications to > > n900-kontact-touch-2...@intevation.de > > until the 8th of August! We have not gotten any suggestions for people to receive the phone. So if you had written a simple: I want it, you would have been the one. ;) Therefore we extend the the deadline until and including the 21st of August (UTC). > We try to decide within a week and shipment will happen then, > given the device has reached us meanwhile. And we still do not have it. Of course if Nokia fails to ship it, we cannot give it away. ;) > Include why the person you are suggesting - may it be yourself > or someone else - should get the device. > > Here are some criteria we will use: > It would be nice to see the device being used, > Kontact Touch also being used and progressed as much as possible, > may that be development, promoting, documentation, assisting other people > or anything else that helps Kontact Touch, its underlying KDE stack > and our community! > > Best Regards, > Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: How to get krazy check playground/ksecretservice ?
On 08/01/2011 03:19 PM, Allen Winter wrote: > On Sunday 31 July 2011 6:19:20 PM Valentin Rusu wrote: >> Hello, >> >> I'd like to get the KSecretsService code checked by Krazy. [snip] > In playground/base (SVN) create a file called .krazy with the line: > EXTRASUBS ksecretservice > > then commit playground/base/.krazy > > that should do it. wait a day or 2 for the EBN to process > Ok, it now appeared, thanks! http://www.englishbreakfastnetwork.org/krazy/reports/playground/base/ksecretservice/index.html
Re: KWallet/KSecretsService & GIT workflow
Hello Sebas :-) On 08/04/2011 09:51 AM, Sebastian Kügler wrote: > Hi Valentino, > > [snip] >> One more component should be the KWallet backend, an implementation of >> the current KWallet class based on the new "Client API". KWallet code is >> actually spread inside several GIT repositories: kdelibs, kdeutils and >> kde-runtime. I think that I should do a branch named "ksecretsservice" >> inside each of these repositories, then start using the new "Client API" >> and do the switch to the new infrastructure. When this might become >> "showable", I might push these branches to each of thses repositories, >> along with an appropriate announcement to this list. >> >> Any thoughts about this process? How does it fit with current kdelibs >> modularization process? > How would the switch work, is it runtime-choosable, compile-time, or do you > need to change the code from kwallet to ksecretservice, so there's not other > means to go back, short of reverting? I plan to let the existing code in place and switch in the new code by the means of a runtime variable. This variable will default to the new code when not defined in the rc file. That would allow people to get back to old kwallet in the (very unlikely indeed ;-) ) case where the new code would encounter a severe bug when in "production". A release or two later, when bugs.kde.org show that new code works nicely, then I'll remove the old wallet code. The secret service daemon has a piece of code that detects existing wallets and, if the right command-line switch is given, starts importing them. But at the time of the release I think I'll deactivate the command-line switch requirement and let the daemon automatically import wallets, then mark them as imported in it's own storage. This way, passwords will get in secret service and the wallet clients will seamlessly continue to work. That would be the critical stage on the path to secret service switch. Once applications function correctly with the KWallet API on KSecretsService backend, the process of migration to KSecretsService client API may start. The introduction of the new daemon and API will also be accompanied by an announce inviting application developers to start using this new API instead of the obsolescent KWallet API. A compile warning will also be added at that time. As such, there will be a lapse of time where new applications will use the new API and existing applications will still use KWallet API. I know that Telepathy will be one of the first clients of the new client API. > This question does affect how we introduce ksecretservice all over KDE. > > Cheer, and thanks for your work on ksecretservice! Welcome :-)
KWallet/KSecretsService & GIT workflow
Hello, KSecretsService API is now nearing the finished state. But this would be confirmed by starting using it as a KWallet API backend. Naturally, I'll do this on my system but I'd like to do it such that: - allow for current kdelibs modularization efforts, - allow volunteers to test this new feature, - ease the "playground to kdereview to kde-???" process, - easy merging to master when code become stable enough. KSecretsService is intended to supersede the KWallet infrastructure. It's structured in several modules: - Client API -- intended for KDE applications as a KWallet API replacement; behind the scenes it's using DBus to call the deamon, but that's an implementation detail, - Daemon -- implementing a DBus freedesktop.org specification (see [1]) and doing the actual secret management on disk (and hopefully on smartcards), - SecretSync tool -- intended to allow secrets synchronization among several devices. All these modules now live together inside one playground GIT repository [2]. One more component should be the KWallet backend, an implementation of the current KWallet class based on the new "Client API". KWallet code is actually spread inside several GIT repositories: kdelibs, kdeutils and kde-runtime. I think that I should do a branch named "ksecretsservice" inside each of these repositories, then start using the new "Client API" and do the switch to the new infrastructure. When this might become "showable", I might push these branches to each of thses repositories, along with an appropriate announcement to this list. Any thoughts about this process? How does it fit with current kdelibs modularization process? [1] http://specs.freedesktop.org/secret-service/ [2] https://projects.kde.org/projects/playground/base/ksecretservice
How to get krazy check playground/ksecretservice ?
Hello, I'd like to get the KSecretsService code checked by Krazy. It's living in projects.kde.org/playground/base and Krazy seems ignoring it : http://www.englishbreakfastnetwork.org/krazy/index.php?component=playground&module=base At the time of svn.kde.org, a simple add_subdirectory macro in the parent module (e.g. playground/base/CMakeLists.txt) was enough to get it scan the code. The new GIT repository layout seems lacking such a file. What should I do to get it included in Krazy scan? Valentin
Re: Review Request: Fix paste operation using mouse middle click in KLineEdit, when selected text is not cleared before paste
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101583/ --- (Updated June 11, 2011, 9:33 p.m.) Review request for kdelibs. Summary (updated) --- KLineEdit : Clear selected text when middle click occurs to prepare for paste operation. NOTE : I came accross this when investigating a crash in Kate when opening files. It crashes if you middle click the file name KLineEdit to paste a filename previously selected in the konsole. I'm working in fixing that also. Diffs - kdeui/widgets/klineedit.cpp 0dd3690 Diff: http://git.reviewboard.kde.org/r/101583/diff Testing --- Thanks, Valentin
Review Request: Fix paste operation using mouse middle click in KLineEdit, when selected text is not cleared before paste
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101583/ --- Review request for kdelibs. Summary --- KLineEdit : Clear selected text when middle click occurs to prepare for paste operation. Diffs - kdeui/widgets/klineedit.cpp 0dd3690 Diff: http://git.reviewboard.kde.org/r/101583/diff Testing --- Thanks, Valentin
Re: Review Request: Use the port number in the filename when caching favicons
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101577/#review3830 --- Ship it! Looks ok. - Valentin On June 10, 2011, 8:34 p.m., Dawit Alemayehu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101577/ > --- > > (Updated June 10, 2011, 8:34 p.m.) > > > Review request for KDE Base Apps. > > > Summary > --- > > The attached patch uses the port number of a favicon's url when creating its > local cache name. This helps distinguish two severs running on the same host > as pointed out in the bug report listed above. > > > This addresses bug 124482. > http://bugs.kde.org/show_bug.cgi?id=124482 > > > Diffs > - > > lib/konq/favicons/favicons.cpp 8ba9258 > > Diff: http://git.reviewboard.kde.org/r/101577/diff > > > Testing > --- > > > Thanks, > > Dawit > >
Re: Review Request: Fix crash in KDirLister
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101560/#review3810 --- Ship it! I checked kdirlister.cpp and itemsForDir truely can return NULL, so the patch seems OK to me - Valentin On June 9, 2011, 4:29 p.m., Sebastian Sauer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101560/ > --- > > (Updated June 9, 2011, 4:29 p.m.) > > > Review request for kdelibs. > > > Summary > --- > > Attached patch fixes a crash reported by gopalK, one of our Calligra@Windows > heros. > > Backtrace (only one line); > #0 KDirLister::Private::emitChanges (this=0x13332c70) > at d:\kderoot\git\kdelibs\kio\kio\kdirlister.cpp:2155 > > The reason is that kDirListerCache->itemsForDir can return NULL. That is > handled in all cases in that file except those two lines. The patch fixes it. > > p.s. whoever pressed "Ship It" please commit the patch for me and backport > cause I didn't had the time to get my kdelibs+kdebase setup updated since the > latest moves and renames. Thanks in advance :) > > > Diffs > - > > kio/kio/kdirlister.cpp d554723 > > Diff: http://git.reviewboard.kde.org/r/101560/diff > > > Testing > --- > > > Thanks, > > Sebastian > >
