Earlier this year I applied for funding: a call was opened by the European Union and someone told me it was worth a shot for a project related to software forges. My lack of experience writing grant applications was a handicap but I went ahead anyway. I asked a friend if he would agree to apply with me because I felt it would increase the chances of success. I soon discovered that there was no example of grant applications to get inspiration from. Although people and organizations share such documents in private, within their own network, they are shy about publishing them for everyone to see. This was a handicap to get started. In the spirit of sharing, I then decided to be 100% transparent about my own work: not only by publishing the drafts of the grant application but also the discussions with everyone involved.
The grant was accepted and transparency became a core value of the project, from the spreadsheet where all expenses/income are kept to the monthly reports summarizing what was done. Although it is not a very big project, full transparency also means there is a lot of information and digesting it can be very time consuming. However, someone with enough time on their hands could know almost everything, down to the last detail. Including how the money is spent to further the project.
The spreadsheet is one page long and once all expenses below 100€ per month are trimmed, there only are two items: 3,000€ per month (which amounts to roughly 1,500€ per month after taxes in France) for our salaries. And a single income source for the project: the European Union over a period of nine month, from May 2021 to January 2022 included. The work being funded is divided into deliverables and the monthly reports published for the project conveniently help trace what was done on a particular topic. This is on purpose since they are also used to show progress to the European Union. And by reading the reports it is trivial to figure out who did what. Even a superficial analysis shows that I’m the only one working on most deliverables and that I did most of the work on the others.
There are many possible interpretations for this imbalance, one of them would be that some people are more efficient than others in a given context. For instance I would make a very inefficient manual worker, although I would likely be paid the same as my colleagues. Another example, closer to my skills, would be if I was co-authoring a book of fiction with someone (this has been a dream of mine for the longest time). The main author would presumably be a seasoned writer and my contribution would comparatively be very small because it takes me a long time to come up with just a short paragraph that is decently written. But we could agree to be paid the same for this work, regardless of our respective skills. In the context of the project funded by the European Union, it turned out that I was more efficient.
I’ve been told that when people are paid the same they should by as efficient. Or that people should be paid depending on how how efficient they are, which is another aspect of the same idea. But I think it is impossible to expect the exact same amount of work for the same amount of money regardless of the person. What really matters is that there is an agreement between every party involved. I agreed to a 50/50 split the European Union grant when the project started and I’m fine with this agreement, regardless of how efficient each of us is.
In march 2021 the libreboot project was taken over by one of the core developers and went from a democratic governance to being controlled by a single person. In July 2021 the same happend to the misskey project. Such a “coup” is a bug in how a democratic project is setup: it should not be possible for a single person to take control of the entire project. But it is possible, by design, in horizontal communities such as Enough or fedeproxy.
Although the people who lost their influence over libreboot could have forked the repository and start a new one to keep going, they apparently did not. There were a few assets that could not be forked:
- The domain name
- The IRC channel
- The wikipedia page
Bootstraping a new project with a new domain name, an empty IRC channel and a two year period to build enough of a reputation to deserve a wikipedia page is a lot of work. Enough work to put the person who wants to fork at such a disadvantage that it effectively prevents it from happening. In democratic communities this centralization is acknowledged and considered acceptable. There is no need to fork because the voting process gives everyone the power to control these centralized resources.
Online horizontal communities must be designed to fork as a whole because there is no way to prevent someone from taking over exclusive resources such as the domain name. If there was a way, the community would not be horizontal, by definition. However the concept of a fork cannot be applied to a centralized resource (e.g. domain name), it is only meaningful for decentralized resources (e.g. DVCS). It follows that all centralized resources must be removed from horizontal communities otherwise their ability to fork is diminished and it opens a path to the tyranny of structurlessness.
When a command requires a tty although it should not (some OpenStack client subcommands do), it will fail when included in a crontab. Unfortunately there is no packaged utility such as ptyget to allocate a pty. Fortunately ssh -tt can be used instead:
-t‘ Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys
$ ssh -tt $USER@127.0.0.1 tty < /dev/null
$ ssh -t $USER@127.0.0.1 tty < /dev/null
Pseudo-terminal will not be allocated because stdin is not a terminal.
I’m very new federation. Over the years I heard rumors that it was good without understanding why and how. I ran a mastodon instance for a few years but did not use it much: I’m a developer and not much of a microblogger (reading or writing). Beginning of last year I started using https://peer.tube/ and was happy to see it work for real but did not use any of its federated features. But when https://joinmobilizon.org/ was announced I thought it made a lot of sense to organize events in a federated way: smart move. And all along I thought I should read about fediverse but I still have no idea what it means (really).
Continue reading “Federated development and federated forges”
The C API of libvirt is well documented and one can easily understand how the virNetworkGetDHCPLeases function should be called. However, it is less straightforward with the python libvirt module despite the libvirt development guide. The example from the sources shows the corresponding python method is DHCPLeases
conn = libvirt.open("qemu:///system")
net = conn.networkLookupByName("default")
leases = net.DHCPLeases()
But how did virNetworkGetDHCPLeases become DHCPLeases?
Continue reading “libvirt functions discovery in python”
Even when nonprofit organizations publish their financial records (such as the mediawiki foundation), the work done by volunteers has an estimated financial value of zero. These organizations will however unanimously claim that volunteers are an essential part of society and have a very special place in their heart. While most of them are sincere, observation tells us a different story:
- In the context of fundraising, volunteers are second class citizens compared to organizations who donate money
- A lack of transparency excludes volunteers from decisions and day to day work
How is it that one year of a volunteer who is worth $60,000 on the market is considered less valuable than a $60,000 grant used to pay the salary of the same person?
Continue reading “Volunteer work is not worth a dime”
The Debian GNU/Linux cloud images can conveniently be used out of the box with the following:
$ wget -O debian.qcow2 https://cloud.debian.org/images/cloud/buster/20201214-484/debian-10-generic-amd64-20201214-484.qcow2
$ virt-sysprep -a debian.qcow2 --run-command 'dpkg-reconfigure --frontend=noninteractive openssh-server' --ssh-inject debian:file:$HOME/.ssh/id_rsa.pub
$ virt-install --connect qemu:///system --boot hd --name debian --memory 1024 --vcpus 1 --cpu host --disk path=$(pwd)/debian.qcow2,bus=virtio,format=qcow2 --os-type=linux --os-variant=debian10 --graphics vnc --noautoconsole
$ virsh --connect qemu:///system domifaddr debian
Name MAC address Protocol Address
vnet0 52:54:00:3e:6f:1a ipv4 192.168.122.84/24
$ ssh firstname.lastname@example.org df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 1.9G 1.3G 481M 73% /
However, 2GB for the root file system may not be enough: virt-resize and virt-rescue should be used to expand it.
Continue reading “virt-resize applied to Debian GNU/Linux cloud images”
Enough is a software released as a pypi package and a docker image to maintain an infrastructure composed of multiple machines, physical or virtual. In other words, it is an infrastructure as code based on Ansible and OpenStack. In addition it is built exclusively on Free Software, primarily because it helps with backdoors and viruses. These two properties combined create a unique opportunity to onboard volunteers devops willing to help nonprofit organizations defending whistleblowers.
Continue reading “Onboarding devops with infrastructure as code”
After four years volunteering for non-profits (from the Freedom of the Press Foundation working on SecureDrop to the Maison des Lanceurs d’Alerte working on Enough), I find myself looking for paid work. It is a challenge, mainly because I do my best to only use Free Software and only write Free Software. The last part (writing Free Software) has become increasingly easier in the past twenty years: there are hundreds of companies willing to pay a full time developer to exclusively contribute to a Free Software code base. The first part (using Free Software) is still very difficult.
Continue reading “Looking for a Free Software vegetarian developer position”
Installing packages from PyPi is a dangerous proposition. In July 2020, the request package (note the typo: request and not requests) was downloaded over 10,000 times. It was a malware that installed a daemon in .bashrc, providing the attacker with a remote shell on the machine. PyPi has always been vulnerable to typosquatting attacks but does not display any warning to their users. A system administrator with a healthy discipline with regard to security hosted the “request” malware during 20 days in August 2020 and discovered it by chance. How many machines are still compromised? Why is there no information on PyPi about this malware and all others? Even though there is every reason to suspect such attacks happen on a weekly basis and target hundreds of thousands of users, is is almost never discussed in public.
When contacted about a malicious package the python security team or the people responsible for PyPi only answer is that you can’t trust anything on PyPI. There however is no such warning on https://pypi.org and no documentation on how to verify that a package can be trusted. If PyPi did not already know about the malicious package, they will remove it. But there will be no security warning about which malicious package was published or when. For instance a dozen malicious packages were discovered in 2018 and removed from PyPi, but there is no way to know when they were published and for how long.
Consequently as a PyPi user who wants to avoid malware, I’m responsible:
- to not make typos when running pip install somepackage, even for test purposes
- to verify it does not contain a malware (there is no documentation on that topic)
- to keep track of all packages installed for forensic analysis (because there is no public database of known malware distributed via PyPi)
This is a very heavy burden.
The Debian GNU/Linux distribution maintains a software repository which is similar to PyPi in the sense that it contains packages. With one major difference: it is efficiently protected against malware. All packages are signed by their authors and the signature can be verified with a web of trust when they are installed.
As a Debian GNU/Linux user, my responsibility to avoid malware is:
Ideally PyPi will provide a similar security feature in the future but there currently is no work in this direction (note that PIP 458 Secure PyPI downloads with signed repository metadata is being worked on but is not about package authors signing their packages). As a result downloading a package from PyPi is either very time consuming (because it needs to be carefully analyzed) or a security risk because it can contain a malware for which no information is ever going to be released on PyPi, even after it is discovered.
This is a large scale problem because PyPi is implicitly trusted by hundreds of thousands of users who are not informed about the risks they take. Over the past decade people working on PyPi and organizations financing their work repeatedly made a conscious choice to work on something other than protecting users from malware. It may be OK to do so occasionally but after such an extended period of time it becomes a pattern. PyPi is responsible for distributing malware and urgently needs to re-adjust its priorities to resolve the problem.