Last week, I left Paris for the first ever FSFE coordinators meeting. So-called “coordinators” who came to this meeting are FSFE activists, usually volunteers, organising activities and campaigns with other FSFE fellows and free software activists in their local area. They also usually hold FSFE fellowship meetings to prepare such activities, discuss Free Software, attend and organise talks, etc.[^meanwhile] These coordinators are amongst the most important volunteers within FSFE. Some of the groups they coordinate were started around 2005 when the Free Software Foundation Europe launched the Fellowship programme, which is the primary way free software activists can identify with the FSFE and support it work.

[^meanwhile]: Meanwhile in Vienna, Fellows of the FSFE had a booth at the city hall for the Game City Fair. Check it out!

(BTW, there's now a very simple way to show us your support, and that's to sign-up as a supporter: https://fsfe.org/support.)

As former fellowship representative, I attended 2 General Assemblies for FSFE, and thus had the chance to visit 2 European cities I've never been to, and connect to free software users and developers in the area of Ljubljana and Lisbon (in 2 weeks, it will be Vienna!)

However, I've expressed on these occasions that there should be other face-to-face meetings within the FSFE, because they're important for our personal relations and they're motivation-boosters. Aside from that, the meetings themselves can also be very productive.

So the mere fact that this first FSFE coordinators meeting has happened is already great, and I'm sure looking forward to the next one! I think we should take the chance that most of us will be at FOSDEM, as usual, to organise something in addition to FOSDEM (like one day before).

Thanks to everyone who joined!


Other posts in the Installing Kolab series: - part 2 - part 3 - part 4 - part 5

Grr. I just spent some time setting up a new debian machine to serve as a new personal and self hosted server. So I started with trying out kolab.

I followed the instructions in the official doc and then run


Unfortunately, it didn't work. When accessing the Kolab web admin interface, I had no way to add users. Then I figured out that I could not connect as root to mysql even though I had just set up a root account for mysql during the setup-kolab process. After trying out with the former mysql password, I discovered the database was there properly. But still, the Kolab web admin wouldn’t let me add users as if there was a problem and indeed the Roundcube panel was giving a nice


At this point I thought I could try running setup-kolab again to see what could get wrong. I can't even get to the end of it, now I get…

Kolab Service password []: 
Traceback (most recent call last):
  File "/usr/sbin/setup-kolab", line 42, in <module>
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/__init__.py", line 43, in run
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 170, in execute
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 202, in execute
    components[component_name]['function'](conf.cli_args, kw)
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/setup_ldap.py", line 405, in execute
    auth._auth.ldap.add_s(dn, ldif)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 195, in add_s
    return self.result(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 458, in result
    resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 462, in result2
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 469, in result3
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99, in _ldap_call
    result = func(*args,**kwargs)
ldap.INAPPROPRIATE_AUTH: {'info': 'Anonymous access is not allowed.', 'desc': 'Inappropriate authentication'}

Yes. Quite annoying.

Other posts in the Installing Kolab series: - part 1 - part 3 - part 4 - part 5

I’ve been told not to run setup-kolab twice, and to try the development packages provided by http://mirror.kolabsys.com/pub/debian/kolab-3.0/. Unfortunately, setup-kolab failed, again.

Traceback (most recent call last):
  File "/usr/sbin/setup-kolab", line 42, in <module>
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/__init__.py", line 43, in run
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 170, in execute
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 202, in execute
    components[component_name]['function'](conf.cli_args, kw)
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/setup_ldap.py", line 247, in execute
UnboundLocalError: local variable 'setup_ds_admin' referenced before assignment

At this point, I don’t really know what do do any more! I guess I’ll have to find out how to report a bug in the kolab community. Let’s this how this goes…

Other posts in the Installing Kolab series: - part 1 - part 2 - part 4 - part 5

So the problem related to a former installation of "sldap". So now I purged everything and tried running setup-kolab again. It seems now to be fine. Except that I can't send emails, getting SMTP error 454 in roundcube.

But again, I found it was incredibly hard to set up kolab for self-hosting amateurs. On the one hand, I wished they could get some inspiration from YunoHost, on the other hand, Kolab has been there for so long that it's very professional.

Let’s see how it goes…

Il y a quelques années, je me suis pris une vraie claque en découvrant «Smash» de Jackson & His Computer Band. Il m'arrive encore assez souvent d'écouter l'album et de le trouver toujours aussi bon et rempli d'une énergie un peu folle et détraquée. Je me suis même surpris à vouloir retrouver des similarités avec certains passages de Lumpy Gravy… (j'en cherche partout de toute façon…)

Sauf que le fameux Jackson, là, difficile de pouvoir le suivre. En huit ans, aucun album, rien, nada. Pendant un temps j'ai même cru qu'il était mort ! Jusqu'à ce qu'il y a deux ans, lors d'un concert de Warp à Paris. Je me souviens avoir trouvé un enregistrement de ses mix sur YouTube et de m'être demandé ce que c'était que ce truc un peu naze…

Le deuxième album est sorti le mois dernier, et il est franchement bon, très différent du premier, pas du tout aussi détraqué, mais comme un peu fou et toujours aussi énergique.

Si ça vous plaît, voilà d'autres trucs qu'il a fait :

  • 2005, Smash Up Megamix 1.0

    Un mix de son propre album Smash et d'autres trucs. Vraiment bon.

  • 1998, Sense Juice E.P.

    Rien d'exceptionnel, mais de l'électro et de la house plutôt sympas

  • Remixes:

    • sur le disque bonus de ✝ par Justice
    • Batcaves, Kap Bambino
    • Pacific Coast Highway, Kavinsky (bonus de Nightcall)
    • Run into Flowers, M83
    • Illumination, Panico

Sync enables to have Firefox on several devices and to sync bookmarks, passwords, history, and other browser data between them.

By default, Firefox Sync will use Mozilla's servers. (Hence, you have to agree to their Privacy Policy and to their Terms, I hope you’ve read them, right?)

There's nothing wrong with Mozilla, they're big champion of Free Software. But on the one hand, there's definitely something troubling with sending very private data such as browsing history over the internet. Fortunately, Sync encrypts locally before uploading data and I hope they’re up to the Free Software standards of crypto.

On the other hand, centralisation is often a problem (don't put all your eggs in the same basket!). First, it puts the burden of maintaining huge Sync servers on Mozilla whereas a lot of users could be running Sync themselves and thus do a favour to Mozilla. Second, Mozilla becomes a single point of failure in case something's wrong with Sync; and with all the crazy stuff NSA’s been doing lately avoiding single points of failure is good because it raises the costs of surveillance.

And really, it is so simple to set up, that you really wonder why you haven't done it before!

[I’m starting yet another folder on this blog/wiki where I'm going to post some of the configs for my home servers.]

Looking for a way to escape NSA surveillance on your own? Patricia has designed an air gap system for you… good luck!

patricia • October 12, 2013 12:59 AM

The properties of my airgap system:

  1. It is inexpensive.
  2. It is not require much technical know how (not reverse engineering your BIOS to verify its integrity or trying to debug rootkits).
  3. The overhead involved is scalable to the amount of security required. That is, many shortcuts can be taken without weakening the overall system.
  4. It is an unambiguous set of steps that don't require judgment to be performed.
  5. It is fault tolerant (many components can get pwned, and it still is very secure).
  6. It is effective against a variety of threat models, up to and including a nation-state which has full knowledge of your setup, a team of hackers working to pwn you individually, and a black bag team that can enter your home without your knowledge.

Let's call our adversary Eve. I believe unless Eve can bring to bear the resources described in item 6, your setup is perfectly secure. Any feedback on the protocol I describe would be appreciated.

The threat models we will consider:

  1. A targeted attack in which the Eve has perfect knowledge of your setup and unlimited resources to craft an attack over the internet.

  2. Same as 1, but they will attack using malware which infects your hardware (BIOS, NIC, etc.) before you purchase it (the supply chain attack).

  3. Side channel attacks

  4. Black bag/ physical access to your home and computers.

  5. Untargeted attacks

I assume the reader can acquired uninfected software. One method for doing this is documented on the TOR website. The basic idea is to download from multiple sources, from multiple internet connects, compare the hashes, and verify downloads with PGP signatures.

Here's the setup:

The first computer (which I'll call CannonFodder) connects to the internet via TOR, ideally with PORTAL between the computer and the internet. PORTAL is the grugq's open source project which installs on Raspberry Pi and acts like a proxy forwarding all your traffic to TOR. Recently a hidden service was discovered on TOR which hacks the browser and phones home through the user's non-TOR internet connection the actual IP address and MAC address of the user. PORTAL prevents this attack by only allowing traffic to route through TOR, and blocking any other traffic.

The purpose of CannonFodder is to receive PGP encrypted messages and send PGP encrypted messages. It's what connects to the internet so the rest of the equipment doesn't have to. While it will be assumed to be hacked into and rootkit'ed, it is not going to be an easy target.

On CannonFodder install whatever personal security products you can get your hands on. Anti-virus, anti-persistence software, software that whitelists good processes and blacklists bad processes, EMIT... anything and everything possible. Make sure the OS and all software on it is patched regularly. What OS runs on the host is up to you. The host will run a VM and nothing else. What virtualization software you use is up to you, but the OS you run in the VM should be different from the host. So if the host is windows, the VM should be some flavor of linux or BSD.

The VM is going to run another VM. That VM will be a third OS, different from the other two. It's only job is to run a browser that can connect to TOR. Whether that means the TOR browser bundle, or Chrome connecting through PORTAL, it is up to you. Chrome is a good choice, since it auto-updates itself, making patching mindless. Once the VMs are set up, snapshot them. After every use, revert to the most recent snapshot. When new patches become available, revert the VMs, apply the patches, and take a new snapshot.

Make sure the browser has NoScript installed (meaning no javascript). Do not whitelist any websites in NoScript. Make sure the browser has no plugins installed besides NoScript. That means no Java, no silverlight, and certainly no flash.

The idea of all of this is if someone tries to exploit your browser, they might not get a rootkit on your host, because Eve may not have realized you are in a VM, and therefore might not be prepared to escape your VM. She may not even have a VM escape. If she does, she will still need to have a variety of exploits and be willing to use them against you. She may be unwilling because you are not a noob, a complicated setup like your's could trip up her exploits, and maybe expose them in a way that you can steal them. Think about it: Eve needs VM escapes for two different pieces of software, code that can run in all flavors of Linux, Windows, and BSD, possibly privilege escalations for each of those OS's, and most likely the ability to navigate PORTAL before phoning home. You are a complicated target relative to most people on the internet. Patched software ensures Eve must throw 0day at you. Personal security products can trip up her exploits or mean she'll have to invest even more individual attention in crafting exploits that sidestep your protections.

If CannonFodder is running on Sparc or MIPS or ARM, even more bonus points, because now even fewer people have the expertise required exploit and rootkit you.

CannonFodder is only used for visiting email, saving email, sending email, and burning CDs. No other browsing is allowed. A different email account is used for every different pen pal. In between logging into each email account, a new TOR identity is generated-- in the TOR browser bundle just click the generate new identity, using PORTAL it is a little more complicated. Messages should move from public email addresses tied to real identities to burner email accounts as quickly as possible. You should register a new email address for each new pen pal you correspond with. The email address should have no information that ties your real identity or your pen pal's real identity to the address.

CannonFodder can either be a laptop (which has had the camera removed, the mic destroyed, etc.) or a desktop. A laptop has the advantage that you can take it to different restaurants and connect to a different wifi access points every time CannonFodder connects to the internet. A desktop has the advantage of convenience (driving to a new access point every time you want to send an email eats up a lot of time). The downside to the laptop is other users of the wifi access point can attack your laptop. The downside to the desktop is your IP address is easy to obtain from your internet company, and with your IP address it is not far fetched that Eve can hack your router, and then your desktop.

Every day (or every other day, or every week) check the email accounts. Each email account gets its own CD. Any messages received from Alice are burned to CD A, any messages received from Bob are burned to a separate CD B, and so on.

By using TOR, not browsing the internet, and using random email accounts the hope is that you will be harder identify as someone to target and harder to locate once you are targeted. The VMs and other mitigations will ideally tip you off once you are targeted since your unusual setup could cause their attack to fail in a loud way. Even if it doesn't tip you off, it may be effective in preventing your computer from being rootkit'ed indefinitely, since Eve may not have the techniques readily available to breakout of your VMs.

Even given all these precautions, we will always assume CannonFodder is owned and has a rootkit which is recording every keystroke, the MAC addresses of all wifi access points in proximity, and whatever other information your computer might be privy to.

Now for the airgap. The second computer, which I'll call IvoryTower, is air gapped. If the only secrets you are trying to hide are your private PGP keys, the cleartext of your messages, and the cleartext of your pen pals'' messages, IvoryTower should be a raspberry Pi with a USB CD (read-write) drive. If you also want to read PDFs, I'm unsure if a raspberry pi can handle this, so you might have to use a desktop. The raspberry pi has several advantages when it comes to side channel attacks and black bag attacks. We'll discuss these later. It also has the advantage of being ARM architecture instead of x86 and x64. The architecture matters because in depth knowledge of x86 and x64 are much more abundant than knowledge of ARM. You increase the cost of attacking you by using a more unusual architecture.

IvoryTower is our most privileged machine, because private keys are used to decrypt messages on it. If we can prevent it from being rootkit'ed, our secrets are safe (except from black bags, more on this later). However, we should always assume IvoryTower is pwned and take steps to guarantee none of the secrets it protects leak onto CannonFodder and from there onto the internet.

Backing up for a moment, IvoryTower is where the PGP keys you use to correspond with your pen pals' are generated. The first day IvoryTower is set up, when it has the lowest likelihood of being rootkit'ed, generate a ton of PGP key pairs and burn them to CDs. If you are very security conscious, IvoryTower should be shutdown in between each key you generate. This is to clear the RAM of the device (always use an OS which overwrites RAM at shutdown). Many rootkits can't survive a reboot. A shutdown could clean the machine. If a rootkit does infect the computer, and private key material from other pen pals is still in memory, the malware can compromise more of your private keys than it would have been able to otherwise.

If IvoryTower is a desktop, it should have no hard drive, and it should boot from a live CD in a CD-ROM (no write) drive. The CD containing the new messages from Alice can be put in a separate CD drive. When the encrypted messages are copied to the desktop, they will be put in RAM on the device. Insert the CD containing the private key corresponding to the public key you gave to Alice, and decrypt the messages. Read then, then reboot. Write a new message to Alice, encrypt it with her public key. You can retrieve her public key either from the same CD that holds the private key you use to communicate with her, or by requesting she append it to the messages she sends. Burn your encrypted message to a new CD, and destroy the CD that transfered Alice's messages from CannonFodder to IvoryTower.

Part of Alice's message should be a new email address she created just to receive your next message. Similarly, your new message to her should contain the email address you've registered to receive her next reply. In the message you are sending should be an email address that they can send their next message to. This protocol, of always sending to a new email address, means Eve has fewer selectors to key in on when she taps the internet backbone, and she can't use your old email address as a selector to serve an exploit to you when you visit the old email account. If she gets your key, the messages are not all aggregated in one place for her to decrypt. Since the next email address is encrypted in each message, she will not know the next place a message is being sent.

Now for a trick. Write down the exact size (in bytes) of the encrypted message that is destined for Alice. Open the encrypted message in a hex editor (still on IvoryTower). Write down the first 5 bytes of the file. Write down the last 5 bytes. Pick a random offset (or 2 or 10) and write down 5 bytes there along with the offset. Reboot.

Repeat the procedure on IvoryTower for every correspondence that sent you a new message.

Now another trick. Using a public-key/private-key pair you've kept reserved for testing purposes, encrypt a fake message. If can say anything, just make sure you'll recognize your fake message when you decrypt it (more about this later).

You have destroyed the CDs with the messages your pen pals' sent you, you have a bunch of CDs with messages you'd like to send on CannonFodder, and you recorded some metadata about each of the encrypted messages (i.e., filesize, the first five bytes).

We have now reached the most dangerous part of the process, because if IvoryTower is rootkit'ed, any of the CDs could contain information about your secret key, information about the cleartext of your message or your pen pals'' messages. For example, if GPG on IvoryTower has been subverted by malware, the malware could have used the Eve's key to encrypt your message instead of Alice's public key. Then, when you transfer the message to CannonFodder, malware on that system could use Eve's private key to decrypt the message, send it to Eve, and re-encrypt the message with Alice's public key. You would have not idea you were compromised, because from your perspective Alice got the message OK.

To guard against this, we have a third computer, which I'll call DoubtingThomas. This is the one computer who's integrity is important. Luckily, it too can get rootkit'ed, as long as it is rootkit'ed by an untargeted attack. If Eve and her minions target yo and get on DoubtingThomas, you're in trouble.

DoubtingThomas is a raspberry pi. This is a nice choice because it can be physically hidden, making physical tampering by a black bag team more difficult. It also uses much less power than a desktop, meaning many side channel attacks don't apply. Also, electronic devices (bugs) that could be hidden on a desktop computer's motherboard or PCI peripherals stand out much more on a raspberry pi.

The most important thing about DoubtingThomas is simplicity. We want very little surface area on DoubtingThomas. IvoryTower runs a full fledged OS with lots of code and lots of surface area, making it easier to own. DoubtingThomas, however, just needs to have a hex editor, GPG, and the ability to read from a CD. Ideally the CD has filesystem, since a filesystem is more surface area for an exploit, so a raw filesystem that can be read with would work well, especially if that meant 'dd /dev/[cdrom]' would have identical output to the encrypted blob IvoryTower produced.

DT has a CD-ROM (no write) drive connected by usb so it needs a USB driver as well. The OS on DoubtingThomas would be custom coded to be minimal and only have what is needed for this task. On DT we open the encrypted messages from IT in a hex editor so you can visually inspect the file is unchanged since being on IT. It is important also verify that the file size is the same, and that the rest of the disk is empty.

What does this buy you? If the hex editor on DoubtingThomas shows the same values as the hex editor on IvoryTower, you know you can trust IvoryTower's hex editor and burner. However, you cannot know for sure what key actually encrypted the message. Eve could easily have encrypted the payload if she was on IT and subverted GPG. Basically, you can trust the burning software and the hex editor, but you still don't know if you can trust the install of GPG on IT.

This is where the message you encrypted with a public key for which you have the private key comes in. Decrypt it on IvoryTower, and if it decrypts correctly, you know you can trust GPG on IvoryTower. Why? Because if malware has subverted GPG on IvoryTower the fake message won't decrypt correctly. If your message is encrypted with the Eve's key, there's no way to tell just by looking at the encrypted file.

After the test on DoubtingThomas, you know you can safely put the CDs in CannonFodder, and email your messages to your pen pals'.

That's the procedure, now how does it stand up to our threats, and are there any other things we can do to make it even more secure?

1) Attack from the internet.

If CannonFodder is pwned, when you burn a CD of messages addressed to you, an filesystem exploit or an exploit that targets any of the other code that is required to read from a CD could be burned to the CD too. This is the only way IvoryTower can be rootkit'ed if Eve limits herself to attacking over the internet. If IvoryTower is rootkit'ed, you can't trust the output of any of the software on that system. IvoryTower could:

a) encrypt with the Eve's public key when it says it's encrypting with Alice's public key (they get cleartext of your message to Alice) b) append your private key, encrypt with the Eve's public key (they get your private key for corresponding with Alice, and your message to Alice). c) Write your private key and any cleartext left in RAM to slack space on the CD.

DoubtingThomas verifies the work of IvoryTower as described earlier. However, there are ways malware could get around this. The first that comes to mind is maintaining a whitelist of keys that it will subvert and your fake key is not on the list. But that would be so targeted, and require such perfect knowledge it's not believable.

Make sure to generate plenty of private keys as soon as you get IvoryTower setup. Once it's subverted it could be generating weak keys. Also register lots of email accounts on CannonFodder.

2 and 3) Your equipment was pre-pwned with BIOS malware before you bought it and side channel attacks

This would have to be general purpose malware that didn't target you specifically (because you were careful enough to buy hardware in person from a big store and not online with your credit card, where it could be messed with in a targeted way). There are a couple threats here. The first is that IvoryTower's key generation is weakened. This is a serious flaw that I don't know a good way around. The second is the computer is modified to transmit data through side channels. So, for example, it flickers the screen at a frequency imperceptible to the human eye, and it just scans through RAM constantly doing this, so that a sensor picking up the flickers would have a dump of RAM. Or it scans through RAM and modifies the power unit to transmit data (using the power cord to create an antenna, or to communicate with another device on the same power circuit, perhaps CannonFodder). Or it blinks an LED faster than humanly perceptible. Or it uses the wire that wraps around the perimeter of the monitor that connects to the LED and forms an antenna to ex-filtrate data. Or it produces auditory signals by the making the processor hum. It can control the frequency of the hum with the type of operation it has it do. Or Eve uses Van Eck Phreaking to reconstruct your monitor display by the radiation it gives off.

Side channel attacks are real. They are very hard to defend against. On the positive side, I assume they are expensive to deploy. But since our assumption is we must be resistant to expensive attacks, we must consider side channel attacks.

First I'll point out that the only computer in our setup that must be resistant to a side channel attack is IvoryTower. If IvoryTower is a raspberry pi, it draws such little power that the power cord attack is not feasible. Any form of radiation attack (the antennas, Van Eck phreaking) can be mitigated by only running IvoryTower in a local restaurant's walk-in freezer (the poor man's faraday cage). A Raspberry Pi is portable enough to take to a walking freezer. For Eve to pull off the visual and auditory based attacks she presumably requires a black bag team to place sensors in your workspace (more on this in a minute), but a raspberry pi based system could be set up in a different location every time you use it (meaning it's much harder to 'bug' in this way).

Note that the cords for keyboards and mice should have shielded cabling. Every cord in your setup for IvoryTower should. Peripherals should never be shared amongst computers since they could be infected with malware.

All LEDs should be disabled in all your computers/ monitors/ peripherals by digging out the LED.

4) Blackbag team visits your house while you aren't there

You are going to have to have a good place to stash the CDs containing your private keys as well are your raspberry pi(s). They are the prize you are trying to defend.

One threat is Eve's henchmen break into your house and replace your keyboard with a duplicate that has a key logger, or that infects your device with malware when you plug it in. For this reason, put distinctive scratches into all your peripherals, take a photo, and regularly check that the scratches are identical to the photo. This is how weapons inspectors ensure the seals protecting weapons caches have not been tampered with. The seals are scratched in a distinctive way that can't be forged, then check periodically. Use tamper evident tape on your devices to slow down a burglar that wants to plant a keylogger in your keyboard.

If IvoryTower is infected in its BIOS and it is capable of stashing private keys (in the BIOS or in the firmware of PCI peripherals on the system), then a black bag team could get your keys this way. This is another argument for IvoryTower being a raspberry pi and being stashed somewhere. If IvoryTower is hidden and the burglar can't find it, they can pull the private keys from the BIOS. On a desktop, the fewer PCI peripherals, the less space the malware has to stash keys if it is in fact using this strategy. So make sure you have no PCI peripherals. If you have a desktop, put super glue in all the USB interfaces so they aren't functional. Do the same to any interface on the mother boards that could attach removable media. Try to make the case impossible to open (bonus points for encasing it in cement except for the fan, CD tray, cables for keyboard/mouse, power cable and power button). Your attack surface for a burglar becomes what they can modify with a liveCD and maybe the drivers that handle input from your monitor (minimal).

5) Other threats Most other threats won't get past your browser, because it's fully patched, and it they do, they'll be destroyed by reverting your VM.


Is it easier to verify raspberry pi's embedded code than a desktop's BIOS?

What if IvoryTower is pwned before you buy it and produces weak PGP keys?

What to put for full name, email address in PGP key?

How long should keys stay valid for?

In today’s world, communication and branding matter almost as much in business as they do in conveying ideas and ethics. Which is why I often wonder, what the people using the term “Open Source” are doing against this:

Is Facebook The World's Largest Open Source Company?

Yes, says Matt Asay–who claimed that for Free Software/Open Source to succeed in business, “it may need a little help from proprietary software.”

So, one must wonder…

What makes Facebook an Open Source company?

I hope that, at this point, we can drop the notion of Free Software; because free software focuses on the users’ rights to be in control of the technology that affects them. If there’s anyone in control of Facebook, it’s Mark Zuckerberg, certainly not the users. ↓↓↓

  • Even though open source software and free software designate the exact same category of software, and the community of people who develop free and open source software is not as divided as some might think, there’s no denying that the terms convey different meaning, have a different emphasis.

    Actually, it’s not entirely clear to me what the term Open Source conveys any more. What hasn’t helped at all, is the belief that “the Internet”, as Morozov would put it, can been used as the driver for solving everything in all areas; and that the same is true of Open Source. Open Source bears some of the same hype that “the Internet” does. Think open data, open access, open innovation[^open-innov], open government, open science, etc.

[^open-innov]: What’s most troubling about “open innovation” is that innovation itself is deeply misunderstood, too often confused with merely “packaging” existing technologies–at which Apple excels, even though Apple is far, far, from being “open.”

What “open” even means is relatively ambiguous. Ambiguous enough that Facebook can claim as far as 2006 to be about a “spirit of openness.”

That reminds me of an internal European Commission draft that was leaked on which I worked with Karsten at the FSFE in 2009:

"Specifications, software and software development methods that promote collaboration and the results of which can freely be accessed, reused and shared are considered open and lie at one end of the spectrum while non-documented, proprietary specifications, proprietary software and the reluctance or resistance to reuse solutions, i.e. the "not invented here" syndrome, lie at the other end.

The spectrum of approaches that lies between these two extremes can be called the openness continuum."

With this kind of nonsense, you can say anything. I was trying to put it into words. I remember Georg put it brilliantly: to say that proprietary software lies at one end of the openness continuum equals to saying that North-Korea lies at one end of the democratic continuum.

Maybe all this is possible, because in this context, open is meant to refer explicitly to free software/open source software. But that’s missing the point of what free software actually is about, and about how you categorise free software.

Proprietary software isn’t at the end of the free software continuum, it’s antagonistic to free software. They’re opposite. You can't have both; it's either something’s been distributed to the users of the program with a license that grants them the four essential rights to use, share, study and improve the program; or it's not.

Now, let’s go back to Facebook. Without thinking clearly, sure, Facebook could end up inside the “openness continuum” of whatever.

But before saying that Facebook is an open source company, one must ask: is Facebook a software company to begin with? And if not, then what is Facebook doing that has to do with open source at all?

Look closely, and you’ll realise that all that Facebook’s releasing as free software/open source is not related to the core of the service they're providing their users with over at facebook.com.

Sure, it's publishing some of its in-house developed software, for data centers, database, etc. In that sense, it's quite clearly in accordance to the current mantra, “open source (almost) everything” in which the part that's left off is actually the most important part.

But that's not enough to call yourself an “open source company.” Or does that mean that all manufacturers embedding a linux kernel in their device are open source companies as soon as they release sources of their modifications to the kernel? Of course not!

What makes a Free Software company, then?

usage of and contribution to Free Software are not differentiators for what makes a Free Software company. The critical differentiator is provision of Free Software downstream to customers. In other words: Free Software companies are companies that have adopted business models in which the revenue streams are not tied to proprietary software model licensing conditions.

Georg published an article in 2008 precisely about this issue.

Other posts in the Installing Kolab series: - part 1 - part 2 - part 3 - part 5

After I upgraded from Kolab 3.0 to 3.1, hoping it would solve the SMTP issue (i.e. I could not send email from the roundcube app freshly setup by the kolab script! Same problem with msmtp…), I ended up with another broken kolab instance: Roundcube wouldn't connect to the database any more. When I was trying to restart kolab's service, all I got was:

root@totosh:/home/hrd# service kolab-saslauthd start
root@totosh:/home/hrd# Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/saslauthd/__init__.py", line 114, in run
  File "/usr/lib/python2.7/dist-packages/saslauthd/__init__.py", line 195, in do_saslauthd
  File "/usr/lib/python2.7/dist-packages/pykolab/auth/__init__.py", line 148, in connect
    from pykolab.auth import ldap
  File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 38, in <module>
   import auth_cache
ImportError: No module named auth_cache

Quite fed up, I tried to re-install the thing again. Yes, I'm trying really hard to make this work.

So this time, I followed the not-yet-official docs which are up-to-date to deal with kolab 3.1, the latest release version.

During the setup, I got this:

Please supply a Kolab Service account password. This account is used by various
services such as Postfix, and Roundcube, as anonymous binds to the LDAP server
will not be allowed.

Kolab Service password [xxxxxxxxxxxxxx]: 
Traceback (most recent call last):
  File "/usr/sbin/setup-kolab", line 42, in <module>
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/__init__.py", line 43, in run
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 170, in execute
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 202, in execute
    components[component_name]['function'](conf.cli_args, kw)
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/setup_ldap.py", line 483, in execute
  File "/usr/lib/python2.7/dist-packages/pykolab/auth/__init__.py", line 148, in connect
    from pykolab.auth import ldap
  File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 38, in <module>
    import auth_cache
ImportError: No module named auth_cache

Yet again, on a completely fresh Debian wheezy, Kolab's setup failed.

The conclusion, that others have got to on the IRC channel (hello bertie if you read this!) is that Kolab was not working on Debian at that point.

So I'm now trying CentOS, which I never used… I’m not too happy to have to try to get used to a whole new system just to run Kolab. But I guess it can't hurt to learn a little bit about CentOS and since the machine's only purpose is actually to run Kolab, it seems like the best choice.

Fortunately now, some people are contributing to fix the Debian packages of Kolab. I'll try again in the future!

Other posts in the Installing Kolab series: - part 1 - part 2 - part 3 - part 4

So, after about 4 tries on Debian, I decided to give Kolab a try on CentOS, the community derivative of Red Hat Entreprise Linux. Fortunately, I was not completely lost here, it seems I kept some habits from when I was using Fedora.

A few hints, if you want to install CentOS 6.

  • Finding the download link is not easy from the project's home page. Go to the wiki.
  • If you do a netinstall, make sure to use reliable sources
  • if you try with the Live CD/DVD, make sure that your hard drive is encrypted using a QWERTY-layout-friendly pass phrase…

After CentOS was set up, I just followed the not-yet-official docs at kolab: http://hosted.kolabsys.com/~vanmeeuwen/build/html/installation-guide/. Everything went smoothly this time. And within a few minutes, I was running Kolab.

So far, the only issue I've got was that I could not get an email delivered to a @gmail.com address, Google decided that I did not meet their standards. It seems the problem is that the IP address has changed and thus Google does not like that… I hope it will resolve in the future, there's nothing wrong with moving servers around and pointing the domain to a new IP address after all!

I just had a good day ☺

The results of the first part of the bar exam were announced earlier today. I passed! So I’ve got no more excuses now: I’ve got to work to pass the second part (oral exams). Of course, that's kind of a relief because with these kinds of exams you're never really sure if you succeeded.

To make things even better today, it looks like Kolab on Debian is going to get some love from the Free Software community!

As far as I'm concerned, this is all great news. It is a bit sad that I was too impatient and already went for CentOS to try Kolab. But at least now, I know I can recommend Kolab to my friends who use Debian: the community is here to help! I'll have to find a way to contribute personally though ☺

Oh and BTW, I'm now in London until Monday. Mozilla invited me to run a session at the Mozilla festival on “Fighting the biggest lie on the Web” (I agree to the terms of service!)

I am really looking forward to this. Mozilla is one of the most important organisation building the technologies that empower people! I don't even want to think about what the web would look like today without the work they have done (including a lot of volunteers and a very open way). I can't wait to feel the atmosphere of the festival!

So if you're in London too, even if you're not attending #MozFest (I have read the event is already full!) do not hesitate to get in touch. Tomorrow I'll try to meet with my friend Andreas who's been a volunteer with the Free Software Foundation Europe for a long time, and who's moving in London. I'll also try to catch up with Mark Lizar who's one of the core persons behind Open Notice, the place where projects related to ToS and privacy policies collaborate.

Exciting week-end ahead!

The Windows Tax problem and free software

At this point, you must have figured this out. I am a free software advocate. I think it's both painful and wrong when I'm not in control at all of the software that I use on my computers.

As many users of GNU/Linux systems know, it's incredibly difficult to buy a decent laptop without being forced into buying Microsoft Windows, even if you don't want to use it. This is what we usually refer to as “the Windows tax.” This has two consequences:

  • we have to pay indirectly for a Microsoft Windows license fee through the manufacturer, and we do not even know how much it really costs us,

  • we get hardware that may or may not be supported by the Linux kernel out-of-the-box, which results in a waste of time in settings adjustment (or worse).

If you're looking for information on where to get hardware free of pre-installed proprietary software, FSFE volunteers maintain a list of Hardware Vendors.

If you already bought a machine with Windows and want to get your money back, there's also tons of information on how to get a Windows Tax Refund (make sure to look at information specific to your country).

But getting your money back does not fully fix the problem and takes a lot of time (sometimes met with deception). Indeed, it does not resolve the hardware support issue in any way because it does not impact the manufacturers' sale, and it sure does not help to make demand of GNU/Linux grow on the market of pre-installed laptops.

So obviously, one of the best strategy is to reward manufacturers that meet our demands and supply laptops with GNU/Linux pre-installed and good hardware support. By good hardware support, I mean that it should work without requiring non-free software.

And here comes the Dell XPS 13.

Dell XPS 13 Ubuntu: wireless issues with Qualcomm Atheros AR9462

Dell logo

Dell has launched a project to provide developers with a good laptop. I am not really a developer in my day-to-day life, but I could certainly enjoy a good laptop as well ☺

Especially, the XPS 13 comes with Ubuntu. I have been told by Otto Kekäläinen (FSFE head in Finland!) there's even a custom linux kernel and all that. I could have a look at his XPS 13 while in Berlin last month and it looked amazing.

So I decided to get one, as I was looking to replace the Thinkpad Edge that has been around me for the last 3 years (which I have not been very pleased with because of several hardware issues and not so helpful Lenovo customer relations). The only thing that was holding me on from buying the XPS 13 was the price. It's 50% more expensive than the budget I usually put into a laptop.

About two weeks ago, I made up my mind and bought one. I got my hands on it today. And surprise! the wireless connection drops off momentarily here and then, something like every 10 minutes. And when I deactivate bluetooth using the Ubuntu menu in the top-right hand corner, the wifi drops as well (and it's super strange to get it back, I have not found the exact pattern that works).

At this point, I was kind of surprised. But well, I go on with the setup process, hoping that the wireless connectivity does not drop too often, because the laptop is too thin to have an RJ45 port as backup!

One thing that did not go well during the setup process, even though Ubuntu asked me for the keyboard layout, it sticked to QWERTY afterwards, making it quite painful to enter passwords and stuff.

After the setup (which went very quickly), I decided to upgrade everything. Maybe that'll solve it… It didn't. Of course.

So I opened the terminal, and

$ lspci
Network controller: Atheros Communications Inc. AR9462 Wireless Network Adapter

Why. Oh, why Dell? Why are you doing this to me? The original page where I bought the laptop from states quite clearly:

Intel® Centrino® Advanced-N 6230 802.11 a/g/n

Having a quick look around and searching, I see that I'm not the only one who got a different wireless chipset than the one announced by Dell. I wouldn't care so much if it were working out-of-the-box after updating. But it doesn't!

And No, I don't want to fix it myself. The reason why I'm buying a pre-installed GNU/Linux computer in the first place is to make sure everything is perfectly supported!

I'm now trying to get mine exchanged for the Intel Centrino wireless card… But of course, tomorrow is a holiday.

Well, maybe it's for the best. I am not supposed to tweak my laptop these days: the bar exam orals are approaching!