Premier article…

Et voici une nouvelle section, « Politique universitaire », qui devrait rassembler des articles liés à mes activités d’élu CEVU et VPE à l’UJF. Cet outil devrait, au moins temporairement, me permettre d’aller vers plus de transparence dans mes fonctions. Il s’agit d’un espace officieux, en attendant une refonte du site web de l’UJF telle que discutée ce soir.

Tout d’abord, j’ai obtenu l’accord du Conseil des Élus Étudiants pour mettre en place un groupe spécifique aux élus étudiants de conseils centraux et conseils de composantes sur le Bureau Virtuel. Il nous permettra d’échanger et de nous organiser à travers une liste de discussion, et de partager les documents nécessaires à la réalisation de nos nombreuses ambitions. Malheureusement, le Bureau Virtuel est indisponible cette nuit, ce qui met en évidence le problème de stabilité évoqué lors de notre réunion et retarde la mise à disposition du parfait distribué par la CEVPU. Cependant, aucune autre plateforme n’est mise à notre disposition actuellement et il me paraitrait inapproprié de dépendre d’un fournisseur de service externe, entre autres pour des questions de gouvernance.

J’en profite pour rappeler aux élus sur liste Interasso qu’ils ne sont pas « les élus Interasso » mais des élus UJF, particulièrement dans une véritable démarche de travail commun. De plus, ils ont brillé par leur absence dans un Conseil mis en place par Jérôme Guyony, alors VPE élu sur leurs listes et membre de leur organisation. J’espère que leur apparente politique d’absentéisme, si elle existe réellement, disparaîtra dès la rentrée…

Il est également possible que je profite de cet espace pour mettre en avant les projets auxquels je suis amené à participer en tant que bénévole à EVE. J’ai récemment démissionné de mes fonctions de responsable de commission en raison des conflits d’intérêts avec mes nouvelles attributions, puisque je siège notamment au CA de cette association. Cependant, je souhaite prolonger mon investissement dans cette structure unique en France, et qui semble faire des émules ces derniers temps…

Au plaisir d’un prochain article.

LXNM is not Debian-specific anymore

LXNM, the LXDE network manager, had Debian-specific scripts. That’s why I did not package it in Archlinux. As I said on my previous post, I worked on generic scripts, which use dhcpcd instead of dhclient (smaller, easier to control, DNS updates by default under Archlinux) and stop using ifup/ifdown. They are now in LXNM’s trunk. I’ll wait for a release to include lxnm in Archlinux, but the PKGBUILD with a rc.d script is ready.

Another thing: Did I mention LXDE’s lead developer is using Archlinux? Well, the wiki page about Archlinux was updated to mention the new lxde group even before I finished adding it to the packages :)

One last thing: git-svn rocks. I won’t use svn any longer. Using SVN branches still suck, or I missed something, which is highly possible.

Well, I lied, one last thing: I need to mention that I just started a fork of lxnm which doesn’t work as a daemon anymore. There are little chance that I ever finish. Default policy might be to use SUID with user root, group network, but I’d like to make it easy to use sudoers with NOPASSWD for “extra security” (that would need to adapt lxpanel a little more; anyway, I would have to). That makes installation harder so it won’t become the default behaviour. This sucks as I need to reset ENV.

I’m not ready to replace Steve Jobs…

LXDE in Archlinux

LXDE (screenshots) is a great desktop environment. I felt in love for it in a few days, exactly when I discovered it.

It is based on Openbox, which is my favourite WM except for tiling ones. It includes PCManFM, which is by far the best file manager I’ve ever seen on a Linux environment, after KDE4’s Dolphin/Konqueror: I’ve been waiting for the multicolumn mode from OpenStep under Linux for years. I’ll talk with LXDE’s developers about it. LXAppearance provides an easy way to choose the GTK theme, icon theme and font. It is, AFAIK, the only graphical alternative to Gnome’s tool for those features. LXPanel works great, it provides exactly what I’m looking for and is light, still easy to configure. To name a few, icon-only window list, keyboard LEDs indicators (did you remember I use a EEEPC?), launchers you can manage just by selecting .desktop files (sooo better than Xfce). The session manager permits me to shutdown/reboot/suspend/etc., without using any display manager (I use x:5:respawn:/bin/su - gcarrier /usr/bin/startx). And it doesn’t depend on many libs: GTK2, DBus, HAL, FAM. There’s a simple NetworkManager alternative which is work-in-progress. For now, it only works with Debian-based systems (as it uses ifup/down scripts), but I got SVN commit access and will improve this very soon. Anyway, it will never follow the NetworkManager way and any advanced stuff should be done through a shell. But it manages ASCII/hexadecimal WEP keys, parts of WPA and is very easy to extend by customizing shell scripts. What really astonished me was LXLauncher, an enhanced replica of EEEPC’s default tabbed desktop launcher. Considering it, I could really provide LXDE to my grandma.

I wrote PKGBUILDs for everything today. For now, various TU maintain parts of it; I’d like to entirely maintain it as I’ll follow the developers very closely. And provide a lxde group to make it easier to install. You might want to use lxsession-lite instead of lxsession which is buggy. Last but not least, the Subversion repository contains nice apps to come.

Packages signing in pacman, Archlinux getting secured?

Introduction

This post title is such a troll… Archlinux is my favorite Linux-based distribution, it’s already secured, blah blah blah, you got the point. Here’s the story. Questions come next.

Signing? How awesome is that!?

Security is one of my big concerns. So I started to work on packages signing, which might be the biggest lack in Archlinux for now. Thanks to toofishes, who is totally mentoring me on this, we went to a point where a nearly complete design is available. The implementation is far from finished, but it’s now possible to see where we’re going, if we keep this way. And I think it perfectly suits the Arch philosophy.

The place to start with

We started working on makepkg. Basically, we added an option in the BUILDENV array (defined in /etc/makepkg.conf) named sign, which causes makepkg to sign the package it builds using gpg, creating a binary 72 bytes detached signature file.

That’s one small step for add-repo…

Then, we need the signature to be available on the repos. Using a 72 bytes file for each package would be overkill considering the number of mirrors. So we wanted to include the signature in the repo database (this .db.tar.gz file you might have opened if you understand a few words in this post). A whole file path in the tarball for every signature would be overkill too, plus it is uncompressed in /var/lib/pacman/sync/ and each signature could take something like 8kb (depending on your fs and its options, btw) as a separate file! But for each package, there’s a desc file with fields in it. Our idea is to put the signature in it. As it is plain text, we can’t put the binary signature directly. base64 is here! With a tool to (de)code it in coreutils, it definitely was the way to go. Now we have a new field which looks like:

%GPGSIG%
iEYEABECAAYFAkhDcqcACgkQj8OreK3cj9eStwCeIjf9AWQcPE9hH+t7iQ2pVCychxwAoKBcIiYph4RzVISP6bklppdOwmkF

It’s a long line, but it is still plain ASCII and won’t interfere with the file format as there can’t be any % in it. So we tweaked repo-add. That was a one line patch in the code. Did I tell you it’s a true story?

What’s the point?

Now that everything is here to generate repos with signed packages, maybe pacman could use this brand new information…

It could embed muuuch code from GnuPG. OK, what else? It could use gpgme, which would rely on gnupg itself, but is supposed to make things easier. Here, we just have to check a signature. We can work like git! Basically, we just need to popen something like gpg --keyring $keyringfile --no-default-keyring --verify - $pkgfilename and write the binary key to it. Then check for return code 0.

That’s where the biggest design choice come. How pacman should know whether a package can be trusted or not? Let’s use (a) keyring(s)!

I’ll let the gnupg users who learnt their lesson tell you that to trust Archlinux’s packages, you need to meet Aaron Griffin himself (omg omg! RMS would be so jealous!), or someone who met him, or someone who met someone who met him, etc. as long as it seems at least a lot more than reasonable to you. And please do the same for [archlinuxfr], [eee], etc. Web of trust is a good concept.

Irrelevant throughts: Now let’s suppose you install Archlinux via FTP: you launch your installer from the USB key you’ll give to Grand’ma at her birthday next week, and you have configure gpg before installing packages. Well, I don’t know for you, but when I install a system, I want this done fast. Meaning at least a prompt to start tweaking within minutes. Dealing with a keyring like you would do for e-mails or chat sessions with your buddies at the NSA is not really adapted. Anyway, you will be able to work that way with our system!

We could have a keyring per repository in pacman.conf. I think it doesn’t make much sense: if I trust a developer to provide me binaries it seems I want to use, I don’t really care whether it’s init or vim (but I care whether it’s not emacs or still not). And I care even less if it’s in [core] or [community], because I love TUs. Did I tell you TUs are beautiful and smart young men and women who need care and love?

Now that you’re convinced pacman’s keyring should be system-wide, it would be convenient to deal with the various packagers of the repos you use. Here’s a hypothetical story:

I wake up at 10AM. I take my breakfast, a shower, and go to school. My girlfriend (yes, hypothetical) kisses my math teacher… Let’s be realistic. A year later, I install Archlinux on my brand new laptop. In [core], I keep archlinux-keyring. I add the [archlinuxfr] repository to /etc/pacman.conf, pacman -S archlinuxfr-keyring. I confirm the installation even if this package is not signed. I change Keyring /etc/pacman.d/archlinux.gpg to Keyring /etc/pacman.d/belovedlaptop.gpg, and run gpg-merge-keyrings archlinux.gpg archlinuxfr.gpg belovedlaptop.gpg. Then I add the [kdemod] repository, install its keyring and run gpg-add-keyring kdemod.gpg belovedlaptop.gpg.

Questions as promised

Why don’t the thousands of people who visit this blog put at least a dozen of comments on it? Do you think I should stop replying to my replies to my patches on pacman[dash]dev[at]archlinux[dot]org? Is packages signatures something you actually want? Do we do it completely wrong or just wrong?

Python on your Twintact

Here comes the first experimental release! Jean-Christophe is focusing on his exams and I don’t have much time either, but we’d love to get feedback and help.

You just need to download one archive and extract it on your micro SD card root, as a “twinthon” directory.

It comes in many flavours: tar.bz2 (12M), tar.gz (16M), zip (17M).

The (small) port system, with (inexistant) documentation and examples (for now, an example script with its shebang) is available on github.

Twinthon’s coming! Twinthon arrive !

Here we are: Twinthon! Python on the Twintact… Yes, that’s a little bit nerd. More to come in the next days.
On y est : Twinthon ! Python sur le Twintact… Oui, c’est un peu nerd. Plus à venir dans les prochains jours.
/mnt/fat/python
Linux (none) 2.4.20_mvlcee31-omap730_gsm_gprs #1 Wed Mar 5 15:30:00 CST 2008 armv5EJl unknown
Python 2.5 (r25:51908, May 26 2008, 18:59:45)
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "Hello Twintact! I'm Python!"
Hello Twintact! I'm Python!
>>>
Ça pourrait intéresser les gars de chez OpenTwin…

Ideas for Arora: forms autofill, or “Think different”.

Do we need a password manager? I don’t think so.

Is it a good idea to bother the user about whether the form he just submitted should be stored locally or not? I don’t think so!

I think it should be easy to remember any form value easily. I want to control that from the keyboard or the mouse in seconds. This choice is field-related. That’s why it should be simply available from the contextual menu (so, simply using the Menu key on anyone’s modern PC keyboard).

Three states could be useful (I didn’t think a lot about the naming issue):

• Don’t remember (default)
• Remember on this page
• Remember on the whole website/domain

But contextual menu is not visible by default, and this choice should always be visible to the user and intuitive. That’s why I suggest extending the input widgets. Widgets extensions rock, just see how useful and easy it is to resize a multiline input field using drap and drop… Some rounded icon at the right of the field, like the one on the adress bar. Grey by default, which means nothing is stored. Grey when the field value is stored for the page, blue when it is stored for the website. You just have to click it to change this state.

BTW, a central place to control which form items are stored, and forget some would be necessary. It could look like some sort of browser, with a two-pane view.

No mockups for now, but I’m working on it!

Edit: here’s a mockup for the forms autofill values manager (please find a name; and BTW, the lines headers are stupid, there should be 2 columns):

Ideas for Arora: the download location

I would like some intuitive way of choosing the download location in Arora.

From what I’ve seen:

• A lot of people just always use the desktop. Maybe just because it’s their browser default setting, but they adapted their behaviours to it. They want all their downloads to go straight to it.
• Some people use some “Downloads” directory the same way as the desktop. They don’t want to be worried about the download location each time but want to choose it once.
• A fairly small amout of users prefer choosing the download location each time.

I propose a Arora design that will suit all those people by staying, IMHO, intuitive.

If no default location is chosen, this dialog is shown (I have no idea if it’s easy to extend the QFileDialog to get something like that; otherwise, we might open some simple dialog after it for the first download):

By default, the “Always here” checkbox is unchecked, except for the first download (as it is the behaviour most people will expect).

The preferences pane would be changed to this (I’ll skip the handmade draft for a real mockup this time; you can thank me):

Edit: Here’s a new version, as some think that a checkbox is counter-intuitive. Please give your opinion in comments!

Edit 2: As Arora’s developers prefer to keep the native file dialogs (under Windows and Mac OS X), there are no hooks to implement the first download checkbox. Another (maybe better) solution could be to use this kind of dialog on the first download then:

It would be better to default to “Yes”, I guess.

EEEPC = revolution

I won’t write a lot of thoughts on this weblog, but this one might become related to my work, as I just contacted MSI to spend time on their Wind netbook.

I got really interested in the EEEPC concept during last summer. The buzz around it seems to make logic to me, and I’m happy to participate to it.

I were an early adopter and turned into an impatient child until I received mine from Taipei. And it met my expectations, thanks to toofishes and his marvelous EEE repository.

I won’t spend time on the choice of not using Microsoft Windows. People who might contest it might also want to leave this place…

The EEEPC has some defaults, indeed. From the beginning, I wanted a 9 or 10 inches screen, at least 1024×600. Too bad it didn’t came out soon. I expected it to be completely Intel-based, and was disapointed by the Ethernet and Wifi drivers issues. I also was worried about its CPU. As I use it as my main computer for interaction (I mostly use its keyboard, trackpad and screen, and a X server on it for everything), I suffer from all those limitations on a daily basis. Flash is great, but 4GB became small when I started contributing to various OSS projects. Add its plastic design, relatively low battery (as most notebooks) and you should understand why I’m waiting for the next generation.

But my next computer will not a EEEPC 900 because 64 bits is the future, and I’d love Intel VT (not sure the Wind Atom model will support it, though). Not a EEEPC 901 either because this keyboard is a real pain in my *ss. Flash is lovely, but I’d rather get a 80GB harddrive that I can easily replace by something bigger. And I want way more battery life.

I will try to keep my EEEPC alive for years to come. This model will belong to museums someday.

Arora static builds for Archlinux

I just wrote a PKGBUILD for Arora, using Qt snapshot (static build). It makes the binary 19MiB, but will permit nsplugins (meaning Flash and Java) support very soon and permits you to keep the full-featured Archlinux Qt 4.3. Everything is again available on my server. And again, it’s highly experimental work.