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.

Why I deleted my GitHub account

Today I permanently deleted the GitHub account that was in my name. I used it to contribute to Free Software projects that only use this proprietary platform. I started using GitHub a few years ago and constantly tried (and failed) to convince projects to self-host using Free Software instead. As more and more Free Software projects I care about moved to GitHub, I ended up using it daily and it made me sad.

The recent acquisition of GitHub by Microsoft turned it into a service that belongs to a company that is actively working against the Free Software movement by:

  • Lobbying for Software Patents and being one of the largest Software Patents holder in the world
  • Lobbying for DRMs and implementing them in their software products
  • Convincing people they must not fight in court when their rights under copyleft licenses are violated

By using Microsoft services daily, I would also implicitly support them, even if indirectly. I feel better knowing I no longer depend on Microsoft in any way.

HOWTO nginx & letsencrypt on Debian GNU/Linux stretch/9

The goal is to configure a nginx server with automatic Let’s Encrypt renewal, assuming a new dedicated virtual machine running a pristine Debian GNU/Linux stretch/9.

Install docker-compose:

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates dirmngr
sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
echo deb https://apt.dockerproject.org/repo debian-stretch main | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get install -y docker-engine
sudo bash -c 'curl -L https://github.com/docker/compose/releases/download/1.13.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose'
sudo chmod +x /usr/local/bin/docker-compose

Assuming the FQDN of the machine is download.securedrop.club and the person responsible can be reached at admin@securedrop.cub, create the docker-compose.yml with:

cat > docker-compose.yml <<EOF
version: '2'
services:
  web:
    image: nginx:1.13.3
    volumes:
      - ./html:/usr/share/nginx/html:ro
    ports:
      - "8080:80"
    environment:
      - VIRTUAL_HOST=download.securedrop.club
      - LETSENCRYPT_HOST=download.securedrop.club
      - LETSENCRYPT_EMAIL=admin@securedrop.club
  proxy:
    image: jwilder/nginx-proxy
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./certs:/etc/nginx/certs:ro
      - /etc/nginx/vhost.d
      - /usr/share/nginx/html
    ports:
      - "80:80"
      - "443:443"
    restart: always
    depends_on:
      - web
  letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./certs:/etc/nginx/certs:rw
    volumes_from:
      - proxy
EOF

and run docker-compose up in the same directory as the docker-compose.yml file.

logging udev events at boot time

Adapted from Peter Rajnoha post:

  • create a special systemd unit to monitor udev during boot:
    cat > /etc/systemd/system/systemd-udev-monitor.service <<EOF
    [Unit]
    Description=udev Monitoring
    DefaultDependencies=no
    Wants=systemd-udevd.service
    After=systemd-udevd-control.socket systemd-udevd-kernel.socket
    Before=sysinit.target systemd-udev-trigger.service
    
    [Service]
    Type=simple
    ExecStart=/usr/bin/sh -c "/usr/sbin/udevadm monitor --udev --env > /udev_monitor.log"
    
    [Install]
    WantedBy=sysinit.target
    EOF
    
  • run systemctl daemon-reload
  • run systemctl enable systemd-udev-monitor.service
  • reboot
  • append “systemd.log_level=debug systemd.log_target=kmsg udev.log-priority=debug log_buf_len=8M” to kernel command line
  • collect the logs in /udev_monitor.log

Continue reading “logging udev events at boot time”

Semi-reliable GitHub scripting

The githubpy python library provides a thin layer on top of the GitHub V3 API, which is convenient because the official GitHub documentation can be used. The undocumented behavior of GitHub is outside of the scope of this library and needs to be addressed by the caller.

For instance creating a repository is asynchronous and checking for its existence may fail. Something similar to the following function should be used to wait until it exists:

    def project_exists(self, name):
        retry = 10
        while retry > 0:
            try:
                for repo in self.github.g.user('repos').get():
                    if repo['name'] == name:
                        return True
                return False
            except github.ApiError:
                time.sleep(5)
            retry -= 1
        raise Exception('error getting the list of repos')

    def add_project(self):
        r = self.github.g.user('repos').post(
            name=GITHUB['repo'],
            auto_init=True)
        assert r['full_name'] == GITHUB['username'] + '/' + GITHUB['repo']
        while not self.project_exists(GITHUB['repo']):
            pass

Another example is merging a pull request. It sometimes fails (503, cannot be merged error) although it succeeds in the background. To cope with that, the state of the pull request should be checked immediately after the merge failed. It can either be merged or closed (although the GitHub web interface shows it as merged). The following function can be used to cope with that behavior:

    def merge(self, pr, message):
        retry = 10
        while retry > 0:
            try:
                current = self.github.repos().pulls(pr).get()
                if current['state'] in ('merged', 'closed'):
                    return
                logging.info('state = ' + current['state'])
                self.github.repos().pulls(pr).merge().put(
                    commit_message=message)
            except github.ApiError as e:
                logging.error(str(e.response))
                logging.exception('merging ' + str(pr) + ' ' + message)
                time.sleep(5)
            retry -= 1
        assert retry > 0

These two examples have been implemented as part of the ceph-workbench integration tests. The behavior described above can be reproduced by running the test in a loop during a few hours.

write-only ssh based rsync server

A write-only rsync server can be used by anyone to upload content with no risk of deleting existing files. Assuming access to the rsync server is handled via ssh, the following line can be added to the ~/.ssh/authorized_keys file

command="rrsync /usr/share/nginx/html" ssh-rsa AAAAB3NzaC1y...

The rrsync script is found in the rsync package documentation and installed with:

gzip -d < /usr/share/doc/rsync/scripts/rrsync.gz > /usr/bin/rrsync
chmod +x /usr/bin/rrsync

DNS spoofing with RPZ and bind9

When two web services reside on the same LAN, it may be convenient to spoof DNS entries to use the LAN IP instead of the public IP. It can be done using RPZ and bind9.
For instance workbench.dachary.org can be mapped to 10.0.2.21 with

$ cat /etc/bind/rpz.db
$TTL 60
@            IN    SOA  localhost. root.localhost.  (
                          2   ; serial
                          3H  ; refresh
                          1H  ; retry
                          1W  ; expiry
                          1H) ; minimum
                  IN    NS    localhost.

workbench.dachary.org        A    10.0.2.21

The zone is declared in

$ cat /etc/bind/named.conf.local
zone "rpz" {
      type master;
      file "/etc/bind/rpz.db";
      allow-query {none;};
};

and the response-policy is set in the options file with

$ cat /etc/bind/named.conf.options
...
	response-policy { zone "rpz"; };
};

When bind9 is restarted with /etc/init.d/bind9 restart, the mapping can be verified with

$ dig @127.0.0.1 workbench.dachary.org
workbench.dachary.org.	5	IN	A	10.0.2.21

If the bind9 server runs on a docker host, it can be used by docker containers with

docker run  ... --dns=172.17.42.1 ...

Using a cloud image with kvm

It would be convenient to have a virt-builder oneliner such as

$ virt-builder --arch i386 --ssh-inject ~/.ssh/id_rsa.pub fedora-21

to get an image suitable to run and login with

$ qemu-kvm -m 1024 -net user,hostfwd=tcp::2222-:22 \
  -drive file=fedora-21.qcow2 &
$ ssh -p 2222 localhost grep PRETTY /etc/os-release
PRETTY_NAME="Fedora 21 (Twenty One)"

Docker users have a simpler form because there is no need to ssh to enter the container:

$ docker run fedora:21 grep PRETTY /etc/os-release
PRETTY_NAME="Fedora 21 (Twenty One)"

It is not currently possible to use virt-builder as described above because

  • the set of images available by default is limited (no i386 architecture for instance)
  • the –inject-ssh option is only available in the development version

The libguestfs.org toolbox can however be used to implement a script modifying images prepared for the cloud (see ubuntu cloud images for instance):

  • wget the image
    wget -O my.img http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-i386-disk1.img
    
  • create a config-drive for cloud-init to feed it the ssh public key.
    mkdir -p config-drive
    cat > config-drive/user-data <<EOF
    #cloud-config
    ssh_authorized_keys:
     - $(cat ~/.ssh/id_rsa.pub)
    chpasswd: { expire: False }
    EOF
    cat > config-drive/meta-data <<EOF
    instance-id: iid-123459
    local-hostname: testhost
    EOF
    ( cd config-drive ; LIBGUESTFS_BACKEND=direct virt-make-fs \
      --type=msdos --label=cidata .  ../config-drive.img )
    
  • launch the image with the config drive attached and it will be auto detected
    qemu-kvm -m 1024 -net user,hostfwd=tcp::2222-:22 \
      -drive file=my.img -drive config-drive.img
    

Continue reading “Using a cloud image with kvm”

Upgrade nodejs on Ubuntu 14.04

To run gh a version of nodejs more recent than the one packaged by default on Ubuntu 14.04 is required:

$ apt-cache policy nodejs
nodejs:
  Installed: 0.10.25~dfsg2-2ubuntu1
  Candidate: 0.10.25~dfsg2-2ubuntu1
  Version table:
 *** 0.10.25~dfsg2-2ubuntu1 0
        500 http://fr.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status
$ gh watch
fatal: Please update your NodeJS version: http://nodejs.org/download

The recommended way to upgrade is currently broken and the following can be used instead:

sudo add-apt-repository 'deb https://deb.nodesource.com/node trusty main'
sudo apt-get update
sudo apt-get install nodejs

If either apt-get update or apt-get install fail with a message like SSL: certificate subject name:

...
Err https://deb.nodesource.com trusty/main amd64 Packages
  SSL: certificate subject name (login.meteornetworks.com) does not match target host name 'deb.nodesource.com'
Ign http://ceph.com trusty/main Translation-en
Err https://deb.nodesource.com trusty/main i386 Packages
  SSL: certificate subject name (login.meteornetworks.com) does not match target host name 'deb.nodesource.com'
Ign https://deb.nodesource.com trusty/main Translation-en_US
Ign https://deb.nodesource.com trusty/main Translation-en
Ign http://get.docker.io docker/main Translation-en_US
Ign http://get.docker.io docker/main Translation-en
W: Failed to fetch https://deb.nodesource.com/node/dists/trusty/main/binary-amd64/Packages  SSL: certificate subject name (login.meteornetworks.com) does not match target host name 'deb.nodesource.com'
W: Failed to fetch https://deb.nodesource.com/node/dists/trusty/main/binary-i386/Packages  SSL: certificate subject name (login.meteornetworks.com) does not match target host name 'deb.nodesource.com'
E: Some index files failed to download. They have been ignored, or old ones used instead.

The following will fix it:

echo 'Acquire::https::deb.nodesource.com::Verify-Peer "false";' > /etc/apt/apt.conf.d/99verify

Alternatively a version of gh that does not require a recent version of nodejs can be installed with

sudo npm install -g gh@1.9.4