Allocating pty in a shell script

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.

$ ssh-keygen
$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys
$ ssh -tt $USER@127.0.0.1 tty < /dev/null
/dev/pts/14
$ ssh -t $USER@127.0.0.1 tty < /dev/null
Pseudo-terminal will not be allocated because stdin is not a terminal.

Federated development and federated forges

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”

libvirt functions discovery in python

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

import libvirt
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”

Volunteer work is not worth a dime

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”

virt-resize applied to Debian GNU/Linux cloud images

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 debian@192.168.122.84 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”

Onboarding devops with infrastructure as code

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”

Looking for a Free Software vegetarian developer position

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”

PyPi is responsible for distributing malware

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:

  • nothing

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.

How the cancel culture was leveraged against RMS

Starting in August 2019, MIT was being put on the spot for accepting money from Jeffrey Epstein and accusations against the late Marvin Minsky for having sex with one of his victims resurfaced. In a call for protest, someone even wrote that Marvin Minsky assaulted her. In reaction Richard Stallman replied in an email that “the word “assaulting” presumes that [Marvin Minsky] applied force or violence, in some unspecified way, but the article itself says no such thing”. The rise of the “cancel culture” makes it very hazardous to publicly say or write anything regarding sexism, prostitution or racism. Despite this, Richard Stallman has published a number of blog entries on those topics over the years, ignoring people urging him to stop or become a target. But this time he caught the attention of someone.

After reading Richard Stallman email, Selam G. published an article and commented: “[Richard Stallman] says that an enslaved child could, somehow, be “entirely willing””. What Richard Stallman actually wrote is: “We can imagine many scenarios, but the most plausible scenario is that she presented herself to him as entirely willing. Assuming she was being coerced by Epstein, he would have had every reason to tell her to conceal that from most of his associates”. More tabloid articles followed, further mischaracterising Richard Stallman statements. A photo of Richard Stallman office door at MIT labeled “Richard Stallman: Knight for Justice (also: hot ladies)” was also included in Selam G.’s article as a proof against Richard Stallman.

In response, Richard Stallman commented on his blog: “headlines say that I defended Epstein. Nothing could be further from the truth. I’ve called him a “serial rapist”, and said he deserved to be imprisoned.” As for the label on Richard Stallman office door, it was added by an unknown person, over a decade ago. In a documentary shot in 2017/2018, it only reads “Richard Stallman: Knight for Justice” (at 6:22) because Richard Stallman removed the ending: (also: hot ladies). The content and the tone of Selam G.’s article is archetypal of the cancel culture and she was joined by people sharing the same faith to demand the resignation of Richard Stallman.

Any effort to establish the truth was a loss of time: Richard Stallman participating in a discussion about rape and prostitution was blasphemy. He was not attacked for what he wrote, he was attacked for writing on a forbidden topic. Another similar and well documented instance is what happened to Bret W. in 2017 at the Evergreen College when he wrote “one’s right to speak –or to be– must never be based on skin color” in an email. In both cases there were many witness who did not intervene for fear of being the next target. I also stayed silent and horrified while Richard Stallman was shamed publicly. I wanted to believe it would blow over after a few days. I trusted the Free Software community to be rational and eventually disregard this episode. I was sorely mistaken.

Two days after Selam G. article was published, Software Freedom Conservancy who is run by some of the most influential people in the Free Software movement, published a statement demanding Richard Stallman’s resignation from the FSF. Neil McGovern, executive director of GNOME, also asked for Richard Stallman resignation and links to a tabloid article grossly mischaracterising Richard Stallman. They endorsed the attacks and legitimized them in the eye of the Free Software community. The next day Richard Stallman resigned from his position as president of the FSF.

It all happened very quickly but the roots of Richard Stallman’s dispute with other members of the Free Software community are deep. Software Freedom Conservancy states that “when considered with other reprehensible comments [Richard Stallman] has published over the years, these incidents form a pattern of behavior that is incompatible with the goals of the free software movement” and Neil McGovern wrote something similar. Although they did not reference any specific event, there are some publicly available records of past disputes. For instance, in September 2018, Richard Stallman wrote a blog entry very similar to the defense of Marvin Minsky. He rewrote it in the following weeks because, in his own words: “some people reading earlier versions of this note seem to have got the idea that I condone enslavement of prostitutes”.

I can only assume the respected members of the Free Software community who leveraged the cancel culture and tabloid journalism felt justified because of years of frustrating disputes with Richard Stallman. But they made a terrible mistake. Richard Stallman was unjustly and severely punished. He no longer has a position at the FSF, which he founded 34 years ago, he also lost his position at MIT, his scheduled talks could be canceled and he lost his home.

History will remember that in 2019 Richard Stallman took a major hit from the cancel culture and tabloid journalists. And also that respected members of the Free Software community endorsed the cancel culture and tabloid journalists. They sent an ominous message to all their opponents: we fight dirty. They negated the benefit of dialog, any sense of rational thinking and threw away years of debate with Richard Stallman. Leveraging someone who had no clue about the past disputes to get rid of their opponent proved to be much more efficient. We should now expect that some Free Software activists will use the cancel culture as a mean to an end. But what they should do instead is to ignore the furor, wait until it passes and resume a discussion based on truth and logic. It takes longer but it is the only way to build a safe and inclusive community.

recovering from lost partition table: a use case

This happened today and may be of use to other Ubuntu or Debian users with a similar configuration. The disk of a laptop lost its partition table because it was mistaken for a USB key and modified. There was no way to recover the old GPT partition table from the backup because it was not corrupted. The new partition table was both in the GPT partition table and its backup.

The laptop was installed with Ubuntu 16.04 about two years ago and it was assumed to:

  • Have an EFI partition
  • Have a separate boot partition

The partition table is rebuilt to start with a 512MB partition for EFI (type 1) followed by another parition for the rest of the disk. When the second partition table is created using fdisk, it will issue a warning about an ext2 signature: it must be preserved.

Using dumpe2fs on the second partition the actual size of the partition is displayed, for instance:

$ dumpe2fs /dev/nvme0n1p2
...
Block count:              249856
...
Block size:               1024

The partition table is adjusted accordingly, taking into account that filesystem blocks are 1024 bytes and fdisk sectors are 512 bytes (i.e. 249856 * 2 == 499712):

$ fdisk -l /dev/nvme0n1
Device           Start        End   Sectors   Size Type
/dev/nvme0n1p1    2048    1050623   1048576   512M EFI System
/dev/nvme0n1p2 1050624    1550335    499712   244M Linux filesystem

Note: for some reason fdisk adds 1 to the specified number of sectors in some cases. Care must be taken to verify the actual number of sectors allocated to the partition and adjust them accordingly.

The signature of the third partition gives a hint regarding its content. If it is crypto_LUKS, it can be open with cryptsetup luksOpen /dev/nvme0n1p3 root and the device will show under /dev/mapper.