KSecret Service just created its first secrets file

Greetings from Randa!

Take a look at this:

Well, this is the first secrets file ever created with KSecret Service, and it happened here, in Randa. For the impatient – just hold your keyboards, the code is not yet ready. The tests are still failing, but items started to appear on disk, encrypted with libgcrypt.

Stay tuned and meanwhile remember, the fund raising campaign for KDE Sprints is still ongoing. Please consider to donate by clicking the banner below to make coding sprint like this one possible.
KDE sprints 2015 fundraiser campaign

Next week I’ll be in Randa

Since Akademy 2015 KSecrets Service development continued. I did lots of code cleanup. The async API now uses QFuture and the secrets file backend, based on libgcrypt, was added. Tests are there to confirm it’s not yet working. ๐Ÿ™‚

One week from now I’ll be in Randa. The hacking ambiance will surely help to hopefully get a first pre-alpha version of the service. I also look forward to peer reviews and feedback on this new codebase.

This kind of events is made possible by our generous donors. If you’d like to join them and donate, helping the KDE community and me, then just click the image below:
KDE Sprints Fundraiser

Goodbye Akademy 2015, See You Randa 2015

OK, Akademy 2015 ended last week. This is my second Akademy, though the first full one.

A Coruรฑa is located on the Atlantic front and on my way there, I encountered rainy spots and the rain was a familiar one for me, after having lived several years in northern France (Paris and Pays de la Loire). But this time I actually found it quite enjoyable, knowing that I left behind a 39ยฐ-heated Lyon. So, yes, A Coruรฑa is warmer than what we could encounter in other parts of Spain. I shared my car with Sandro KnauรŸ, who came to Lyon from Germany by train, so the one full-day trip was quite nice, KDE hacking-oriented. But be assured, we were also able to talk lots of other topics.

The venue and the hosting in Rialta were just perfect. The local team did an awesome job when organizing the event. They had it all: welcome party – we arrived at the right moment for the Queimada – sponsored food during the week-end (thanks Blue Systems), essential goodies (they carried the VIM T-shirt), “social event” – that was really a party where I had an excellent time -, the day trip and all the schedules which weren’t difficult to follow. Rialta has free swimming pool and I actually managed to use it.

Akademy is about KDE technology but also about meeting like-minded people. Getting along together is really easy, language barrier took apart, and I actually really enjoyed just sitting there and hacking with others, then having a beer or discussing technical issues or ideas. I already miss these spontaneous late evening hacking moments.

Speaking about KDE technology, we are at a turning moment, with Plasma Mobile becoming available. KDE is now ready to take on the mobiles platforms and that’s pretty cool. I look forward to the moment when I’ll have a Linux smartphone running both KDE software and Android applications (with Shashlik, bien-sur). I’ll do my best to help and I already plan to support KSecrets Service on mobile.

KSecrets Service had it’s own BoF. The updated slides are here. I’m working right now in implementing it and that would bring us to Randa, where I intend to continue even further and hopefully I’ll even have a working version by that time.

Randa is a great location for hacking. In fact, no, not Randa, but the venue in Randa is quite perfect for that ๐Ÿ™‚ They have that big room under the roof, upstairs, where I look forward to hack, between some BoF’s or swiss meals. Some people who couldn’t make it to Akademy will go to Randa, so I look forward to meeting them there. Oh, and if you can, please help them getting there by the means of a small donation.

Finally, but not less importantly, I’d like to thank KDE e.V. and the sponsors for organizing these events and for providing travel reimbursement.

KWallet needs a serious face-lift ; enter KSecret Service

Users are often confused by the current KWallet system behavior. When their computers start, they enter the KDE session password but just after logging-in, they are prompted yet another password, for something named KWallet. Sometimes, they even see several password prompts from KWallet, depending on their precise desktop configuration.

Some users find that annoying and they file bug reports or, even worse, simply uncheck the “Enable the KDE wallet subsystem” in an attempt to deactivate it as a whole and switch to using some other external tools. Well, these tools are OK, but the KDE experience is affected, as the applications are no longer able to correctly store and retrieve their secrets. And that raises the barrier to entry for some of our potential users, adding negative points against KDE.

The remaining users have now several devices and would like to have their passwords synchronized all over these devices. They won’t find this kind of function and they’ll start using some other external tools, providing cross-device synchronization. That’s another bad point for the KDE experience.

Finally, more advanced users would like to know where their wallet data is stored and they would like to be able to put their wallets in some places of their choice, perhaps in an owncloud synchronized directory.

Enter KSecret Service!

The KDE Wallet system has some design flaws (I’ll write more on that in the future, but right now my post risk to get too long) affecting the security and should be replaced ASAP. Back in 2008 and until or 2011 an initiative was taken by the former KDE Wallet maintainer Michael Leupold and Stef Walter from GNOME to create a Freedesktop.org interface aiming to replace it. It’s called “Secret Service” and the draft may be found here: http://standards.freedesktop.org/secret-service/

This interface is already implemented by GNOME keyring and AFAICT KDE should also implement this interface if it wanted to enhance users experience.

All these points will be addressed by a new system, aiming to replace KWallet. It’s name is already known – KSecret Service.

I’m in the process of (re)defining it’s architecture and I’ll post it, for feedback, on the KDE developer mailing list as soon as I’ll get something stable enough. I cannot tell more right now – the post is already long enough – but it’s an ambitious plan! And I’m sure you’ll like it!

KWallet for Plasma 5 now automatically migrates KDE4 wallets!

Next time you’ll start your updated Plasma 5 session’s KDE Wallet system, it’ll eventually start migrating your wallets. The precondition is that you’re doing that on a system that also has KDE4 and that you previously used that installation’s KDE Wallet system. If your system doesn’t have a KDE4 wallet daemon, then nothing will happen.

Simply follow the instructions of the wizard that’ll popup. If you accept the migration option, then for each of your existing KDE4 wallet you’ll be :
– prompted with a new Plasma 5 wallet creation wizard – that’ll eventually be the moment to switch to GPG wallets ๐Ÿ˜‰
– eventually prompted for the old wallet’s password, it the old daemon didn’t had it already opened by some other KDE4 program.
The migration assistant will preserve wallet names and wallet internal structure.

As usual, do not hesitate to file bug reports if you encounter any problem!

A final note about those who installed KDE4 in a prefix that’s not /usr. Please ‘ln -s [your kwalletd location] /usr/bin/kwalletd’ in order to let the migration agent correctly find and start the KDE4 daemon. Without that, it’ll not trigger the migration. (yes, that’s a quick hack, but it works).

Starting KF5 using the I3 window manager

Lately I started experimenting several tiling window managers, and I settled on I3 (see its Official site and the corresponding ArchLinux wiki page)

I now plan to return hacking KF5 and I’d like to use this tiling manager. In KDE4 I simply used the “Default Applications” control module from “System Settings” to choose i3, after adding the right i3.desktop file. However, with KF5 that will not be enough. For some reason kwin will still be loaded. (And BTW, the new kwin looks really great. I also like the new plasma desktop very much, but it won’t fit my workflow, as I prefer tiling WMs paradigm) Today I started searching a quick way to workaround that and here it is what I did.

Firstly, create the $KF5/share/ksmserver/windowmanagers/i3.desktop file with this contents:

[Desktop Entry]
Comment=Highly configurable framework window manager

Then edit the file ~/.config/ksmserverrc and modify the windowManager line from the [General] section:

# other lines ommited

Alternatively, you can use the “Default Applications” control module from KF5 System Settings to change the window manager to i3.

Finally, here is the little bit that made it. Modify the KF5 startup script to define the KDEWM environment variable. It should read like this:
export KDEWM=/usr/bin/i3

Here is how:
On my system, I’m using kdm. For it to start a KF5 session, I created /usr/share/config/kdm/sessions/kf5.desktop with this contents:

[Desktop Entry]

As you can see, my KF5 is installed in /home/kde5 (others may have it in /opt/kf5). The start-up script, named ‘start-kde’ simply sets the righ environment variables, calls ssh-agent and gpg-agent, then calls startkde from KF5. I added the export KDEWM=/usr/bin/i3 line into this script.

Quit your current session, choose the KF5 session in KDM and enjoy I3 with KF5!

I’ll now return to tinkering it, as some adjustments still need to be done ๐Ÿ™‚

Oldies but goodies! Welcome back to VRCOM!

Yesterday I just created a new repository on github and pushed a new awesome library ๐Ÿ˜‰ This library is an LGPL alternative to MS ATL Library. Yes, you read that correctly! I just pushed a library implementing a technology that’s more that 14 years old. I’m talking about Microsoft’s COM technology. I used to be an expert of that technology, back in 1999, and this library was my two cents about COM objects implementation in C++. See the readme file for more details of my motivations for writing this library. Please note that this library was successfully used in a production environment.

What pushed me to publish this? Well, it appears that Microsoft is slowly returning to COM. In my opinion WinRT is purely a new version of COM. That alone would not push me to create that repository. The trigger was someone on Google+ “C++ – Libraries & Frameworks” group asking if someone knew about an ATL alternative. And that started me. Why not help and share what I wrote at that time?

I managed to get on old CD with the sources, created the repo and directly pushed them. So, please expect them not to compile using modern MSVC. At that time I was a big fan of the templates (well, I still like them alot), a very new feature of the C++ language at that time. They were not clearly specified and the syntax varied heavily from one compiler to another. At that time I stick with MSVC compiler syntax. But I think that’ll be not so hard to adjust them for the current technology. I cannot do that myself, because I no longer use Windows nor I have MSVC on my computer. I only tried Visual C++ Express Edition in a virtual machine, but please accept I don’t plan to maintain this library. I published it only to help and lower the entry barrier for those who want an ATL alternative. And it would be awesome if someone there would update this library and maintain it. Just drop me a line and we’ll arrange for the commit rights on the github repository.

Here is the repository link for the VRCOM library : https://github.com/valir/vrcom

svnmerge2.py – A tool for SVN merge operations

Well, SVN is not yet dead. Enterprise world still uses it, or at least it’s still used at my workplace ๐Ÿ™‚

When it comes to merging, one has the choice of TortoiseSVN or svnmerge from Orcaware. Each of these has their drawbacks. For example, TortoiseSVN is very mouse-intensive, so it’s click-error prone (yes, yes). The script from Orcaware is somewhat strict, and it even requires one to use it from the very beginning of the project. But what if you didn’t use it at that time? So, how to get a small improvement to this situation? Enter svnmerge2.py. I put the sources on, well, GitHub! ๐Ÿ˜‰

There are instructions in both French and English. However, the script only shows French strings. I plan to add English translation later, when I’ll have some spare time. Meanwhile, if you need it, feel free to translate it and add a pull request on GitHub. I’d be glad to integrate it.

New GnuPG backend for the KDE Wallet!

The classical KDE Wallet uses blowfish algorithm to encrypt sensitive data before writing it to disk. The key used for the encryption is a user-defined password that sometimes is even left empty by the user!

GnuPG offers some very strong encryption algorithms and uses passphrase-protected long keys. But I’m not going to talk about GPG here. I’ll rather tell you that I just added a new backend in kwalletd allowing for GPG-encrypted wallets! The code is fully functional and I actually configured my KDE session to use it! So here are the screenshots.



As you can see, I now have a “testgpg” wallet that is selected as the system-default wallet. So what, you’d say? Well, I’d answer, as you can see there’s no apparent difference when using these wallets, and that’s expected behavior. Things changes however when you try to create a new wallet. There are two ways to do that. The usual way is in system settings, where user would click the “New…” button you see in the second screenshot. That will pop-up a wizard that I adjusted to let the user choose between the more secure GPG-backend or the classical, blowfish-based, backend.

After clicking “New…”, user is prompted for the new wallet’s name, as usual, then here is the redesigned “new wallet wizard”:

disclaimer: I’m not an english-native, so wording may not be the best in the following screenshots. Feel free to adjust the strings in the sources ๐Ÿ˜‰




The screenshots above show the case where an encryption capable GPG key was found on the system. If the user do not have such a key, then the last page changes to this:


(the different color comes from the different color-scheme my test user has in it’s kde session)

And that’s all it takes!

If using KWalletManager, the wizard is slightly different (I don’t know why kwalletd uses two code paths for wallet creation, but I choose to keep this original behavior):

  • Choose “File > New wallet…”
  • Enter the new wallet’s name
  • Next, the following wizard will show:



That’s it for this case too!

kwalletd will use GPG when storing wallets and when opening them. The same KDE session can handle simultaneously both file formats. kwalletd will transparently detect the file format and load the correct backend to handle it. So you can do as I did:

  • Create a new GPG-based wallet (using one of the previous described methods)
  • Fire KWalletManager and
    • Select your old wallet then choose “File > Export as XML…” to create an XML file with your sensitive data
    • Select the GPG-based wallet then choose “File > Import XML…”, then choose the file you just saved
    • NOTE: “File > Import wallet…” should also work, but in that case you should choose the .kwl file corresponding to your old wallet, located in ~/.kde/share/apps/kwallet
  • Go to System Settings > Account Details > KDE Wallet and select the newly created, GPG-based, wallet from the “select wallet to use as default” combo box
  • gpg-encrypt the XML file to keep a back-up

What about file sizes? Well, on my system, the new GPG-based wallet show a dramatic drop in file size for storing the exact same data:

$ ll
total 80
-rw------- 1 valentin valentin 60664 Aug 15 16:54 kdewallet.kwl
-rw------- 1 valentin valentin 19329 Aug 15 18:56 testgpg.kwl

The performance difference is not noticeable. There’s only a slight lag on first GPG library initialization.

IMPORTANT NOTE: the passphrase dialog only shows once. Even if the wallet is closed after initial open, subsequent opening will occur silently during the same KDE session! That’s great news for those annoyed by the kwallet password prompt in the middle of the KDE session.

Eager to test the code? I’d be glad to hear your feedback, as this code should be thoroughly tested and reviewed before letting it go to master. I’ll soon post a review-request on the official mailing list. The code is available under the kde-runtime’s branch named kwalletd-gpg. The new features are compiled-in only if your system has QGpgme, part of kdepimlibs, which in turn requires gnupg and gpgme.

A final word: those of us who own a FSFE Fellowship Smart Card now have a new cool usage for it!