Last week was SUSE Hackweek and one of my projects was to get Let's Encrypt configured and working on my NAS.
Let's Encrypt is a project aimed at providing SSL certificates for free, in an automated way.
I wanted to get a SSL certificate for my Synology NAS. Synology now supports natively Let's Encrypt but only if the NAS accepts incoming HTTP / HTTPS connections (which is not always what you want).
Fortunately, the protocol used by Let's Encrypt to validate a hostname (and generate a certificate), Automatic Certificate Management Environment (ACME) has a alternative validation path, DNS-01, based on DNS.
DNS-01 requires access to your DNS server, so you can add a validation token used by Let's Encrypt server, to ensure you own the domain name you are requesting a certificate for.
There is a lot of ACME implementations, but very few supports DNS-01 validation with my DNS provider (gandi.net).
I ended-up using acme.sh, fully written in shell script and tried to plug Gandi DNS support in it.
After some tests, I discovered Gandi current DNS service is not allowing fast changing DNS zone informations (which is somehow a requirement for DNS-01 validation). Fortunately, Gandi is now providing a new LiveDNS server, available in beta, with a RESTful HTTP API.
I was able to get it working quite rapidly with curl, and once the prototype was working, I've cleaned everything and created a pull request for integrating the support in acme.sh.
Now, my NAS has its own Let's Encrypt certificate and will update it every 90 days automatically. Getting and installing a certificate for another server (running openSUSE Leap) only took me 5 minutes.
This was a pretty productive hackweek !
Monday, February 27, 2017
Last week was SUSE Hackweek and one of my projects was to get Let's Encrypt configured and working on my NAS.
Wednesday, October 7, 2015
Did you knew SUSE is hiring ?
I've just looked at our counter today (October 7, 2015) and we have 68 opened positions.
Moreover, we have two positions which might interest people who are reading this blog through Planet GNOME(-FR):
Tuesday, April 14, 2015
This week is Hackweek 12 at SUSE
My hackweek project is improving GNOME password management, by investigating password manager integration in GNOME.
Currently, I'm using LastPass which is a cloud-based password management system.
It has a lot of very nice features, such as:
- 2 factor authentication
- Firefox and Chrome integration
- Linux support
- JS web client with no install required, when logging from a unknown system (I never needed it myself)
- Android integration (including automatic password selection for applications)
- cli open-source client (lastpass-cli), allowing to extract account specific information
- encrypted data (nothing is stored unencrypted server side)
- strong-password generator
- support encrypted notes (not only password)
- server based (clients sync) with offline operations supported
- subscription based (required for Android support)
- can't be hosted on my own server
- doesn't integrate at all with GNOME desktop
So far, I found the following programs:
- KeePass (GPL):
- version 1.x written in Java, still supported, not actively developed
- version 2.x written in C# (Windows oriented), works with Mono under Linux
- UI feels really Windows-like
- DB format change between v1 and v2
- supports encrypted notes
- password generator
- supports plugins ( a lot are available)
- support OTP (keeotp plugin, provide 2factor auth through TOTP, HTOP built-in)
- shared db editing
- support yubikey (static or hotp)
- 2 Firefox extension available(keefox, passifox)
- 3 android applications available (one application KeePass2Android supports alternative keyboard, KeepShare supports alternative keyboard + a11y framework to fill android application forms, like LastPass)
- Chrome extension available
- JS application available
- CLI available
- big ecosystem of plugins and other applications able to process file format
- KeePassX (GPL)
- Qt4 "port" of KeePass (feels more a Linux application than KeePass)
- alpha version for DB v2 support
- missing support for OTP
- missing support for keypasshttp (required by firefox extensions to discuss with main application), support is being done in a separate branch by a contributor, not merged
- release are very scarse (latest release is April 2014, despite commits on git, very few people are contributing, according to git)
- libsecret dbus support is being started by a contributor
- company developped it was bought by Twitter last year, project released under GPL, no development since January.
- Password Safe (Artistic license):
- initially written by Bruce Schneier
- beta version available on Linux
- written in wxWidgets 3.0 / C++
- yubikey supported
- android application available, no keyboard nor a11y framework usage, only use copy/paste (but allows sync of db with owncloud and other cloud platforms)
- CLI available
- 3 different DB formats (pre-2.0, 2.0, 3.0)
- password history
- no firefox extension and the "auto-type" built-in function is all but intuitive
- support merge of various db
- same 0 knowledge framework as SpiderOak
- node-js based
- simple script on top of text files / gnupg and optionnally git (used for history and can also be used to manage hosting the file)
- not easy learning curve (CLI mostly), need gnupg to be setup before usage
- one file per password entry, should make
- very basic Qt GUI available
- basic FF extension available
- basic android application available
I've also looked at gnome-keyring integration with the various browsers:
- Chrome has already gnome-keyring and libsecret integration
- Epiphany already works nicely with gnome-keyring
- No password generator is available in Firefox / Chrome / Epiphany (nor GTK+ on a more generic basis)
Conclusions for this first day of hackweek:
- Keepass file format seems to be the format of choice for password manager (a lot of applications written around it)
- Password manager which would fit my requirement is KeePass but is written in Mono (I don't want Mono stack to come back on my desktops) and too Windows oriented, so not an option.
- KeePassX seems to be the way to go (even if it is Qt based) but it lacks a lot of features and I'm not sure if it worth spending effort in adding those missing features there.
- Pass is extremely simple (which would make hacking around it pretty straightforward) but requires a lot of work around it (android, GUI) to make it nicely integrated in GNOME.
Comments welcome, of course.
Sunday, May 11, 2014
As always, long time no blog. These days, I don't have enough energy (nor content, IMO) to write blog posts, mostly on Free Software, which would relevant for other people.
Why, would you ask ? Mostly because with my not-so-new-anymore position at SUSE (Enterprise Desktop Release Manager), I'm mostly working behind the scene (discovery the joy of OBS to create ISO images and lot of crazy similar stuff) which might not be that sexy to describe but still need to be done ;)
So, instead of closing this blog for new posts, I'm trying something new to me: writing about things which aren't Free Software but might still interest people:
My new thing these days (asks my wife ;) is coffee.
I've always been fond of coffee (and tea, they aren't mutually exclusive, fortunately), probably because when I was a child, my parents loved good coffee and I was happy to be the one taking care of both electric grinder and Expresso machine we had. And I remember how difficult it was to find good coffee, even more when you were living in a very rural area of France and when the only online services were accessible with a Minitel and were definitively not selling coffee ;)
And then started my love story with Nespresso, which has not ended (yet), with its ups (being part of a customer panel once, including UI designers, very interesting) and downs. I often skipped coffee in cafés and restaurants because I knew it wouldn't be good!
Terre de Café for instance). I ended up sticky with the original, until something better "happens".
And it has happened these days, somehow unexpectedly: for a few years, I was reading about strange devices (Aeropress being cited often) and tasty filter coffee (which, for me, as always been synonym of bad coffee) and I also heared some radio shows on coffee which make me think: let's try.
I ordered an Aeropress and tried it (with some fair trade coffee from my supermarket since I don't have any grinded coffee at home and opening caps wasn't really a good idea). Result: not bad, compared to the consistency of Nespresso but not that great. I knew I wasn't using great coffee.
Coutume Café (their main website is not great ATM, better to look at their FB account), who also have a coffee shop. I went there, tried one of their coffee and I was astonished. This was the best ever coffee I ever tasted, with flavor like red fruits and chocolate. This was incredible and it wasn't even an expresso (which has been my reference for coffee) but filter coffee which looks like dishwater ;)
So, I'm now with this exact same coffee at home, waiting for delivery of a freshly ordered manual grinder to try to duplicate this coffee experience, because I try other coffee and other Paris roasters.
Let's see if I succeed :)
Saturday, February 2, 2013
for those of you who are attending FOSDEM this year and were planning to attend my talk about Secure Boot on openSUSE on Sunday, I'm sorry to announce I had to cancel my travel to Brussels (and my talk) for family reasons.
Since my slides were already written, I thought I could still share them with you Feel free to ask questions / comments on this blog post.
Friday, November 23, 2012
At openSUSE Conference in Prague last month, we had a BoF about Secure Boot, where I describe the various tasks which are needed to ensure openSUSE can support Secure Boot. They are listed on my slides, but I thought it would be more useful to describe them here.
Before we begin, if you need some refresh about Secure Boot, I suggest the blog posts from Olaf Kirch and Vojtěch Pavlík on SUSE Blog (overview, details and approach to it) and of course, all the war stories of Matthew Garrett on this topic ;)
To have openSUSE installable (and runnable) on a Secure Boot enabled system, without any additional user intervention (like adding your own key in UEFI firmware or disabling Secure Boot), we need to do the following to the distribution :
- to the kernel (many of those features are in 3.7 or in upcoming 3.8):
- convert the kernel as a EFI executable (it will be used to store kernel signature)
- UEFI variable access
- UEFI clock support (nice to have)
- UEFI getvideomode (if we want flicker-free boot)
- UEFI reboot (we already have 4 other way to reboot a system, why not add yet another one ;)
- KMS drivers (for old chipsets like Matrox, AST).
- sign main kernel
- sign all in-tree kernel modules
- generate a private/public key pair to be used out of tree modules
- add Secure Boot support in KExec / KDump and Xen (optional)
- disable hibernation in Secure Boot mode (or have a secure way to save / restore suspended system)
- add signature check in kernel
- to bootloader:
- package shim loader
- modify grub2 so it uses shim loader to check kernel signature at boot
- to Build Service:
- to be able to build external kernel modules (think KMP) using the private/public key generated at kernel build
- but do not allow this key to be used for any random KMP build (otherwise, you defeat the purpose of signing the module)
- to userspace tools:
- package xf86-video-modesettings, for graphics chipset with non-accelerated KMS drivers
- add support for signature check in modutils / kmod
- package tools to sign kernel / modules
- package tools to manage UEFI variables and keys
- to the installer / DVD image
- maybe display some warnings about installing a system in Secure Boot mode (not 100% sure we should do this)
- maybe signing the initial installer (and make sure it can't load non-signed modules)
- ensure the DVD image has shim + grub2 as bootloader when booting on UEFI system
- and we also need to do the signing part:
- if we want Secure Boot to be transparent to users, we need our shim loader to be signed by the authority handling UEFI key, ie Microsoft
- this requires some legal paperwork (getting MS developer account, getting a Authenticode certificate, etc..), some obligation (making sure you can't circumvent Secure Boot once Linux is booted) and once it is done, sending shim loader to be signed by MS and package the result.
Tuesday, November 20, 2012
Some weeks ago, I had the pleasure to do a talk at the openSUSE conference in Prague, about systemd (its current state in openSUSE and what we plan for the future) and dracut (mkinitrd replacement).
For those of you who didn't attend the conference, you can watch my talk on YouTube or Blip.tv (thanks to openSUSE awesome video team for the recording):
And you can even get my slides ;)