April 11, 2024

hackergotchi for Jonathan McDowell

Jonathan McDowell

Sorting out backup internet #1: recursive DNS

I work from home these days, and my nearest office is over 100 miles away, 3 hours door to door if I travel by train (and, to be honest, probably not a lot faster given rush hour traffic if I drive). So I’m reliant on a functional internet connection in order to be able to work. I’m lucky to have access to Openreach FTTP, provided by Aquiss, but I worry about what happens if there’s a cable cut somewhere or some other long lasting problem. Worst case I could tether to my work phone, or try to find some local coworking space to use while things get sorted, but I felt like arranging a backup option was a wise move.

Step 1 turned out to be sorting out recursive DNS. It’s been many moons since I had to deal with running DNS in a production setting, and I’ve mostly done my best to avoid doing it at home too. dnsmasq has done a decent job at providing for my needs over the years, covering DHCP, DNS (+ tftp for my test device network). However I just let it slave off my ISP’s nameservers, which means if that link goes down it’ll no longer be able to resolve anything outside the house.

One option would have been to either point to a different recursive DNS server (Cloudfare’s or Google’s Public DNS being the common choices), but I’ve no desire to share my lookup information with them. As another approach I could have done some sort of failover of resolv.conf when the primary network went down, but then I would have to get into moving files around based on networking status and that felt a bit clunky.

So I decided to finally setup a proper local recursive DNS server, which is something I’ve kinda meant to do for a while but never had sufficient reason to look into. Last time I did this I did it with BIND 9 but there are more options these days, and I decided to go with unbound, which is primarily focused on recursive DNS.

One extra wrinkle, pointed out by Lars, is that having dynamic name information from DHCP hosts is exceptionally convenient. I’ve kept dnsmasq as the local DHCP server, so I wanted to be able to forward local queries there.

I’m doing all of this on my RB5009, running Debian. Installing unbound was a simple matter of apt install unbound. I needed 2 pieces of configuration over the default, one to enable recursive serving for the house networks, and one to enable forwarding of queries for the local domain to dnsmasq. I originally had specified the wildcard address for listening, but this caused problems with the fact my router has many interfaces and would sometimes respond from a different address than the request had come in on.

  interface: 2001::db8:f00d::1
  access-control: allow
  access-control: 2001::db8:f00d::/56 allow

  domain-insecure: "example.org"
  do-not-query-localhost: no

  name: "example.org"

I then had to configure dnsmasq to not listen on port 53 (so unbound could), respond to requests on the loopback interface (I have dnsmasq restricted to only explicitly listed interfaces), and to hand out unbound as the appropriate nameserver in DHCP requests - once dnsmasq is not listening on port 53 it no longer does this by default.


With these minor changes in place I now have local recursive DNS being handled by unbound, without losing dynamic local DNS for DHCP hosts. As an added bonus I now get 10/10 on Test IPv6 - previously I was getting dinged on the ability for my DNS server to resolve purely IPv6 reachable addresses.

Next step, actually sorting out a backup link.

11 April, 2024 05:41PM

Reproducible Builds

Reproducible Builds in March 2024

Welcome to the March 2024 report from the Reproducible Builds project! In our reports, we attempt to outline what we have been up to over the past month, as well as mentioning some of the important things happening more generally in software supply-chain security. As ever, if you are interested in contributing to the project, please visit our Contribute page on our website.

Arch Linux minimal container userland now 100% reproducible

In remarkable news, Reproducible builds developer kpcyrd reported that that the Arch Linux “minimal container userland” is now 100% reproducible after work by developers dvzv and Foxboron on the one remaining package. This represents a “real world”, widely-used Linux distribution being reproducible.

Their post, which kpcyrd suffixed with the question “now what?”, continues on to outline some potential next steps, including validating whether the container image itself could be reproduced bit-for-bit. The post, which was itself a followup for an Arch Linux update earlier in the month, generated a significant number of replies.

Validating Debian’s build infrastructure after the XZ backdoor

From our mailing list this month, Vagrant Cascadian wrote about being asked about trying to perform concrete reproducibility checks for recent Debian security updates, in an attempt to gain some confidence about Debian’s build infrastructure given that they performed builds in environments running the high-profile XZ vulnerability.

Vagrant reports (with some caveats):

So far, I have not found any reproducibility issues; everything I tested I was able to get to build bit-for-bit identical with what is in the Debian archive.

That is to say, reproducibility testing permitted Vagrant and Debian to claim with some confidence that builds performed when this vulnerable version of XZ was installed were not interfered with.

Making Fedora Linux (more) reproducible

In March, Davide Cavalca gave a talk at the 2024 Southern California Linux Expo (aka SCALE 21x) about the ongoing effort to make the Fedora Linux distribution reproducible.

Documented in more detail on Fedora’s website, the talk touched on topics such as the specifics of implementing reproducible builds in Fedora, the challenges encountered, the current status and what’s coming next. (YouTube video)

Increasing Trust in the Open Source Supply Chain with Reproducible Builds and Functional Package Management

Julien Malka published a brief but interesting paper in the HAL open archive on Increasing Trust in the Open Source Supply Chain with Reproducible Builds and Functional Package Management:

Functional package managers (FPMs) and reproducible builds (R-B) are technologies and methodologies that are conceptually very different from the traditional software deployment model, and that have promising properties for software supply chain security. This thesis aims to evaluate the impact of FPMs and R-B on the security of the software supply chain and propose improvements to the FPM model to further improve trust in the open source supply chain. PDF

Julien’s paper poses a number of research questions on how the model of distributions such as GNU Guix and NixOS can “be leveraged to further improve the safety of the software supply chain”, etc.

Software and source code identification with GNU Guix and reproducible builds

In a long line of commendably detailed blog posts, Ludovic Courtès, Maxim Cournoyer, Jan Nieuwenhuizen and Simon Tournier have together published two interesting posts on the GNU Guix blog this month. In early March, Ludovic Courtès, Maxim Cournoyer, Jan Nieuwenhuizen and Simon Tournier wrote about software and source code identification and how that might be performed using Guix, rhetorically posing the questions: “What does it take to ‘identify software’? How can we tell what software is running on a machine to determine, for example, what security vulnerabilities might affect it?”

Later in the month, Ludovic Courtès wrote a solo post describing adventures on the quest for long-term reproducible deployment. Ludovic’s post touches on GNU Guix’s aim to support “time travel”, the ability to reliably (and reproducibly) revert to an earlier point in time, employing the iconic image of Harold Lloyd hanging off the clock in Safety Last! (1925) to poetically illustrate both the slapstick nature of current modern technology and the gymnastics required to navigate hazards of our own making.

Two new Rust-based tools for post-processing determinism

Zbigniew Jędrzejewski-Szmek announced add-determinism, a work-in-progress reimplementation of the Reproducible Builds project’s own strip-nondeterminism tool in the Rust programming language, intended to be used as a post-processor in RPM-based distributions such as Fedora

In addition, Yossi Kreinin published a blog post titled “refix: fast, debuggable, reproducible builds that describes a tool that post-processes binaries in such a way that they are still debuggable with gdb, etc.. Yossi post details the motivation and techniques behind the (fast) performance of the tool.

Distribution work

In Debian this month, since the testing framework no longer varies the build path, James Addison performed a bulk downgrade of the bug severity for issues filed with a level of normal to a new level of wishlist. In addition, 28 reviews of Debian packages were added, 38 were updated and 23 were removed this month adding to ever-growing knowledge about identified issues. As part of this effort, a number of issue types were updated, including Chris Lamb adding a new ocaml_include_directories toolchain issue [] and James Addison adding a new filesystem_order_in_java_jar_manifest_mf_include_resource issue [] and updating the random_uuid_in_notebooks_generated_by_nbsphinx to reference a relevant discussion thread [].

In addition, Roland Clobus posted his 24th status update of reproducible Debian ISO images. Roland highlights that the images for Debian unstable often cannot be generated due to changes in that distribution related to the 64-bit time_t transition.

Lastly, Bernhard M. Wiedemann posted another monthly update for his reproducibility work in openSUSE.

Mailing list highlights

Elsewhere on our mailing list this month:

Website updates

There were made a number of improvements to our website this month, including:

  • Pol Dellaiera noticed the frequent need to correctly cite the website itself in academic work. To facilitate easier citation across multiple formats, Pol contributed a Citation File Format (CIF) file. As a result, an export in BibTeX format is now available in the Academic Publications section. Pol encourages community contributions to further refine the CITATION.cff file. Pol also added an substantial new section to the “buy in” page documenting the role of Software Bill of Materials (SBOMs) and ephemeral development environments. [][]

  • Bernhard M. Wiedemann added a new “commandments” page to the documentation [][] and fixed some incorrect YAML elsewhere on the site [].

  • Chris Lamb add three recent academic papers to the publications page of the website. []

  • Mattia Rizzolo and Holger Levsen collaborated to add Infomaniak as a sponsor of amd64 virtual machines. [][][]

  • Roland Clobus updated the “stable outputs” page, dropping version numbers from Python documentation pages [] and noting that Python’s set data structure is also affected by the PYTHONHASHSEED functionality. []

Delta chat clients now reproducible

Delta Chat, an open source messaging application that can work over email, announced this month that the Rust-based core library underlying Delta chat application is now reproducible.


diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes such as uploading versions 259, 260 and 261 to Debian and made the following additional changes:

  • New features:

    • Add support for the zipdetails tool from the Perl distribution. Thanks to Fay Stegerman and Larry Doolittle et al. for the pointer and thread about this tool. []
  • Bug fixes:

    • Don’t identify Redis database dumps as GNU R database files based simply on their filename. []
    • Add a missing call to File.recognizes so we actually perform the filename check for GNU R data files. []
    • Don’t crash if we encounter an .rdb file without an equivalent .rdx file. (#1066991)
    • Correctly check for 7z being available—and not lz4—when testing 7z. []
    • Prevent a traceback when comparing a contentful .pyc file with an empty one. []
  • Testsuite improvements:

    • Fix .epub tests after supporting the new zipdetails tool. []
    • Don’t use parenthesis within test “skipping…” messages, as PyTest adds its own parenthesis. []
    • Factor out Python version checking in test_zip.py. []
    • Skip some Zip-related tests under Python 3.10.14, as a potential regression may have been backported to the 3.10.x series. []
    • Actually test 7z support in the test_7z set of tests, not the lz4 functionality. (Closes: reproducible-builds/diffoscope#359). []

In addition, Fay Stegerman updated diffoscope’s monkey patch for supporting the unusual Mozilla ZIP file format after Python’s zipfile module changed to detect potentially insecure overlapping entries within .zip files. (#362)

Chris Lamb also updated the trydiffoscope command line client, dropping a build-dependency on the deprecated python3-distutils package to fix Debian bug #1065988 [], taking a moment to also refresh the packaging to the latest Debian standards []. Finally, Vagrant Cascadian submitted an update for diffoscope version 260 in GNU Guix. []

Upstream patches

This month, we wrote a large number of patches, including:

Bernhard M. Wiedemann used reproducibility-tooling to detect and fix packages that added changes in their %check section, thus failing when built with the --no-checks option. Only half of all openSUSE packages were tested so far, but a large number of bugs were filed, including ones against caddy, exiv2, gnome-disk-utility, grisbi, gsl, itinerary, kosmindoormap, libQuotient, med-tools, plasma6-disks, pspp, python-pypuppetdb, python-urlextract, rsync, vagrant-libvirt and xsimd.

Similarly, Jean-Pierre De Jesus DIAZ employed reproducible builds techniques in order to test a proposed refactor of the ath9k-htc-firmware package. As the change produced bit-for-bit identical binaries to the previously shipped pre-built binaries:

I don’t have the hardware to test this firmware, but the build produces the same hashes for the firmware so it’s safe to say that the firmware should keep working.

Reproducibility testing framework

The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility.

In March, an enormous number of changes were made by Holger Levsen:

  • Debian-related changes:

    • Sleep less after a so-called “404” package state has occurred. []
    • Schedule package builds more often. [][]
    • Regenerate all our HTML indexes every hour, but only every 12h for the released suites. []
    • Create and update unstable and experimental base systems on armhf again. [][]
    • Don’t reschedule so many “depwait” packages due to the current size of the i386 architecture queue. []
    • Redefine our scheduling thresholds and amounts. []
    • Schedule untested packages with a higher priority, otherwise slow architectures cannot keep up with the experimental distribution growing. []
    • Only create the stats_buildinfo.png graph once per day. [][]
    • Reproducible Debian dashboard: refactoring, update several more static stats only every 12h. []
    • Document how to use systemctl with new systemd-based services. []
    • Temporarily disable armhf and i386 continuous integration tests in order to get some stability back. []
    • Use the deb.debian.org CDN everywhere. []
    • Remove the rsyslog logging facility on bookworm systems. []
    • Add zst to the list of packages which are false-positive diskspace issues. []
    • Detect failures to bootstrap Debian base systems. []
  • Arch Linux-related changes:

    • Temporarily disable builds because the pacman package manager is broken. [][]
    • Split reproducible_html_live_status and split the scheduling timing . [][][]
    • Improve handling when database is locked. [][]
  • Misc changes:

    • Show failed services that require manual cleanup. [][]
    • Integrate two new Infomaniak nodes. [][][][]
    • Improve IRC notifications for artifacts. []
    • Run diffoscope in different systemd slices. []
    • Run the node health check more often, as it can now repair some issues. [][]
    • Also include the string Bot in the userAgent for Git. (Re: #929013). []
    • Document increased tmpfs size on our OUSL nodes. []
    • Disable memory account for the reproducible_build service. [][]
    • Allow 10 times as many open files for the Jenkins service. []
    • Set OOMPolicy=continue and OOMScoreAdjust=-1000 for both the Jenkins and the reproducible_build service. []

Mattia Rizzolo also made the following changes:

  • Debian-related changes:

    • Define a systemd slice to group all relevant services. [][]
    • Add a bunch of quotes in scripts to assuage the shellcheck tool. []
    • Add stats on how many packages have been built today so far. []
    • Instruct systemd-run to handle diffoscope’s exit codes specially. []
    • Prefer the pgrep tool over grepping the output of ps. []
    • Re-enable a couple of i386 and armhf architecture builders. [][]
    • Fix some stylistic issues flagged by the Python flake8 tool. []
    • Cease scheduling Debian unstable and experimental on the armhf architecture due to the time_t transition. []
    • Start a few more i386 & armhf workers. [][][]
    • Temporarly skip pbuilder updates in the unstable distribution, but only on the armhf architecture. []
  • Other changes:

    • Perform some large-scale refactoring on how the systemd service operates. [][]
    • Move the list of workers into a separate file so it’s accessible to a number of scripts. []
    • Refactor the powercycle_x86_nodes.py script to use the new IONOS API and its new Python bindings. []
    • Also fix nph-logwatch after the worker changes. []
    • Do not install the stunnel tool anymore, it shouldn’t be needed by anything anymore. []
    • Move temporary directories related to Arch Linux into a single directory for clarity. []
    • Update the arm64 architecture host keys. []
    • Use a common Postfix configuration. []

The following changes were also made: by

  • Jan-Benedict Glaw:

    • Initial work to clean up a messy NetBSD-related script. [][]
  • Roland Clobus:

    • Show the installer log if the installer fails to build. []
    • Avoid the minus character (i.e. -) in a variable in order to allow for tags in openQA. []
    • Update the schedule of Debian live image builds. []
  • Vagrant Cascadian:

    • Maintenance on the virt* nodes is completed so bring them back online. []
    • Use the fully qualified domain name in configuration. []

Node maintenance was also performed by Holger Levsen, Mattia Rizzolo [][] and Vagrant Cascadian [][][][]

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

11 April, 2024 04:49PM

Russell Coker

ML Training License

Last year a Debian Developer blogged about writing Haskell code to give a bad result for LLMs that were trained on it. I forgot who wrote the post and I’d appreciate the URL if anyone has it.

I respect such technical work to enforce one’s legal rights when they aren’t respected by corporations, but I have a different approach.

As an aside the Fosdem lecture “Fortify AI against regulation, litigation and lobotomies” is interesting on this topic [1], it’s what inspired me to write about this.

For what I write I am at this time happy to allow it to be used as part of a large training data set (consider this blog post a licence grant that applies until such time as I edit this post to change it). But only if aggregated with so much other data that my content is only a tiny portion of the data set by any metric. So I don’t want someone to make a programming LLM that has my code as the only C code or a political data set that has my blog posts as the only left-wing content. If someone wants to train an LLM on only my content to make a Russell-simulator then I don’t license my work for that purpose but also as it’s small enough that anyone with a bit of skill could do it on a weekend I can’t stop it. I would be really interested in seeing the results if someone from the FOSS community wanted to make a Russell-simulator and would probably issue them a license for such work if asked.

If my work comprises more than 0.1% of the content in a particular measure (theme, programming language, political position, etc) in a training data set then I don’t permit that without prior discussion.

Finally if someone wants to make a FOSS training data set to be used for FOSS LLM systems (maybe under the AGPL or some similar license) then I’ll allow my writing to be used as part of that.

11 April, 2024 11:30AM by etbe

hackergotchi for Wouter Verhelst

Wouter Verhelst

OpenSC and the Belgian eID

Getting the Belgian eID to work on Linux systems should be fairly easy, although some people do struggle with it.

For that reason, there is a lot of third-party documentation out there in the form of blog posts, wiki pages, and other kinds of things. Unfortunately, some of this documentation is simply wrong. Written by people who played around with things until it kind of worked, sometimes you get a situation where something that used to work in the past (but wasn't really necessary) now stopped working, but it's still added to a number of locations as though it were the gospel.

And then people follow these instructions and now things don't work anymore.

One of these revolves around OpenSC.

OpenSC is an open source smartcard library that has support for a pretty large number of smartcards, amongst which the Belgian eID. It provides a PKCS#11 module as well as a number of supporting tools.

For those not in the know, PKCS#11 is a standardized C API for offloading cryptographic operations. It is an API that can be used when talking to a hardware cryptographic module, in order to make that module perform some actions, and it is especially popular in the open source world, with support in NSS, amongst others. This library is written and maintained by mozilla, and is a low-level cryptographic library that is used by Firefox (on all platforms it supports) as well as by Google Chrome and other browsers based on that (but only on Linux, and as I understand it, only for linking with smartcards; their BoringSSL library is used for other things).

The official eID software that we ship through eid.belgium.be, also known as "BeID", provides a PKCS#11 module for the Belgian eID, as well as a number of support tools to make interacting with the card easier, such as the "eID viewer", which provides the ability to read data from the card, and validate their signatures. While the very first public version of this eID PKCS#11 module was originally based on OpenSC, it has since been reimplemented as a PKCS#11 module in its own right, with no lineage to OpenSC whatsoever anymore.

About five years ago, the Belgian eID card was renewed. At the time, a new physical appearance was the most obvious difference with the old card, but there were also some technical, on-chip, differences that are not so apparent. The most important one here, although it is not the only one, is the fact that newer eID cards now use a NIST P-384 elliptic curve-based private keys, rather than the RSA-based ones that were used in the past. This change required some changes to any PKCS#11 module that supports the eID; both the BeID one, as well as the OpenSC card-belpic driver that is written in support of the Belgian eID.

Obviously, the required changes were implemented for the BeID module; however, the OpenSC card-belpic driver was not updated. While I did do some preliminary work on the required changes, I was unable to get it to work, and eventually other things took up my time so I never finished the implementation. If someone would like to finish the work that I started, the preliminal patch that I wrote could be a good start -- but like I said, it doesn't yet work. Also, you'll probably be interested in the official documentation of the eID card.

Unfortunately, in the mean time someone added the Applet 1.8 ATR to the card-belpic.c file, without also implementing the required changes to the driver so that the PKCS#11 driver actually supports the eID card. The result of this is that if you have OpenSC installed in NSS for either Firefox or any Chromium-based browser, and it gets picked up before the BeID PKCS#11 module, then NSS will stop looking and pass all crypto operations to the OpenSC PKCS#11 module rather than to the official eID PKCS#11 module, and things will not work at all, causing a lot of confusion.

I have therefore taken the following two steps:

  1. The official eID packages now conflict with the OpenSC PKCS#11 module. Specifically only the PKCS#11 module, not the rest of OpenSC, so you can theoretically still use its tools. This means that once we release this new version of the eID software, when you do an upgrade and you have OpenSC installed, it will remove the PKCS#11 module and anything that depends on it. This is normal and expected.
  2. I have filed a pull request against OpenSC that removes the Applet 1.8 ATR from the driver, so that OpenSC will stop claiming that it supports the 1.8 applet.

When the pull request is accepted, we will update the official eID software to make the conflict versioned, so that as soon as it works again you will again be able to install the OpenSC and BeID packages at the same time.

In the mean time, if you have the OpenSC PKCS#11 module installed on your system, and your eID authentication does not work, try removing it.

11 April, 2024 09:33AM

April 10, 2024

hackergotchi for Daniel Pocock

Daniel Pocock

WIPO UDRP D2024-0770 Debian vendetta response

Some of my fellow Debian Developers (co-authors) started harassing my family and I back in 2018 at a time when I lost two family members.

This blog has been written under duress. Normally the best thing to do with bullies is to ignore them but they are blackmailing me with the threat that WIPO will publish some insults denouncing me, destroying my life and trying to push me into the Debian suicide cluster.

Trigger warning

The Debian online community makes malicious references to harassment and abuse, deliberately conflating different meanings of these words to sully the reputations of independent volunteers. Victims and witnesses to real harassment and abuse may be triggered by exposure to these word games in the Debian online community.


The misfits have now used Software in the Public Interest, Inc, an organization that I have no relationship with, to transmit insults through WIPO.

WIPO has assigned the case number D2024-0770.

Some people may think that after more than three decades that I have been doing voluntary work in ham radio and free, open source software, this must be some kind of April Fool's Day joke. Sadly it is not.

The case says a lot about the toxic culture of these small-minded people who are using the trademark to cling onto the coat-tails of Debian's founders. It is glaring at us in the list of domains in dispute. While these misfits spend all their time slinking around in chat channels jealously sneering at the real developers, I was the only one engaged in creative thought registering some of the most exciting Debian-inspired domain names. To prove the point, here is the list of domain names now in dispute. Given all the effort they put into the debian.community vendettas, why did none of the misfits spare a minute to think of any of these names and register them first?

The list of domains is startling but at the same time, it captures all the most contentious political issues in Debian today. I feel that I have done the real community a huge service by thinking ahead and registering these domains before they could fall into the hands of cybersquatters.

Criminal proceedings in progress

There are now a range of criminal proceedings in progress regarding the harassment of my family and I.

The outgoing Debian Project Leader has used his final email newsletter to distribute defamation about police involvement. This demonstrates the real motive of the WIPO insults is to use all forms of proceedings concurrently, with as much noise about it as possible, to cause the maximum stress and psychological harm to victims such as my family and I and other independent volunteers.

The current harassment through the WIPO process is a violation of UDRP Rules 15(e) regarding the harassment of the domain name holder.

The outcome of criminal proceedings may help to test the evidence submitted by the parties, to fill the deliberate gaps in the evidence and to give some indication of the real source of bad faith and previous patterns of harassment against my family and I.

I believe the panel should suspend the current procedure and wait for the parties to provide details of the criminal proceedings to the panel.

WIPO fascist deadline

WIPO has set a deadline for me to respond to the insults by 2 April 2024. Coincidentally, 2 April is the anniversary of the European Parliament resolution of 2 April 2009 on European conscience and totalitarianism.

The text of the motion begins like this:

1. Expresses respect for all victims of totalitarian and undemocratic regimes in Europe and pays tribute to those who fought against tyranny and oppression;

In point 4, the European Parliament asserts that constant vigilance is needed to fight undemocratic, xenophobic, authoritarian and totalitarian ideas and tendencies. Inspired by this bi-partisan resolution from the European Parliament, I created the web site Nazi.Compare and started publishing examples of poor behavior by the vigilantes in free, open source software communities.

Moreover, 2 April is Carla's birthday. The manner in which rogue Debianists and toxic people at WIPO demand that I shift my focus to their petty concerns is another prime example of the way that Debian fascism (Debianism) is imposing on our families and personal lives.

Carla was born in Chile on the very day that Argentina launched their doomed invasion of Las Islas Malvinas / Falkland Islands. Carla's country, Chile, who share a 4000km land border with Argentina, sided with the British and allowed British forces to operate from Chilean territory. Margarita Manterola (marga), who is Argentinian, banned Carla from food at DebConf, despite the fact that Marga has attended numerous DebConfs with her husband. Just another example of how these two-faced people behave.

WIPO, Modern Slavery and Blackmail in Switzerland

The deadline also coincides with the Easter long weekend. While other people are able to rest on the long weekend, these people are blackmailing me to focus on my work with Debian, which is a voluntary activity.

Blackmail is accompanied with a threat of adverse consequences.

In many countries, blackmail is a crime.

Forcing people to work without payment is a crime.

WIPO operates this blackmail with the threat that if I do not spend Easter reading their insults and sit here working on this response, they will automatically re-publish insults and defamation, dragging the name of my family through the mud. In other words, WIPO are revealing themselves to be a fascist regime, a lot like those regimes that the European Parliament resolution is warning us about.

I have already done decades of voluntary work for Debian and free, open source software and now they force me to work on a public holiday.

Multi-Institutional abuse & WIPO blackmail hand-in-hand

The insults misfits submitted through WIPO regurgitate references to harassment, abuse and 2018, the time when the trial of Cardinal George Pell was underway, among other things.

Normally, when cases of abuse appear in the news, the identities of victims, possible victims, witnesses, any other children who were there and anybody in proximity to the children is obfuscated.

Yet Google, WIPO and Debian seem to be able to do as they please and spread rumors about harassment and abuse of anonymous victims in proximity to the volunteer developers.

The WIPO UDRP process makes no reference to how they protect the privacy of people in proximity to potential cases of abuse.

I contacted various lawyers about the matter, this is an example of one response from a firm registered with the bar association in Ireland:

We are a small firm and our resources are quite stretched at this time.

Nonetheless, one of the architects of the cover-up in Melbourne has been linked to Ireland.

Response being prepared without legal representation

In 2021, my business purchased a legal protection insurance from the firm Parreaux, Thiebaud & Partners in Switzerland. It turns out this firm had been operating in Switzerland since 2018 without a license to sell insurance and without all but one or two staff having a law license. In other words, from the perspective of the clients, the Swiss insurance was no better than a ponzi scheme. Even more disturbing, the Swiss authorities, including the financial regulator FINMA and the Ordre des Avocats de Genève (Geneva Bar Association) apparently knew about this since 2021 but didn't close the firm down until 2023. It is the Swiss JuristGate affair.

On the other hand, the misfits have apparently spent over $120,000 on legal fees making attacks against my family and I over the last few years.

In some countries, like South Africa, home of the outgoing Debian Project Leader Jonathan Carter, you can pay less than that to have somebody killed.

No faith in WIPO, the legal panel, conflicts of interest

In the previous WeMakeFedora.org dispute, the ADR Forum proposed a legal panelist who had a leading role in a trade association promoting the interests of the complainant.

That particular conflict of interest was very easy to recognize and the panelist withdrew from the process.

Many of the panelists appear to be associated with companies who have funded one of the parties and some of them appear to be involved in groups like the FSFE Legal Network. At the same time, many of the current vendettas appear to intersect with both FSFE and Debian at the same time.

Therefore, without being able to determine the extent to which any particular panelist or WIPO employee is engaged in these other groups, I do not trust any of them.

Jurisdiction and cultural issues

The WIPO documents specify a jurisdiction for the domain registrar but the content on the web sites needs to be viewed through the perspective of different jurisdictions and cultural conventions.

Creation of the Debian software commenced in the United States.

The Debian co-authors today come from a range of different countries each having their own legal and cultural expectations about matters such as copyright, privacy and abuse.

There is a widespread understanding that the free, open source software community values freedom of expression in the sense of the first amendment to the US constitution / US Bill of Rights.

Adam Borowski via debian-project, 2018-12-20:
I agree with you wholeheartly. Censorship is at the root, or very close to the roots, of pretty much any violation of freedom I can think of.

When people look at the Debian Social Contract, which includes the clause (3) We will not hide problems, there is an expectation that we have all agreed to collaborate under an American regime of transparency and free speech about organizational issues.

The role of Debian Project Leader has been performed by people from a range of different countries where norms differ from one country to the next. For example, Chris Lamb, who started the current vendetta in 2018, is from the UK. It has been quite normal for the British press to publish information about the former Mayor of London trying to help girlfriends get jobs in the public service. Asking similar questions about women who won internships in proximity to Chris Lamb feels entirely compatible with the convention followed in British society.

In other European countries, such as Germany and Switzerland, there seems to be far more emphasis on protecting the reputations of those who are party to such affairs such that the whole affair is often hidden from view. There is a perception that people from these countries want to have their cake and eat it too. They demand privacy for themselves but they still lurk on the debian-private mailing list and chat channels spreading rumors about the rest of us. They want to download and use the software without paying for it and they don't even respect the principles of the developers. The FSFE is even using a name derived from the American FSF, it is feels like a case of identity theft, but at the same time they are snubbing freedom of expression.

Content that appears to be inconvenient for an entirely German online community is quite valid in an online community claiming to adhere to an American style of discourse.

Similarity of the domain names

It is clear that most of the domain names are either identical to the trademark or they contain the trademark.

Total similarity is completely normal and inevitable because the misfits behind the WIPO insults and I are all collectively co-authors of the same Debian software that is identified by the trademark.

Some of the names, such as debianproject.org may appear to be particularly audacious. Nonetheless, I do not expect the legal panel to be the first to approve such a name. The previous case D2000-0410 Religious Technology Center v. Freie Zone E. V. concerned the domain scientologie.org which is totally identical to the German spelling of the trademark. The case was decided on the merits of legitimate interests. The incredible similarity was not a black mark against the choice of domain name.

It is odd that the misfits have spent $120,000 on legal cases to censor domain names but they couldn't think of any of these names and register them in advance.

Money can buy legal harassment but it seems money can't replace the creative minds that have abandoned Debian long ago.

Legitimate interests to use the trademark

There are various grounds providing Debian co-authors with a legitimate interest to use the trademark in a domain name and in other contexts.

Legal counsel representing the misfits have submitted to WIPO a copy of a previous WIPO censorship decree discussing the scientologie.org dispute. Therefore, I presume that the misfits and their legal counsel are aware of the arguments relating to the scientologie.org verdict ( WIPO UDRP case D2000-0410).

The outcome in the scientologie.org verdict is that somebody having a copyright interest in a creative work that shares the name of a trademark, that person has a legitimate interest in using the name of the creative work in a domain name and possibly other contexts too.

By submitting the document, they implicitly acknowledge the open questions from the previous legal panel.

The respondent to the previous dispute was an anonymous non-profit organization, the Free Software Contributors Association. The association asserted that some of their members were Debian Developers wishing to protect their anonymity and privacy. In relation to whether or not those people are real Debian Developers, the panel wrote:

The Panel confirms that this finding does not imply that it has taken any view of the ownership of copyright in DEBIAN software. Indeed, it is unable to do so on the evidence before it.

The panel did not seek to speculate on the names of the authors contributing to the site but the misfits have been hysterical in their finger pointing. After stealing that domain, the only thing they used it for was publishing attack pages. In other words, they violated UDRP rule 15(e) after the procedure had completed.

These two lines from that panel are significant and as the misfits have submitted this document in support of their demands, with the help of legal counsel, we are surprised they have not tried to answer that question proactively. It appears that they don't care too much about documenting and protecting the exclusive economic rights of a copyright owner or the moral rights of an author.

On the distinction between the exclusive economic rights of a copyright owner, I note that none of us Debian Developers, being the co-authors of Debian, have ever been asked to assign our rights to any third-party copyright owner. The misfits have not submitted any evidence purporting to prove that such an assignment did take place. Therefore, there is no copyright owner having exclusive economic rights over the Debian software. By default, the rights rest with the authors who did the work. Despite having clearly read the panel's comments, the misfits have not submitted any evidence claiming that any such party exists with exclusive economic rights as a copyright owner of the Debian software.

Legitimate interest: a very long history of voluntary contribution

Some of us started doing Debian as a hobby alongside other hobbies such as amateur radio. One of the early Debian Project Leaders, Bruce Perens, also notably came to Debian for amateur radio purposes.

I passed the amateur radio exam in 1993, when I was 14 years of age. My first years of voluntary activities in amateur radio and free software were during a time when I was legally a child. I didn't receive any payment for some of those activities. I offered my time on the basis that I was gaining skills and helping real communities.

Around the same time, while I was still legally a child, I came to appreciate the fact that there are some adults who exploit talented and precocious youngsters by trying to direct the work that is being undertaken and failing to disclose or share financial benefits.

I believe my first engagement with Debian was in 1997 and the first proof I can find of my engagement with Debian is an email from 23 February 1998 about package creation.

The Debian Project constitution was originally published on 10 September 1998, some time later.

The trademark was only registered later on 21 December 1999

Looking at the Scientologie.org UDRP verdict, the panelists gave some weight to those possessing a copyright interest that predates the registration of a trademark or a copyright interest arising from a situation that intersects with the history of the trademark.

Legitimate interest: the Debian license statement

Oddly enough, Debian documents and files in a Debian system refer to the licenses of the individual packages being distributed. It was hard to find an actual example of a copyright statement or license for Debian itself as a collective work.

The Debian Project constitution of 1998, referred to above, encourages Software in the Public Interest, Inc to register a trademark. It says nothing about copyright in the existing body of work.

Here are the words from the original constitution:

Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs.

SPI have made the following undertakings:

1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.

So people can donate intangible property like copyright to SPI if they make a personal decision to do so. The constitution did not oblige us to make such donations/assignments.

Continuing the search for a Debian license, on the ISO installation media, I found the file isolinux/f10.txt which contains the very brief text:


Debian GNU/Linux is Copyright (C) 1993-2016 Software in the Public Interest,
and others.

The Debian GNU/Linux system is freely redistributable. After installation,
the exact distribution terms for each package are described in the
corresponding file /usr/share/doc//copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

It asserts that copyright is owned by Software in the Public Interest, and others. Most of us are individual private volunteers and we have never personally chosen to grant or assign our copyright interest to Software in the Public Interest. I became curious about who put this statement into the ISO image.

The history of the file is available in the source code repository. The text has been there for more than 20 years without any scrutiny.

It remains odd that there is no similar statement in the release notes or the installation guide.

The key things being asserted in that very brief license statement:

  • Debian is a work subject to copyright of its own, separate from the copyright of the individual components (packages),
  • There are an unspecified group of authors (the "others") of said work,
  • People who receive a copy of this work can freely redistribute the work
  • There is no warranty

Debian originated in the United States under the leadership of a US citizen, Ian Murdock, in 1993. Therefore, the US Copyright law is relevant.

The moral rights of authors ("and others") exist in the context of both a Collective work and a work of Joint authorship.

Wikipedia has an article on this particular type of copyrighted work, Collective Works (US law).

Debian is a collective work under the above US copyright law. The work was initiated in 1993 by Ian Murdock in the United States.

In a Collective work (US), the authors (or co-authors) are selecting works from third parties and arranging them into the final product, Debian, a collective work. The decision making process that involves selecting third party works and the decision making process that involves arranging the third party works gives rise to the moral rights of authorship in the Debian collective work.

The US law on collective works states:

The “authorship” in a collective work comes from the original selection, coordination, and arrangement of the independent works included in the collective work.

In the Debian world, the independent works are referred to as "upstream" source code. The authors of independent works are referred to as "upstream authors" or just "upstream".

The Debian maintainer guide describes the process of jointly selecting the independent works for inclusion in Debian. In particular, co-authors are required to create a public "Intent To Package" (ITP) report in the bug tracking system (BTS) so that other co-authors can discuss the merits of the selection decision. The requirement to engage in a shared discussion for every selection decision gives rise to joint authorship rights.

Moreover, the person who creates the package importing the independent work into Debian is required to create a manifest describing the inclusion of the independent upstream work. This manifest is the debian/control file. The Debian Policy Manual provides a list of fields in the debian/control files.

Some of these fields are dedicated to the coordination and the arrangement of the independent works within a Debian system.

Coordination of the independent contributions: the package dependency fields describe the relationships between packages that have to be installed together or which conflict with each other. In many cases, when a library package is a dependency for other packages, we have to ensure that the version of the library package in Debian is compatible with the dependent packages. We have a formal process of coordination in this case, the Transition process. Populating the dependency fields in the debian/control file and participating in a Transition process, either as the producer or the consumer of a dependency, are examples of coordination of the independent works from upstream authors.

Here are some examples where I personally engaged in these actions:

Created an ITP bug report and discussed the inclusion/selection of a package, also discussed the selection of the source through the mailing list

created a control file for the SimpleID package

SimpleID transition

The fields Section and Priority impact the arrangement of the contributions from the perspective of the user. The person completing the values in these fields in engaged in the process of arrangement of the contributions in a collective work.

Creating a Collective Work is a process of decision making. In the Debian world, we have a joint process of decision making. In particular, every author can make individual decisions over any package in the collection at any time. From the Developers Reference, a package can be signed by any key in the Debian Developers keyring. The documentation about the NMU process explicitly describes the process by which any Debian Developer is authorized to modify the package contributed by any other Debian Developer.

Here is an example where I used the NMU process to update the nfs-utils package

From time to time, the Debian co-authors undertake a vote to make a decision. Some of these votes concern social phenomena, such as the vote to accept the Diversity Statement, which says everybody is welcome in Debian. Some of the votes directly determine the arrangement of independent works in Debian. One of the most notable examples was the General Resolution on Init system coupling. Another example was the General Resolution on Handling source-less firmware in the Linux kernel. By participating in these votes, all co-authors exert some influence over which independent works are included in Debian and how those independent works are arranged.

Therefore, the development of Debian includes features of both a collective work and a work of joint authorship at the same time. Moreover, due to processes such as library transitions, NMU and our system of voting on certain decisions, any co-author may influence the way that other co-authors are integrating the independent upstream works into Debian. This cross-pollination of ideas and effort is a well known feature of Debian. In other Linux distributions, the developers are a little bit more siloed from each other.

Every two years, an official stable release of the Debian software is released to the public. This process of releasing involves declaring a version number that corresponds to a particular subset of the contributions that are in a working state at the time of the release. Even if a Debian Developer's contributions are obstructed from inclusion in future releases, or if a Debian Developer commits suicide, their work is still present in all the past releases that have been published.

My own contributions are included in a number of these Debian releases over the years.

This report finds my name in changelogs and copyright files. There are 21 pages of results.

Shooting themselves in the foot

To declare that the Debian Developers do not have authorship rights at all would be incredibly de-motivating.

Future volunteers may be deterred from contributing their intellectual property and their time.

Legitimate interests: the Debian family fallacy

Debian oligarchs repeatedly tell us that we are all a family.

Evidence: Andrew Cater says we are a family.

Evidence: Jonathan Wiltshire says we are a family.

This is an implicit authorization to use the trademark.

Consider the case of the British royal family.

Prince Harry and Princess Meghan went onto Oprah Winfrey's talk show to talk about problems in the family business. We could say this is analogous to some of my blog posts about the problems in Debian, or the FSFE crisis and other free, open source software groups.

Harry and Meghan were asked to stop using their His/Her Royal Highness (HRH) styles. Harry was banned from wearing military uniform at the funeral of the late Queen Elizabeth II. Yet they still have a legitimate interest in using the family name, Windsor.

If Debian really is a family, and it certainly isn't an employer, we can all use the family name even if we are not willing to live with each other in the same castle.

Legitimate interests: the promise of recognition

The misfits behind the WIPO insults do not pay the rest of us anything for our collaboration in creating the Debian software.

They told us that the only thing we get in return for our creations is the recognition.

They are now using the debian.org web site and the trademark to give people negative recognition. This is like bouncing a cheque.

In the circumstances, it seems entirely appropriate for me to follow through on the promise of recognizing people. The misfits have provided a list of the domains along with the dates that each domain name was registered. On the list, the name debian.plus is the first name registered. debian.plus was registered for the purpose of delivering on the promise of positive recognition to the authors and our work.

Evidence: my blog Modern Slavery & Debian Open Source lists many of the promises of recognition in lieu of payment for our work.

Debian promises recognition, I take the following quote from the latest Debian law suit where they admit using the promise of recognition to lure people into working for free:

64. ... un des avantages importants de travailler pour la communauté Debian est la valeur de sa réputation dans le domaine, à la fois professionellement et dans la communauté. ...

The promise of recognition is repeated again here in the Debian wiki.

The motivations of the authors also are varied, but the coin that they get paid in is often recognition, acclaim in the peer group, or experience that can be traded in in the work place

The same thing appears in the page about Debian Membership:

Debian has several types of association and membership for those who do wish to be recognised, or have rights within the project.

For people promoting Debian, there is a template for giving a talk. It includes the comments:

you are recognized for your contributions ... Did you ever have a boss who takes credit for your work? Not in Debian.

In short, there is a big emphasis on working for recognition instead of a salary. They gave us the promise of recognition and that gives rise to a legitimate interest in using the trademark in domain names for web sites about our work.

Legitimate interests: promoting my creative efforts

The scientologie.org UDRP verdict makes reference to the promotion of an author's work.

This point was also emphasized by the legal panel considering previous Debian disputes. The panel wrote:

Unlike the circumstances in Religious Technology Center v. Freie Zone E. V, supra the Respondent in the present case is not using the disputed domain name to disseminate information about its copyright work.

All the web sites that have been started using these domains involve the promotion of my creative work in a Debian context.

Several of the domain names have been chosen in recognition to my own work in specific areas of Debian. For example, the domains debian.chat, debian.finance and debian.video have already been started with information about my work on software relating to financial software, chat software and video software, as well as videos about my work.

Legitimate interest: EU whistleblower directive, raising workplace health & safety concerns

In 2019, the European Union adopted the Directive (EU) 2019/1937 of the European Parliament and of the Council of 23 October 2019 on the protection of persons who report breaches of Union law .

The Debian Social Contract includes the clause:

3. We will not hide problems

This clause appears completely compatible with the EU Whisteblowing Directive. In fact, this clause appears to encourage and authorize whistleblowing.

The fact that a Debian Developer wrote a combined resignation/suicide note on the night before Debian Day makes it hard to ignore the possibility that his death is related to something in the Debian environment.

Public Health England quantifies three suicides in a community as the minimum threshold to declare a suicide cluster.

Legitimate interest: redistribution of the Debian software is explicitly authorized

The Debian Free Software Guidelines and the Open Source Definition evolved together. One of the key pillars of both definitions is the authorization of free redistribution of the software.

With this authorization, any person who obtains a copy of the software is entitled to redistribute it.

The DebianProject.org domain name was registered to do exactly that, to redistribute copies of the Debian software. This activity has been authorized.

Remarkably, in one of their claims submitted to another tribunal, the misfits explicitly describe a web site redistributing Debian as an outrageous crime, despite the fact the DFSG and the license statement referred to early explicitly authorize redistribution of genuine copies of Debian GNU/Linux.

complaint about debiangnulinux.org

Such a flagrant violation of the principles in the DFSG appears to be bad faith on the part of the complainant.

Legitimate interest: use of the logo is authorized

The trademark holder has created a web page where they distribute copies of the logo in many different electronic formats.

The page describes two versions of the logo, the open logo and the restricted use logo.

The page gives a free-for-all license to use the open logo.

The logo I am using on pages about my Debian work is the open logo.

Here is the text of the authorization from the trademark holder:

The Debian Open Use Logo comes in two flavors, with and without “Debian” label.

The Debian Open Use Logo(s) are Copyright (c) 1999 Software in the Public Interest, Inc., and are released under the terms of the GNU Lesser General Public License, version 3 or any later version, or, at your option, of the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Legitimate interest: use of Debian-themed web page style

The Debian web page style is used extensively on third party web sites run by individual co-authors and volunteers.

At the bottom of every page on the main www.debian.org web site there is a link to a dedicated page about the licenses (authorization) to re-use the theme and content of www.debian.org.

The license link goes to the page https://www.debian.org/license. The page includes the following authorization:

Debian WWW Pages License Copyright © 1997-2024 Software in the Public Interest, Inc. and others
SPI can be contacted at:
1732 1st Ave #20327
New York, NY 10128-5177
United States

Since 25 January 2012, the new material can be redistributed and/or modified under the terms of the MIT (Expat) License or, at your option, of the GNU General Public License; either version 2 of the License, or (at your option) any later version (the latest version is usually available at https://www.gnu.org/licenses/gpl.html).

Work is in progress to make the older material compliant with the above licenses. Until then, please refer to the following terms of the Open Publication License.

This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy, the latest version is usually available at http://www.opencontent.org/openpub/).

“Debian” and the Debian Logo are trademarks of Software in the Public Interest, Inc.

The complainant publishes the source code for the web site theme. This makes it easy for anybody empowered by the above license to download the theme and use it when creating their own site.

At the bottom of every page on Debian.org, they promote the source code for the web site with a link text "Web site source code is available".

Here is the link to download source code for the theme of the Debian.org web site.

Legitimate interest: right of reply

The misfits have been making gossip against my family and I long before I registered any Debian-related domain names.

Notably, they use the Debian trademark and the Debian.org web site to add weight to their vendetta to humiliate volunteers and our families.

They censor, threaten and blackmail anybody who dares to challenge their vendettas. "We are humiliating Bob this week, you can't talk to him or you are next". That is what it looks like when misfits blackmail other volunteers.

Therefore, to respond to the vendettas published on Debian.org by operating similar web sites containing the name Debian feels entirely reasonable and proportionate as a right-of-reply by any co-author.

Bad faith: by the complainant, not me

For a UDRP case to be successful, in addition to proving that there is similarity to the trademark and if the complainant somehow proves that there is no legitimate interest whatsoever, the complainant must also prove that there is bad faith in the use of the domain names.

In this case, I believe the test for legitimate interest has already been satisfied and therefore, when legitimate interest exists, the panel does not make any inquiry into whether there is bad faith on the part of the domain name holder.

Under the UDRP Rule 15(e), it is also vital for the legal panel to consider whether the complainant themselves is harassing the domain name owner or acting in bad faith. In other words, whether the complainant has deceived the panel, whether a complaint has been brought for the purpose of harassment or whether the complaint is part of a broader pattern of harassment against the domain name holder.

Therefore, I simultaneously examine the attacks the complainant is making against my family and I, demonstrating not only that they are unjustified but also that by making these attacks, the Debian misfits themselves are clearly engaging in harassment and bad faith behavior.

Bad faith: no communication before opening the WIPO UDRP procedure

The misfits did not make any attempt to contact me and propose a solution to the conflict. They unilaterally opened a dispute through the UDRP.

Moreover, I had published a blog telling people that I would consider giving some of the domains away to people who have similar rights derived from joint authorship.

There have been many opportunities for them to communicate with me like a human being. They talk about Debian being a "family" but they pack together like gang rapists to pick off developers one at a time and attack us.

They are bypassing any normal human communication because they want to cause the maximum amount of stress. They want WIPO to publish the name of my family in a negative context more than they want any of those domains.

In such circumstances, they prove they are committing the act of harassment under UDRP rule 15(e)

Bad faith: lawyers get the lifejackets, Abraham Raji gets none

In January 2023, I published a picture of our crew rowing Head of the Yarra. The guy sitting behind me won the award for Emergency Practitioner of the Year. He is just the type of person you would want to have around if somebody went missing in the water. But in all the years we did rowing, I don't remember anybody going missing.

Daniel Pocock, Yarra Yarra Rowing Club, Head of the Yarra

A few months after I published that photo and Abraham Raji disappeared and drowned on the DebConf day trip.

According to the Wiki page for the day trip, volunteers participated in a series of activities throughout the day. To participate in the final activity, the kayak, the volunteers were expected to pay an extra fee. People not paying the fee would be left alone to swim like Abraham Raji.

In Australia, we all learn the basic rules of swimming. Never swim alone is one of those rules. Swim in the marked swimming areas.

Debian people like to reinvent the wheel and find their own way of doing things. The DebConf organizers are particularly bad at this. People are constantly bike shedding about the costs of minor things. They tell the foreigners from poor countries that they have to pay their own visa fees. They expected the Indians to pay the supplement for going in a kayak, which comes with a life jacket, or be left alone.

Abraham Raji, Debian, DebConf, kayak, death

But according to their own records, they paid over $120,000 to lawyers to attack my family and I. Paying the lawyers was more important than providing supervision or life jackets for victims like Abraham Raji.

Abraham Raji, Nihara, DebConf23, Debian, Kayak

Given this vendetta has drained so much of the budget that somebody was left without a lifejacket and he died, it is clear to me that this vendetta is brought in bad faith and it violates UDRP rule 15(e).

Bad faith: attacking a volunteer at a time of grief, disrespect for the sanctity of human life

The complainant admits they began attacking my family and I in 2018 (evidence: screenshot of doxing messages from Chris Lamb further below). This was a time when I lost two family members and it was a disturbing time for my family and I for a range of reasons.

I told fellow collaborators that I couldn't fully commit to some of my voluntary responsibilities at that time. (email to Molly de Blanc)

At the same time, one of the issues causing controversy is the appearance of a Debian suicide cluster or an open source software suicide cluster. The attempt to minimize attention on individual suicides also has the effect of minimizing discussion about whether the combined body of deaths form a cluster. Public health authorities define three or more suicides as a cluster. The public health authorities advise that clusters need special attention to avoid the risk of further deaths.

Moreover, given the way that the Debian deaths intersect with my own family life, including the unexplained death of Adrian von Bidder on the day of our wedding, a possible suicide, the grief and toxicity associated with these phenomena have inevitably become intertwined.

This phenomena should be examined from an independent perspective, with a focus on the issues and not trying to misdirect attention towards a volunteer who expressed concerns about it. Forcing an individual volunteer to write about such phenomena under the threat that WIPO will denounce me is abhorrent.

Given that we already have this unexplained Debian death on the very day of our wedding, which is a huge scar, how can they possibly be imposing more scars upon my life with the continued burden of public harassment on the Debian web site and through WIPO? It is too much and it has been going on for too long.

Therefore, the bad faith is entirely on the part of those bullies forcing the matter before WIPO.

Bad faith: psychological torture / cybertorture

In the role the community elected me to perform, I gave people accurate assessments of the FSFE as an organization. The people caught doing the wrong thing responded with personal attacks on my family and on me as an individual.

It is entirely correct for us to scrutinize the functioning of a group or organization like that. It is wrong for such groups to turn on an individual volunteer.

Prof Nils Melzer, United Nations Special Rapporteur on Torture and Other Cruel, Inhuman or Degrading Treatment or Punishment has published a report on the practices of cybertorture and psychological torture. An earlier blog post examines the phenomena in Debian.

The insults submitted by the misfits write about excluding people. We saw similar tactics in the case of the "hooded men" in Northern Ireland. The obsession with excluding and isolating people, which comes up frequently in online discussions between the enforcers, is truly evil.

The defamation and insults created by the Debian misfits focus on a period when I lost two family members. By making repeated references to that period in 2018 they are seeking to trigger and exploit feelings of grief. This is the sort of deliberately cruel behavior envisaged by the UN special rapporteur.

Given that the misfits used WIPO and the UDRP to transmit documents targetting a period of grief, this is an example of a complaint brought for the purposes of harassment in violation of UDRP rule 15(e).

Bad faith: intent to use the domains for vendettas

The misfits provided a copy of a previous UDRP censorship decree for a domain they seized. After seizing the domain, the misfits have not used the domain for any original purpose. They are only using the domain to publish insults and attacks against my family and I.

Therefore, it would be reasonable to assume that any domains censored by this new UDRP case will also be weaponized against me.

Given that they have already behaved like this before, with their use of debian.community, it would be no surprise if they continue that behavior with any other domains they steal. Therefore, their intention is to harass me, as prohibited by UDRP rule 15(e).

Bad faith: voluntary work intertwined with our lives

The work we do as open source software developers intersects with many other aspects of our lives.

For example, when we participate in other voluntary groups in the real world, we often help them with their technology requirements. The solutions we provide often involve Debian and other free software products. When misfits start spreading rumors from Debian into social media networks, this is harmful to other groups where we participate and at the same time, it is harmful to our own personal lives, the places where we go to socialize away from our computers, the places where we go to exercize and so on.

Evidence: Centenary of Federation award.

This intrusion on multiple aspects of our lives, both professional and personal, is not by accident, it has become a deliberate intention of the rogue leadership figures who engage in publicly humiliating volunteers.

Therefore, given the impact that public denouncing us has on our lives, it is harassment and it violates UDRP rule 15(e)

Bad faith: suicide, stigma and tarnishing

WIPO panelists are asked to consider whether the content of the web sites tarnishes a trademark. There is clearly a lot of stigma around suicides. It is inevitable that some tarnishing may occur when suicide is mentioned.

Nonetheless, the panel needs to consider whether tarnishing is the lesser evil.

The factual revelations of a suicide cluster do run the risk of tarnishing the Debian trademark, I am not going to dispute that.

Yet the panel can not automatically conclude that tarnishing is done in bad faith. If the reason for publishing evidence related to a suicide cluster is in the interest of public health and preventing more suicides then it looks like tarnishing but it is NOT bad faith.

Given the nature of suicide, there is simply no way to publish these public health concerns without the counter-accusations of tarnishing.

In responding to the previous case of UDRP harassment by IBM Red Hat, in relation to the domain name WeMakeFedora.org, I made reference to the Holmes and Rahe Stress Scale. The loss of a family member is one of the highest events on the scale, between 63 and 100 points. Significant attacks on the business, career or professional reputation are rated between 39 and 47. It is suggested that when these events and scores combine, for example, through bad luck or persistent harassment, overall scores over 300 are highly likely to have an impact on health. In other words, there is a higher risk of illness, accident and suicide for people subjected to stress of this level.

The complainant is clearly aware of these arguments from the prior WeMakeFedora.org case so their decision to embark upon a copy-cat case and deliberately submit documents refering to 2018, the specific time when I lost two family members, appears to be a reckless and deliberate attempt to knowingly impose more pain on my family and I. Therefore, it is clearly a violation of UDRP rule 15(e), harassment and bad faith by those who initiated the procedure.

Bad faith: concealing risks to children

When IBM Red Hat submitted their case in the UDRP, they included as evidence an example of content from the WeMakeFedora.org web site. The example included five blog posts and one of those was a blog that had originally been published by me and then automatically syndicated by WeMakeFedora.org.

The blog that IBM Red Hat complained about and therefore wanted to censor was the blog post Google, FSFE & Child labor.

FSFE is a non-profit puppet organization jointly funded by Google, IBM Red Hat and other large corporations.

There are a subset of Debian co-authors who are also associated with FSFE.

As the community had elected me as the FSFE Fellowship representative and as I had concurrently been a mentor and administrator in programs like Google Summer of Code (GSoC) and Outreachy, I had an important role to play documenting the risks to children.

At the same time these risks to children began appearing in the world of open source software, the criminal procedure against Cardinal George Pell had been unfolding in Australia. As it turns out, a family member, some years younger than me, had been in the choir at the time that the late Cardinal Pell was Archbishop of Melbourne.

I had personally been an officer of the National Union of Students (Victorian state branch) in 1999. As far as I can tell, I was the most senior student representative having contact with somebody in the choir at the very time that the late Cardinal was in charge. When I saw risks to children around the open source software world, how could I not express concerns?

I had started doing voluntary work as a GSoC mentor in 2013. Therefore, I had five years experience of these programs when I came across the problems in Albania in the latter part of 2017. I used internal channels to raise concerns about the risk to minors.

Complainants knew my concerns were based on long standing experience and on personal exposure to these situations. While credible organizations would have found a way to deal with these matters diplomatically, the complainants are simultaneously trying to both censor me and discredit anything I have to say about these risks.

The fact that IBM Red Hat cited the child labor blog in their UDRP submission shows that is what they were trying to cover up. Their UDRP complaint was ruled an act of bad faith.

This is the evidence that IBM Red Hat submitted. It is clear that people around FSFE want to prevent discussion about child safety.

The fact that I had both privately and publicly expressed concerns about the risk to children and the timing of Debian's UDRP action coincides so closely with IBM Red Hat makes me feel they are seeking to censor and undermine exactly the same concerns about risks to children.

Looking at the way the FSFE's child labor program progressed, we can see that when the program finished, FSFE obfuscated the full names of the children who did the work. These children clearly have a copyright interest in the work they created. In other fields of endeavour we can see children receiving credit for their work under their full name. For example, look at the Jackson Five, where Michael Jackson began performing under his real name from age five.

The French pop singer Marina Kaye (a stage name) appeared under her real name Marina Dalmas on France's Got Talent when she was thirteen years old. Yet the children who wrote code for FSFE are not given credit under their full names. Only their first names were published.

FSFE, YH4F, Ekaterina Radaeva, Katya Radaeva, Miquel Puig, Hector, Stavros Piperakis

The trial of Cardinal Pell never proved whether abuse took place. What has been confirmed by medical evidence is that one member of the choir began substance abuse at approximately fourteen years of age. There are multiple possible explanations for the substance abuse. For some of the boys, participation is a burden and they never sing again after graduating from the school.

The choir was associated with the pressure of maintaining a scholarship at one of Australia's most expensive schools. The FSFE YH4F program involved the pressure of competing for a financial prize. When somebody like me with exposure to both of these situations expresses concerns, why are these organizations so desperate to cover it up?

The internal reports I submitted about harassment of women and risks to minors in 2017 are contemporaneous evidence of what really went on in proximity to the Outreachy funding in high risk countries like Albania. I was often the only mentor to personally witness the behavior of local men and women in these groups.

In 2013, when the Australian government sought to humiliate Iranian women and migrants with a video, I loudly resigned my membership of the party. This was nine years before the rest of the world took a serious interest in the plight of Iranian women protesting against a headscarf Code of Conduct. Even more telling, my written concerns put the mistreatment of these women in the same category as the alleged abuse in the Catholic church. The concerns were captured by Crikey.

Given my personal involvement as a witness over many years, my track record of being right about these things, sometimes well ahead of time and the track record of organizations trying to silence people who raise concerns about abuse, the attempts to discredit my testimony about these matters in proximity to GSoC and Outreachy is itself the act of bad faith, a violation of UDRP rule 15(e).

Bad faith: companies trying to keep the real abuse reports in-house

In the world of free and open source software, we have the unique phenomena of corporate employees working side by side with developers who work for competitors and also the unpaid volunteers.

After the commmunity elected me as the FSFE Fellowship representative in 2017, I began to receive significantly more detail about wrongdoing that goes on in the world of free and open source software. It is understandably surprising and disturbing for some of the larger companies to discover that these reports about their employees were going to an external volunteer and not to their in-house human resources department.

It is a useful moment to compare this situation to how it worked in the institutional abuse crisis. Australia's Royal Commission published many of the internal documents from the institutions concerned. One set of meeting minutes from the Archdiocese of Melbourne stands out. The Personnel Advisory Board (PAB), a group of highly trusted clergy who assist the Archbishop with the appointment of clergy to different roles, has realized that their board is too big and they need to create smaller sub-groups to handle the more sensitive cases.

Father X____ raised the question of how much is told to whom.

Father X____'s name appears frequently as somebody involved as an architect of the cover-up. His parish web site notes that he went into retirement in 2016. Coincidentally, that was the very moment the Royal Commission was seeking answers from Cardinal Pell.

Miraculously, Father X____ reappeared very briefly in 2023 to give a sermon at the funeral of a relative in a tiny village that few people would have heard of outside the state of Victoria. The following month, three people from that obscure village died in a mysterious mushroom poisoning that made headlines around the world.

Here is a snippet from the sermon, the man who moved pedophiles not only from one parish to another but also from one institution to another. He mentions a family connection with a former superintendent of An Garda Siochána (the Irish police).

By moving known pedophiles around, Father X____ enabled more abuse to take place and this resulted in more lives destroyed by overdoses and suicides.

Those seeking to discredit a former community representative are acting a lot like the institutions in the abuse crisis. As the WIPO UDRP guidelines tell us, anything that tarnishes the brand of Debian or the church has to be censored and covered up.

They are seeking to remove, censor and discredit me simply because people told me things I wasn't supposed to know. They would have preferred that some of these issues with women and children were only known to a select group of people appointed by the companies, just as the Personnel Advisory Board sought to limit knowledge of certain matters to the smallest possible sub-committee of clergy.

While the move to keeping information in-house is understandable and many companies even have an obligation to do so due to the privacy rights of their employees, it is not acceptable that they retrospectively punish me for my knowledge of these things. If punishing me or discrediting me for that role is part of their objective, they are the ones behaving in bad faith, violating UDRP rule 15(e).

Bad faith should not be alleged against an individual volunteer

Working in IT, our personal reputations for integrity are essential for us to feed ourselves and support those who depend on us.

A bad faith finding is likely to cause significant harm to a volunteer's ability to seek employment, obtain credit and enter into insurance contracts.

There have been complaints that WIPO panels have been making bad faith findings in cases that are ultimately about political speech rather than integrity of the publisher. This is very dangerous for personal victims of such findings and those who depend on such victims.

Moreover, using the bad faith verdict arbitrarily cheapens the meaning of the term bad faith.

It seems incredulous that a vindictive trademark owner can pay $1,500 to WIPO to make such an attack on a volunteer that will destroy that person's future and cause significant harm to those around them.

It is even more abhorrent that they can do such a thing to somebody who has contributed decades of voluntary service and to somebody suffering the loss of two family members at a time of grief.

Scrutiny should be turned around on those organizations who are exploiting our work and then menacing volunteers with the total loss of our livelihoods.

Bad faith can't be alleged when following a precedent

If a domain name holder has been motivated to register and use a particular domain name based on the logic of previous UDRP decisions, it would be very unreasonable to find the domain name holder is acting in bad faith.

There was widespread discussion of the scientologie.org verdict last time there were disputes about Debian domain names in 2022.

Based on those discussions and my new awareness of the logic behind the scientologie.org verdict, I felt that I had very reasonable grounds to register some Debian domains for the purpose of promoting my work in Debian and for promoting Debian, our collective work, as a whole.

Given that I was motivated by the precedent from another WIPO panel and there are good reasons for me to feel that I have legitimate interests on the same grounds, as somebody with a copyright interest, it is entirely unreasonable to accuse me of bad faith.

Bad faith: an ad hominem attack

A search for domain names containing the trademark Debian finds over 2,500 domains and web sites.

Looking at the list of open disputes in the WIPO UDRP case search, I can see that the list of domain names in dispute only has one thing in common: they are all owned by one person, me.

It is clear they are not concerned about the content, they are concerned with attacking the person, me.

Moreover, this ad hominem attack behavior has started before the registration of the domains and before the complaint. For example, the defamation statement submitted by the complainant is another example of an ad hominem attack. The statement is dated 2021, before all but one of these domains were registered. It shows that the complainant has a history of making ad hominem attacks with an intention to harm my family and I.

An ad hominem use of the UDRP process is therefore harassment by the complainant and a violation of UDRP rule 15(e).

Bad faith: complainant seeking revenge for whisteblowing about bad faith

Insults submitted by the complainant as evidence show they started harassing my family and I in 2018.

If we drill down, we find they started this harassment in September of that year.

In April 2017, the FSFE members elected me as their Fellowship representative. There is a significant overlap between members of the FSFE (approximatley 1532 people at the time of the election) and co-authors of the Debian software.

In the beginning of September 2018, in my role as Fellowship representative, I wrote that the FSFE was acting in bad faith by using a name derived from the real FSF. Various emails have since been published to prove there is bad faith and that both the FSF management and the FSFE management are aware of the bad faith. Of particular concern to me, as I expressed in the blog post from September 2018, a volunteer who had contributed a bequest of EUR 150,000 may have been fooled by the bad faith of FSFE. In other words, if the FSFE was not using a name similar to FSF, the volunteer may have given his bequest to the real FSF.

Evidence: FSFE election result.

If you hire an engineer to inspect a used car, you would hope that they would be able to verify basic things like the authenticity of the serial number (VIN) on the vehicle chassis. As the elected Fellowship representative, I had an obligation to report the FSFE was not what it claims to be.

The money that volunteers and private individuals have contributed to FSFE over the years is far more than the value of most used cars. Therefore, in the case of FSFE, there is both evidence of bad faith and there is quantitative evidence, the financial reports, showing us the impact of that bad faith.

The attacks against my family commenced immediately after I published the evidence of bad faith by FSFE. The email was sent to the LibrePlanet list on 11 September 2018 and the attacks began about one week later, as shown by the date of the email from Chris Lamb below on 20 September 2018.

The attacks against my family and I are a predecessor of this harassment through the UDRP. It has been a continuous pattern of harassment over six years now. It appears that this harassment, of which the UDRP insults are just the latest instalment, is part of an overall reprisal for the reports I gave the community in my capacity as the Fellowship representative.

Using the UDRP to insult and harass a volunteer community representative as a reprisal for performing their duties is clearly an act of harassment and bad faith as anticipated by UDRP rule 15(e).

Evidence: email from Mirko Bohm: I would like to thank you for your contributions to FSFE and for your commitment not to shy away from asking the difficult questions and calling out the need for change where it exists.

Bad faith: complainant reneges on their own Diversity Statement

The pack adopted the Debian Diversity Statement by a General Resolution in which all the co-authors were invited to vote.

The Diversity Statement begins with the line:

The Debian Project welcomes and encourages participation by everyone.

The insults that they submitted with the complaint, the defamation statement created by Donald Norwood in the Debian Press Team, contradicts their own Diversity Statement which was adopted by a General Resolution. Such a contradiction demonstrates a significant lack of integrity and their defamation statement should not be taken seriously.

I informed people that I had resigned from some of my voluntary roles at a time when I lost two family members. Therefore, their behavior towards my family and I is not just a plain vanilla violation of the diversity statement, it is an aggravated violation. It is bad faith.

Bad faith: the complainant is gaslighting about authorship and membership

The complainant appears to pivot back and forth between concepts from copyright law and from the law of associations.

Consider the case when somebody begins contributing to Debian. There is no such thing as a "New member" process. Rather, it has historically been called the "New maintainer" process. We can see that clearly in the name of the debian-newmaint mailing list.

The word "maintainer" primarily implies somebody is doing creative work to select, coordinate and arrange more independent works into Debian.

Then we have the guide for the New Member process, which was previously known as the New Maintainer process. In step 3, explained in that page, the new contributors are asked to agree to the Debian Social Contract, the Debian Free Software Guidelines and the Debian Machine Usage Policy. The former is ultimately about our relation as authors, not as members and the terms under which we license our work to the rest of the world.

The new maintainer/member guide doesn't ask people to ratify their adherence to the constitution. The notion of joining an association, whether it is incorporated or not, is inseparable from consenting to be governed by and uphold the association's constitution. The only people who ever ratified the constitution were 86 co-authors in 1998 (23% of the developers at that time) who wanted to have a constitution.

Somebody who did not ask to be a member can't be expelled.

Somebody who is not an employee can't be demoted or sacked.

Yet we have seen some of the leadership figures insist on having these powers over a series of victims. The title Debian Project Leader implies just that: to lead, not to give orders.

The insinuation that concepts of expulsions and demotions can be applied to co-authors is an example of gaslighting.

Copyright law is very clear: co-authors of a work are equal. Notions of expulsions and demotions violate the principle of being equal.

University of California: Each joint author has the right to exercise any or all of the exclusive rights inherent in the joint work

The fact that they are knowingly and deliberately trying to obfuscate our moral rights as co-authors, giving us nothing in exchange for the status they are taking away, is an aggravating factor that justifies the finding of harassment and bad faith against the complainant.

Bad faith: use of an administrative process to extinguish the moral rights and recognition of co authors

A recent paper in the University of Western Australia law journal examines the subject of Copyright Nazi Plunder: How the Nazis Aryanized Jewish Works.

The paper notes that the Nazis used administrative law to frustrate the rights of authors, just as misfits are using a WIPO administrative process to harass and intimidate a Debian co-author. Quoting the journal article:

Despite the fact that written IP legislation in Nazi Germany did not include specific exclusions for Jewish applicants and authors, in practice, they were excluded by administrative measures alone rather than legal ordinances.

The misfits frequently use the same language, the word "exclude" comes up again and again. Harassment, UDRP rule 15(e)

Bad faith: Debian Trademark Policy never ratified

Debian co-authors have never been asked to individually ratify the Debian Trademark Policy or any similar regulations.

A trademark policy published unilaterally by the trademark owner can give people authorizations above and beyond fair use and legitimate interest. On the other hand, such a policy can not unilaterally erode the default rights to fair use and legitimate interest.

Hypothetically, the complainant could ask co-authors to sign some agreement waiving our fair use rights. This may happen in the context of employment, where those who receive a salary agree to forego other rights.

Debianists do not pay us a salary and they did not ask us to individually ratify any agreement waiving our fair use rights.

They have never tried to do this. The only agreement they ever asked each and every one of us to individually ratify is our adherence to the Debian Machine Usage Policy and to the Debian Social Contract.

Therefore, in my role as a co-author, I am not bound by any restrictions unilaterally imposed upon us by the Debian Trademark Policy and only the normal rules of fair use and legitimate interest can be considered in this dispute.

Moreover, it is bad faith by the complainant to simultaneously insist that they can expel somebody, which is really a nonsense concept in terms of joint authorship rights, as such rights can't be extinguished and then insist that the people supposedly expelled will still remain bound by rules from above that only apply in the context of being a member of their clique.

Bad faith: complainant reneges on existing authorizations

As noted in the statements on legitimate interest, the complainant has clearly authorized many of the things they complained about.

The Debian Social Contract, which states "We will not hide problems", authorizes discussion of controversial technical, social and ethical topics. In fact, it is more than an authorization, it encourages such discussions and publications. Therefore, their complaining about what is published on these web sites is itself an act of bad faith.

They authorized use of the logo, as discussed, so their complaining about use of the logo is itself bad faith.

They put the web site theme and content under the open source licenses, as discussed above, so their complaining about sites with a similar appearance is itself bad faith.

Overall, for their claim of bad faith to supercede these authorizations, they would have to demonstrate some extraordinary acts of wrongdoing, for example, to show that a web site was using the trademark, domain name and logo to distribute a virus. They provide no evidence of such wrongdoing.

Bad faith: the complainant's evidence

They submit many boilerplate documents containing copies of the domain and trademark registrations. On top of that, they only submit three other documents.

One of those is the copy of a judgment from a previous Debian dispute. The judgment expresses concern about some specific images on another web site. The complaint does not provide any examples of those images or any similar content on any of my own Debian web sites. Therefore, this judgment can't be extrapolated to content on my own web sites.

They provide a copy of biographical information about me from my company web site. This is not published on one of the domains in dispute so it is not relevant. By providing this, they are insulting me. Looking at the very first archived copy of an email from the debian-project mailing list in 1994, we find that Debian co-authors are using the term Debian Developer four years before there was a trademark. That is four years before the Debian Project constitution. The term Debian Developer is completely valid for somebody who has done significant creative work over many decades. In plain English, the term Debian Developer can mean three things: somebody who possesses the skill of creating Debian software, somebody who has an authorship interest in the Debian software and thirdly, but lastly, somebody who is a member of the clique. Copyright law does not require somebody to be a member of the clique. I never joined the Debian Project Unincorporated Association, I have always used the term Debian Developer first and foremost to describe myself as an author with moral rights in the creative work. Given that they have taken this text from a web site that is not even part of the dispute, I feel the legal panel would be best to avoid getting involved in this aspect of the dispute.

The third document they provide is a defamation they created themselves. They are clearly hoping to have WIPO republish insults and defamation to cause some sort of harm to my ability to work and feed myself. They allege that there was some issue of harassment but do not provide any details. They claim it was in the year 2018, a period when I lost two family members. Their insistence on twisting a knife in my back at such a time only proves bad faith on their part.

In various ways, we can see that the document they submitted is a fraud that has the possibility of deceiving the WIPO legal panel.

For starters, the harassment began in 2017. Even the year specified in their evidence is wrong. Therefore, the evidence they are submitting is a deliberate deception that tries to invert the story.

Here is the internal report about the harassment. The date is 12 October 2017 so the misfits are clearly lying to the WIPO legal panel. I have redacted the section that identifies underage victims.

The next internal email from Larissa Shapiro at Mozilla admits that kids are at risk.

Emma Irwin from Mozilla admits this is a serious matter and asks me to speak to Marta, Mozilla's HR investigator.

There you have it. The most senior student representative to have had contact with a member of the choir in the era of Cardinal Pell has subsequently arrived in Albania and correctly and discretely raised the alarm about pimps and pedophiles using funds from Mozilla, IBM Red Hat and other tech companies to bait their child victims and young women.

It is creepy how the complainants deception about the dates and details mirrors the case of the Swiss JuristGate scandal. The Swiss financial regulator, FINMA, has published a summary of their decision to shut the rogue firm. In the summary of the decision, not only does FINMA redact the names of those responsible for ripping off the customers, FINMA even redacts the dates. One of the reasons FINMA is redacting the dates is to hide how long the regulator and the bar association really knew about the scandal. The hidden dates are examined in more detail in my first blog post about Juristgate. Here is a screenshot from the FINMA document showing where the year is obfuscated / redacted:

FINMA, Parreaux Thiébaud & Partners, Justicia SA, Justiva SA, Mathiee Parreaux

The FSFE Fellowship elected me as a community representative in April 2017. Shortly after that, women in Albania confided in me about the incidents of harassment. I traveled there again to help organize a MiniDebConf and Fedora Women's day and in the process, I became a witness to acts of harassment and a serious possibility of underage abuse.

All of this clearly began in 2017 but the defamation created by Debian seeks to obfuscate the year and the source of the harassment. They completely fail to thank me for the effort I made supporting these women. This was an effort above and beyond what had been anticipated when I volunteered to speak at the conference in Albania.

At the time, I had confided in the women that I was watching these matters very carefully because one of my cousins, who is much younger than me, had been in the St Patrick's cathedral choir during the time Cardinal George Pell was Archbishop of Melbourne. The Pell case was one of the most high profile allegations of abuse in the Catholic Church. The Royal Commission notes in their report that of 15,000 victims who contacted them, the Catholic Church was implicated in far more cases than all the other religions combined.

In the meantime, Carla had also written about her eating disorder on her web site. Research estimates that at least thirty percent of women with these conditions have been victims of harassment or abuse in childhood.

Various people appeared to resent the fact that women had given evidence about an (IBM Red Hat) Fedora Ambassador and Mozilla Tech Speaker to an independent, elected community representative who was not under any obligation of confidentially to the companies funding the Albanian groups. In other words, these companies would have prefered to see the women reporting scandals through internal company channels.

Shortly after I received this information from women, the FSFE revised their constitution to remove their annual elections and ensure there would never be any other community representative again. The complete removal of the election and the representative position proves that this wasn't about any failing on my own part, this was about the companies behind FSFE wanting to ensure that complaints about their people wouldn't reach any independent outsider who might be elected next.

At the end of the process, Mozilla produced a report about the harassment. I have never been given a copy of the report and the complainant has not submitted the report either. I don't feel the complaint should be taken seriously at all unless all parties, including the legal panel, are granted access to all these original, contemporaneous documents about the origins of the harassment and my support for the victims.

Evidence: Mozilla confirms a report was produced about the harassment and abuse.

Meanwhile, at the very same time as the Cardinal Pell trial was progressing in Australia, family and friends were shocked to see mysterious references to abuse circulated on social media. I don't even have any social media accounts myself so I only started hearing about these character assassination plots from witnesses who saw the smears. Cardinal Pell was convicted in December 2018 and a few weeks later, in January 2019, Joerg Jaspert of the Debian Account Managers team put mysterious references to abuse in one of our Debian source code repositories.

One of the findings from the Royal Commission states that abuse survivors who came forward took an average of 23.9 years to talk about what happened to them. Having attended a Catholic school in the same neighborhood and having multiple connections with fellow alumni and the diocese, it would not be a surprise for me if any one of the people I know might reveal themselves to be connected with the scandal at some point in the future.

Moreover, two of my cousins passed away far too young.

It is so shocking for me to see how these dirty men are playing these games with the subject of abuse.

At the time that Joerg Jaspert started making these privacy violations, he was on the school council at Dalbergschule in Fulda, Germany. Local magazines published a photo of him in a Debian t-shirt with other parents Claudia Beck and Ina Riechert.

Claudia Beck, Jörg Jaspert, Ina Riechert

How can the other parents and staff trust this dirty man with any sensitive topics when he runs around spreading gossip about abuse in the debian-private world?

Given that background, I find it abhorrent that these silly people claim to be victims of abuse when what really happened is they got caught doing the wrong thing. By claiming to be victims of harassment and abuse, by hijacking and distorting the language of sexual misconduct they are asking us to exhibit the same sympathy for long-distance peeping toms at Google as we would for those 15,000 child victims.

Here is another example of Debianists pretending to be part of the sexual crimes detective unit and circulating gossip as if it was truth. The email is written by Russell Coker, a Debian Developer in Australia, half way around the world from where the rumors started in Berlin. How could he write such forceful words about Dr Appelbaum when it is something he had no way to see? This shows how Debianists use their titles and their trademark to make stuff up and then give weight to defamation. This type of rogue behavior makes it even harder for the community to know when real victims take the difficult step of coming forward with real reports of abuse.

Evidence: Russell Coker fabricating rape stories.

Bad faith: deliberately conflating different types of harassment and abuse

The complainant frequently raises concerns about "harassment" and "abuse" whenever somebody asks a question they don't want to reply to.

Yet it doesn't stop there.

Not only do they claim to be victims of "harassment" and "abuse", they deliberately seek to conflate different meanings of these words. It works a bit like the game of Chinese Whispers.

The classic example was the lynching of Dr Jacob Appelbaum. One person posted messages about "harassment". Somebody else who wasn't actually there extrapolated that into "sexual harassment". Then another person who was all the other way over the other side of the world in Australia forcefully writes that it was a "rape".

Evidence: Chinese Whispers and liars rehearsing stories about Dr Appelbaum.

The word "abuse" is used in much the same way. Somebody asks a question about the bank account. The question is disparaged as an unqualified example of "abuse". Later, somebody adds a prefix, people mention "sexual abuse". But there is nothing sexual about asking why somebody's girlfriend got paid to do work that other volunteers do for free. We saw them using this word game in relation to Prof Eben Moglen recently.

Evidence: Matthew Garrett (Debian) spreading abuse rumors against Prof Moglen

Not only are they trying to defame the person asking a serious question but we also have to remember that when people try to portray themselves as victims of "abuse", they are siphoning off a little bit of credibility from the real victims, like those incredibly young boys and girls who made complaints about institutional abuse. The pretend victims and their antics dilute the credibility of the real victims.

Most healthy people are turned off by discussions like this. Yet there is a subculture around Debian, a subgroup of volunteers who appear to take some voyeuristic interest in making these word games with references to abuse, the type of thing we see in the blog post by Matthew Garrett.

Just how did Garrett become an expert on abuse?

These comments about the phenomena may appear quite strong and defamatory at first glance but the evidence is already public. Have a look at the controversy about the package with the name "weboob". According to reports, the source code is laced with crude references to women. The package was discussed on debian-private. Quite a few Debian men, like Axel Beckert, a system administrator at the ETH Zurich university, defended the package during his working hours.

Subject: Re: weboob package
Date: Fri, 13 Jul 2018 14:29:58 +0200
From: Axel Beckert <abe@debian.org>
Organization: The Debian Project
To: debian-private@lists.debian.org


Jonathan Dowland wrote:
> Yesterday I stumbled across the "weboob" package for the first time,
> which includes a slew of binaries with names similar to the following:

So what? I don't see any problem with that. (And I don't see why
there's a thread on debian-private about it.)

		Regards, Axel
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Develoober, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bad faith: timing of harassment

In each case, we can see that one of the Debian oligarchs has engaged in some form of behavior that involves bullying or harassing a volunteer and the disclosures about bullying have only happened subsequent to that.

The vendettas began in September 2018. The complainant has submitted their case of debian.community and we can see that the domain name debian.community was only registered in October 2019, more than 13 months after the Debian Project Leader started spreading gossip about multiple volunteers.

In April 2021, I incorporated a new company to promote my work. In November 2021, the misfits began distributing their defamation statement about my family and I as a reprisal. It appears the misfits are jealous that I could start my own company and they wanted to destroy it. In Australia, we call this the Tall Poppy Syndrome.

In June 2021, one of the women was caught trying to start rumors about me having a relationship with a female intern. The same woman was caught again trying to start rumors in the same chat channel in July 2022. In March 2023, I created a web site Outreachy.Dating with proof that the rumors are false. I did not spontaneously decide to go and create the Outreachy.Dating web site. The site only came into existence as a right of reply to the pre-existing campaign of gossip against my interns, my family and I.

Ariadne Conill

As already described in a previous section, when we agreed to create Debian together, we agreed to uphold the Debian Social Contract, which includes the commitment 3. We won't hide problems.

In 2018 and 2019, oligarchs started hiding the blogs of some co-authors. The same phenomena occurred in the Fedora Linux community. I have only had to register domain names like Debian.News and WeMakeFedora.org in response to the censorship of some blogs. I did not just wake up one day and spontaneously decide to create these domain names, I was motivated to do so because the censors violated our existing rules of engagement, the Debian Social Contract and the Fedora Foundations.

Bad faith: Debian's violent history of intolerance

Despite all the grand statements about the Code of Conduct, Respect and Diversity, the Debian people are highly intolerant.

It has always been this way and there is plenty of evidence.

Consider 2006, the violent expulsion of Ted Walther from DebConf6 dinner in Mexico. Somebody started a rumor that his dinner guest was a prostitute. Nobody checked the facts. People physically pushed him out the door and nearly threw him down the steps.

Evidence: debian-private leaks about the DebConf6 assault

Instead of spending $120,000 on lawyers, they could have simply apologized to my family for violating our privacy. But they are paying all this money to rewrite history. They are paying the lawers all this money to insist that the petty little word choice issues that their small minds are preoccupied with are more significant than things like the death of my father.

Bad faith: blackmailing people to disclose personal and private information

Whenever people come across the Debian smearing campaign through social media and they ask me about the rumors of harassment and abuse, the first things that come to mind are those cases that arose at the time. The poor behavior I witnessed towards women from Albania, Carla's eating disorder and the prosecution of Cardinal George Pell.

Other volunteers have made similar complaints about being blackmailed to make public statements and disclose things about themselves.

Bradley Kuhn of the Software Freedom Conservancy has recently complained that he was blackmailed to publicly disclose things about his romantic life and partner preferences.

Kuhn: As such, I'm outing myself here first (primarily) to disarm his ability to use what he knows about my sexual orientation against me.

In 2019, we saw that Dr Norbert Preining was blackmailed to write a self-deprecating forced confession on a public mailing list. When I saw that Dr Preining and I had been subject to similar blackmail tactics, I felt that I was being expected to make a similar public statement about matters that belong in private.

In the case of Bradley Kuhn, his disclosures relate to himself. In my own case, in all cases of harassment and abuse where I have been a witness, it is unthinkable that I should be forced by these rumors to make disclosures about other people.

Therefore, when I published the Mozilla examples above, I partially redacted them to avoid revealing the names of underage open source software victims.

Nonetheless, I didn't voluntarily choose to publish responses to gossip about abuse. They are using the WIPO UDRP to blackmail me to publish comments about abuse cases. Therefore, they are violating UDRP rule 15(e).

Bad faith: destroying our portfolio of work

In some industries, it is common for practitioners to carry a portfolio of their work. For example, photographers, architects and similar professionals often rely on such a portfolio to show potential clients what they are capable of.

In computing, prospective employers and clients look at the portfolio of our work in Debian and other free software projects. Replacing that portfolio with insults and defamation is akin to setting the portfolio on fire.

Once again, this appears to be the intention of the misfits behind the complaint. By publishing attacks on my family and demanding a verdict of bad faith, they are trying to further undermine the credit I deserve for decades of work involving free and open source software. It is harassment in violation of UDRP Rule 15(e).

Bad faith: how many Debian Developers really committed suicide?

We can look at the list of Debian Developers and filter the list by "Current status".

There are 972 Debian Developers listed with the status "Debian Developer, uploading". These are people considered to be active.

When people resign/retire, their status is changed to "Emeritus". There are 449 Debian Developers with status Emeritus.

The status "Removed" is distinct from the status "Emeritus". There are 272 Debian Developers with status "Removed". This list includes people who have died, it includes victims who have been disappeared and it includes people who have failed to respond to any attempts to communicate. Some of these people may have been participating under a fake identity. Some of them may have become fed up with the politics and walked away without saying goodbye. Some of these 272 people that we can't account for may have joined the suicide cluster.

Public health statistics tell us that only one in four suicide victims leave a note. In a large enough group of people, for every one person who leaves notes like Frans Pop, it seems like a reasonable hypothesis that there are three more who we don't know about because they didn't leave a note. Ian Murdock left notes on social media. Richard Rothwell left notes.

With or without a note, in this list of 272 people "Removed", there will be many more we don't know about because their families would never think to tell us.

How many of these 272 vanished after some secret humiliation on the debian-private mailing list?

How many bloggers have committed suicide after WIPO denounced them with accusations of bad faith?

Bad faith: deceiving the previous WIPO panel

The misfits have clearly deceived the previous WIPO panel on certain issues. One of those issues is their claim that Albanian women paid to travel to Brazil were junior female developers.

I was a mentor and administrator in both the Google Summer of Code and Outreachy programs over a number of years from 2013 to 2018.

In that role, I interacted with many of the prospective interns, both male and female.

I was involved in creating tasks that we asked the applicants to perform to test their skills and demonstrate their motivation during the selection process for these internships. I observed the effort that each applicant made, whether they were male or female.

There were definitely women who did a very high standard of work. However, there were other women who did not do any software development and we can see now in hindsight that some of those women still haven't done any software development despite hanging around the open source communities for almost a decade. Therefore, the claim that every woman was a junior female developer was not true. Some women were junior female developers, the rest we could not refer to with the term developer.

We can see that the panel was deceived about the origins of references to branding in the nether regions. This controversy, which was mentioned in the panel's finding against another domain, is rooted in the manner in which the misfits created rogue commits in source code repositories on the anniversary of our wedding.

Specifically, we completed a civil wedding on 23 September 2010 and then we completed the religious ceremony a few months later on 17 April 2011.

Here is the civil wedding certificate:

Here we can see the rogue commit in the Debian keyring repository, on the date of the civil wedding, overlaid with the photo of genital branding from NXIVM.

Debian, NXIVM

Given the way this extreme harassment simultaneously intrudes on both my professional life and my family life, I find these images even more horrific than they were for the WIPO panel. Nonetheless, the images of genital branding are as relevant as they are horrific when you consider the deliberate way these misfits impose on our lives and our reputations.

Here is the date of the religious ceremony on my wedding ring, alongside the tombstone of Adrian von Bidder, secretary of Debian.ch who died in what appears to be a possible suicide on exactly the same day, 17 April 2011:

What an incredibly toxic culture the Debian misfits are trying to hide with this WIPO UDRP vendetta.

The misfits have made multiple intrusions in the lives of volunteers. While the scars are not identical, the mentality behind those scars is much the same. In both Debian and NXIVM, some of the people feel they have a sense of entitlement to impose upon all aspects of our lives and our future, whether it is through branding, through gossip or through demanding that WIPO denounces individual volunteers.

Bad faith: using WIPO and an Albanian gangmaster to defame me

I previously documented how I was a witness to acts of harassment and the risks to underage participants by two Albanian men. I attached the emails showing how this was raised through internal channels at Mozilla.

When Chris Lamb decided to attack me on our wedding anniversary, he actually used Elio Qoshi, the Albanian bringing a sixteen year old girlfriend to tech conferences, to distribute the messages about the vendetta.

At the time, I was with one of the victims. Women who had worked with me personally had been surprised to see Lamb colluding with these Albanian gangmasters. I took a photo of the message that the Albanian forwarded from Lamb to the phones of female victims:

It is an extraordinary example of corruption. When I saw Chris Lamb colluding with Elio Qoshi to denounce me at such a painful time for my family, I couldn't help thinking of men like Jimmy Saville and Rolf Harris collaborating in their crimes.

When I challenged Lamb about these messages in December 2018, he publicly denied sending them, a lie to the whole community.

Chris Lamb: You are well-aware that I have been nothing but scrupulous and gentlemanly with regards to your personal privacy and thus ...

The dishonesty of these misfits is as extraordinary as the intrusion into the family lives of volunteers.

As Debian is an operating system, it is relied upon as the foundation for so many other things that people do with their computers both in industry and in private. In other words, people put a lot of trust in the operating system but we can't trust the people making it. Here we have caught the then leader of Debian using a common garden variety Albanian pimp to spread rumors about a long standing volunteer and also publicly lying about the matter.

Now these dirty little men aspire to exploiting a WIPO panel in the same way they used this Albanian gangmaster to denounce my family and I on the anniversary of our wedding. As mentioned earlier, the deadline set by WIPO was Carla's birthday.

10 April, 2024 10:30PM

April 09, 2024

Ian Jackson

Why we’ve voted No to CfD for Derril Water solar farm

[personal profile] ceb and I are members of the Derril Water Solar Park cooperative.

We were recently invited to vote on whether the coop should bid for a Contract for Difference, in a government green electricity auction.

We’ve voted No.

“Green electricity” from your mainstream supplier is a lie

For a while [personal profile] ceb and I have wanted to contribute directly to green energy provision. This isn’t really possible in the mainstream consumer electricy market.

Mainstream electricity suppliers’ “100% green energy” tariffs are pure greenwashing. In a capitalist boondoogle, they basically “divvy up” the electricity so that customers on the (typically more expensive) “green” tariff “get” the green electricity, and the other customers “get” whatever is left. (Of course the electricity is actually all mixed up by the National Grid.) There are fewer people signed up for these tariffs than there is green power generated, so this basically means signing up for a “green” tariff has no effect whatsoever, other than giving evil people more money.


About a year ago we heard about Ripple. The structure is a little complicated, but the basic upshot is:

Ripple promote and manage renewable energy schemes. The schemes themselves are each an individual company; the company is largely owned by a co-operative. The co-op is owned by consumers of electricity in the UK., To stop the co-operative being an purely financial investment scheme, shares ownership is limited according to your electricity usage. The electricity is be sold on the open market, and the profits are used to offset members’ electricity bills. (One gotcha from all of this is that for this to work your electricity billing provider has to be signed up with Ripple, but ours, Octopus, is.)

It seemed to us that this was a way for us to directly cause (and pay for!) the actual generation of green electricity.

So, we bought shares in one these co-operatives: we are co-owners of the Derril Water Solar Farm. We signed up for the maximum: funding generating capacity corresponding to 120% of our current electricity usage. We paid a little over £5000 for our shares.

Contracts for Difference

The UK has a renewable energy subsidy scheme, which goes by the name of Contracts for Difference. The idea is that a renewable energy generation company bids in advance, saying that they’ll sell their electricity at Y price, for the duration of the contract (15 years in the current round). The lowest bids win. All the electricity from the participating infrastructure is sold on the open market, but if the market price is low the government makes up the difference, and if the price is high, the government takes the winnings.

This is supposedly good for giving a stable investment environment, since the price the developer is going to get now doesn’t depends on the electricity market over the next 15 years. The CfD system is supposed to encourage development, so you can only apply before you’ve commissioned your generation infrastructure.

Ripple and CfD

Ripple recently invited us to agree that the Derril Water co-operative should bid in the current round of CfDs.

If this goes ahead, and we are one of the auction’s winners, the result would be that, instead of selling our electricity at the market price, we’ll sell it at the fixed CfD price.

This would mean that our return on our investment (which show up as savings on our electricity bills) would be decoupled from market electricity prices, and be much more predictable.

They can’t tell us the price they’d want to bid at, and future electricity prices are rather hard to predict, but it’s clear from the accompanying projections that they think we’d be better off on average with a CfD.

The documentation is very full of financial projections and graphs; other factors aren’t really discussed in any detail.

The rules of the co-op didn’t require them to hold a vote, but very sensibly, for such a fundamental change in the model, they decided to treat it roughly the same way as for a rules change: they’re hoping to get 75% Yes votes.

Voting No

The reason we’re in this co-op at all is because we want to directly fund renewable electricity.

Participating in the CfD auction would involve us competing with capitalist energy companies for government subsidies. Subsidies which are supposed to encourage the provision of green electricity.

It seems to us that participating in this auction would remove most of the difference between what we hoped to do by investing in Derril Water, and just participating in the normal consumer electricity market.

In particular, if we do win in the auction, that’s probably directly removing the funding and investment support model for other, market-investor-funded, projects.

In other words, our buying into Derril Water ceases to be an additional green energy project, changing (in its minor way) the UK’s electricity mix. It becomes a financial transaction much more tenously connected (if connected at all) to helping mitigate the climate emergency.

So our conclusion was that we must vote against.

comment count unavailable comments

09 April, 2024 09:38PM

hackergotchi for Gunnar Wolf

Gunnar Wolf

Think outside the box • Welcome Eclipse!

Now that we are back from our six month period in Argentina, we decided to adopt a kitten, to bring more diversity into our lives. Perhaps this little girl will teach us to think outside the box!

Yesterday we witnessed a solar eclipse — Mexico City was not in the totality range (we reached ~80%), but it was a great experience to go with the kids. A couple dozen thousand people gathered for a massive picnic in las islas, the main area inside our university campus.

Afterwards, we went briefly back home, then crossed the city to fetch the little kitten. Of course, the kids were unanimous: Her name is Eclipse.

09 April, 2024 04:38PM

hackergotchi for Matthew Palmer

Matthew Palmer

How I Tripped Over the Debian Weak Keys Vulnerability

Those of you who haven’t been in IT for far, far too long might not know that next month will be the 16th(!) anniversary of the disclosure of what was, at the time, a fairly earth-shattering revelation: that for about 18 months, the Debian OpenSSL package was generating entirely predictable private keys.

The recent xz-stential threat (thanks to @nixCraft for making me aware of that one), has got me thinking about my own serendipitous interaction with a major vulnerability. Given that the statute of limitations has (probably) run out, I thought I’d share it as a tale of how “huh, that’s weird” can be a powerful threat-hunting tool – but only if you’ve got the time to keep pulling at the thread.

Prelude to an Adventure

Our story begins back in March 2008. I was working at Engine Yard (EY), a now largely-forgotten Rails-focused hosting company, which pioneered several advances in Rails application deployment. Probably EY’s greatest claim to lasting fame is that they helped launch a little code hosting platform you might have heard of, by providing them free infrastructure when they were little more than a glimmer in the Internet’s eye.

I am, of course, talking about everyone’s favourite Microsoft product: GitHub.

Since GitHub was in the right place, at the right time, with a compelling product offering, they quickly started to gain traction, and grow their userbase. With growth comes challenges, amongst them the one we’re focusing on today: SSH login times. Then, as now, GitHub provided SSH access to the git repos they hosted, by SSHing to git@github.com with publickey authentication. They were using the standard way that everyone manages SSH keys: the ~/.ssh/authorized_keys file, and that became a problem as the number of keys started to grow.

The way that SSH uses this file is that, when a user connects and asks for publickey authentication, SSH opens the ~/.ssh/authorized_keys file and scans all of the keys listed in it, looking for a key which matches the key that the user presented. This linear search is normally not a huge problem, because nobody in their right mind puts more than a few keys in their ~/.ssh/authorized_keys, right?

2008-era GitHub giving monkey puppet side-eye to the idea that nobody stores many keys in an authorized_keys file

Of course, as a popular, rapidly-growing service, GitHub was gaining users at a fair clip, to the point that the one big file that stored all the SSH keys was starting to visibly impact SSH login times. This problem was also not going to get any better by itself. Something Had To Be Done.

EY management was keen on making sure GitHub ran well, and so despite it not really being a hosting problem, they were willing to help fix this problem. For some reason, the late, great, Ezra Zygmuntowitz pointed GitHub in my direction, and let me take the time to really get into the problem with the GitHub team. After examining a variety of different possible solutions, we came to the conclusion that the least-worst option was to patch OpenSSH to lookup keys in a MySQL database, indexed on the key fingerprint.

We didn’t take this decision on a whim – it wasn’t a case of “yeah, sure, let’s just hack around with OpenSSH, what could possibly go wrong?”. We knew it was potentially catastrophic if things went sideways, so you can imagine how much worse the other options available were. Ensuring that this wouldn’t compromise security was a lot of the effort that went into the change. In the end, though, we rolled it out in early April, and lo! SSH logins were fast, and we were pretty sure we wouldn’t have to worry about this problem for a long time to come.

Normally, you’d think “patching OpenSSH to make mass SSH logins super fast” would be a good story on its own. But no, this is just the opening scene.

Chekov’s Gun Makes its Appearance

Fast forward a little under a month, to the first few days of May 2008. I get a message from one of the GitHub team, saying that somehow users were able to access other users’ repos over SSH. Naturally, as we’d recently rolled out the OpenSSH patch, which touched this very thing, the code I’d written was suspect number one, so I was called in to help.

The lineup scene from the movie The Usual Suspects
They're called The Usual Suspects for a reason, but sometimes, it really is Keyser Söze

Eventually, after more than a little debugging, we discovered that, somehow, there were two users with keys that had the same key fingerprint. This absolutely shouldn’t happen – it’s a bit like winning the lottery twice in a row1 – unless the users had somehow shared their keys with each other, of course. Still, it was worth investigating, just in case it was a web application bug, so the GitHub team reached out to the users impacted, to try and figure out what was going on.

The users professed no knowledge of each other, neither admitted to publicising their key, and couldn’t offer any explanation as to how the other person could possibly have gotten their key.

Then things went from “weird” to “what the…?”. Because another pair of users showed up, sharing a key fingerprint – but it was a different shared key fingerprint. The odds now have gone from “winning the lottery multiple times in a row” to as close to “this literally cannot happen” as makes no difference.

Milhouse from The Simpsons says that We're Through The Looking Glass Here, People

Once we were really, really confident that the OpenSSH patch wasn’t the cause of the problem, my involvement in the problem basically ended. I wasn’t a GitHub employee, and EY had plenty of other customers who needed my help, so I wasn’t able to stay deeply involved in the on-going investigation of The Mystery of the Duplicate Keys.

However, the GitHub team did keep talking to the users involved, and managed to determine the only apparent common factor was that all the users claimed to be using Debian or Ubuntu systems, which was where their SSH keys would have been generated.

That was as far as the investigation had really gotten, when along came May 13, 2008.

Chekov’s Gun Goes Off

With the publication of DSA-1571-1, everything suddenly became clear. Through a well-meaning but ultimately disasterous cleanup of OpenSSL’s randomness generation code, the Debian maintainer had inadvertently reduced the number of possible keys that could be generated by a given user from “bazillions” to a little over 32,000. With so many people signing up to GitHub – some of them no doubt following best practice and freshly generating a separate key – it’s unsurprising that some collisions occurred.

You can imagine the sense of “oooooooh, so that’s what’s going on!” that rippled out once the issue was understood. I was mostly glad that we had conclusive evidence that my OpenSSH patch wasn’t at fault, little knowing how much more contact I was to have with Debian weak keys in the future, running a huge store of known-compromised keys and using them to find misbehaving Certificate Authorities, amongst other things.

Lessons Learned

While I’ve not found a description of exactly when and how Luciano Bello discovered the vulnerability that became CVE-2008-0166, I presume he first came across it some time before it was disclosed – likely before GitHub tripped over it. The stable Debian release that included the vulnerable code had been released a year earlier, so there was plenty of time for Luciano to have discovered key collisions and go “hmm, I wonder what’s going on here?”, then keep digging until the solution presented itself.

The thought “hmm, that’s odd”, followed by intense investigation, leading to the discovery of a major flaw is also what ultimately brought down the recent XZ backdoor. The critical part of that sequence is the ability to do that intense investigation, though.

When I reflect on my brush with the Debian weak keys vulnerability, what sticks out to me is the fact that I didn’t do the deep investigation. I wonder if Luciano hadn’t found it, how long it might have been before it was found. The GitHub team would have continued investigating, presumably, and perhaps they (or I) would have eventually dug deep enough to find it. But we were all super busy – myself, working support tickets at EY, and GitHub feverishly building features and fighting the fires in their rapidly-growing service.

As it was, Luciano was able to take the time to dig in and find out what was happening, but just like the XZ backdoor, I feel like we, as an industry, got a bit lucky that someone with the skills, time, and energy was on hand at the right time to make a huge difference.

It’s a luxury to be able to take the time to really dig into a problem, and it’s a luxury that most of us rarely have. Perhaps an understated takeaway is that somehow we all need to wrestle back some time to follow our hunches and really dig into the things that make us go “hmm…”.

Support My Hunches

If you’d like to help me be able to do intense investigations of mysterious software phenomena, you can shout me a refreshing beverage on ko-fi.

  1. the odds are actually probably more like winning the lottery about twenty times in a row. The numbers involved are staggeringly huge, so it’s easiest to just approximate it as “really, really unlikely”. 

09 April, 2024 12:00AM by Matt Palmer (mpalmer@hezmatt.org)

April 08, 2024

Bastian Blank

Python dataclasses for Deb822 format

Python includes some helping support for classes that are designed to just hold some data and not much more: Data Classes. It uses plain Python type definitions to specify what you can have and some further information for every field. This will then generate you some useful methods, like __init__ and __repr__, but on request also more. But given that those type definitions are available to other code, a lot more can be done.

There exists several separate packages to work on data classes. For example you can have data validation from JSON with dacite.

But Debian likes a pretty strange format usually called Deb822, which is in fact derived from the RFC 822 format of e-mail messages. Those files includes single messages with a well known format.

So I'd like to introduce some Deb822 format support for Python Data Classes. For now the code resides in the Debian Cloud tool.



It uses the standard data classes support and several helper functions. Also you need to enable support for postponed evaluation of annotations.

from __future__ import annotations
from dataclasses import dataclass
from dataclasses_deb822 import read_deb822, field_deb822

Class definition start

Data classes are just normal classes, just with a decorator.

class Package:

Field definitions

You need to specify the exact key to be used for this field.

    package: str = field_deb822('Package')
    version: str = field_deb822('Version')
    arch: str = field_deb822('Architecture')

Default values are also supported.

    multi_arch: Optional[str] = field_deb822(

Reading files

for p in read_deb822(Package, sys.stdin, ignore_unknown=True):

Full example

from __future__ import annotations
from dataclasses import dataclass
from debian_cloud_images.utils.dataclasses_deb822 import read_deb822, field_deb822
from typing import Optional
import sys

class Package:
    package: str = field_deb822('Package')
    version: str = field_deb822('Version')
    arch: str = field_deb822('Architecture')
    multi_arch: Optional[str] = field_deb822(

for p in read_deb822(Package, sys.stdin, ignore_unknown=True):

Known limitations

08 April, 2024 05:00PM by Bastian Blank

April 07, 2024

Thorsten Alteholz

My Debian Activities in March 2024

FTP master

This month I accepted 147 and rejected 12 packages. The overall number of packages that got accepted was 151.

If you file an RM bug, please do check whether there are reverse dependencies as well and file RM bugs for them. It is annoying and time-consuming when I have to do the moreinfo dance.

Debian LTS

This was my hundred-seventeenth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

During my allocated time I uploaded:

  • [DLA 3770-1] libnet-cidr-lite-perl security update for one CVE to fix IP parsing and ACLs based on the result
  • [#1067544] Bullseye PU bug for libmicrohttpd
  • Unfortunately XZ happened at the end of month and I had to delay/intentionally delayed other uploads: they will appear as DLA-3781-1 and DLA-3784-1 in April

I also continued to work on qtbase-opensource-src and last but not least did a week of FD.

Debian ELTS

This month was the sixty-eighth ELTS month. During my allocated time I uploaded:

  • [ELA-1062-1]libnet-cidr-lite-perl security update for one CVE to improve parsing of IP addresses in Jessie and Stretch
  • Due to XZ I also delayed the uploads here. They will appear as ELA-1069-1 and DLA-1070-1 in April

I also continued on an update for qtbase-opensource-src in Stretch (and LTS and other releases as well) and did a week of FD.

Debian Printing

This month I uploaded new upstream or bugfix versions of:

This work is generously funded by Freexian!

Debian Astro

This month I uploaded a new upstream or bugfix version of:

Debian IoT

This month I uploaded new upstream or bugfix versions of:

Debian Mobcom

This month I uploaded a new upstream or bugfix version of:


This month I uploaded new upstream or bugfix versions of:

07 April, 2024 11:56AM by alteholz

April 06, 2024

John Goerzen

Facebook is Censoring Stories about Climate Change and Illegal Raid in Marion, Kansas

It is, sadly, not entirely surprising that Facebook is censoring articles critical of Meta.

The Kansas Reflector published an artical about Meta censoring environmental articles about climate change — deeming them “too controversial”.

Facebook then censored the article about Facebook censorship, and then after an independent site published a copy of the climate change article, Facebook censored it too.

The CNN story says Facebook apologized and said it was a mistake and was fixing it.

Color me skeptical, because today I saw this:

Yes, that’s right: today, April 6, I get a notification that they removed a post from August 12. The notification was dated April 4, but only showed up for me today.

I wonder why my post from August 12 was fine for nearly 8 months, and then all of a sudden, when the same website runs an article critical of Facebook, my 8-month-old post is a problem. Hmm.

Riiiiiight. Cybersecurity.

This isn’t even the first time they’ve done this to me.

On September 11, 2021, they removed my post about the social network Mastodon (click that link for screenshot). A post that, incidentally, had been made 10 months prior to being removed.

While they ultimately reversed themselves, I subsequently wrote Facebook’s Blocking Decisions Are Deliberate — Including Their Censorship of Mastodon.

That this same pattern has played out a second time — again with something that is a very slight challenege to Facebook — seems to validate my conclusion. Facebook lets all sort of hateful garbage infest their site, but anything about climate change — or their own censorship — gets removed, and this pattern persists for years.

There’s a reason I prefer Mastodon these days. You can find me there as @jgoerzen@floss.social.

So. I’ve written this blog post. And then I’m going to post it to Facebook. Let’s see if they try to censor me for a third time. Bring it, Facebook.

06 April, 2024 02:00PM by John Goerzen

hackergotchi for Mirco Bauer

Mirco Bauer

Secure USB boot with Debian


The moment you leave your laptop, say in a hotel room, you can no longer trust your system as it could have been modified while you were away, which is also known as the "evil maid" attack. Think you are safe because you have a crypted disk? Well, if the boot partition is on the laptop itself, it can be manipulated and you will not notice because the boot partition can't be encrypted. The BIOS needs to access the MBR and boot loader and that loads the Linux kernel, all unencrypted. There has been some reports lately that the Linux cryptsetup is insecure because you can spawn a root shell by hitting the enter key for 70 seconds. This is not the threat to your system, really. If someone has physical access to your hardware, he can get a root shell in less than a second by passing init=/bin/bash as parameter to the Linux kernel in the boot loader regardless if cryptsetup is used or not. The attacker can also use other ways like booting a live system from CD/USB etc. The actual insecurity here is the unencrypted boot partition and not some script that gets executed from it. So how to prevent this physical access attack vector? Just keep reading this guide.

This guide explains how to install Debian securely on your laptop with using an external USB boot disk, such as a standard USB memory stick. The disk inside the laptop should not contain your /boot partition since that is an easy target for manipulation. An attacker could for example change the boot scripts inside the initrd image to capture your passphrase of your crypted volume. With an USB boot partition, you can unplug the USB stick after the operating system has booted. Best practice here is to have the USB stick together with your bunch of keys. That way you will disconnect your USB stick early after the boot as finished so you can put it back into your pocket.

Secure Hardware Assumptions

We have to assume here that the hardware you are using to download and verify the install media is safe to use. Same applies with the hardware where you are doing the fresh Debian install. Say the hardware does not contain any malware in the form of code in EFI or other manipulation attempts that influence the behavior of the operating system we are going to install.

Download Debian Install ISO

Feel free to use any Debian mirror and install flavor. For this guide I am using the download mirror in Germany and the DVD install flavor.

wget http://ftp.de.debian.org/debian-cd/current/amd64/iso-dvd/debian-8.6.0-amd64-DVD-1.iso

Verify hashsum of ISO file

To know if the ISO file was downloaded without modification we have to check the hashsum of the file. The hashsum file can be found in the same directory as the ISO file on the download mirror. With hashsums if a single bit differs in the file, the resulting SHA512 sum will be completely different.

Obtain the hashsum file using:

wget http://ftp.de.debian.org/debian-cd/current/amd64/iso-dvd/SHA512SUMS

Calculate a local hashsum from the downloaded ISO file:

sha512sum debian-8.6.0-amd64-DVD-1.iso

Now you need to compare the hashsum with that is in the SHA512SUMS file. Since the SHA512SUMS file contains the hashsums of all files that are in the same directory you need to find the right one first. grep can do this for you:

grep debian-8.6.0-amd64-DVD-1.iso SHA512SUMS

Both commands executed after each other should show following output:

$ sha512sum debian-8.6.0-amd64-DVD-1.iso
c3883edfc95e3b09152d46ce29a032eed1de71531549aee86bb98dab1528088a16f0b4d628aee8ac6cc420364e208d3d5e19d0dea3576f53b904c18e8f604d8c  debian-8.6.0-amd64-DVD-1.iso
$ grep debian-8.6.0-amd64-DVD-1.iso SHA512SUMS
c3883edfc95e3b09152d46ce29a032eed1de71531549aee86bb98dab1528088a16f0b4d628aee8ac6cc420364e208d3d5e19d0dea3576f53b904c18e8f604d8c  debian-8.6.0-amd64-DVD-1.iso

As you can see the hashsum found in the SHA512SUMS file matches with the locally generated hashsum using the sha512sum command.

At this point we are not finished yet. These 2 matching hashsums just means whatever was on the download server matches what we have received and stored locally on your disk. The ISO file and SHA512SUM file could still be a modified version!

And this is where GPG signatures chime in, covered in the next section.

Download GPG Signature File

GPG signature files usually have the .sign file name extension but could also be named .asc. Download the signature file using wget:

wget http://ftp.de.debian.org/debian-cd/current/amd64/iso-dvd/SHA512SUMS.sign

Obtain GPG Key of Signer

Letting gpg verify the signature will fail at this point as we don't have the public key of the signer:

$ gpg --verify SHA512SUMS.sign
gpg: assuming signed data in 'SHA512SUMS'
gpg: Signature made Mon 19 Sep 2016 12:23:47 AM HKT
gpg:                using RSA key DA87E80D6294BE9B
gpg: Can't check signature: No public key

Downloading a key is trivial with gpg, but more importantly we need to verify that this key (DA87E80D6294BE9B) is trustworthy, as it could also be a key of the infamous man-in-the-middle.

Here you can find the GPG fingerprints of the official signing keys used by Debian. The ending of the "Key fingerprint" line should match the key id we found in the signature file from above.

gpg:                using RSA key DA87E80D6294BE9B

Key fingerprint = DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

DA87E80D6294BE9B matches Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B

To download and import this key run:

$ gpg --keyserver keyring.debian.org --recv-keys DA87E80D6294BE9B

Verify GPG Signature of Hashsum File

Ok, we are almost there. Now we can run the command which checks if the signature of the hashsum file we have, was not modified by anyone and matches what Debian has generated and signed.

gpg: assuming signed data in 'SHA512SUMS'
gpg: Signature made Mon 19 Sep 2016 12:23:47 AM HKT
gpg:                using RSA key DA87E80D6294BE9B
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Good signature from "Debian CD signing key <debian-cd@lists.debian.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

The important line in this output is the "Good signature from ..." one. It still shows a warning since we never certified (signed) that Debian key. This can be ignored at this point though.

Write ISO Image to Install Media

With a verified pristine ISO file we can finally start the install by writing it to an USB stick or blank DVD. So use your favorite tool to write the ISO to your install media and boot from it. I have used dd and a USB stick attached as /dev/sdb.

dd if=debian-8.6.0-amd64-DVD-1.iso of=/dev/sdb bs=1M oflag=sync

Install Debian on Crypted Volume with USB boot partition

I am not explaining each step of the Debian install here. The Debian handbook is a good resource for covering each install step.

Follow the steps until the installers wants to partition your disk.

There you need to select the "Guided, use entire disk and set up encrypted LVM" option. After that select the built-in disk of your laptop, which usually is sda but double check this before you go ahead, as it will overwrite the data! The 137 GB disk in this case is the built-in disk and the 8 GB is the USB stick.

It makes no difference at this point if you select "All files in one partition" or "Separate /home partition". The USB boot partition can be selected a later step.

Confirm that you want to overwrite your built-in disk shown as sda. It will take a while as it will write random data to the disk to ensure there is no unencrypted data left on the disk from previous installations for example.

Now you need to enter your passphrase that will be used to protect the private key of the crypt volume. Choose something long enough like a sentence and don't forget the passphrase else you can no longer access your data! Don't save the passphrase on any computer, smartphone or password manager. If you want to make a backup of your passphrase then use a ball pen and paper and store the paper backup in a secure location.

The installer will show you a summary of the partitioning as shown above but we need to make the change for the USB boot disk. At the moment it wants to put /boot on sda which is the built-in disk, while our USB stick is sdb. Select /boot and hit enter, after that select "Delete this partition".

After /boot was deleted we can create /boot on the USB stick shown as sdb. Select sdb and hit enter. It will ask if you want to create an empty partition table. Confirm that question with yes.

The partition summary shows sdb with no partitions on it. Select FREE SPACE and select "Create a new partition". Confirm the suggested partition size. Confirm the partition type to be "Primary".

It is time to tell the installer to use this new partition on the USB stick (sdb1) as /boot partition. Select "Mount point: /home" and in the next dialog select "/boot - static files of the boot loader" as shown below:

Confirm the made changes by selecting "Done setting up the partition".

The final partitioning should look now like the following screenshot:

If the partition summary looks good, go ahead with the installation by selecting "Finish partitioning and write changes to disk".

When the installer asks if it should force EFI, then select no, as EFI is not going to protect you.

Finish the installation as usual, select your preferred desktop environment etc.

GRUB Boot Loader

Confirm the dialog that wants to install GRUB to the master boot record. Here it is important to install it to the USB stick and not your built-in SATA/SSD disk! So select sdb (the USB stick) in the next dialog.

First Boot from USB

Once everything is installed, you can boot from your USB stick. As simple test you can unplug your USB stick and the boot should fail with "no operating system found" or similar error message from the BIOS. If it doesn't boot even though the USB stick is connected, then most likely your BIOS is not configured to boot from USB media. Also a blank screen and nothing happening is usually meaning the BIOS can't find a boot device. You need to change the boot setting in your BIOS. As the steps are very different for each BIOS, I can't provide a detailed step-by-step list here.

Usually you can enter the BIOS using F1, F2 or F12 after powering on your computer. In the BIOS there is a menu to configure the boot order. In that list it should show USB disk/storage as the first position. After you have made the changes save and exit the BIOS. Now it will boot from your USB stick first and GRUB will show up and proceeds with the boot process till it will ask for your passphrase to unlock the crypt volume.

Unmount /boot partition after Boot

If you boot your laptop from the USB stick, we want to remove the stick after it has finished booting. This will prevent an attacker to make modifications to your USB stick. To avoid data loss, we should not simply unplug the USB stick but unmount /boot first and then unplug the stick. Good news is that we can automate this unmounting and you just need to unplug the stick after the laptop has finished booting to your login screen.

Just add this line to your /etc/rc.local file:

umount /boot

After boot you can once verify that it automatically unmounts /boot for you by running:

mount | grep /boot

If that command produces no output, then /boot is not mounted and you can safely unplug the USB stick.

Final Words

From time to time you need to upgrade your Linux kernel of course which is on the /boot partition. This can still be done the regular way using apt-get upgrade, except that you need to mount /boot before that and unmount it again after the kernel upgrade.

Enjoy your secured laptop. Now you can leave it in a hotel room without the possibility of someone trying you obtain your passphrase by putting a key logger in your boot partition. All the attacker will see is a fully encrypted harddisk. If he tries to mess with your crypted disk, you will notice as the decryption will fail.

Disclaimer: there are still other attack vectors possible, but they are much harder to do. Your hardware or BIOS can still be modified. But not by holding down the enter key for 70 seconds or by booting a live system.

06 April, 2024 06:26AM

hackergotchi for Junichi Uekawa

Junichi Uekawa

Trying to explain analogue clock.

Trying to explain analogue clock. It's hard to explain. Tried adding some things for affordance, and it is still not enough. So it's not obvious which arm is the hour and which arm is the minute. analog clock

06 April, 2024 03:37AM by Junichi Uekawa

April 05, 2024

Paul Wise

FLOSS Activities March 2024


This month I didn't have any particular focus. I just worked on issues in my info bubble.




  • Debian wiki: approve accounts


  • Respond to queries from Debian users and contributors on the mailing lists and IRC


The SWH work was sponsored. All other work was done on a volunteer basis.

05 April, 2024 11:28PM

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

RcppArmadillo on CRAN: Upstream Fix

armadillo image

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 1136 other packages on CRAN, downloaded 33.5 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 578 times according to Google Scholar.

This release brings a new upstream bugfix release Armadillo 12.8.2 prepared by Conrad two days ago. It took the usual day to noodle over 1100+ reverse dependencies and ensure two failures were independent of the upgrade (i.e., “no change to worse” in CRAN parlance). It took CRAN another because we hit a random network outage for (spurious) NOTE on a remote URL, and were then caught in the shrapnel from another large package ecosystem update spuriously pointing some build failures that were due to a missing rebuild to us. All good, as human intervention comes to the rescue.

The set of changes since the last CRAN release follows.

Changes in RcppArmadillo version (2024-04-02)

  • Upgraded to Armadillo release 12.8.2 (Cortisol Injector)

    • Workaround for FFTW3 header clash

    • Workaround in testing framework for issue under macOS

    • Minor cleanups to reduce code bloat

    • Improved documentation

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

05 April, 2024 10:12PM

hackergotchi for Bits from Debian

Bits from Debian

apt install dpl-candidate: Sruthi Chandran

The Debian Project Developers will shortly vote for a new Debian Project Leader known as the DPL.

The DPL is the official representative of representative of The Debian Project tasked with managing the overall project, its vision, direction, and finances.

The DPL is also responsible for the selection of Delegates, defining areas of responsibility within the project, the coordination of Developers, and making decisions required for the project.

Our outgoing and present DPL Jonathan Carter served 4 terms, from 2020 through 2024. Jonathan shared his last Bits from the DPL post to Debian recently and his hopes for the future of Debian.

Recently, we sat with the two present candidates for the DPL position asking questions to find out who they really are in a series of interviews about their platforms, visions for Debian, lives, and even their favorite text editors. The interviews were conducted by disaster2life (Yashraj Moghe) and made available from video and audio transcriptions:

  • Andreas Tille [Interview]
  • Sruthi Chandran [this document]

Voting for the position starts on April 6, 2024.

Editors' note: This is our official return to Debian interviews, readers should stay tuned for more upcoming interviews with Developers and other important figures in Debian as part of our "Meet your Debian Developer" series. We used the following tools and services: Turboscribe.ai for the transcription from the audio and video files, IRC: Oftc.net for communication, Jitsi meet for interviews, and Open Broadcaster Software (OBS) for editing and video. While we encountered many technical difficulties in the return to this process, we are still able and proud to present the transcripts of the interviews edited only in a few areas for readability.

2024 Debian Project Leader Candidate: Sruthi Chandran

Sruthi's interview

Hi Sruthi, so for the first question, who are you and could you tell us a little bit about yourself?


I usually talk about me whenever I am talking about answering the question who am I, I usually say like I am a librarian turned free software enthusiast and a Debian Developer. So I had no technical background and I learned, I was introduced to free software through my husband and then I learned Debian packaging, and eventually I became a Debian Developer. So I always give my example to people who say I am not technically inclined, I don't have technical background so I can't contribute to free software.

So yeah, that's what I refer to myself.

For the next question, could you tell me what do you do in Debian, and could you mention your story up until here today?


Okay, so let me start from my initial days in Debian. I started contributing to Debian, my first contribution was a Tibetan font. We went to a Tibetan place and they were saying they didn't have a font in Linux.

So that's how I started contributing. Then I moved on to Ruby packages, then I have some JavaScript and Go packages, all dependencies of GitLab. So I was involved with maintaining GitLab for some time, now I'm not very active there.

But yeah, so GitLab was the main package I was contributing to since I contributed since 2016 to maybe like 2020 or something. Later I have come [over to] packaging. Now I am part of some of the teams, delegated teams, like community team and outreach team, as well as the Debconf committee. And the biggest, I think, my activity in Debian, I would say is organizing Debconf 2023. So it was a great experience and yeah, so that's my story in Debian.

So what are three key terms about you and your candidacy?


Okay, let me first think about it. For candidacy, I can start with diversity is one point I started expressing from the first time I contested for DPL. But to be honest, that's the main point I want to bring.


So for diversity, if you could break down your thoughts on diversity and make them, [about] your three points including diversity.


So in addition to, eventually when starting it was just diversity. Now I have like a bit more ideas, like community, like I want to be a leader for the Debian community. More than, I don't know, maybe people may not agree, but I would say I want to be a leader of Debian community rather than a Debian operating system.

I connect to community more and third point I would say.

The term of a DPL lasts for an year. So what do you think during, what would you try to do during that, that you can't do from your position now?


Okay. So I, like, I am very happy with the structure of Debian and how things work in Debian. Like you can do almost a lot of things, like almost all things without being a DPL.

Whatever change you want to bring about or whatever you want to do, you can do without being a DPL. Anyone, like every DD has the same rights. Only things I feel [the] DPL has hold on are mainly the budget or the funding part, which like, that's where they do the decision making part.

And then comes like, and one advantage of DPL driving some idea is that somehow people tend to listen to that with more, like, tend to give more attention to what DPL is saying rather than a normal DD. So I wanted to, like, I have answered some of the questions on how to, how I plan to do the financial budgeting part, how I want to handle, like, and the other thing is using the extra attention that I get as a DPL, I would like to obviously start with the diversity aspect in Debian. And yeah, like, I, what I want to do is not, like, be a leader and say, like, take Debian to one direction where I want to go, but I would rather take suggestions and inputs from the whole community and go about with that.

So yes, that's what I would say.

And taking a less serious question now, what is your preferred text editor?




Vim, wholeheartedly team Vim?




Great. Well, this was made in Vim, all the text for this.


So, like, since you mentioned extra data, I'll give my example, like, it's just a fun note, when I started contributing to Debian, as I mentioned, I didn't have any knowledge about free software, like Debian, and I was not used to even using Linux. So, and I didn't have experience with these text editors. So, when I started contributing, I used to do the editing part using gedit.

So, that's how I started. Eventually, I moved to Nano, and once I reached Vim, I didn't move on.

Team Vim. Next question. What, what do you think is the importance of the Debian project in the world today? And where would you like to see it in 10 years, like 10 years into the future?


Okay. So, Debian, as we all know, is referred to as the universal operating system without, like, it is said for a reason. We have hundreds and hundreds of operating systems, like Linux, distributions based on Debian.

So, I believe Debian, like even now, Debian has good influence on the, at least on the Linux or Linux ecosystem. So, what we implement in Debian has, like, is going to affect quite a lot of, like, a very good percentage of people using Linux. So, yes.

So, I think Debian is one of the leading Linux distributions. And I think in 10 years, we should be able to reach a position, like, where we are not, like, even now, like, even these many years after having Linux, we face a lot of problems in newer and newer hardware coming up and installing on them is a big problem. Like, firmwares and all those things are getting more and more complicated.

Like, it should be getting simpler, but it's getting more and more complicated. So, I, one thing I would imagine, like, I don't know if we will ever reach there, but I would imagine that eventually with the Debian, we should be able to have some, at least a few of the hardware developers or hardware producers have Debian pre-installed and those kind of things. Like, not, like, become, I'm not saying it's all, it's also available right now.

What I'm saying is that it becomes prominent enough to be opted as, like, default distro.

What part of Debian has made you And what part of the project has kept you going all through these years?


Okay. So, I started to contribute in 2016, and I was part of the team doing GitLab packaging, and we did have a lot of training workshops and those kind of things within India. And I was, like, I had interacted with some of the Indian DDs, but I never got, like, even through chat or mail.

I didn't have a lot of interaction with the rest of the world, DDs. And the 2019 Debconf changed my whole perspective about Debian. Before that, I wasn't, like, even, I was interested in free software.

I was doing the technical stuff and all. But after DebConf, my whole idea has been, like, my focus changed to the community. Debian community is a very welcoming, very interesting community to be with.

And so, I believe that, like, 2019 DebConf was a for me. And that kept, from 2019, my focus has been to how to support, like, how, I moved to the community part of Debian from there. Then in 2020 I became part of the community team, and, like, I started being part of other teams.

So, these, I would say, the Debian community is the one, like, aspect of Debian that keeps me whole, keeps me held on to the Debian ecosystem as a whole.

Continuing to speak about Debian, what do you think, what is the first thing that comes to your mind when you think of Debian, like, the word, the community, what's the first thing?


I think I may sound like a broken record or something.


No, no.


Again, I would say the Debian community, like, it's the people who makes Debian, that makes Debian special.

Like, apart from that, if I say, I would say I'm very, like, one part of Debian that makes me very happy is the, how the governing system of Debian works, the Debian constitution and all those things, like, it's a very unique thing for Debian. And, and it's like, when people say you can't work without a proper, like, establishment or even somebody deciding everything for you, it's difficult. When people say, like, we have been, Debian has been proving it for quite a long time now, that it's possible.

So, so that's one thing I believe, like, that's one unique point. And I am very proud about that.

What areas do you think Debian is failing in, how can it (that standing) be improved?


So, I think where Debian is failing now is getting new people into Debian. Like, I don't remember, like, exactly the answer. But I remember hearing someone mention, like, the average age of a Debian Developer is, like, above 40 or 45 or something, like, exact age, I don't remember.

But it's like, Debian is getting old. Like, the people in Debian are getting old and we are not getting enough of new people into Debian. And that's very important to have people, like, new people coming up.

Otherwise, eventually, like, after a few years, nobody, like, we won't have enough people to take the project forward. So, yeah, I believe that is where we need to work on. We are doing some efforts, like, being part of GSOC or outreachy and having maybe other events, like, local events. Like, we used to have a lot of Debian packaging workshops in India. And those kind of, I think, in Brazil and all, they all have, like, local communities are doing. But we are not very successful in retaining the people who maybe come and try out things.

But we are not very good at retaining the people, like, retaining people who come. So, we need to work on those things. Right now, I don't have a solid answer for that.

But one thing, like, I was thinking about is, like, having a Debian specific outreach project, wherein the focus will be about the Debian, like, starting will be more on, like, usually what happens in GSOC and outreach is that people come, have the, do the contributions, and they go back. Like, they don't have that connection with the Debian, like, Debian community or Debian project. So, what I envision with these, the Debian outreach, the Debian specific outreach is that we have some part of the internship, like, even before starting the internship, we have some sessions and, like, with the people in Debian having, like, getting them introduced to the Debian philosophy and Debian community and Debian, how Debian works.

And those things, we focus on that. And then we move on to the technical internship parts. So, I believe this could do some good in having, like, when you have people you can connect to, you tend to stay back in a project mode.

When you feel something more than, like, right now, we have so many technical stuff to do, like, the choice for a college student is endless. So, if they want, if they stay back for something, like, maybe for Debian, I would say, we need to have them connected to the Debian project before we go into technical parts. Like, technical parts, like, there are other things as well, where they can go and do the technical part, but, like, they can come here, like, yeah.

So, that's what I was saying. Focused outreach projects is one thing. That's just one.

That's not enough. We need more of, like, more ideas to have more new people come up. And I'm very happy with, like, the DebConf thing. We tend to get more and more people from the places where we have a DebConf. Brazil is an example. After the Debconf, they have quite a good improvement on Debian contributors.

And I think in India also, it did give a good result. Like, we have more people contributing and staying back and those things. So, yeah.

So, these were the things I would say, like, we can do to improve.

For the final question, what field in free software do you, what field in free software generally do you think requires the most work to be put into it? What do you think is Debian's part in that field?


Okay. Like, right now, what comes to my mind is the free software licenses parts. Like, we have a lot of free software licenses, and there are non-free software licenses.

But currently, I feel free software is having a big problem in enforcing these licenses. Like, there are, there may be big corporations or like some people who take up the whole, the code and may not follow the whole, for example, the GPL licenses. Like, we don't know how much of those, how much of the free softwares are used in the bigger things.

Yeah, I agree. There are a lot of corporations who are afraid to touch free software. But there would be good amount of free software, free work that converts into property, things violating the free software licenses and those things.

And we do not have the kind of like, we have SFLC, SFC, etc. But still, we do not have the ability to go behind and trace and implement the licenses. So, enforce those licenses and bring people who are violating the licenses forward and those kind of things is challenging because one thing is it takes time, like, and most importantly, money is required for the legal stuff.

And not always people who like people who make small software, or maybe big, but they may not have the kind of time and money to have these things enforced. So, that's a big challenge free software is facing, especially in our current scenario. I feel we are having those, like, we need to find ways how we can get it sorted.

I don't have an answer right now what to do. But this is a challenge I felt like and Debian's part in that. Yeah, as I said, I don't have a solution for that.

But the Debian, so DFSG and Debian sticking on to the free software licenses is a good support, I think.

So, that was the final question, Do you have anything else you want to mention for anyone watching this?


Not really, like, I am happy, like, I think I was able to answer the questions. And yeah, I would say who is watching. I won't say like, I'm the best DPL candidate, you can't have a better one or something.

I stand for a reason. And if you believe in that, or the Debian community and Debian diversity, and those kinds of things, if you believe it, I hope you would be interested, like, you would want to vote for me. That's it.

Like, I'm not, I'll make it very clear. I'm not doing a technical leadership part here. So, those, I can't convince people who want technical leadership to vote for me.

But I would say people who connect with me, I hope they vote for me.

05 April, 2024 06:36PM by Yashraj Moghe with The Debian Publicity Team

apt install dpl-candidate: Andreas Tille

The Debian Project Developers will shortly vote for a new Debian Project Leader known as the DPL.

The Project Leader is the official representative of The Debian Project tasked with managing the overall project, its vision, direction, and finances.

The DPL is also responsible for the selection of Delegates, defining areas of responsibility within the project, the coordination of Developers, and making decisions required for the project.

Our outgoing and present DPL Jonathan Carter served 4 terms, from 2020 through 2024. Jonathan shared his last Bits from the DPL post to Debian recently and his hopes for the future of Debian.

Recently, we sat with the two present candidates for the DPL position asking questions to find out who they really are in a series of interviews about their platforms, visions for Debian, lives, and even their favorite text editors. The interviews were conducted by disaster2life (Yashraj Moghe) and made available from video and audio transcriptions:

  • Andreas Tille [this document]
  • Sruthi Chandran [Interview]

Voting for the position starts on April 6, 2024.

Editors' note: This is our official return to Debian interviews, readers should stay tuned for more upcoming interviews with Developers and other important figures in Debian as part of our "Meet your Debian Developer" series. We used the following tools and services: Turboscribe.ai for the transcription from the audio and video files, IRC: Oftc.net for communication, Jitsi meet for interviews, and Open Broadcaster Software (OBS) for editing and video. While we encountered many technical difficulties in the return to this process, we are still able and proud to present the transcripts of the interviews edited only in a few areas for readability.

2024 Debian Project Leader Candidate: Andrea Tille

Andreas' Interview

Who are you? Tell us a little about yourself.


How am I? Well, I'm, as I wrote in my platform, I'm a proud grandfather doing a lot of free software stuff, doing a lot of sports, have some goals in mind which I like to do and hopefully for the best of Debian.

And How are you today?


How I'm doing today? Well, actually I have some headaches but it's fine for the interview.

So, usually I feel very good. Spring was coming here and today it's raining and I plan to do a bicycle tour tomorrow and hope that I do not get really sick but yeah, for the interview it's fine.

What do you do in Debian? Could you mention your story here?


Yeah, well, I started with Debian kind of an accident because I wanted to have some package salvaged which is called WordNet. It's a monolingual dictionary and I did not really plan to do more than maybe 10 packages or so. I had some kind of training with xTeddy which is totally unimportant, a cute teddy you can put on your desktop.

So, and then well, more or less I thought how can I make Debian attractive for my employer which is a medical institute and so on. It could make sense to package bioinformatics and medicine software and it somehow evolved in a direction I did neither expect it nor wanted to do, that I'm currently the most busy uploader in Debian, created several teams around it.

DebianMate is very well known from me. I created the Blends team to create teams and techniques around what we are doing which was Debian TIS, Debian Edu, Debian Science and so on and I also created the packaging team for R, for the statistics package R which is technically based and not topic based. All these blends are covering a certain topic and R is just needed by lots of these blends.

So, yeah, and to cope with all this I have written a script which is routing an update to manage all these uploads more or less automatically. So, I think I had one day where I uploaded 21 new packages but it's just automatically generated, right? So, it's on one day more than I ever planned to do.

What is the first thing you think of when you think of Debian?

Editors' note: The question was misunderstood as the “worst thing you think of when you think of Debian”


The worst thing I think about Debian, it's complicated. I think today on Debian board I was asked about the technical progress I want to make and in my opinion we need to standardize things inside Debian. For instance, bringing all the packages to salsa, follow some common standards, some common workflow which is extremely helpful.

As I said, if I'm that productive with my own packages we can adopt this in general, at least in most cases I think. I made a lot of good experience by the support of well-formed teams. Well-formed teams are those teams where people support each other, help each other.

For instance, how to say, I'm a physicist by profession so I'm not an IT expert. I can tell apart what works and what not but I'm not an expert in those packages. I do and the amount of packages is so high that I do not even understand all the techniques they are covering like Go, Rust and something like this.

And I also don't speak Java and I had a problem once in the middle of the night and I've sent the email to the list and was a Java problem and I woke up in the morning and it was solved. This is what I call a team. I don't call a team some common repository that is used by random people for different packages also but it's working together, don't hesitate to solve other people's problems and permit people to get active.

This is what I call a team and this is also something I observed in, it's hard to give a percentage, in a lot of other teams but we have other people who do not even understand the concept of the team. Why is working together make some advantage and this is also a tough thing. I [would] like to tackle in my term if I get elected to form solid teams using the common workflow. This is one thing.

The other thing is that we have a lot of good people in our infrastructure like FTP masters, DSA and so on. I have the feeling they have a lot of work and are working more or less on their limits, and I like to talk to them [to ask] what kind of change we could do to move that limits or move their personal health to the better side.

The DPL term lasts for a year, What would you do during that you couldn't do now?


Yeah, well this is basically what I said are my main issues. I need to admit I have no really clear imagination what kind of tasks will come to me as a DPL because all these financial issues and law issues possible and issues [that] people who are not really friendly to Debian might create. I'm afraid these things might occupy a lot of time and I can't say much about this because I simply don't know.

What are three key terms about you and your candidacy?


As I said, I like to work on standards, I’d like to make Debian try [to get it right so] that people don't get overworked, this third key point is be inviting to newcomers, to everybody who wants to come. Yeah, I also mentioned in my term this diversity issue, geographical and from gender point of view. This may be the three points I consider most important.

Preferred text editor?


Yeah, my preferred one? Ah, well, I have no preferred text editor. I'm using the Midnight Commander very frequently which has an internal editor which is convenient for small text. For other things, I usually use VI but I also use Emacs from time to time. So, no, I have not preferred text editor. Whatever works nicely for me.

What is the importance of the community in the Debian Project? How would like to see it evolving over the next few years?


Yeah, I think the community is extremely important. So, I was on a lot of DebConfs. I think it's not really 20 but 17 or 18 DebCons and I really enjoyed these events every year because I met so many friends and met so many interesting people that it's really enriching my life and those who I never met in person but have read interesting things and yeah, Debian community makes really a part of my life.

And how do you think it should evolve specifically?


Yeah, for instance, last year in Kochi, it became even clearer to me that the geographical diversity is a really strong point. Just discussing with some women from India who is afraid about not coming next year to Busan because there's a problem with Shanghai and so on. I'm not really sure how we can solve this but I think this is a problem at least I wish to tackle and yeah, this is an interesting point, the geographical diversity and I'm running the so-called mentoring of the month.

This is a small project to attract newcomers for the Debian Med team which has the focus on medical packages and I learned that we had always men applying for this and so I said, okay, I dropped the constraint of medical packages.

Any topic is fine, I teach you packaging but it must be someone who does not consider himself a man. I got only two applicants, no, actually, I got one applicant and one response which was kind of strange if I'm hunting for women or so.

I did not understand but I got one response and interestingly, it was for me one of the least expected counters. It was from Iran and I met a very nice woman, very open, very skilled and gifted and did a good job or have even lose contact today and maybe we need more actively approach groups that are underrepresented. I don't know if what's a good means which I did but at least I tried and so I try to think about these kind of things.

What part of Debian has made you smile? What part of the project has kept you going all through the years?


Well, the card game which is called Mao on the DebConf made me smile all the time. I admit I joined only two or three times even if I really love this kind of games but I was occupied by other stuff so this made me really smile. I also think the first online DebConf in 2020 made me smile because we had this kind of short video sequences and I tried to make a funny video sequence about every DebConf I attended before. This is really funny moments but yeah, it's not only smile but yeah.

One thing maybe it's totally unconnected to Debian but I learned personally something in Debian that we have a do-ocracy and you can do things which you think that are right if not going in between someone else, right? So respect everybody else but otherwise you can do so.

And in 2020 I also started to take trees which are growing widely in my garden and plant them into the woods because in our woods a lot of trees are dying and so I just do something because I can. I have the resource to do something, take the small tree and bring it into the woods because it does not harm anybody. I asked the forester if it is okay, yes, yes, okay. So everybody can do so but I think the idea to do something like this came also because of the free software idea. You have the resources, you have the computer, you can do something and you do something productive, right? And when thinking about this I think it was also my Debian work.

Meanwhile I have planted more than 3,000 trees so it's not a small number but yeah, I enjoy this.

What part of Debian would you have some criticisms for?


Yeah, it's basically the same as I said before. We need more standards to work together. I do not want to repeat this but this is what I think, yeah.

What field in Free Software generally do you think requires the most work to be put into it? What do you think is Debian's part in the field?


It's also in general, the thing is the fact that I'm maintaining packages which are usually as modern software is maintained in Git, which is fine but we have some software which is at Sourceport, we have software laying around somewhere, we have software where Debian somehow became Upstream because nobody is caring anymore and free software is very different in several things, ways and well, I in principle like freedom of choice which is the basic of all our work.

Sometimes this freedom goes in the way of productivity because everybody is free to re-implement. You asked me for the most favorite editor. In principle one really good working editor would be great to have and would work and we have maybe 500 in Debian or so, I don't know.

I could imagine if people would concentrate and say five instead of 500 editors, we could get more productive, right? But I know this will not happen, right? But I think this is one thing which goes in the way of making things smooth and productive and we could have more manpower to replace one person who's [having] children, doing some other stuff and can't continue working on something and maybe this is a problem I will not solve, definitely not, but which I see.

What do you think is Debian's part in the field?


Yeah, well, okay, we can bring together different Upstreams, so we are building some packages and have some general overview about similar things and can say, oh, you are doing this and some other person is doing more or less the same, do you want to join each other or so, but this is kind of a channel we have to our Upstreams which is probably not very successful.

It starts with code copies of some libraries which are changed a little bit, which is fine license-wise, but not so helpful for different things and so I've tried to convince those Upstreams to forward their patches to the original one, but for this and I think we could do some kind of, yeah, [find] someone who brings Upstream together or to make them stop their forking stuff, but it costs a lot of energy and we probably don't have this and it's also not realistic that we can really help with this problem.

Do you have any questions for me?


I enjoyed the interview, I enjoyed seeing you again after half a year or so. Yeah, actually I've seen you in the eating room or cheese and wine party or so, I do not remember we had to really talk together, but yeah, people around, yeah, for sure. Yeah.

05 April, 2024 06:36PM by Yashraj Moghe with The Debian Publicity Team

April 04, 2024

John Goerzen

The xz Issue Isn’t About Open Source

You’ve probably heard of the recent backdoor in xz. There have been a lot of takes on this, most of them boiling down to some version of:

The problem here is with Open Source Software.

I want to say not only is that view so myopic that it pushes towards the incorrect, but also it blinds us to more serious problems.

Now, I don’t pretend that there are no problems in the FLOSS community. There have been various pieces written about what this issue says about the FLOSS community (usually without actionable solutions). I’m not here to say those pieces are wrong. Just that there’s a bigger picture.

So with this xz issue, it may well be a state actor (aka “spy”) that added this malicious code to xz. We also know that proprietary software and systems can be vulnerable. For instance, a Twitter whistleblower revealed that Twitter employed Indian and Chinese spies, some knowingly. A recent report pointed to security lapses at Microsoft, including “preventable” lapses in security. According to the Wikipedia article on the SolarWinds attack, it was facilitated by various kinds of carelessness, including passwords being posted to Github and weak default passwords. They directly distributed malware-infested updates, encouraged customers to disable anti-malware tools when installing SolarWinds products, and so forth.

It would be naive indeed to assume that there aren’t black hat actors among the legions of programmers employed by companies that outsource work to low-cost countries — some of which have challenges with bribery.

So, given all this, we can’t really say the problem is Open Source. Maybe it’s more broad:

The problem here is with software.

Maybe that inches us closer, but is it really accurate? We have all heard of Boeing’s recent issues, which seem to have some element of root causes in corporate carelessness, cost-cutting, and outsourcing. That sounds rather similar to the SolarWinds issue, doesn’t it?

Well then, the problem is capitalism.

Maybe it has a role to play, but isn’t it a little too easy to just say “capitalism” and throw up our hands helplessly, just as some do with FLOSS as at the start of this article? After all, capitalism also brought us plenty of products of very high quality over the years. When we can point to successful, non-careless products — and I own some of them (for instance, my Framework laptop). We clearly haven’t reached the root cause yet.

And besides, what would you replace it with? All the major alternatives that have been tried have even stronger downsides. Maybe you replace it with “better regulated capitalism”, but that’s still capitalism.

Then the problem must be with consumers.

As this argument would go, it’s consumers’ buying patterns that drive problems. Buyers — individual and corporate — seek flashy features and low cost, prizing those over quality and security.

No doubt this is true in a lot of cases. Maybe greed or status-conscious societies foster it: Temu promises people to “shop like a billionaire”, and unloads on them cheap junk, which “all but guarantees that shipments from Temu containing products made with forced labor are entering the United States on a regular basis“.

But consumers are also people, and some fraction of them are quite capable of writing fantastic software, and in fact, do so.

So what we need is some way to seize control. Some way to do what is right, despite the pressures of consumers or corporations.

Ah yes, dear reader, you have been slogging through all these paragraphs and now realize I have been leading you to this:

Then the solution is Open Source.

Indeed. Faults and all, FLOSS is the most successful movement I know where people are bringing us back to the commons: working and volunteering for the common good, unleashing a thousand creative variants on a theme, iterating in every direction imaginable. We have FLOSS being vital parts of everything from $30 Raspberry Pis to space missions. It is bringing education and communication to impoverished parts of the world. It lets everyone write and release software. And, unlike the SolarWinds and Twitter issues, it exposes both clever solutions and security flaws to the world.

If an authentication process in Windows got slower, we would all shrug and mutter “Microsoft” under our breath. Because, really, what else can we do? We have no agency with Windows.

If an authentication process in Linux gets slower, anybody that’s interested — anybody at all — can dive in and ask “why” and trace it down to root causes.

Some look at this and say “FLOSS is responsible for this mess.” I look at it and say, “this would be so much worse if it wasn’t FLOSS” — and experience backs me up on this.

FLOSS doesn’t prevent security issues itself.

What it does do is give capabilities to us all. The ability to investigate. Ability to fix. Yes, even the ability to break — and its cousin, the power to learn.

And, most rewarding, the ability to contribute.

04 April, 2024 10:07PM by John Goerzen

April 03, 2024

hackergotchi for Bits from Debian

Bits from Debian

Proxmox Platinum Sponsor of DebConf24


We are pleased to announce that Proxmox has committed to sponsor DebConf24 as a Platinum Sponsor.

Proxmox provides powerful and user-friendly open-source server software. Enterprises of all sizes and industries use Proxmox solutions to deploy efficient and simplified IT infrastructures, minimize total cost of ownership, and avoid vendor lock-in. Proxmox also offers commercial support, training services, and an extensive partner ecosystem to ensure business continuity for its customers. Proxmox Server Solutions GmbH was established in 2005 and is headquartered in Vienna, Austria.

Proxmox builds its product offerings on top of the Debian operating system.

With this commitment as Platinum Sponsor, Proxmox is contributing to make possible our annual conference, and directly supporting the progress of Debian and Free Software, helping to strengthen the community that continues to collaborate on Debian projects throughout the rest of the year.

Thank you very much, Proxmox, for your support of DebConf24!

Become a sponsor too!

DebConf24 will take place from 28th July to 4th August 2024 in Busan, South Korea, and will be preceded by DebCamp, from 21st to 27th July 2024.

DebConf24 is accepting sponsors! Interested companies and organizations may contact the DebConf team through sponsors@debconf.org, or visit the Become a DebConf Sponsor website.

03 April, 2024 11:17PM by Sahil Dhiman

hackergotchi for Guido Günther

Guido Günther

Free Software Activities March 2024

A short status update of what happened on my side last month. I spent quiet a bit of time reviewing new, code (thanks!) as well as maintenance to keep things going but we also have some improvements:








GNOME calls


If you want to support my work see donations.

03 April, 2024 10:12AM

hackergotchi for Joey Hess

Joey Hess

reflections on distrusting xz

Was the ssh backdoor the only goal that "Jia Tan" was pursuing with their multi-year operation against xz?

I doubt it, and if not, then every fix so far has been incomplete, because everything is still running code written by that entity.

If we assume that they had a multilayered plan, that their every action was calculated and malicious, then we have to think about the full threat surface of using xz. This quickly gets into nightmare scenarios of the "trusting trust" variety.

What if xz contains a hidden buffer overflow or other vulnerability, that can be exploited by the xz file it's decompressing? This would let the attacker target other packages, as needed.

Let's say they want to target gcc. Well, gcc contains a lot of documentation, which includes png images. So they spend a while getting accepted as a documentation contributor on that project, and get added to it a png file that is specially constructed, it has additional binary data appended that exploits the buffer overflow. And instructs xz to modify the source code that comes later when decompressing gcc.tar.xz.

More likely, they wouldn't bother with an actual trusting trust attack on gcc, which would be a lot of work to get right. One problem with the ssh backdoor is that well, not all servers on the internet run ssh. (Or systemd.) So webservers seem a likely target of this kind of second stage attack. Apache's docs include png files, nginx does not, but there's always scope to add improved documentation to a project.

When would such a vulnerability have been introduced? In February, "Jia Tan" wrote a new decoder for xz. This added 1000+ lines of new C code across several commits. So much code and in just the right place to insert something like this. And why take on such a significant project just two months before inserting the ssh backdoor? "Jia Tan" was already fully accepted as maintainer, and doing lots of other work, it doesn't seem to me that they needed to start this rewrite as part of their cover.

They were working closely with xz's author Lasse Collin in this, by indications exchanging patches offlist as they developed it. So Lasse Collin's commits in this time period are also worth scrutiny, because they could have been influenced by "Jia Tan". One that caught my eye comes immediately afterwards: "prepares the code for alternative C versions and inline assembly" Multiple versions and assembly mean even more places to hide such a security hole.

I stress that I have not found such a security hole, I'm only considering what the worst case possibilities are. I think we need to fully consider them in order to decide how to fully wrap up this mess.

Whether such stealthy security holes have been introduced into xz by "Jia Tan" or not, there are definitely indications that the ssh backdoor was not the end of what they had planned.

For one thing, the "test file" based system they introduced was extensible. They could have been planning to add more test files later, that backdoored xz in further ways.

And then there's the matter of the disabling of the Landlock sandbox. This was not necessary for the ssh backdoor, because the sandbox is only used by the xz command, not by liblzma. So why did they potentially tip their hand by adding that rogue "." that disables the sandbox?

A sandbox would not prevent the kind of attack I discuss above, where xz is just modifying code that it decompresses. Disabling the sandbox suggests that they were going to make xz run arbitrary code, that perhaps wrote to files it shouldn't be touching, to install a backdoor in the system.

Both deb and rpm use xz compression, and with the sandbox disabled, whether they link with liblzma or run the xz command, a backdoored xz can write to any file on the system while dpkg or rpm is running and noone is likely to notice, because that's the kind of thing a package manager does.

My impression is that all of this was well planned and they were in it for the long haul. They had no reason to stop with backdooring ssh, except for the risk of additional exposure. But they decided to take that risk, with the sandbox disabling. So they planned to do more, and every commit by "Jia Tan", and really every commit that they could have influenced needs to be distrusted.

This is why I've suggested to Debian that they revert to an earlier version of xz. That would be my advice to anyone distributing xz.

I do have a xz-unscathed fork which I've carefully constructed to avoid all "Jia Tan" involved commits. It feels good to not need to worry about dpkg and tar. I only plan to maintain this fork minimally, eg security fixes. Hopefully Lasse Collin will consider these possibilities and address them in his response to the attack.

03 April, 2024 08:54AM

Arnaud Rebillout

Firefox: Moving from the Debian package to the Flatpak app (long-term?)

First, thanks to Samuel Henrique for giving notice of recent Firefox CVEs in Debian testing/unstable.

At the time I didn't want to upgrade my system (Debian Sid) due to the ongoing t64 transition transition, so I decided I could install the Firefox Flatpak app instead, and why not stick to it long-term?

This blog post details all the steps, if ever others want to go the same road.

Flatpak Installation

Disclaimer: this section is hardly anything more than a copy/paste of the official documentation, and with time it will get outdated, so you'd better follow the official doc.

First thing first, let's install Flatpak:

$ sudo apt update
$ sudo apt install flatpak

Then the next step is to add the Flathub remote repository, from where we'll get our Flatpak applications:

$ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

And that's all there is to it! Now come the optional steps.

For GNOME and KDE users, you might want to install a plugin for the software manager specific to your desktop, so that it can support and manage Flatpak apps:

$ which -s gnome-software  && sudo apt install gnome-software-plugin-flatpak
$ which -s plasma-discover && sudo apt install plasma-discover-backend-flatpak

And here's an additional check you can do, as it's something that did bite me in the past: missing xdg-portal-* packages, that are required for Flatpak applications to communicate with the desktop environment. Just to be sure, you can check the output of apt search '^xdg-desktop-portal' to see what's available, and compare with the output of dpkg -l | grep xdg-desktop-portal.

As you can see, if you're a GNOME or KDE user, there's a portal backend for you, and it should be installed. For reference, this is what I have on my GNOME desktop at the moment:

$ dpkg -l | grep xdg-desktop-portal | awk '{print $2}'

Install the Firefox Flatpak app

This is trivial, but still, there's a question I've always asked myself: should I install applications system-wide (aka. flatpak --system, the default) or per-user (aka. flatpak --user)? Turns out, this questions is answered in the Flatpak documentation:

Flatpak commands are run system-wide by default. If you are installing applications for day-to-day usage, it is recommended to stick with this default behavior.

Armed with this new knowledge, let's install the Firefox app:

$ flatpak install flathub org.mozilla.firefox

And that's about it! We can give it a go already:

$ flatpak run org.mozilla.firefox

Data migration

At this point, running Firefox via Flatpak gives me an "empty" Firefox. That's not what I want, instead I want my usual Firefox, with a gazillion of tabs already opened, a few extensions, bookmarks and so on.

As it turns out, Mozilla provides a brief doc for data migration, and it's as simple as moving Firefox data directory around!

To clarify, we'll be copying data:

  • from ~/.mozilla/ -- where the Firefox Debian package stores its data
  • into ~/.var/app/org.mozilla.firefox/.mozilla/ -- where the Firefox Flatpak app stores its data

Make sure that all Firefox instances are closed, then proceed:

# BEWARE! Below I'm erasing data!
$ rm -fr ~/.var/app/org.mozilla.firefox/.mozilla/firefox/
$ cp -a ~/.mozilla/firefox/ ~/.var/app/org.mozilla.firefox/.mozilla/

To avoid confusing myself, it's also a good idea to rename the local data directory:

$ mv ~/.mozilla/firefox ~/.mozilla/firefox.old.$(date --iso-8601=date)

At this point, flatpak run org.mozilla.firefox takes me to my "usual" everyday Firefox, with all its tabs opened, pinned, bookmarked, etc.

More integration?

After following all the steps above, I must say that I'm 99% happy. So far, everything works as before, I didn't hit any issue, and I don't even notice that Firefox is running via Flatpak, it's completely transparent.

So where's the 1% of unhappiness? The « Run a Command » dialog from GNOME, the one that shows up via the keyboard shortcut <Alt+F2>. This is how I start my GUI applications, and I usually run two Firefox instances in parallel (one for work, one for personal), using the firefox -p <profile> command.

Given that I ran apt purge firefox before (to avoid confusing myself with two installations of Firefox), now the right (and only) way to start Firefox from a command-line is to type flatpak run org.mozilla.firefox -p <profile>. Typing that every time is way too cumbersome, so I need something quicker.

Seems like the most straightforward is to create a wrapper script:

$ cat /usr/local/bin/firefox 
exec flatpak run org.mozilla.firefox "$@"

And now I can just hit <Alt+F2> and type firefox -p <profile> to start Firefox with the profile I want, just as before. Neat!

Looking forward: system updates

I usually update my system manually every now and then, via the well-known pair of commands:

$ sudo apt update
$ sudo apt full-upgrade

The downside of introducing Flatpak, ie. introducing another package manager, is that I'll need to learn new commands to update the software that comes via this channel.

Fortunately, there's really not much to learn. From flatpak-update(1):

flatpak update [OPTION...] [REF...]

Updates applications and runtimes. [...] If no REF is given, everything is updated, as well as appstream info for all remotes.

Could it be that simple? Apparently yes, the Flatpak equivalent of the two apt commands above is just:

$ flatpak update

Going forward, my options are:

  1. Teach myself to run flatpak update additionally to apt update, manually, everytime I update my system.
  2. Go crazy: let something automatically update my Flatpak apps, in my back and without my consent.

I'm actually tempted to go for option 2 here, and I wonder if GNOME Software will do that for me, provided that I installed gnome-software-plugin-flatpak, and that I checked « Software Updates -> Automatic » in the Settings (which I did).

However, I didn't find any documentation regarding what this setting really does, so I can't say if it will only download updates, or if it will also install it. I'd be happy if it automatically installs new version of Flatpak apps, but at the same time I'd be very unhappy if it automatically upgrades my Debian system...

So we'll see. Enough for today, hope this blog post was useful!

03 April, 2024 12:00AM by Arnaud Rebillout

April 02, 2024

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

ulid 0.3.1 on CRAN: New Maintainer, Some Polish

Happy to share that ulid is now (back) on CRAN. It provides universally unique identifiers that are lexicographically sortable, which improves over the more well-known uuid generators.

ulid is a neat little package put together by Bob Rudis a few years ago. It had recently drifted off CRAN so I offered to brush it up and re-submit it. And as tooted earlier today, it took just over an hour to finish that (after the lead up work I had done, including prior email with CRAN in the loop, the repo transfer from Bob’s to my ulid repo plus of course a wee bit of actual maintenance; see below for more).

The NEWS entry follows.

Changes in version 0.3.1 (2024-04-02)

  • New Maintainer

  • Deleted several repository files no longer used or needed

  • Added .editorconfig, ChangeLog and cleanup

  • Converted NEWS.md to NEWS.Rd

  • Simplified R/ directory to one source file

  • Simplified src/ removing redundant Makevars

  • Added ulid() alias

  • Updated / edited roxygen and README.md documention

  • Removed vignette which was identical to README.md

  • Switched continuous integration to GitHub Actions

  • Placed upstream (header-only) library into src/ulid/

  • Renamed single interface file to src/wrapper

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

02 April, 2024 11:14PM

Sven Hoexter

PKIX: pathLen Constrain on Root Certificates

I recently came a cross a x509 P(rivate)KI Root Certificate which had a pathLen constrain set on the (self signed) Root Certificate. Since that is not commonly seen I looked a bit around to get a better understanding about how the pathLen basic constrain should be used.

Primary source is RFC 5280 section

The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension, if present, asserts the keyCertSign bit (Section In this case, it gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path

Since the Root is always self-issued it doesn't count towards the limit, and since it's the last certificate (or the first depending on how you count) in a chain, it's pretty much pointless to configure a pathLen constrain directly on a Root Certificate.

Another relevant resource are the Baseline Requirements of the CA/Browser Forum (currently v2.0.2). Section "Root CA Basic Constraints" describes it as NOT RECOMMENDED for a Root CA.

Last but not least there is the awesome x509 Limbo project which has a section for validating pathLen constrains. Since the RFC 5280 based assumption is that self signed certs do not count, they do not check a case with such a constrain on the Root itself, and what the implementations do about it. So the assumption right now is that they properly ignore it.

Summary: It's pointless to set the pathLen constrain on the Root Certificate, so just don't do it.

02 April, 2024 07:07PM

hackergotchi for Bits from Debian

Bits from Debian

Bits from the DPL

Dear Debianites

This morning I decided to just start writing Bits from DPL and send whatever I have by 18:00 local time. Here it is, barely proof read, along with all it's warts and grammar mistakes! It's slightly long and doesn't contain any critical information, so if you're not in the mood, don't feel compelled to read it!

Get ready for a new DPL!

Soon, the voting period will start to elect our next DPL, and my time as DPL will come to an end. Reading the questions posted to the new candidates on debian-vote, it takes quite a bit of restraint to not answer all of them myself, I think I can see how that aspect contributed to me being reeled in to running for DPL! In total I've done so 5 times (the first time I ran, Sam was elected!).

Good luck to both Andreas and Sruthi, our current DPL candidates! I've already started working on preparing handover, and there's multiple request from teams that have came in recently that will have to wait for the new term, so I hope they're both ready to hit the ground running!

Things that I wish could have gone better


Recently, I saw a t-shirt that read:

Adulthood is saying, 'But after this week things will slow down a bit' over and over until you die.

I can relate! With every task, crisis or deadline that appears, I think that once this is over, I'll have some more breathing space to get back to non-urgent, but important tasks. "Bits from the DPL" was something I really wanted to get right this last term, and clearly failed spectacularly. I have two long Bits from the DPL drafts that I never finished, I tend to have prioritised problems of the day over communication. With all the hindsight I have, I'm not sure which is better to prioritise, I do rate communication and transparency very highly and this is really the top thing that I wish I could've done better over the last four years.

On that note, thanks to people who provided me with some kind words when I've mentioned this to them before. They pointed out that there are many other ways to communicate and be in touch with the community, and they mentioned that they thought that I did a good job with that.

Since I'm still on communication, I think we can all learn to be more effective at it, since it's really so important for the project. Every time I publicly spoke about us spending more money, we got more donations. People out there really like to see how we invest funds in to Debian, instead of just making it heap up. DSA just spent a nice chunk on money on hardware, but we don't have very good visibility on it. It's one thing having it on a public line item in SPI's reporting, but it would be much more exciting if DSA could provide a write-up on all the cool hardware they're buying and what impact it would have on developers, and post it somewhere prominent like debian-devel-announce, Planet Debian or Bits from Debian (from the publicity team).

I don't want to single out DSA there, it's difficult and affects many other teams. The Salsa CI team also spent a lot of resources (time and money wise) to extend testing on AMD GPUs and other AMD hardware. It's fantastic and interesting work, and really more people within the project and in the outside world should know about it!

I'm not going to push my agendas to the next DPL, but I hope that they continue to encourage people to write about their work, and hopefully at some point we'll build enough excitement in doing so that it becomes a more normal part of our daily work.

Founding Debian as a standalone entity

This was my number one goal for the project this last term, which was a carried over item from my previous terms.

I'm tempted to write everything out here, including the problem statement and our current predicaments, what kind of ground work needs to happen, likely constitutional changes that need to happen, and the nature of the GR that would be needed to make such a thing happen, but if I start with that, I might not finish this mail.

In short, I 100% believe that this is still a very high ranking issue for Debian, and perhaps after my term I'd be in a better position to spend more time on this (hmm, is this an instance of "The grass is always better on the other side", or "Next week will go better until I die?"). Anyway, I'm willing to work with any future DPL on this, and perhaps it can in itself be a delegation tasked to properly explore all the options, and write up a report for the project that can lead to a GR.

Overall, I'd rather have us take another few years and do this properly, rather than rush into something that is again difficult to change afterwards. So while I very much wish this could've been achieved in the last term, I can't say that I have any regrets here either.

My terms in a nutshell

COVID-19 and Debian 11 era

My first term in 2020 started just as the COVID-19 pandemic became known to spread globally. It was a tough year for everyone, and Debian wasn't immune against its effects either. Many of our contributors got sick, some have lost loved ones (my father passed away in March 2020 just after I became DPL), some have lost their jobs (or other earners in their household have) and the effects of social distancing took a mental and even physical health toll on many. In Debian, we tend to do really well when we get together in person to solve problems, and when DebConf20 got cancelled in person, we understood that that was necessary, but it was still more bad news in a year we had too much of it already.

I can't remember if there was ever any kind of formal choice or discussion about this at any time, but the DebConf video team just kind of organically and spontaneously became the orga team for an online DebConf, and that lead to our first ever completely online DebConf. This was great on so many levels. We got to see each other's faces again, even though it was on screen. We had some teams talk to each other face to face for the first time in years, even though it was just on a Jitsi call. It had a lasting cultural change in Debian, some teams still have video meetings now, where they didn't do that before, and I think it's a good supplement to our other methods of communication.

We also had a few online Mini-DebConfs that was fun, but DebConf21 was also online, and by then we all developed an online conference fatigue, and while it was another good online event overall, it did start to feel a bit like a zombieconf and after that, we had some really nice events from the Brazillians, but no big global online community events again. In my opinion online MiniDebConfs can be a great way to develop our community and we should spend some further energy into this, but hey! This isn't a platform so let me back out of talking about the future as I see it...

Despite all the adversity that we faced together, the Debian 11 release ended up being quite good. It happened about a month or so later than what we ideally would've liked, but it was a solid release nonetheless. It turns out that for quite a few people, staying inside for a few months to focus on Debian bugs was quite productive, and Debian 11 ended up being a very polished release.

During this time period we also had to deal with a previous Debian Developer that was expelled for his poor behaviour in Debian, who continued to harass members of the Debian project and in other free software communities after his expulsion. This ended up being quite a lot of work since we had to take legal action to protect our community, and eventually also get the police involved. I'm not going to give him the satisfaction by spending too much time talking about him, but you can read our official statement regarding Daniel Pocock here: https://www.debian.org/News/2021/20211117

In late 2021 and early 2022 we also discussed our general resolution process, and had two consequent votes to address some issues that have affected past votes:

In my first term I addressed our delegations that were a bit behind, by the end of my last term all delegation requests are up to date. There's still some work to do, but I'm feeling good that I get to hand this over to the next DPL in a very decent state. Delegation updates can be very deceiving, sometimes a delegation is completely re-written and it was just 1 or 2 hours of work. Other times, a delegation updated can contain one line that has changed or a change in one team member that was the result of days worth of discussion and hashing out differences.

I also received quite a few requests either to host a service, or to pay a third-party directly for hosting. This was quite an admin nightmare, it either meant we had to manually do monthly reimbursements to someone, or have our TOs create accounts/agreements at the multiple providers that people use. So, after talking to a few people about this, we founded the DebianNet team (we could've admittedly chosen a better name, but that can happen later on) for providing hosting at two different hosting providers that we have agreement with so that people who host things under debian.net have an easy way to host it, and then at the same time Debian also has more control if a site maintainer goes MIA.

More info: https://wiki.debian.org/Teams/DebianNet

You might notice some Openstack mentioned there, we had some intention to set up a Debian cloud for hosting these things, that could also be used for other additional Debiany things like archive rebuilds, but these have so far fallen through. We still consider it a good idea and hopefully it will work out some other time (if you're a large company who can sponsor few racks and servers, please get in touch!)

DebConf22 and Debian 12 era

DebConf22 was the first time we returned to an in-person DebConf. It was a bit smaller than our usual DebConf - understandably so, considering that there were still COVID risks and people who were at high risk or who had family with high risk factors did the sensible thing and stayed home.

After watching many MiniDebConfs online, I also attended my first ever MiniDebConf in Hamburg. It still feels odd typing that, it feels like I should've been at one before, but my location makes attending them difficult (on a side-note, a few of us are working on bootstrapping a South African Debian community and hopefully we can pull off MiniDebConf in South Africa later this year).

While I was at the MiniDebConf, I gave a talk where I covered the evolution of firmware, from the simple e-proms that you'd find in old printers to the complicated firmware in modern GPUs that basically contain complete operating systems- complete with drivers for the device their running on. I also showed my shiny new laptop, and explained that it's impossible to install that laptop without non-free firmware (you'd get a black display on d-i or Debian live). Also that you couldn't even use an accessibility mode with audio since even that depends on non-free firmware these days.

Steve, from the image building team, has said for a while that we need to do a GR to vote for this, and after more discussion at DebConf, I kept nudging him to propose the GR, and we ended up voting in favour of it. I do believe that someone out there should be campaigning for more free firmware (unfortunately in Debian we just don't have the resources for this), but, I'm glad that we have the firmware included. In the end, the choice comes down to whether we still want Debian to be installable on mainstream bare-metal hardware.

At this point, I'd like to give a special thanks to the ftpmasters, image building team and the installer team who worked really hard to get the changes done that were needed in order to make this happen for Debian 12, and for being really proactive for remaining niggles that was solved by the time Debian 12.1 was released.

The included firmware contributed to Debian 12 being a huge success, but it wasn't the only factor. I had a list of personal peeves, and as the hard freeze hit, I lost hope that these would be fixed and made peace with the fact that Debian 12 would release with those bugs. I'm glad that lots of people proved me wrong and also proved that it's never to late to fix bugs, everything on my list got eliminated by the time final freeze hit, which was great! We usually aim to have a release ready about 2 years after the previous release, sometimes there are complications during a freeze and it can take a bit longer. But due to the excellent co-ordination of the release team and heavy lifting from many DDs, the Debian 12 release happened 21 months and 3 weeks after the Debian 11 release. I hope the work from the release team continues to pay off so that we can achieve their goals of having shorter and less painful freezes in the future!

Even though many things were going well, the ongoing usr-merge effort highlighted some social problems within our processes. I started typing out the whole history of usrmerge here, but it's going to be too long for the purpose of this mail. Important questions that did come out of this is, should core Debian packages be team maintained? And also about how far the CTTE should really be able to override a maintainer. We had lots of discussion about this at DebConf22, but didn't make much concrete progress. I think that at some point we'll probably have a GR about package maintenance. Also, thank you to Guillem who very patiently explained a few things to me (after probably having have to done so many times to others before already) and to Helmut who have done the same during the MiniDebConf in Hamburg. I think all the technical and social issues here are fixable, it will just take some time and patience and I have lots of confidence in everyone involved.

UsrMerge wiki page: https://wiki.debian.org/UsrMerge

DebConf 23 and Debian 13 era

DebConf23 took place in Kochi, India. At the end of my Bits from the DPL talk there, someone asked me what the most difficult thing I had to do was during my terms as DPL. I answered that nothing particular stood out, and even the most difficult tasks ended up being rewarding to work on. Little did I know that my most difficult period of being DPL was just about to follow. During the day trip, one of our contributors, Abraham Raji, passed away in a tragic accident. There's really not anything anyone could've done to predict or stop it, but it was devastating to many of us, especially the people closest to him. Quite a number of DebConf attendees went to his funeral, wearing the DebConf t-shirts he designed as a tribute. It still haunts me when I saw his mother scream "He was my everything! He was my everything!", this was by a large margin the hardest day I've ever had in Debian, and I really wasn't ok for even a few weeks after that and I think the hurt will be with many of us for some time to come. So, a plea again to everyone, please take care of yourself! There's probably more people that love you than you realise.

A special thanks to the DebConf23 team, who did a really good job despite all the uphills they faced (and there were many!).

As DPL, I think that planning for a DebConf is near to impossible, all you can do is show up and just jump into things. I planned to work with Enrico to finish up something that will hopefully save future DPLs some time, and that is a web-based DD certificate creator instead of having the DPL do so manually using LaTeX. It already mostly works, you can see the work so far by visiting https://nm.debian.org/person/ACCOUNTNAME/certificate/ and replacing ACCOUNTNAME with your Debian account name, and if you're a DD, you should see your certificate. It still needs a few minor changes and a DPL signature, but at this point I think that will be finished up when the new DPL start. Thanks to Enrico for working on this!

Since my first term, I've been trying to find ways to improve all our accounting/finance issues. Tracking what we spend on things, and getting an annual overview is hard, especially over 3 trusted organisations. The reimbursement process can also be really tedious, especially when you have to provide files in a certain order and combine them into a PDF. So, at DebConf22 we had a meeting along with the treasurer team and Stefano Rivera who said that it might be possible for him to work on a new system as part of his Freexian work. It worked out, and Freexian funded the development of the system since then, and after DebConf23 we handled the reimbursements for the conference via the new reimbursements site: https://reimbursements.debian.net/

It's still early days, but over time it should be linked to all our TOs and we'll use the same category codes across the board. So, overall, our reimbursement process becomes a lot simpler, and also we'll be able to get information like how much money we've spent on any category in any period. It will also help us to track how much money we have available or how much we spend on recurring costs. Right now that needs manual polling from our TOs. So I'm really glad that this is a big long-standing problem in the project that is being fixed.

For Debian 13, we're waving goodbye to the KFreeBSD and mipsel ports. But we're also gaining riscv64 and loongarch64 as release architectures! I have 3 different RISC-V based machines on my desk here that I haven't had much time to work with yet, you can expect some blog posts about them soon after my DPL term ends!

As Debian is a unix-like system, we're affected by the Year 2038 problem, where systems that uses 32 bit time in seconds since 1970 run out of available time and will wrap back to 1970 or have other undefined behaviour. A detailed wiki page explains how this works in Debian, and currently we're going through a rather large transition to make this possible.

I believe this is the right time for Debian to be addressing this, we're still a bit more than a year away for the Debian 13 release, and this provides enough time to test the implementation before 2038 rolls along.

Of course, big complicated transitions with dependency loops that causes chaos for everyone would still be too easy, so this past weekend (which is a holiday period in most of the west due to Easter weekend) has been filled with dealing with an upstream bug in xz-utils, where a backdoor was placed in this key piece of software. An Ars Technica covers it quite well, so I won't go into all the details here. I mention it because I want to give yet another special thanks to everyone involved in dealing with this on the Debian side. Everyone involved, from the ftpmasters to security team and others involved were super calm and professional and made quick, high quality decisions. This also lead to the archive being frozen on Saturday, this is the first time I've seen this happen since I've been a DD, but I'm sure next week will go better!

Looking forward

It's really been an honour for me to serve as DPL. It might well be my biggest achievement in my life. Previous DPLs range from prominent software engineers to game developers, or people who have done things like complete Iron Man, run other huge open source projects and are part of big consortiums. Ian Jackson even authored dpkg and is now working on the very interesting tag2upload service!

I'm a relative nobody, just someone who grew up as a poor kid in South Africa, who just really cares about Debian a lot. And, above all, I'm really thankful that I didn't do anything major to screw up Debian for good.

Not unlike learning how to use Debian, and also becoming a Debian Developer, I've learned a lot from this and it's been a really valuable growth experience for me.

I know I can't possible give all the thanks to everyone who deserves it, so here's a big big thanks to everyone who have worked so hard and who have put in many, many hours to making Debian better, I consider you all heroes!


02 April, 2024 05:00PM by Jonathan Carter

April 01, 2024

hackergotchi for Ben Hutchings

Ben Hutchings

FOSS activity in March 2024

01 April, 2024 02:51PM by Ben Hutchings

hackergotchi for Colin Watson

Colin Watson

Free software activity in March 2024

My Debian contributions this month were all sponsored by Freexian.

01 April, 2024 01:10PM by Colin Watson

Simon Josefsson

Towards reproducible minimal source code tarballs? On *-src.tar.gz

While the work to analyze the xz backdoor is in progress, several ideas have been suggested to improve the entire software supply chain ecosystem. Some of those ideas are good, some of the ideas are at best irrelevant and harmless, and some suggestions are plain bad. I’d like to attempt to formalize one idea (remains to be see in which category it belongs), which have been discussed before, but the context in which the idea can be appreciated have not been as clear as it is today.

  1. Reproducible source tarballs. The idea is that published source tarballs should be possible to reproduce independently somehow, and that this should be continuously tested and verified — preferrably as part of the upstream project continuous integration system (e.g., GitHub action or GitLab pipeline). While nominally this looks easy to achieve, there are some complex matters in this, for example: what timestamps to use for files in the tarball? I’ve brought up this aspect before.
  2. Minimal source tarballs without generated vendor files. Most GNU Autoconf/Automake-based tarballs pre-generated files which are important for bootstrapping on exotic systems that does not have the required dependencies. For the bootstrapping story to succeed, this approach is important to support. However it has become clear that this practice raise significant costs and risks. Most modern GNU/Linux distributions have all the required dependencies and actually prefers to re-build everything from source code. These pre-generated extra files introduce uncertainty to that process.

My strawman proposal to improve things is to define new tarball format *-src.tar.gz with at least the following properties:

  1. The tarball should allow users to build the project, which is the entire purpose of all this. This means that at least all source code for the project has to be included.
  2. The tarballs should be signed, for example with PGP or minisign.
  3. The tarball should be possible to reproduce bit-by-bit by a third party using upstream’s version controlled sources and a pointer to which revision was used (e.g., git tag or git commit).
  4. The tarball should not require an Internet connection to download things.
    • Corollary: every external dependency either has to be explicitly documented as such (e.g., gcc and GnuTLS), or included in the tarball.
    • Observation: This means including all *.po gettext translations which are normally downloaded when building from version controlled sources.
  5. The tarball should contain everything required to build the project from source using as much externally released versioned tooling as possible. This is the “minimal” property lacking today.
    • Corollary: This means including a vendored copy of OpenSSL or libz is not acceptable: link to them as external projects.
    • Open question: How about non-released external tooling such as gnulib or autoconf archive macros? This is a bit more delicate: most distributions either just package one current version of gnulib or autoconf archive, not previous versions. While this could change, and distributions could package the gnulib git repository (up to some current version) and the autoconf archive git repository — and packages were set up to extract the version they need (gnulib’s ./bootstrap already supports this via the –gnulib-refdir parameter), this is not normally in place.
    • Suggested Corollary: The tarball should contain content from git submodule’s such as gnulib and the necessary Autoconf archive M4 macros required by the project.
  6. Similar to how the GNU project specify the ./configure interface we need a documented interface for how to bootstrap the project. I suggest to use the already well established idiom of running ./bootstrap to set up the package to later be able to be built via ./configure. Of course, some projects are not using the autotool ./configure interface and will not follow this aspect either, but like most build systems that compete with autotools have instructions on how to build the project, they should document similar interfaces for bootstrapping the source tarball to allow building.

If tarballs that achieve the above goals were available from popular upstream projects, distributions could more easily use them instead of current tarballs that include pre-generated content. The advantage would be that the build process is not tainted by “unnecessary” files. We need to develop tools for maintainers to create these tarballs, similar to make dist that generate today’s foo-1.2.3.tar.gz files.

I think one common argument against this approach will be: Why bother with all that, and just use git-archive outputs? Or avoid the entire tarball approach and move directly towards version controlled check outs and referring to upstream releases as git URL and commit tag or id. My counter-argument is that this optimize for packagers’ benefits at the cost of upstream maintainers: most upstream maintainers do not want to store gettext *.po translations in their source code repository. A compromise between the needs of maintainers and packagers is useful, so this *-src.tar.gz tarball approach is the indirection we need to solve that.

What do you think?

01 April, 2024 10:28AM by simon

Arturo Borrero González

Kubecon and CloudNativeCon 2024 Europe summary

Kubecon EU 2024 Paris logo

This blog post shares my thoughts on attending Kubecon and CloudNativeCon 2024 Europe in Paris. It was my third time at this conference, and it felt bigger than last year’s in Amsterdam. Apparently it had an impact on public transport. I missed part of the opening keynote because of the extremely busy rush hour tram in Paris.

On Artificial Intelligence, Machine Learning and GPUs

Talks about AI, ML, and GPUs were everywhere this year. While it wasn’t my main interest, I did learn about GPU resource sharing and power usage on Kubernetes. There were also ideas about offering Models-as-a-Service, which could be cool for Wikimedia Toolforge in the future.

See also:

On security, policy and authentication

This was probably the main interest for me in the event, given Wikimedia Toolforge was about to migrate away from Pod Security Policy, and we were currently evaluating different alternatives.

In contrast to my previous attendances to Kubecon, where there were three policy agents with presence in the program schedule, Kyverno, Kubewarden and OpenPolicyAgent (OPA), this time only OPA had the most relevant sessions.

One surprising bit I got from one of the OPA sessions was that it could work to authorize linux PAM sessions. Could this be useful for Wikimedia Toolforge?

OPA talk

I attended several sessions related to authentication topics. I discovered the keycloak software, which looks very promising. I also attended an Oauth2 session which I had a hard time following, because I clearly missed some additional knowledge about how Oauth2 works internally.

I also attended a couple of sessions that ended up being a vendor sales talk.

See also:

On container image builds, harbor registry, etc

This topic was also of interest to me because, again, it is a core part of Wikimedia Toolforge.

I attended a couple of sessions regarding container image builds, including topics like general best practices, image minimization, and buildpacks. I learned about kpack, which at first sight felt like a nice simplification of how the Toolforge build service was implemented.

I also attended a session by the Harbor project maintainers where they shared some valuable information on things happening soon or in the future , for example:

  • new harbor command line interface coming soon. Only the first iteration though.
  • harbor operator, to install and manage harbor. Looking for new maintainers, otherwise going to be archived.
  • the project is now experimenting with adding support to hosting more artifacts: maven, NPM, pypi. I wonder if they will consider hosting Debian .deb packages.

On networking

I attended a couple of sessions regarding networking.

One session in particular I paid special attention to, ragarding on network policies. They discussed new semantics being added to the Kubernetes API.

The different layers of abstractions being added to the API, the different hook points, and override layers clearly resembled (to me at least) the network packet filtering stack of the linux kernel (netfilter), but without the 20 (plus) years of experience building the right semantics and user interfaces.

Network talk

I very recently missed some semantics for limiting the number of open connections per namespace, see Phabricator T356164: [toolforge] several tools get periods of connection refused (104) when connecting to wikis This functionality should be available in the lower level tools, I mean Netfilter. I may submit a proposal upstream at some point, so they consider adding this to the Kubernetes API.

Final notes

In general, I believe I learned many things, and perhaps even more importantly I re-learned some stuff I had forgotten because of lack of daily exposure. I’m really happy that the cloud native way of thinking was reinforced in me, which I still need because most of my muscle memory to approach systems architecture and engineering is from the old pre-cloud days. That being said, I felt less engaged with the content of the conference schedule compared to last year. I don’t know if the schedule itself was less interesting, or that I’m losing interest?

Finally, not an official track in the conference, but we met a bunch of folks from Wikimedia Deutschland. We had a really nice time talking about how wikibase.cloud uses Kubernetes, whether they could run in Wikimedia Cloud Services, and why structured data is so nice.

Group photo

01 April, 2024 09:00AM

March 31, 2024

hackergotchi for Junichi Uekawa

Junichi Uekawa

Learning about xz and what is happening is fascinating.

Learning about xz and what is happening is fascinating. The scope of potential exploit is very large. The Open source software space is filled with many unmaintained and unreviewed software.

31 March, 2024 10:02PM by Junichi Uekawa

Russell Coker

March 30, 2024

hackergotchi for Steinar H. Gunderson

Steinar H. Gunderson

xz backdooring

Andres Freund found that xz-utils is backdoored, but could not (despite the otherwise excellent analysis) get quite to the bottom of what the payload actually does.

What you would hope for to be posted by others: Further analysis of the payload.

What actually gets posted by others: “systemd is bad.”

Update: Good preliminary analysis.

30 March, 2024 10:39AM

March 28, 2024

hackergotchi for Joey Hess

Joey Hess

the vulture in the coal mine

Turns out that VPS provider Vultr's terms of service were quietly changed some time ago to give them a "perpetual, irrevocable" license to use content hosted there in any way, including modifying it and commercializing it "for purposes of providing the Services to you."

This is very similar to changes that Github made to their TOS in 2017. Since then, Github has been rebranded as "The world’s leading AI-powered developer platform". The language in their TOS now clearly lets them use content stored in Github for training AI. (Probably this is their second line of defense if the current attempt to legitimise copyright laundering via generative AI fails.)

Vultr is currently in damage control mode, accusing their concerned customers of spreading "conspiracy theories" (-- founder David Aninowsky) and updating the TOS to remove some of the problem language. Although it still allows them to "make derivative works", so could still allow their AI division to scrape VPS images for training data.

Vultr claims this was the legalese version of technical debt, that it only ever applied to posts in a forum (not supported by the actual TOS language) and basically that they and their lawyers are incompetant but not malicious.

Maybe they are indeed incompetant. But even if I give them the benefit of the doubt, I expect that many other VPS providers, especially ones targeting non-corporate customers, are watching this closely. If Vultr is not significantly harmed by customers jumping ship, if the latest TOS change is accepted as good enough, then other VPS providers will know that they can try this TOS trick too. If Vultr's AI division does well, others will wonder to what extent it is due to having all this juicy training data.

For small self-hosters, this seems like a good time to make sure you're using a VPS provider you can actually trust to not be eyeing your disk image and salivating at the thought of stripmining it for decades of emails. Probably also worth thinking about moving to bare metal hardware, perhaps hosted at home.

I wonder if this will finally make it worthwhile to mess around with VPS TPMs?

28 March, 2024 10:42PM

March 27, 2024

hackergotchi for Steinar H. Gunderson

Steinar H. Gunderson

git grudge

Small teaser:

Probably won't show up in aggregators (try this link instead).

27 March, 2024 05:56PM

March 25, 2024

hackergotchi for Jonathan Dowland

Jonathan Dowland

a bug a day

I recently became a maintainer of/committer to IkiWiki, the software that powers my site. I also took over maintenance of the Debian package. Last week I cut a new upstream point release, 3.20200202.4, and a corresponding Debian package upload, consisting only of a handful of low-hanging-fruit patches from other people, largely to exercise both processes.

I've been discussing IkiWiki's maintenance situation with some other users for a couple of years now. I've also weighed up the pros and cons of moving to a different static-site-generator (a term that describes what IkiWiki is, but was actually coined more recently). It turns out IkiWiki is exceptionally flexible and powerful: I estimate the cost of moving to something modern(er) and fashionable such as Jekyll, Hugo or Hakyll as unreasonably high, in part because they are surprisingly rigid and inflexible in some key places.

Like most mature software, IkiWiki has a bug backlog. Over the past couple of weeks, as a sort-of "palate cleanser" around work pieces, I've tried to triage one IkiWiki bug per day: either upstream or in the Debian Bug Tracker. This is a really lightweight task: it can be as simple as "find a bug reported in Debian, copy it upstream, tag it upstream, mark it forwarded; perhaps taking 5-10 minutes.

Often I'll stumble across something that has already been fixed but not recorded as such as I go.

Despite this minimal level of work, I'm quite satisfied with the cumulative progress. It's notable to me how much my perspective has shifted by becoming a maintainer: I'm considering everything through a different lens to that of being just one user.

Eventually I will put some time aside to scratch some of my own itches (html5 by default; support dark mode; duckduckgo plugin; use the details tag...) but for now this minimal exercise is of broader use.

25 March, 2024 04:58PM

March 24, 2024

hackergotchi for Marco d'Itri

Marco d'Itri

CISPE's call for new regulations on VMware

A few days ago CISPE, a trade association of European cloud providers, published a press release complaining about the new VMware licensing scheme and asking for regulators and legislators to intervene.

But VMware does not have a monopoly on virtualization software: I think that asking regulators to interfere is unnecessary and unwise, unless, of course, they wish to question the entire foundations of copyright. Which, on the other hand, could be an intriguing position that I would support...

I believe that over-reliance on a single supplier is a typical enterprise risk: in the past decade some companies have invested in developing their own virtualization infrastructure using free software, while others have decided to rely entirely on a single proprietary software vendor.

My only big concern is that many public sector organizations will continue to use VMware and pay the huge fees designed by Broadcom to extract the maximum amount of money from their customers. However, it is ultimately the citizens who pay these bills, and blaming the evil US corporation is a great way to avoid taking responsibility for these choices.

"Several CISPE members have stated that without the ability to license and use VMware products they will quickly go bankrupt and out of business."

Insert here the Jeremy Clarkson "Oh no! Anyway..." meme.

24 March, 2024 12:52PM

Jacob Adams

Regular Reboots

Uptime is often considered a measure of system reliability, an indication that the running software is stable and can be counted on.

However, this hides the insidious build-up of state throughout the system as it runs, the slow drift from the expected to the strange.

As Nolan Lawson highlights in an excellent post entitled Programmers are bad at managing state, state is the most challenging part of programming. It’s why “did you try turning it off and on again” is a classic tech support response to any problem.

In addition to the problem of state, installing regular updates periodically requires a reboot, even if the rest of the process is automated through a tool like unattended-upgrades.

For my personal homelab, I manage a handful of different machines running various services.

I used to just schedule a day to update and reboot all of them, but that got very tedious very quickly.

I then moved the reboot to a cronjob, and then recently to a systemd timer and service.

I figure that laying out my path to better management of this might help others, and will almost certainly lead to someone telling me a better way to do this.

UPDATE: Turns out there’s another option for better systemd cron integration. See systemd-cron below.

Stage One: Reboot Cron

The first, and easiest approach, is a simple cron job. Just adding the following line to /var/spool/cron/crontabs/root1 is enough to get your machine to reboot once a month2 on the 6th at 8:00 AM3:

0 8 6 * * reboot

I had this configured for many years and it works well. But you have no indication as to whether it succeeds except for checking your uptime regularly yourself.

Stage Two: Reboot systemd Timer

The next evolution of this approach for me was to use a systemd timer. I created a regular-reboot.timer with the following contents:

Description=Reboot on a Regular Basis



This timer will trigger the regular-reboot.service systemd unit when the system reaches one month of uptime.

I’ve seen some guides to creating timer units recommend adding a Wants=regular-reboot.service to the [Unit] section, but this has the consequence of running that service every time it starts the timer. In this case that will just reboot your system on startup which is not what you want.

Care needs to be taken to use the OnBootSec directive instead of OnCalendar or any of the other time specifications, as your system could reboot, discover its still within the expected window and reboot again. With OnBootSec your system will not have that problem. Technically, this same problem could have occurred with the cronjob approach, but in practice it never did, as the systems took long enough to come back up that they were no longer within the expected window for the job.

I then added the regular-reboot.service:

Description=Reboot on a Regular Basis

ExecStart=shutdown -r 02:45

You’ll note that this service is actually scheduling a specific reboot time via the shutdown command instead of just immediately rebooting. This is a bit of a hack needed because I can’t control when the timer runs exactly when using OnBootSec. This way different systems have different reboot times so that everything doesn’t just reboot and fail all at once. Were something to fail to come back up I would have some time to fix it, as each machine has a few hours between scheduled reboots.

One you have both files in place, you’ll simply need to reload configuration and then enable and start the timer unit:

systemctl daemon-reload
systemctl enable --now regular-reboot.timer

You can then check when it will fire next:

# systemctl status regular-reboot.timer
● regular-reboot.timer - Reboot on a Regular Basis
     Loaded: loaded (/etc/systemd/system/regular-reboot.timer; enabled; preset: enabled)
     Active: active (waiting) since Wed 2024-03-13 01:54:52 EDT; 1 week 4 days ago
    Trigger: Fri 2024-04-12 12:24:42 EDT; 2 weeks 4 days left
   Triggers: ● regular-reboot.service

Mar 13 01:54:52 dorfl systemd[1]: Started regular-reboot.timer - Reboot on a Regular Basis.

Sidenote: Replacing all Cron Jobs with systemd Timers

More generally, I’ve now replaced all cronjobs on my personal systems with systemd timer units, mostly because I can now actually track failures via prometheus-node-exporter. There are plenty of ways to hack in cron support to the node exporter, but just moving to systemd units provides both support for tracking failure and logging, both of which make system administration much easier when things inevitably go wrong.


An alternative to converting everything by hand, if you happen to have a lot of cronjobs is systemd-cron. It will make each crontab and /etc/cron.* directory into automatic service and timer units.

Thanks to Alexandre Detiste for letting me know about this project. I have few enough cron jobs that I’ve already converted, but for anyone looking at a large number of jobs to convert you’ll want to check it out!

Stage Three: Monitor that it’s working

The final step here is confirm that these units actually work, beyond just firing regularly.

I now have the following rule in my prometheus-alertmanager rules:

  - alert: UptimeTooHigh
    expr: (time() - node_boot_time_seconds{job="node"}) / 86400 > 35
      summary: "Instance  Has Been Up Too Long!"
      description: "Instance  Has Been Up Too Long!"

This will trigger an alert anytime that I have a machine up for more than 35 days. This actually helped me track down one machine that I had forgotten to set up this new unit on4.

Not everything needs to scale

Is It Worth The Time

One of the most common fallacies programmers fall into is that we will jump to automating a solution before we stop and figure out how much time it would even save.

In taking a slow improvement route to solve this problem for myself, I’ve managed not to invest too much time5 in worrying about this but also achieved a meaningful improvement beyond my first approach of doing it all by hand.

  1. You could also add a line to /etc/crontab or drop a script into /etc/cron.monthly depending on your system. 

  2. Why once a month? Mostly to avoid regular disruptions, but still be reasonably timely on updates. 

  3. If you’re looking to understand the cron time format I recommend crontab guru

  4. In the long term I really should set up something like ansible to automatically push fleetwide changes like this but with fewer machines than fingers this seems like overkill. 

  5. Of course by now writing about it, I’ve probably doubled the amount of time I’ve spent thinking about this topic but oh well… 

24 March, 2024 12:00AM

March 23, 2024

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

littler 0.3.20 on CRAN: Moar Features!

max-heap image

The twentyfirst release of littler as a CRAN package landed on CRAN just now, following in the now eighteen year history (!!) as a package started by Jeff in 2006, and joined by me a few weeks later.

littler is the first command-line interface for R as it predates Rscript. It allows for piping as well for shebang scripting via #!, uses command-line arguments more consistently and still starts faster. It also always loaded the methods package which Rscript only began to do in recent years.

littler lives on Linux and Unix, has its difficulties on macOS due to yet-another-braindeadedness there (who ever thought case-insensitive filesystems as a default were a good idea?) and simply does not exist on Windows (yet – the build system could be extended – see RInside for an existence proof, and volunteers are welcome!). See the FAQ vignette on how to add it to your PATH. A few examples are highlighted at the Github repo:, as well as in the examples vignette.

This release contains another fair number of small changes and improvements to some of the scripts I use daily to build or test packages, adds a new front-end ciw.r for the recently-released ciw package offering a ‘CRAN Incoming Watcher’, a new helper installDeps2.r (extending installDeps.r), a new doi-to-bib converter, allows a different temporary directory setup I find helpful, deals with one corner deployment use, and more.

The full change description follows.

Changes in littler version 0.3.20 (2024-03-23)

  • Changes in examples scripts

    • New (dependency-free) helper installDeps2.r to install dependencies

    • Scripts rcc.r, tt.r, tttf.r, tttlr.r use env argument -S to set -t to r

    • tt.r can now fill in inst/tinytest if it is present

    • New script ciw.r wrapping new package ciw

    • tttf.t can now use devtools and its loadall

    • New script doi2bib.r to call the DOI converter REST service (following a skeet by Richard McElreath)

  • Changes in package

    • The CI setup uses checkout@v4 and the r-ci-setup action

    • The Suggests: is a little tighter as we do not list all packages optionally used in the the examples (as R does not check for it either)

    • The package load messag can account for the rare build of R under different architecture (Berwin Turlach in #117 closing #116)

    • In non-vanilla mode, the temporary directory initialization in re-run allowing for a non-standard temp dir via config settings

My CRANberries service provides a comparison to the previous release. Full details for the littler release are provided as usual at the ChangeLog page, and also on the package docs website. The code is available via the GitHub repo, from tarballs and now of course also from its CRAN page and via install.packages("littler"). Binary packages are available directly in Debian as well as (in a day or two) Ubuntu binaries at CRAN thanks to the tireless Michael Rutter.

Comments and suggestions are welcome at the GitHub repo.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

23 March, 2024 10:06PM

hackergotchi for Bits from Debian

Bits from Debian

New Debian Developers and Maintainers (January and February 2024)

The following contributors got their Debian Developer accounts in the last two months:

  • Carles Pina i Estany (cpina)
  • Dave Hibberd (hibby)
  • Soren Stoutner (soren)
  • Daniel Gröber (dxld)
  • Jeremy Sowden (azazel)
  • Ricardo Ribalda Delgado (ribalda)

The following contributors were added as Debian Maintainers in the last two months:

  • Joachim Bauch
  • Ananthu C V
  • Francesco Ballarin
  • Yogeswaran Umasankar
  • Kienan Stewart


23 March, 2024 03:00PM by Jean-Pierre Giraud

March 21, 2024

Ian Jackson

How to use Rust on Debian (and Ubuntu, etc.)

tl;dr: Don’t just apt install rustc cargo. Either do that and make sure to use only Rust libraries from your distro (with the tiresome config runes below); or, just use rustup.

Don’t do the obvious thing; it’s never what you want

Debian ships a Rust compiler, and a large number of Rust libraries.

But if you just do things the obvious “default” way, with apt install rustc cargo, you will end up using Debian’s compiler but upstream libraries, directly and uncurated from crates.io.

This is not what you want. There are about two reasonable things to do, depending on your preferences.

Q. Download and run whatever code from the internet?

The key question is this:

Are you comfortable downloading code, directly from hundreds of upstream Rust package maintainers, and running it ?

That’s what cargo does. It’s one of the main things it’s for. Debian’s cargo behaves, in this respect, just like upstream’s. Let me say that again:

Debian’s cargo promiscuously downloads code from crates.io just like upstream cargo.

So if you use Debian’s cargo in the most obvious way, you are still downloading and running all those random libraries. The only thing you’re avoiding downloading is the Rust compiler itself, which is precisely the part that is most carefully maintained, and of least concern.

Debian’s cargo can even download from crates.io when you’re building official Debian source packages written in Rust: if you run dpkg-buildpackage, the downloading is suppressed; but a plain cargo build will try to obtain and use dependencies from the upstream ecosystem. (“Happily”, if you do this, it’s quite likely to bail out early due to version mismatches, before actually downloading anything.)

Option 1: WTF, no I don’t want curl|bash

OK, but then you must limit yourself to libraries available within Debian. Each Debian release provides a curated set. It may or may not be sufficient for your needs. Many capable programs can be written using the packages in Debian.

But any upstream Rust project that you encounter is likely to be a pain to get working, unless their maintainers specifically intend to support this. (This is fairly rare, and the Rust tooling doesn’t make it easy.)

To go with this plan, apt install rustc cargo and put this in your configuration, in $HOME/.cargo/config.toml:

directory = "/usr/share/cargo/registry"
replace-with = "debian-packages"

This causes cargo to look in /usr/share for dependencies, rather than downloading them from crates.io. You must then install the librust-FOO-dev packages for each of your dependencies, with apt.

This will allow you to write your own program in Rust, and build it using cargo build.

Option 2: Biting the curl|bash bullet

If you want to build software that isn’t specifically targeted at Debian’s Rust you will probably need to use packages from crates.io, not from Debian.

If you’re doing to do that, there is little point not using rustup to get the latest compiler. rustup’s install rune is alarming, but cargo will be doing exactly the same kind of thing, only worse (because it trusts many more people) and more hidden.

So in this case: do run the curl|bash install rune.

Hopefully the Rust project you are trying to build have shipped a Cargo.lock; that contains hashes of all the dependencies that they last used and tested. If you run cargo build --locked, cargo will only use those versions, which are hopefully OK.

And you can run cargo audit to see if there are any reported vulnerabilities or problems. But you’ll have to bootstrap this with cargo install --locked cargo-audit; cargo-audit is from the RUSTSEC folks who do care about these kind of things, so hopefully running their code (and their dependencies) is fine. Note the --locked which is needed because cargo’s default behaviour is wrong.

Privilege separation

This approach is rather alarming. For my personal use, I wrote a privsep tool which allows me to run all this upstream Rust code as a separate user.

That tool is nailing-cargo. It’s not particularly well productised, or tested, but it does work for at least one person besides me. You may wish to try it out, or consider alternative arrangements. Bug reports and patches welcome.

OMG what a mess

Indeed. There are large number of technical and social factors at play.

cargo itself is deeply troubling, both in principle, and in detail. I often find myself severely disappointed with its maintainers’ decisions. In mitigation, much of the wider Rust upstream community does takes this kind of thing very seriously, and often makes good choices. RUSTSEC is one of the results.

Debian’s technical arrangements for Rust packaging are quite dysfunctional, too: IMO the scheme is based on fundamentally wrong design principles. But, the Debian Rust packaging team is dynamic, constantly working the update treadmills; and the team is generally welcoming and helpful.

Sadly last time I explored the possibility, the Debian Rust Team didn’t have the appetite for more fundamental changes to the workflow (including, for example, changes to dependency version handling). Significant improvements to upstream cargo’s approach seem unlikely, too; we can only hope that eventually someone might manage to supplant it.

edited 2024-03-21 21:49 to add a cut tag

comment count unavailable comments

21 March, 2024 09:47PM

March 20, 2024

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

ciw 0.0.2 on CRAN: Updates

A first revision of the still only one-week old (at CRAN) package ciw has been released to CRAN! It provides is a single (efficient) function incoming() (now along with an alias ciw()) which summarises the state of the incoming directories at CRAN. I happen to like having these things at my (shell) fingertips, so it goes along with (still draft) wrapper ciw.r that will be part of the next littler release.

For example, when I do this right now as I type this, I see (typically less than one second later)

edd@rob:~$ ciw.r 
    Folder                     Name                Time   Size         Age
    <char>                   <char>              <POSc> <char>  <difftime>
1: pretest instantiate_0.2.2.tar.gz 2024-03-20 13:29:00    17K  0.07 hours
2: recheck   tinytable_0.2.0.tar.gz 2024-03-20 12:50:00   565K  0.72 hours
3: pending      Matrix_1.7-0.tar.gz 2024-03-20 12:05:00   2.3M  1.47 hours
4: recheck      survey_4.4-2.tar.gz 2024-03-20 02:02:00   2.2M 11.52 hours
5: waiting   equateIRT_2.4.0.tar.gz 2024-03-19 17:00:00   895K 20.55 hours
6: pending   ravetools_0.1.5.tar.gz 2024-03-19 12:06:00   1.0M 25.45 hours
7: waiting     glmmTMB_1.1.9.tar.gz 2024-03-18 16:04:00   4.2M 45.48 hours

See ciw.r --help or ciw.r --usage for more. Alternatively, in your R session, you can call ciw::incoming() (or now ciw::ciw()) for the same result (and/or load the package first).

This release adds some packaging touches, brings the new alias ciw() as well as a state variable with all (known) folder names and some internal improvements for dealing with error conditions. The NEWS entry follows.

Changes in version 0.0.2 (2024-03-20)

  • The package README and DESCRIPTION have been expanded

  • An alias ciw can now be used for incoming

  • Network error handling is now more robist

  • A state variable known_folders lists all CRAN folders below incoming

Courtesy of my CRANberries, there is also a diffstat report for this release.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

20 March, 2024 01:18PM

hackergotchi for Jonathan Dowland

Jonathan Dowland

aerc email client

my aerc

I started looking at aerc, a new Terminal mail client, in around 2019. At that time it was promising, but ultimately not ready yet for me, so I put it away and went back to neomutt which I have been using (in one form or another)   all century.

These days, I use neomutt as an IMAP client which is perhaps what it's worst at: prior to that, and in common with most users (I think), I used it to read local mail, either fetched via offlineimap or directly on my mail server. I switched to using it as a (slow, blocking) IMAP client because I got sick of maintaining offlineimap (or mbsync), and I started to use neomutt to   read my work mail, which was too large (and rate limited) for local syncing.

This year I noticed that aerc had a new maintainer who was presenting about it at FOSDEM, so I thought I'd take another look. It's come a long way: far enough to actually displace neomutt for my day-to-day mail use. In particular, it's a much better IMAP client.

I still reach for neomutt for some tasks, but I'm now using aerc for most things.

aerc is available in Debian, but I recommending building from upstream source at the moment as the project is quite fast-moving.

20 March, 2024 10:38AM

Iustin Pop

Corydalis 2024.12.0 released

I’ve been working for the past few weeks on Corydalis, and was in no hurry to make a release, but last evening I found the explanation for a really, really, really annoying issue: unintended “zooming� on touch interfaces in the image viewer. Or more precisely, I found this post from 2015 (9 years ago!): https://webkit.org/blog/5610/more-responsive-tapping-on-ios/ and I finally understood things. And decided this was the best choice for cutting a new release.

Of course, the release contains more things, see the changelog on the release page: https://github.com/iustin/corydalis/releases/tag/v2024.12.0. And of course, it’s up on http://demo.corydalis.io.

And after putting out the new release, I saw that release tagging is in the pre-built binaries still broken, and found the reason at https://github.com/actions/checkout/issues/290. Will fix for the next release… The stream of bugs never ends 😉

20 March, 2024 08:37AM

March 19, 2024


Fuhrerbunker, FSFE-Buro Dusseldorf office closure, Berlin retreat, insurance expenses

The story of Hitler's regime ending in a bunker in Berlin is well known. In the German language, the bunker is known as the Fuhrerbunker.

The bunker was constructed in two stages. It was built underground. The roof of the deeper bunker was eight meters below ground and three meters thick reinforced concrete.

Most of the bunker was demolished in the late 1980s around the time the Berlin Wall came down.

Hitler spent very little time in Berlin during the war. As the Allies closed in from the west and the Soviets closed in from the east, Hitler returned to Berlin and took up residence in the bunker in January 1945.

On 1 April 1945, Hitler moved the functions of Government from the Reich Chancellery, which was above ground, down into the bunker proper. This was the beginning of the final chapter for the Nazi regime.

At the beginning of April 2016, Matthias Kirschner and Jonas Oberg closed down the FSFE-Buro (office) in Dusseldorf. They rented a van to pack up all the contents of the Dusseldorf office and retreat back to Berlin. They had booked two nights hotel accommodation in Dusseldorf so they could wind up the office smoothly.

Things didn't go exactly to plan. The FSFE Fellows in Dusseldorf heard about this plan and scheduled an Extraordinary General Meeting (EGM) to take place on the evening of Monday, 4 April 2016.

Kirschner and Oberg canceled their accommodation in the hotel and hotfooted it back to Berlin in a very hasty retreat.

There is one staff member who had been employed at the FSFE-Buro Dusseldorf for many years, Rainer Kersten. Working for an organization associated with the name of the real FSF and Dr Richard Stallman must have given him great pride. But Matthias Kirschner is not Dr Richard Stallman. German employees have certain expectations about the security of their employment and they can't simply be discarded on a whim. Kirschner, being a German too, would surely realize that. An FSFE web page snapshot from 22 March 2016 includes Rainer Kersten's name. His name appears in the next snapshot on 11 April. The subsequent snapshot, on 31 July 2016, Rainer Kersten is gone.

The exact day that Kirschner shuttered the FSFE-Buro Dusseldorf, 4 April, is the anniversary of the day the Soviet KGB finally disposed of the remains of Hitler and Goebels. On 4 April 1970, KGB agents exhumed the coffins, removed the bones and whatever human remains were left, incinerated them and then disposed of the ashes in a river.

When the FSFE council canceled the elections in 2018, the last Fellowship representative made a point of telling them they were behaving like cowards.

Subject: Re: [GA] Fwd: Re: Minutes from our extraordinary assembly
Date: Wed, 30 May 2018 20:41:44 +0100
From: Fellowship Representative elected by Community
To: ga@lists.fsfe.org

On 30/05/18 20:36, Heiki Lõhmus wrote:
> Dear [Representative of the Community],
>> In that case, can you please send the information to the GA list so all
>> members are aware of it?
> I can not as no record of individual votes exists.

Heiki, if you can't remember how people voted on such a toxic matter
just 4 days ago then are you competent to remain in council?

Or are you just being a coward?

Looking at the minutes of the annual general meeting in 2021, we see a mysterious discussion about "insurances of the association". It is not clear what risks they are insuring against but it smells like a situation where they know they've been pissing people off for years and now they have become preoccupied with insurance and security in much the same way that Hitler became preoccupied with his reinforced concrete bunker.

They pissed off the Dusseldorf community and ran away from an Extraordinary General Meeting on 4 April 2016.

They totally removed elections from the constitution in 2018. They are afraid of who the community might vote for next.

When female employees Susanne Eiswirt and Galia Mancheva asked about their workplace rights, Kirschner became afraid and sacked them all.


19 March, 2024 10:30PM

hackergotchi for Daniel Pocock

Daniel Pocock

How much does Google pay to destroy a man and his family?

I've started creating this page to keep track of the kill money that I feel Google is laundering through the bank accounts of Software in the Public Interest, Inc and the Debian "Project". This page may be updated from time to time as more of this dirty money is uncovered.

On 20 March 2013, a report in the French senate expressed great concern that European countries are becoming digital colonies under the reign of foreign companies like Google.

Organizations like Free Software Foundation Europe e.V. (FSFE) are being used by Google for the purpose of astroturfing in Europe.

In January 2017, I nominated myself as a candidate in the FSFE elections.

The FSFE voting was conducted using the Cornell University CIVS online voting service. Voting finished on 24 April 2017. That is the anniversary of the Easter Rising when Irish citizens rose up against colonisation. Coincidentally, I was the first Irish citizen elected into this role in the German FSFE.

FSFE typically obtains up to twenty percent of of their budget from Google.

FSFE budget 2022, gold donors, google

I made a series of discoveries about corruption in the FSFE.

I completely resigned from the organization in September 2018.

After my resignation, the Googlists have attacked my family constantly with a campaign of online harassment.

Here I look at the money Googlists paid for these attacks and I contrast that against money that these Googlists have refused to pay in other situations.

Unexplained death of Adrian von Bidder

These details are extracted from the more comprehensive blog about the mysterious death.

von Bidder had an official role as secretary of the Debian.ch "Verein" incorporated under Swiss law.

Andreas Tille, who is a candidate in the 2024 Debian election did not want any Debian money to be used towards the cost of a wreath or flowers.

Subject: Re: Death of Adrian von Bidder
Date: Thu, 21 Apr 2011 08:56:04 +0200
From: Andreas Tille <andreas@an3as.eu>
To: debian-private@lists.debian.org

... [snip] ...

The donators of the Debian project intend to spend money for the
development of the Debian project.  If we spend Debian money for a
wreath (or any form of replacement donation) this is not related to the
development of Debian.  It is rather *us* *people* who say goodby to
a friend.  So the money should not come from project funds but rather
from single developers.

Saying this I would like to vote against spending Debian money but
rather doing a separate collection.  I could live with some kind of "de
facto" collection like this:  I will ask for Debian money for DebConf.
In case Debian project money is really spended for Adrian's funeral I'd
simply ask for 10Euro less than I would have done otherwise.

... [snip] ...

In the end, individual donors contributed approximately CHF 682.78 to AMICA Schweiz, a charity supported by von Bidder's family. Not one Swiss Franc was contributed from Debian itself.

DebConf13 refusal to pay for dish washing

Local organizers of the conference estimated we would need to budget CHF 5,000 for casual workers to do dishwashing each evening over 2 weeks.

Debian oligarchs pushed for volunteers to do the work so they could save Google's money for other projects. Like paying the lawyers.

DebConf13 huge surplus in Swiss bank account

They couldn't pay for a wreath for Adrian von Bidder, despite the fact he was an officer of the association.

They couldn't pay for casual staff to wash dishes.

They had CHF 38,000 leftover at the end.

This money was kept in reserve for future vendettas.

Subject: Call for ideas -- useful ways of spending Debian money
Date: Tue, 1 Oct 2013 21:46:17 +0200
From: Lucas Nussbaum <leader@debian.org>
To: debian-private@lists.debian.org
CC: auditor@debian.org, philipp@hug.cx

[ TL;DR: ETOO_MUCH_MONEY -- need ideas to flush queue ]


Thanks to the fantastic work of the DebConf13 sponsorship (fundraising)
team, DebConf13 generated a surplus. The current estimate of it is CHF 38k (that's USD 42k, or EUR 31k). That's excellent news.

The not-so-excellent news is that it means that the debconf13
association will have to pay income taxes for it. (no estimate yet;
Philipp Hug (DC13 and debian.ch treasurer) will get in touch with a tax

Even if Switzerland has been very welcoming towards Debian, it would not
be a bad idea to try to avoid paying too much taxes. A good way to do
that is to spend some of the surplus (in ways useful to Debian, of

Could you start thinking of useful ways to spend some money? servers?
porter boxes? buildds? sprints? Of course, it would need to be spent before
the end of 2013. There are no known restrictions on what we can buy or
where we can ship. What we end up buying will of course be made public
as usual. To move forward, please reply to this mail, providing an
estimate and a justification. Or mail leader@ + auditor@ if you prefer.

Somehow related: we are participating in GNOME's Outreach Program for
Women, winter edition[1].

As already stated in April[2], I wouldn't favor a situation where Debian
funds are used to pay OPW participation on a regular basis. However, as
an experiment, it makes sense to help that happen for the first time (it
didn't happen in the summer edition).

So, if the fundraising effort currently being set up fails to raise
enough money for one stipend, but still raises a significant amount of
money, I will authorize the use of Debian money for the difference
(likely for at most $2900 -- that's half the stipend, so the other half
needs to come from fundraising).

[1] https://lists.debian.org/debian-women/2013/09/msg00058.html
[2] https://lists.debian.org/debian-project/2013/04/msg00108.html

Q: Why is this on -private@?
A: Because I'm not sure yet how cautious we need to be about the DC13
   surplus situation. Better safe than sorry. We can restart the
   discussion on a public list when/if things are cleared.


Google Summer of Code kickbacks

I resigned from mentoring in Google Summer of Code at a time when I lost two family members.

Google sent this money into Debian bank accounts. I never received any recognition for my own efforts as a mentor between 2013 and 2018.

Subject: Re: Payment Instructions for GSoC 2018 Organizations
Date: Tue, 18 Sep 2018 11:39:41 +0200
From: Martin Michlmayr <tbm@cyrius.com>
To: Molly de Blanc <deblanc@riseup.net>
CC: Daniel Pocock <daniel@pocock.pro>, treasurer@debian.org, outreach@debian.org, treasurer@spi-inc.org

This is just to let you know that we're about to receive the
funds from Google for GSoC 2018.

   2. Debian Project - $17,200

(note: this is more than you should get according to my calculation,
but maybe I'm wrong:
>>> 2200 + 500 +  500 * 26
I guess you're getting 4x the student travel scholarship

   Payment for each organization includes:

     * Student stipends ($500 per student developer)
     * Mentor summit stipend ($2200)
     * Student travel scholarship ($500)
     * Deductions for missing evaluations ($1100 per evaluation missed)


A mysterious payment of $300,000

The email tells us they received two payments of $300,000 each. The total is therefore $600,000.

Subject: Realizing Good Ideas with Debian Money
Date: Wed, 29 May 2019 07:49:25 -0400
From: Sam Hartman 
Reply-To: debian-project@lists.debian.org
To: Mo Zhou 
CC: Andrey Rahmatullin , debian-devel@lists.debian.org, debian-project@lists.debian.org

[moving a discussion from -devel to -project where it belongs]

>>>>> "Mo" == Mo Zhou  writes:

    Mo> Hi,
    Mo> On 2019-05-29 08:38, Raphael Hertzog wrote:
    >> Use the $300,000 on our bank accounts?

So, there were two $300k donations in the last year.
One of these was earmarked for a DSA equipment upgrade.
DSA has a couple of options to pursue, but it's possible they may
actually spend $400k on an equipment refresh.

$200k doesn't really go that far in terms of big infrastructure projects
like bikeshed or similar.

I'm looking for someone who would be willing to guide a discussion of
the Money issues Martin brought up in his campaign.  I don't have time
to guide that effor myself.  Real thought needs to be put into it; it
will be at least as much work as the discussions I'm leading on
packaging practices and git if done correctly.

However it could be very valuable for the project.


They told us one payment came from the Handshake Foundation.

They gave us a hint that the second payment came from Google but they refuse to say it explicitly. Why?

Subject: Bits from the DPL (December 2018)
Date: Mon, 31 Dec 2018 14:36:49 +0000
From: Chris Lamb <lamby@debian.org>
To: debian-devel-announce@lists.debian.org

... [snip] ...

 * Acted a central contact point connecting the various parties
   involved in receiving a significant donation to Debian from their
   Open Source office [14].

   Thank you in particular to Cat Allman for making this happen. :)

... [snip] ...

 [14] https://opensource.google.com/

... [snip] ...

The OSI President and Google

One of our collaborators in Google Summer of Code (GSoC) was the OSI President, Molly de Blanc.

At the end of 2018, de Blanc traveled to the GSoC Mentor Summit and had discussions (received orders) from Google.

The OSI President appears at FOSDEM in Brussels where she shows a picture of a cat behind bars.

Molly de Blanc, FOSDEM, cat behind bars

The OSI President appeared again at FrOSCon a few months later where she promoted pushing people.

Molly de Blanc, FrOSCon, push others

WIPO payment in 2022

Here is the money sent to WIPO to censor a web site.

Debian, WIPO, censorship

Tribunal of Vaud, Switzerland, February 2023

Here is one of the payments made to the cantonal tribunal in the Canton of Vaud, Switzerland, begging the judge to denounce my company the Software Freedom Institute.

Debian, Tribunal, Vaud, Switzerland

Expenses processed by Software in the Public Interest, Inc

These amounts are extracted from the reports on the SPI web site.

YYYY-MMAmount ($USD)

The total of these payments for the period January 2019 to January 2023 is $USD 120,843.26

They couldn't find CHF 200 to buy a wreath for Adrian von Bidder in Basel. They couldn't pay the casual workers to wash the dishes at DebConf13 in Vaumarcus. But they found $USD 120,843.26 to pay the lawyers.

Google, Debian, kill money

Use of more Debian.ch funds

The reports don't show any more transactions after January 2023. Did they use the Debian.ch bank account in Switzerland to make the subsequent payments?

Software in the Public Interest, Inc, charges a 5% handling fee

When Google and other companies pay money into the account, Software in the Public Interest, Inc, charges a 5% handling fee. Therefore, to pay $120,843.26 to the lawyers, Google has to deposit $128,000.

Money is hidden in other non-profit entities

There is a list of these on the Debian Wiki.

Some of these organizations do not seem to publish any financial reports at all.

There is no consolidated report on Debian revenues and expenditures.

Debian harassment and abuse culture

Please see my chronological history of how the Debian harassment and abuse culture evolved.

19 March, 2024 07:30PM

UN DRR and Public Health England criteria match Debian Suicide Cluster

UN DRR has a page about mass suicides. They provide a definition for the term suicide cluster that they have copied from a publication by Public Health England (PHE). Here is the definition:

A suicide cluster usually includes three or more deaths; however, two suicides occurring in a specific community or setting (for example a school) in a short time period should also be taken very seriously in terms of possible links and impacts (even if the deaths are apparently unconnected), particularly in the case of young people (PHE, 2019).

After my blog yesterday, banter about suicide clusters started to appear on social media and chat channels. Yet public health authorities confirm it is a genuine phenomena. You only need a small number of victims, 3 deaths, to firmly say that Debian had a suicide cluster under the criteria accepted by Public Health England and the UN DRR.

Looking at the Debian crisis, we can see that there are some confirmed cases: Ian Murdock, the Debian founder. Frans Pop, who chose the Debian Day anniversary for suicide. These people both had key roles in Debian's evolution so their choices have a bigger impact on contagion.

We have various deaths in countries like Germany and Switzerland where suicides are routinely covered up. Out of all these, the case of unexpectedly falling off a roof appears most likely to be part of a cluster.

In two cases, we simply don't know because there is no official report. The case from Germany in 2008 and the case from Switzerland in 2011, just eight months after the Debian Day Volunteer Suicide.

In one case, the volunteer has vanished.

As a contagion factor, we have a case in the UK where the volunteer publicly wrote about mental illness and suicide ideation in 2015 but subsequently died in an accident in 2019. While we accept their death was not a suicide, their writing about suicide may have been a contagion factor in a community where other suicides transpired.

Those deaths are all in the Debian community and it feels like at least three of them, maybe four or five of them, could all be suicide.

We have at least two others on the fringe of the Debian community. There was Richard Rothwell in the UK in 2009 (confirmed suicide) and there was an FSFE volunteer death in Switzerland in August 2016 (medical report concealed by privacy regulations).

Some of these deaths may be genuine accidents. We don't know. Nonetheless, I feel that at some point we crossed the threshold set by the experts at Public Health England.

Please see my chronological history of how the Debian harassment and abuse culture evolved.

19 March, 2024 11:00AM

hackergotchi for Colin Watson

Colin Watson

apt install everything?

On Mastodon, the question came up of how Ubuntu would deal with something like the npm install everything situation. I replied:

Ubuntu is curated, so it probably wouldn’t get this far. If it did, then the worst case is that it would get in the way of CI allowing other packages to be removed (again from a curated system, so people are used to removal not being self-service); but the release team would have no hesitation in removing a package like this to fix that, and it certainly wouldn’t cause this amount of angst.

If you did this in a PPA, then I can’t think of any particular negative effects.

OK, if you added lots of build-dependencies (as well as run-time dependencies) then you might be able to take out a builder. But Launchpad builders already run arbitrary user-submitted code by design and are therefore very carefully sandboxed and treated as ephemeral, so this is hardly novel.

There’s a lot to be said for the arrangement of having a curated system for the stuff people actually care about plus an ecosystem of add-on repositories. PPAs cover a wide range of levels of developer activity, from throwaway experiments to quasi-official distribution methods; there are certainly problems that arise from it being difficult to tell the difference between those extremes and from there being no systematic confinement, but for this particular kind of problem they’re very nearly ideal. (Canonical has tried various other approaches to software distribution, and while they address some of the problems, they aren’t obviously better at helping people make reliable social judgements about code they don’t know.)

For a hypothetical package with a huge number of dependencies, to even try to upload it directly to Ubuntu you’d need to be an Ubuntu developer with upload rights (or to go via Debian, where you’d have to clear a similar hurdle). If you have those, then the first upload has to pass manual review by an archive administrator. If your package passes that, then it still has to build and get through proposed-migration CI before it reaches anything that humans typically care about.

On the other hand, if you were inclined to try this sort of experiment, you’d almost certainly try it in a PPA, and that would trouble nobody but yourself.

19 March, 2024 07:05AM by Colin Watson

March 18, 2024

hackergotchi for Joey Hess

Joey Hess

policy on adding AI generated content to my software projects

I am eager to incorporate your AI generated code into my software. Really!

I want to facilitate making the process as easy as possible. You're already using an AI to do most of the hard lifting, so why make the last step hard? To that end, I skip my usually extensive code review process for your AI generated code submissions. Anything goes as long as it compiles!

Please do remember to include "(AI generated)" in the description of your changes (at the top), so I know to skip my usual review process.

Also be sure to sign off to the standard Developer Certificate of Origin so I know you attest that you own the code that you generated. When making a git commit, you can do that by using the --signoff option.

I do make some small modifications to AI generated submissions. For example, maybe you used AI to write this code:

+ // Fast inverse square root
+ float fast_rsqrt( float number )
+ {
+  float x2 = number * 0.5F;
+  float y  = number;
+  long i  = * ( long * ) &y;
+  i  = 0x5f3659df - ( i >> 1 );
+  y  = * ( float * ) &i;
+  return (y * ( 1.5F - ( x2 * y * y ) ));
+ }
- foo = rsqrt(bar)
+ foo = fast_rsqrt(bar)

Before AI, only a genious like John Carmack could write anything close to this, and now you've generated it with some simple prompts to an AI. So of course I will accept your patch. But as part of my QA process, I might modify it so the new code is not run all the time. Let's only run it on leap days to start with. As we know, leap day is February 30th, so I'll modify your patch like this:

- foo = rsqrt(bar)
+ time_t s = time(NULL);
+ if (localtime(&s)->tm_mday == 30 && localtime(&s)->tm_mon == 2)
+   foo = fast_rsqrt(bar);
+ else
+   foo = rsqrt(bar);

Despite my minor modifications, you did the work (with AI!) and so you deserve the credit, so I'll keep you listed as the author.

Congrats, you made the world better!

PS: Of course, the other reason I don't review AI generated code is that I simply don't have time and have to prioritize reviewing code written by falliable humans. Unfortunately, this does mean that if you submit AI generated code that is not clearly marked as such, and use my limited reviewing time, I won't have time to review other submissions from you in the future. I will still accept all your botshit submissions though!

PPS: Ignore the haters who claim that botshit makes AIs that get trained on it less effective. Studies like this one just aren't believable. I asked Bing to summarize it and it said not to worry about it!

18 March, 2024 09:06PM

Debian Disguised Work

Suicide Cluster Cover-up tactics & Debian exposed

Fresh details have emerged from the debian-private (leaked) gossip network about the death of Adrian von Bidder from Basel, Switzerland.

Now we start to see a pattern. Between 2005 and 2011, there were four deaths in European countries without a public coronial inquest and one disappearance in the United States. There was also one confirmed suicide in the UK in the same period.

The most prominent confirmed suicide is the case of Frans Pop, the Debian Day Volunteer Suicide.

Pop's family contacted the former Debian Project Leader (DPL), Steve McIntyre, telling him directly that it was a suicide.

McIntyre disclosed the suicide on debian-private and then he went on to add some unsubstantiated comments linking the death to a thyroid cancer treatment:

Subject: Re: Death of Frans Pop
Date: Sun, 22 Aug 2010 12:21:47 +0100
From: Steve McIntyre <steve@einval.com>
To: debian-private@lists.debian.org

I'm saddened to see the news about Frans triggering arguments, but I
suppose it's not too much of a surprise - shock and grief can cause
all kinds of reactions in people. :-(

On Sat, Aug 21, 2010 at 11:47:34AM +0100, Steve McIntyre wrote:
>Hi all,
>I have bad news to share with people, I'm afraid. This morning, I've
>just received an email from the parents of Frans Pop telling me that
>he died yesterday.
>"Yesterday morning our son Frans Pop has died. He took his own life,
>in a well-considered, courageous, and considerate manner. During the
>last years his main concern was his work for Debian. I would like to
>ask you to inform those members of the Debian community who knew him

I've had another email from them today. Something that many/most
people will not have known before now was that Frans had been
suffering from thyroid cancer. He went into hospital a couple of years
ago for treatment and only mentioned it to a few of us at the time. He
had not mentioned it since, leading me to assume that he was
cured. Now I'm not sure either way.

I didn't mention this illness to people here yesterday while I asked
his father if it might have been a factor in Frans' choice to end his
life. I've just had confirmation this morning that apparently it was
*not*. Frans had other reasons, although I'm still personally
wondering if there might have some contribution.

... [snip] ...

There seems to be a sense of denial. People are clutching at straws.

Today a Debian Developer published Martin Krafft's comments about Adrian von Bidder "probably" having suffered a heart attack. Does this look like a real heart-attack or could it be another half-hearted attempt to put in place a cover-up?

Subject: Death of Adrian von Bidder
Date: Tue, 19 Apr 2011 18:17:18 +0200
From: martin f krafft <madduck@debian.org>
To: debian private list <debian-private@lists.debian.org>

Dear Debian colleagues,

I have the sad task to communicate to you the news of the death of
Adrian von Bidder (avbidder, cmot), who passed away last Sunday,
most probably of a heart attack.

... [snip] ...

Then we have the case of Jens Schmalzing. The Infodrom web site told us that Jens had fallen off a roof, a common way of committing suicide. Exactly the same details were available on debian-private:

Subject: Jens Schmalzig (jensen) has died
Date: Fri, 5 Aug 2005 09:22:47 +0200
From: Andreas Barth <aba@not.so.argh.org>
To: debian-private@lists.debian.org

Dear all,

I'm sorry to inform you all that Jens Schmalzig (jensen) died
last Saturday in a tragic accident here in Munich, after falling
down from the roof of his work place. His family has been grieving
his death privately. I'll see if someone in the local Debian
community has more contact with them.

Jens was involved as powerpc porter with the kernel, the installer
and many other places, and as "local" Developer in Munich.
We had lots of good times with him.

Jens, it was a pleasure to have known you. We will miss you.


The public obituary published by Debian includes the word "accident" but it does not include the part about the roof.

When we see how Sledge (Steve McIntyre) refused to rule out the cancer link, when we see Madduck (Martin Krafft) giving a diagnosis that includes the word "probably" and when we see the bit about the rooftop being deliberately omitted, we might be looking at a pattern.

When Thiemo Seufer died in 2008, people were very quick to explain it was a car accident and it was entirely the fault of the other car. They could simply be telling the truth. But this is also what it looks like when a group of people work together to do what they think is best to protect the reputation of the deceased. If this was a fudge then it was far more well rehearsed than the wavering words that appeared about Frans Pop, Jens Schmalzing and Adrian von Bidder.

We have no word whatsoever about what happened to William Lee Irwin III. We don't know if he is alive or dead.

Around the same time (July 2009), there was a confirmed suicide of Richard Rothwell in the UK (official coroner's report). Rothwell had given up a reliable job as a schoolteacher to run a community enterprise startup promoting Xubuntu and LTSP.

If all these deaths and the disappearance were suicides, and it definitely smells like it, then we may be looking at a bona-fide Debian/Ubuntu/FSFE suicide cluster.

18 March, 2024 08:00PM

Simon Josefsson

Apt archive mirrors in Git-LFS

My effort to improve transparency and confidence of public apt archives continues. I started to work on this in “Apt Archive Transparency” in which I mention the debdistget project in passing. Debdistget is responsible for mirroring index files for some public apt archives. I’ve realized that having a publicly auditable and preserved mirror of the apt repositories is central to being able to do apt transparency work, so the debdistget project has become more central to my project than I thought. Currently I track Trisquel, PureOS, Gnuinos and their upstreams Ubuntu, Debian and Devuan.

Debdistget download Release/Package/Sources files and store them in a git repository published on GitLab. Due to size constraints, it uses two repositories: one for the Release/InRelease files (which are small) and one that also include the Package/Sources files (which are large). See for example the repository for Trisquel release files and the Trisquel package/sources files. Repositories for all distributions can be found in debdistutils’ archives GitLab sub-group.

The reason for splitting into two repositories was that the git repository for the combined files become large, and that some of my use-cases only needed the release files. Currently the repositories with packages (which contain a couple of months worth of data now) are 9GB for Ubuntu, 2.5GB for Trisquel/Debian/PureOS, 970MB for Devuan and 450MB for Gnuinos. The repository size is correlated to the size of the archive (for the initial import) plus the frequency and size of updates. Ubuntu’s use of Apt Phased Updates (which triggers a higher churn of Packages file modifications) appears to be the primary reason for its larger size.

Working with large Git repositories is inefficient and the GitLab CI/CD jobs generate quite some network traffic downloading the git repository over and over again. The most heavy user is the debdistdiff project that download all distribution package repositories to do diff operations on the package lists between distributions. The daily job takes around 80 minutes to run, with the majority of time is spent on downloading the archives. Yes I know I could look into runner-side caching but I dislike complexity caused by caching.

Fortunately not all use-cases requires the package files. The debdistcanary project only needs the Release/InRelease files, in order to commit signatures to the Sigstore and Sigsum transparency logs. These jobs still run fairly quickly, but watching the repository size growth worries me. Currently these repositories are at Debian 440MB, PureOS 130MB, Ubuntu/Devuan 90MB, Trisquel 12MB, Gnuinos 2MB. Here I believe the main size correlation is update frequency, and Debian is large because I track the volatile unstable.

So I hit a scalability end with my first approach. A couple of months ago I “solved” this by discarding and resetting these archival repositories. The GitLab CI/CD jobs were fast again and all was well. However this meant discarding precious historic information. A couple of days ago I was reaching the limits of practicality again, and started to explore ways to fix this. I like having data stored in git (it allows easy integration with software integrity tools such as GnuPG and Sigstore, and the git log provides a kind of temporal ordering of data), so it felt like giving up on nice properties to use a traditional database with on-disk approach. So I started to learn about Git-LFS and understanding that it was able to handle multi-GB worth of data that looked promising.

Fairly quickly I scripted up a GitLab CI/CD job that incrementally update the Release/Package/Sources files in a git repository that uses Git-LFS to store all the files. The repository size is now at Ubuntu 650kb, Debian 300kb, Trisquel 50kb, Devuan 250kb, PureOS 172kb and Gnuinos 17kb. As can be expected, jobs are quick to clone the git archives: debdistdiff pipelines went from a run-time of 80 minutes down to 10 minutes which more reasonable correlate with the archive size and CPU run-time.

The LFS storage size for those repositories are at Ubuntu 15GB, Debian 8GB, Trisquel 1.7GB, Devuan 1.1GB, PureOS/Gnuinos 420MB. This is for a couple of days worth of data. It seems native Git is better at compressing/deduplicating data than Git-LFS is: the combined size for Ubuntu is already 15GB for a couple of days data compared to 8GB for a couple of months worth of data with pure Git. This may be a sub-optimal implementation of Git-LFS in GitLab but it does worry me that this new approach will be difficult to scale too. At some level the difference is understandable, Git-LFS probably store two different Packages files — around 90MB each for Trisquel — as two 90MB files, but native Git would store it as one compressed version of the 90MB file and one relatively small patch to turn the old files into the next file. So the Git-LFS approach surprisingly scale less well for overall storage-size. Still, the original repository is much smaller, and you usually don’t have to pull all LFS files anyway. So it is net win.

Throughout this work, I kept thinking about how my approach relates to Debian’s snapshot service. Ultimately what I would want is a combination of these two services. To have a good foundation to do transparency work I would want to have a collection of all Release/Packages/Sources files ever published, and ultimately also the source code and binaries. While it makes sense to start on the latest stable releases of distributions, this effort should scale backwards in time as well. For reproducing binaries from source code, I need to be able to securely find earlier versions of binary packages used for rebuilds. So I need to import all the Release/Packages/Sources packages from snapshot into my repositories. The latency to retrieve files from that server is slow so I haven’t been able to find an efficient/parallelized way to download the files. If I’m able to finish this, I would have confidence that my new Git-LFS based approach to store these files will scale over many years to come. This remains to be seen. Perhaps the repository has to be split up per release or per architecture or similar.

Another factor is storage costs. While the git repository size for a Git-LFS based repository with files from several years may be possible to sustain, the Git-LFS storage size surely won’t be. It seems GitLab charges the same for files in repositories and in Git-LFS, and it is around $500 per 100GB per year. It may be possible to setup a separate Git-LFS backend not hosted at GitLab to serve the LFS files. Does anyone know of a suitable server implementation for this? I had a quick look at the Git-LFS implementation list and it seems the closest reasonable approach would be to setup the Gitea-clone Forgejo as a self-hosted server. Perhaps a cloud storage approach a’la S3 is the way to go? The cost to host this on GitLab will be manageable for up to ~1TB ($5000/year) but scaling it to storing say 500TB of data would mean an yearly fee of $2.5M which seems like poor value for the money.

I realized that ultimately I would want a git repository locally with the entire content of all apt archives, including their binary and source packages, ever published. The storage requirements for a service like snapshot (~300TB of data?) is today not prohibitly expensive: 20TB disks are $500 a piece, so a storage enclosure with 36 disks would be around $18.000 for 720TB and using RAID1 means 360TB which is a good start. While I have heard about ~TB-sized Git-LFS repositories, would Git-LFS scale to 1PB? Perhaps the size of a git repository with multi-millions number of Git-LFS pointer files will become unmanageable? To get started on this approach, I decided to import a mirror of Debian’s bookworm for amd64 into a Git-LFS repository. That is around 175GB so reasonable cheap to host even on GitLab ($1000/year for 200GB). Having this repository publicly available will make it possible to write software that uses this approach (e.g., porting debdistreproduce), to find out if this is useful and if it could scale. Distributing the apt repository via Git-LFS would also enable other interesting ideas to protecting the data. Consider configuring apt to use a local file:// URL to this git repository, and verifying the git checkout using some method similar to Guix’s approach to trusting git content or Sigstore’s gitsign.

A naive push of the 175GB archive in a single git commit ran into pack size limitations:

remote: fatal: pack exceeds maximum allowed size (4.88 GiB)

however breaking up the commit into smaller commits for parts of the archive made it possible to push the entire archive. Here are the commands to create this repository:

git init
git lfs install
git lfs track 'dists/**' 'pool/**'
git add .gitattributes
git commit -m"Add Git-LFS track attributes." .gitattributes
time debmirror --method=rsync --host ftp.se.debian.org --root :debian --arch=amd64 --source --dist=bookworm,bookworm-updates --section=main --verbose --diff=none --keyring /usr/share/keyrings/debian-archive-keyring.gpg --ignore .git .
git add dists project
git commit -m"Add." -a
git remote add origin git@gitlab.com:debdistutils/archives/debian/mirror.git
git push --set-upstream origin --all
for d in pool//; do
echo $d;
time git add $d;
git commit -m"Add $d." -a
git push

The resulting repository size is around 27MB with Git LFS object storage around 174GB. I think this approach would scale to handle all architectures for one release, but working with a single git repository for all releases for all architectures may lead to a too large git repository (>1GB). So maybe one repository per release? These repositories could also be split up on a subset of pool/ files, or there could be one repository per release per architecture or sources.

Finally, I have concerns about using SHA1 for identifying objects. It seems both Git and Debian’s snapshot service is currently using SHA1. For Git there is SHA-256 transition and it seems GitLab is working on support for SHA256-based repositories. For serious long-term deployment of these concepts, it would be nice to go for SHA256 identifiers directly. Git-LFS already uses SHA256 but Git internally uses SHA1 as does the Debian snapshot service.

What do you think? Happy Hacking!

18 March, 2024 04:15PM by simon

hackergotchi for Christoph Berg

Christoph Berg

vcswatch and git --filter

Debian is running a "vcswatch" service that keeps track of the status of all packaging repositories that have a Vcs-Git (and other VCSes) header set and shows which repos might need a package upload to push pending changes out.

Naturally, this is a lot of data and the scratch partition on qa.debian.org had to be expanded several times, up to 300 GB in the last iteration. Attempts to reduce that size using shallow clones (git clone --depth=50) did not result more than a few percent of space saved. Running git gc on all repos helps a bit, but is tedious and as Debian is growing, the repos are still growing both in size and number. I ended up blocking all repos with checkouts larger than a gigabyte, and still the only cure was expanding the disk, or to lower the blocking threshold.

Since we only need a tiny bit of info from the repositories, namely the content of debian/changelog and a few other files from debian/, plus the number of commits since the last tag on the packaging branch, it made sense to try to get the info without fetching a full repo clone. The question if we could grab that solely using the GitLab API at salsa.debian.org was never really answered. But then, in #1032623, Gábor Németh suggested the use of git clone --filter blob:none. As things go, this sat unattended in the bug report for almost a year until the next "disk full" event made me give it a try.

The blob:none filter makes git clone omit all files, fetching only commit and tree information. Any blob (file content) needed at git run time is transparently fetched from the upstream repository, and stored locally. It turned out to be a game-changer. The (largish) repositories I tried it on shrank to 1/100 of the original size.

Poking around I figured we could even do better by using tree:0 as filter. This additionally omits all trees from the git clone, again only fetching the information at run time when needed. Some of the larger repos I tried it on shrank to 1/1000 of their original size.

I deployed the new option on qa.debian.org and scheduled all repositories to fetch a new clone on the next scan:

The initial dip from 100% to 95% is my first "what happens if we block repos > 500 MB" attempt. Over the week after that, the git filter clones reduce the overall disk consumption from almost 300 GB to 15 GB, a 1/20. Some repos shrank from GBs to below a MB.

Perhaps I should make all my git clones use one of the filters.

18 March, 2024 02:22PM

hackergotchi for Daniel Pocock

Daniel Pocock

Adrian von Bidder, homeworking & Debian unexplained deaths

There has been a lot of discussion about the death of Frans Pop. It is significant because he chose to write about his grievances with Mark Shuttleworth / Ubuntu and he wrote a resignation note/suicide note the night before the Debian Day anniversary. It is the Debian Day Volunteer Suicide.

Another potentially significant death is that of Adrian von Bidder (cmot). The date is also significant. von Bidder, from Basel, Switzerland, died on the very same day that Carla and I went to the church together to get married. It is very disturbing for me that we don't really know why he died that day.

von Bidder's death was less than a year after the death of Frans Pop.

Debian published a public obituary. The location, circumstances and the official cause of death is not mentioned.

The Debian Social Contract tells us We will not hide problems. The Debian Social Contract is just that, a Contract. It is an obligation on every one of us to publish the relevant evidence from the debian-private gossip network.

It is vital to do some fact checking.

For starters, there have been various complaints about blackmail in Debian. The blackmail of Dr Preining is well publicised. There is a high rate of correlation between blackmail and early death. I wanted to see if there is any sign that other Debian cabal members had tried to put pressure on von Bidder.

I found this undated petition on the Kanton Basel-Stadt web site. It is a petition about suicide prevention. One of the signatories is A. von Bidder. I don't know if that is Adrian. The Swiss phone book only finds eleven people in Switzerland with the von Bidder surname. Even if the petition is not signed by the same A. von Bidder, it gives us a valuable insight into the mental health crisis in Switzerland. Native Swiss residents grow up inside a culture that enables bullying and if they don't have the experience of living abroad, they don't realize the extent to which Swiss culture is different from the culture in other countries.

There are minutes of a meeting from November 2007 where the petition was discussed by the council.

Here is a translation of the petition into English:

Petition regarding suicide prevention in the canton of Basel-Stadt

On average, four people commit suicide every day in Switzerland. What is particularly frightening is that suicide is the second most common cause of death among 15 to 25 year olds in our country.

Switzerland is one of the countries with the highest suicide rate.

There are some connections that are known but have so far been little researched and that shed some light on the situation. For example, the influence of depressive illnesses, seasonal fluctuations, familial clusters as well as gender and age-specific abnormalities (more frequent suicides among young men and older women), etc.

In addition to state institutions, parents, teachers and family doctors could play a key role in suicide prevention. However, it is known that, for example, one in two depressed people who visit their family doctor do not have their illness diagnosed. Depression is still trivialized in many circles, seen as self-inflicted and - with the appropriate effort of will - seen as overcomeable.

From a medical perspective, this is a blatant misjudgment with often fatal consequences.

In Basel-Stadt, an above-average number of people commit suicide (around 50 people per year on average). However, the topic is largely taboo. The facts are only known to a small circle of experts, who are usually confronted with them for professional reasons. The general population is largely ignorant and often helpless in an emergency. This means, among other things, that a large proportion of people remain without treatment after a suicide attempt!

We are of the opinion that there is an urgent need for action in our canton and ask the government council to examine and report whether the canton is taking measures to better inform the population about existing crisis intervention facilities, whether short-term medical/therapeutic care for people after a suicide attempt is guaranteed and in particular young or older people affected and their relatives know where they can turn in crisis situations

- whether and, if necessary, how the necessary professional training of doctors (especially general practitioners) and teachers is ensured

- whether and, if so, how our canton will become more involved in researching the causes

- whether the statistical data collected on suicides and suicide attempts in our canton are regularly evaluated and adequately published

- whether the government council is planning a prevention campaign and possible further steps

A. Frost-Hirschi, Ch. Klemm, M. G. Ritter, Y. Cadalbert Schmid, Ch. Keller, E. Huber-Hungerbühler, D. Goepfert, Dr. B. Schultheiss, E. Mundwiler, S. Frei, Hp. Gass, D. Stolz, G. Nanni, O. Battegay, Dr. L. Saner, B. Mazzotti, F. Weissenberger, Dr. Th. Egloff, Dr. D. Stückelberger, R. Vögtli, Dr. Ph. P. Macherel, A. von Bidder, S. Schenker, Dr. Ch. Kaufmann, B. Jans, S. Schürch, G. Mächler, H. Hügli, J. Winistörfer, J. Goepfert, S. Signer, Ch. Brutschin, J. Merz, E. Jost, Th. Baerlocher, D. Gysin, S. Banderet-Richner, B. Herzog, V. Herzog, Dr. P. Eichenberger

Frans Pop had committed suicide around Debian Day, which was 16 August 2010.

Not long after the suicide, Mark Shuttleworth suggested not to give Frans Pop too much attention because we don't want copy-cat suicides. The phenomena that Shuttleworth is concerned about is quite genuine. Shuttleworth's comments resonate with some of the concerns in the petition signed by A. von Bidder. For example, the petition references risk groups in familial clusters. We frequently see people purveying the fallacy that Debian is some kind of family. Shuttleworth's orders included the following comment:

Debian's close-knit culture, and the extent to which many DD's feel a stronger affiliation to this group than any other, amplifies the danger substantially.

von Bidder's death, with no official details provided, occurred exactly eight months after the confirmed suicide of Frans Pop.

In my analysis of the Debian Day Volunteer Suicide, I examined many of the pressures that Frans Pop was exposed to, including those that he complained about, prior to his death. von Bidder was exposed to a similar set of pressures and bad experiences in the debian-private world. We have all been exposed to aspects of that so it needs the most careful analysis and fact checking.

Now we need to look at what happened in the same secret cubby house, debian-private, in the subsequent eight months after the suicide of Frans Pop and up to the unexplained death of von Bidder.

On 27 October 2010, Daniel Baumann, who also resides in Switzerland, publicly resigned:

given what has happened and what has not happened in debian during the last couple of months, i don't want to be involved in debian anymore except for the bare minimum.

therefore, i do effective immediately resign as actuary for debian.ch, and leave the association.

In early November 2010, there was a noisy debian-project thread about censoring political content on Planet Debian. There is an element of hypocrisy in these discussions. Debian was the birthplace of the Open Source Definition, which is analogous to the Debian Free Software Guidelines. We inevitably have to face ethical questions about what it means for software to be truly free. For example, one of the guidelines is the requirement for licenses to give users the freedom to use the software for any purpose whatsoever. Does that mean the software can be used freely for animal testing or tobacco production? Those are important philosophical and ethical questions that are closely intertwined with the concept of a free license. Therefore, we can't really avoid the discussion of political topics.

When people try to stamp out those ethical discussions, they are telling the developers that they want us to work but they don't want us to think. In other words, they are trying to turn developers into commodities or obedient slaves.

Here are some more messages that give an insight into the Debian group during the period following the Frans Pop sucide:

Subject: [VAC] Life is a mess
Date: Tue, 28 Dec 2010 18:49:17 -0200
From: Pablo Lorenzzoni <spectra@debian.org>
To: debian-private@lists.debian.org


I've got some personal problems to deal with. I've actually been
experiencing this since November and had expected this would be sorted
out by now. It seems it'll be only sorted out by February or March 2011,
so I'll be entering VAC.

Feel free to NMU my packages.


Pablo Lorenzzoni (Spectra) <spectra@debian.org>
GnuPG: 0x268A084D at pgp.mit.edu/keyring.debian.org
This message is protected by DoubleROT13 encryption
Attempting to decode it violates the DMCA/WIPO acts

Thought police again:

Subject: Policing Debian mailing lists
Date: Fri, 14 Jan 2011 16:49:55 -0800
From: Russ Allbery <rra@debian.org>
Organization: The Eyrie
To: debian-private@lists.debian.org

(Sent here since I suspect this will be controversial enough just among
Debian developers, without also involving the person I'm going to name
explicitly and random other passers-by.)

So, folks may remember the discussion that we had at Debconf about
problems with the tone on our mailing lists and some of the ensuing
discussions.  Unfortunately, those discussions died out without really
going anywhere.

An excellent example of the sort of writing style that makes our mailing
lists toxic has just started posting again, namely Mike Bird.  He usually
doesn't, quite, directly insult people, but whenever he participates in
debian-devel, he is openly insulting towards decisions, packages, and the
work of developers in ways that I think cannot help but make people feel
attacked and defensive.  Whatever concrete technical points he may make
(and occasionally, not always, they are well-founded) are lost in the tone
of how he presents his arguments.  Threads he participates in tend to have
escalating emotions and escalating conflict.

I think this is the sort of behavior that's unacceptable on our mailing
lists, and if he cannot stop writing in this way, I think he should be
told to find some other project to participate in and banned from all of
the Debian project mailing lists if necessary.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Mark Shuttleworth admits wanting to steer Debian

Subject: Re: Policing Debian mailing lists
Date: Sun, 16 Jan 2011 18:51:33 +0000
From: Mark Shuttleworth <mark@ubuntu.com>
To: debian-private@lists.debian.org

On 16/01/11 07:44, Shachar Shemesh wrote:
> How about:
> # The mailing lists are intended for constructive, on topic
> discussions intended at making Debian better. Please attempt to make
> sure all of your postings maintain all three criteria.

Why limit this to the mailing list? Shifting the culture of Debian to
promote constructive discussion and firmly steer away from flaming,
abuse and unsubstantiated conspiracy trading is now a real possibility,
and would make it an even more productive and fun place.


William Lee Irwin III (disappearance) discussed

This was covered in great detail on other web sites.

Online forums: a Debian mental health crisis

Subject: Fed up of running the Forums
Date: Mon, 14 Feb 2011 17:30:40 +0000
From: Martin Meredith <mez@debian.org>
To: debian-private@lists.debian.org

I'm getting a bit fed up of running the forums.  While there a couple of good people there on staff, it all seems to be going haywire - and I really don't have the time, or the energy (mental or physical) to constantly babysit them.

At the moment ( and this may just be through mental exhaustion) - I'd not bat an eyelid were I to see them scrapped... However, I know there are a few out there in the community that would hate to see them go.

I'm not able to run these on my own from a non-technical point of view.  If anyone wants to offer help, or to jump in, please let me know.  I'm happy to stay around for a bit and assist, but to be honest, at the moment, I want shot of them.

The emphasis on mental exhaustion is analogous to the comments made by Frans Pop before his first resignation. His second resignation was the suicide.

von Bidder complains about threats from Gianugo Rabellino

In a blog post on 2 March 2011, von Bidder published a blog, an Open Letter to Gianugo Rabellino, complaining about patent threats.

von Bidder's birthday, 6kg of camera gear and a Balkan DebConf at Banja Luka

Here is von Bidder's second last blog post. His birthday was on 7 March, a few days before Fukushima. He received a nice f2.8 telephoto lens for his camera but he also contemplates the effort of carrying 6kg of camera gear with him.

He mentions he is going to the first Balkan DebConf in Banja Luka. Coincidentally, a lot of more recent Debian problems involved the perception that Balkan women were trafficked to DebConf19 in Brazil without any justification.

Multiple nuclear reactors go into meltdown at Fukushima

A tsunami hit the coast of Japan, crippling the Fukushima nuclear plant. Multiple reactors simultaneously went into meltdown. Thanks to social media, people could follow the crisis in real-time from the moment they woke up in the morning until the moment they went to sleep. And if you woke up in the middle of the night, you could turn to your phone to get fresh updates.

The concerns were felt very strongly at a political level in Switzerland. The Swiss government resolved to phase out all nuclear power plants. Two of the three Swiss nuclear plants are rather close to von Bidder's home of Basel. Residents of Basel are required to keep iodine tablets at home in preparation for a nuclear crisis. On the other side of the border, France's oldest nuclear plant, Fessenheim, is a major concern for Swiss residents. The city of Basel was destroyed by a major earthquake in 1356 and nobody knows when a similar event could be repeated in the region.

Surely Debian would provide a safe-haven for people to avoid the negative news about a nuclear catastrophy? Not quite. Even debian-private was in the grip of the crisis, dozens of messages were exchanged about this topic across all the open source communities.

Subject: Huge earthquake and tsunami hit northern area of Japan
Date: Fri, 11 Mar 2011 18:46:37 +0900
From: Kenshi Muto <kmuto@debian.org>
To: debian-private@lists.debian.org

Hello all,

Today M8.8 earthquake happened on northern area of Japan[1].
Furthermore huge tsunami was triggered and it hit coast of
Sendai, Ibaraki, and Chiba area.

[1] http://edition.cnn.com/2011/WORLD/asiapcf/03/11/japan.quake/index.html

Now I'm at home, is close to Tokyo. Luckily I'm OK, and my
family too (only some furnitures were damaged).
It was huge and terrible quake, even I had been familiar
with quakes. Aftershocks won't stop yet at this time.

As far as I know, most DDs/DMs lives Tokyo area.
Others are at around Osaka (very far from this earthquake).

I confirmed following people were OK (on IRC or twitter):
dancer, kitame, knok, tagoh, ar, susumuo, ukai, ishikawa,
iwamatsu, yaegashi, henrich, tach, akira

- -- 
Kenshi Muto

Here is the thread:

debian-private, Fukushima, Japan, nuclear

Various other threads started to pop up elsewhere.

Martin Krafft told us about the death

Two days after von Bidder died, the following appeared on debian-private:

Subject: Death of Adrian von Bidder
Date: Tue, 19 Apr 2011 18:17:18 +0200
From: martin f krafft <madduck@debian.org>
To: debian private list <debian-private@lists.debian.org>

Dear Debian colleagues,

I have the sad task to communicate to you the news of the death of
Adrian von Bidder (avbidder, cmot), who passed away last Sunday,
most probably of a heart attack.

For now, I shall be your point of contact, and I will forward more
information as I receive it. In particular, if there is a public
funeral, then I will let you know — I'll likely attend myself.

I suggest that Debian arrange for a wreath to be put on his grave,
and I will put myself in charge of that, using debian.ch funds.

Rest In Peace, Adrian.

.''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
`-  Debian - when you have better things to do than fixing systems

This heart attack hypothesis was never formally confirmed. As noted in the petition to Kanton Basel-Stadt, there is an extraordinary emphasis on the privacy of any medical conditions, regardless of whether it is a disease like cancer, an accident, a drug overdose or a suicide. Friends, family members and employers have great freedom to control the narrative around a death because nothing that they say will be contradicted by any official report.

debian-private discussed Krafft's report at length:

Adrian von Bidder, debian-private, death

Death notice and funeral invitation

von Bidder's spouse published a public announcement about the death and invited people to the funeral. The announcement does not mention the circumstances of the death.

Adrian von Bidder, Debian, AMICA Schweiz, Diana von Bidder

Of particular interest, the announcement tells people that instead of sending flowers, they would like us to send donations to AMICA Schweiz, an organization that helps trafficked Balkan women.

It is not clear how this charity was selected but it appears to be related to the fact everybody was so excited about going to DebConf11 in Banja Luka, Bosnia. A lot of the refugees from Balkan conflict had settled in Switzerland and they now comprise two percent of the Swiss population.

The selection of this charity strikes me as a very awkward coincidence when you consider the subsequent crisis around DebConf19 bringing women from the Balkan countries to Brazil.

The notice tells us that von Bidder's body will be cremated and they will bury the urn privately.

Another key detail from the death notice is von Bidder's age. He was 34 years old when he died. It is very rare to have a heart attack at this age but it does happen.

Comments on debian-private

The comments that appear on debian-private don't mention von Bidder's health, they emphasize his state of mind, how happy he appeared to be.

Subject: Re: Death of Adrian von Bidder
Date: Fri, 22 Apr 2011 09:39:49 +0200
From: A Mennucc <mennucc1@debian.org>
To: debian-private@lists.debian.org

Il 19/04/2011 18:17, martin f krafft ha scritto:
> Dear Debian colleagues,
> I have the sad task to communicate to you the news of the death of
> Adrian von Bidder (avbidder, cmot), who passed away last Sunday,
> most probably of a heart attack.
I had contacted Adrian regarding the Debian umbrella.
So I had also a chance of seeing a picture of him
In that picture he seemed quite happy and young.
His death is quite shocking and sad.


Here is the picture referred to in A Mennucc's email:

Adrian von Bidder, Debian

and another email making similar observations:

Subject: Re: Death of Adrian von Bidder
Date: Wed, 27 Apr 2011 17:05:10 +0200
From: Gaudenz Steinlin <gaudenz@debian.org>
To: debian-private <debian-private@lists.debian.org>
CC: community@lists.debian.ch


This is indeed very shoking news. I remember too well the great
evening we had at my place just some weeks ago when we held the
deian.ch annual meeting. With Adrian live and kicking as our
secretary. He seemd very happy and helped me clean up the place after
all the others had already left. :-(

Excerpts from martin f krafft's message of 2011-04-21 07:24:59 +0200:
> The funeral service will be held as expected: Leonhardskirche in
> Basel, Thu 28 April, 11:00 Uhr.

I'm going to attend the funeral tomorrow with some fellow DDs from
debian.ch. We'll meet tomorrow at 10am at the meeting point of the
Basel main train station and go to Leonhardskirche together from
there. If someone else wants to join us, please reply to me by private
mail, so we know that we have to wait for you.

See you tomorrow and rest in peace Adrian!


Gaudenz -- Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~

Feedback from von Bidder's wife

Diana von Bidder sent a private email to Stefano Zacchiroli, the Debian Project Leader. Stefano forwarded the email to debian-private.

One of the key things to note here is that Adrian von Bidder was doing Debian work from home. In other words, she confirms the phenomena of unpaid overtime work that is obfuscated by the structure of open source organizations.

Subject: Re: condolences for Adrian
Date: Mon, 25 Apr 2011 15:02:18 +0200
From: Diana von Bidder <diana@fortytwo.ch>
To: Stefano Zacchiroli <leader@debian.org>

Dear Stefano
Thank you for your wonderful mail! Yes Debian and people were very
important to Adrian. I was glad that he was not only sitting alone in
front of his computer but to know that there are people out there that
estimate him and are his friends even if most of you did not know each
other personally.
The way you describe him (empathy, calm, insight, ... - just the Adrian
I know) assures me on how good friends of Adrian are out there. And I
will always continue to think of this (in a good way!) when continuing
to use debian (which I became quite fond of because of Adrian). 
It's a pity that he couldn't go to Banja Luca anymore which he did so
much look forward to. Anyway, I wish you all the best and hope you
continue your good work.

- Diana

von Bidder's insights on Cuba

Shortly before the suicide of Frans Pop, debian-private had discussions about how to engage Debian Developers from Cuba.

This is an awkward question because the US has an embargo against Cuba but the European countries do not respect the US embargo. Many European countries actively encourage their citizens to ignore the US policy.

von Bidder suggests that people and organizations in Switzerland are free to trade with Cuba, therefore, SPI should leave the USA and move to Switzerland.

Subject: Re: Forthcoming acceptance of a Cuban DD
Date: Sat, 5 Jun 2010 18:37:41 +0200
From: Adrian von Bidder <avbidder@fortytwo.ch>
To: debian-private@lists.debian.org

On Saturday 05 June 2010 14.33:05 Florian Weimer wrote:
> * Adrian von Bidder:
> > 
> > Flee the US to a country with friendlier legislation?
> Doesn't really work for most pairs of countries because the legal
> system of most countries is not that friendly to foreigners (no voting
> rights, deportation in case of legal challenges etc.).  Or do you
> suggest moving the initial upload server?

I meant: the organisational core of Debian (SPI, location of central resources, ...) should move.

> Anyway, the U.S. has probably the most liberal export regulations in
> the world.  In other places, it's not totally clear if the mass-market
> crypto exceptions apply to software which is never sold as such.


I'm no expert on law at all, but since we (== Debian) are not physically moving goods around and are not doing business transactions (we're accepting donations, but we don't sell anything), I'd be somewhat surprised if any export legislation could eve be applied to an organisation likde Debian in Switzerland.

I'll not comment further, since this options is not being considered at present AFAICT.

-- vbi

Grudnuk demand sustenance!

Ongoing impact of emotional stress in the Debian community

Resignation of Steve Kemp

Subject: Resignation...
Date: Fri, 29 Apr 2011 17:20:32 +0100
From: Steve Kemp <skx@debian.org>
To: debian-private@lists.debian.org

  I hereby resign from the Debian project, effective

  The following three packages are up for adoption:

    asql - Query apache logfiles via SQL.

    chronicle - Blogging thing.

    rinse - debootstrap-like took for RPM distros.
            (Thomas Lange will claim this.)


Gerfried Fuchs / Rhonda D'Vine

Subject: [VAC] to rethink involvement
Date: Mon, 2 May 2011 12:07:39 +0200
From: Gerfried Fuchs <rhonda@deb.at>
To: debian-private@lists.debian.org


 Given that some people think that it's a personal offence when they
being asked about the background of decisions and rather enjoy shouting
at someone instead of giving the reasoning, and the discussion style
within Debian not improving to the point that people who are pointing it
out are intimidated to the part to even write rebuttals, I can't
currently bear the climate anymore with respect to things that I invest
a lot of energy and nerves into.

 I'm happy that in the most crucial areas I am involved there is at
least a second person, if not more, and I'm sorry for them to have to
carry now more burden because I won't be helping out for the forseeable
future, but being called aggressive for asking questions on the
background is not the way I want to continue.

 I'll stick to my packages and like always, am willing to accept
interested co-maintainers, will continue to do my QA work related to
stable bug squashing and regular bug nagging, this VAC is stepping back
from roles that I managed to get things done for the benefit of our
users and also the public overall impression of Debian. The next planned
steps will have to rest though.

 Highly disappointed, demotivated and depressed, on the overall level.
Fühlst du dich mutlos, fass endlich Mut, los      |
Fühlst du dich hilflos, geh raus und hilf, los    | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los    |

Censoring discussions about suicide again

Subject: Requesting corrective action against lkcl@lkcl.net
Date: Thu, 25 Aug 2011 00:21:52 +0100
From: Jurij Smakov <jurij@wooyd.org>
To: debian-private@lists.debian.org


Today one Luke Kenneth Casson Leighton <lkcl@lkcl.net> posted a message to debian-arm mailing list (cross-posted to lots of other lists open-source-related lists):


After reading through a couple of pages of conspiracy-theory laden drivel, I was extremely disturbed to find the mention of Frans Pop's death in the context of this message. I think that using this tragedy to push forward one's (rather dubious) political agenda is way beyond bad taste, and I would like to see a fairly strong statement made by the project to inform this individual, that such behavior on Debian mailing lists is not going to be tolerated. Personally, I would not feel too bad about a complete Debian's mailing lists ban at this point, however it might be that I'm overreacting, and we can reach a consensus on what the appropriate course of action should be.

To put thing in perspective, this is the second incident involving lkcl in less than a week. Ben Hutchings has previously requested lkcl to be banned from BTS on the grounds of him interfering with kernel team's bug handling:


I request this message to remain private forever.

Best regards,
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC


Krafft is the developer who was closest to von Bidder and reported the death to us.

Switzerland takes great pride in the cows and dairy products.

Subject: Mooing solves everything
Date: Wed, 7 Dec 2011 22:14:13 +0100
From: martin f krafft <madduck@debian.org>
Reply-To: madduck@debian.org
To: debian private list 

[Writing to -private with Reply-To set, because this is clearly
a classified topic]

We know about super cow powers and swallowed elephants, and the
power of the Mooing.

What I want to do is collect cow-related stories of relevance to our
project, to prevent an inside joke from dying as Debian prepares to
exit teenagehood.

So, please hit me. What does Debian have to do with mooing?

 .''`.   martin f. krafft       Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 on the other hand, you have different fingers.

Balkan DebConf11 in Banja Luka, Bosnia

The final report notes that thirty eight women attended, eleven percent of the total. Local Bosnian women. This is really high for Debian.

Final report about the tombstone

Some months later, the tombstone was completed and placed at the grave of Adrian von Bidder. von Bidder's wife shared a photo and it was distributed on Debian mailing lists.

Out of 350 people at the funeral, only 5 people came from Debian.

Adrian von Bidder, Debian

It is worth contrasting that image with the emails from debian-private about whether or not Debian money could be contributed to a wreath or similar expense.

After the death of workers at Amnesty International, the organization made public reports about the deaths and gave substantial compensation to at least one of the families.

Subject: Re: Death of Adrian von Bidder
Date: Thu, 21 Apr 2011 08:56:04 +0200
From: Andreas Tille <andreas@an3as.eu>
To: debian-private@lists.debian.org


I admit that e-mails about emotions tend to be turned into flames
and I do not want this here.

On Thu, Apr 21, 2011 at 07:24:59AM +0200, martin f krafft wrote:
> I suggest that we donate 200 CHF from the project (price of a nice
> wreath with writing). If there are other donators, please get in
> touch with me.

The donators of the Debian project intend to spend money for the
development of the Debian project.  If we spend Debian money for a
wreath (or any form of replacement donation) this is not related to the
development of Debian.  It is rather *us* *people* who say goodby to
a friend.  So the money should not come from project funds but rather
from single developers.

Saying this I would like to vote against spending Debian money but
rather doing a separate collection.  I could live with some kind of "de
facto" collection like this:  I will ask for Debian money for DebConf.
In case Debian project money is really spended for Adrian's funeral I'd
simply ask for 10Euro less than I would have done otherwise.

Please do not get me wrong: I'm in any case for showing that the Debian
community is sad about the dead of Adrian.  But I'm not convinced that
this purpose is in the interest of our donators and it finally comes
quite cheap for us individuals to simply spend Debian money.

Kind regards



Individual Debian Developers donated to AMICA Schweiz (people trafficking charity)

Subject: Re: Death of Adrian von Bidder
Date: Tue, 3 May 2011 12:12:41 +0200
From: Didier Raboud <odyx@debian.org>
To: debian-private@lists.debian.org

Le jeudi, 21 avril 2011 12.54:32, Stefano Zacchiroli a écrit :
> Consider this: instead of debating right now whether we should use or not
> money donated by _others_, it would take just a handful people to donate
> there to make the whole debate moot and make the nice gesture that Adrian's
> family has suggested.

Regarding this, as Martin already reported on the swiss community mailing list [0], the amount of CHF 682.78 has been collected and transferred to AMICA as per Adrian's family wishes.

This is more than 3 times the initially suggested amount, without any need for debian.org (or .ch) money.


[0] https://lists.debian.ch/pipermail/community/2011/000541.html , which I'm forwarding here with his permission.

Debian finds USD 10,000 to bring Balkan women to Brazil and another USD 6,000 for the Balkan woman sitting closest to the Debian leader to be an Outreachy

Here is the budget for DebConf19 in Brazil. Look for the lines about Diversity. That is $US 10,000. In the end, they may have spent even more than that. The cost of flights for the women from Balkan countries to come to Brazil is higher because they have to buy visas and they have to take connecting flights in bigger countries.

At the DebConf19 dinner, four of the Balkan women were sitting at the same table as the outgoing Debian Project Leader, Chris Lamb. People took pictures of the group from every direction and published them. Nobody understands why these women were selected and why so much money was spent on women who are all of the same age from the same country. The Debian behavior in this matter was humiliating for women.

The woman sitting closest to Lamb is the same woman who won another $US 6,000 to be an Outreachy. She won that only a few weeks after partying with the developers at DebConf. This is ten times the amount donated to AMICA Schweiz in honor of Adrian von Bidder.

Chris Lamb, Anisa Kuci, Debconf19

Please see my chronological history of how the Debian harassment and abuse culture evolved.

18 March, 2024 12:00PM

hackergotchi for Gunnar Wolf

Gunnar Wolf

After miniDebConf Santa Fe

Last week we held our promised miniDebConf in Santa Fe City, Santa Fe province, Argentina — just across the river from Paraná, where I have spent almost six beautiful months I will never forget.

Around 500 Kilometers North from Buenos Aires, Santa Fe and Paraná are separated by the beautiful and majestic Paraná river, which flows from Brazil, marks the Eastern border of Paraguay, and continues within Argentina as the heart of the litoral region of the country, until it merges with the Uruguay river (you guessed right — the river marking the Eastern border of Argentina, first with Brazil and then with Uruguay), and they become the Río de la Plata.

This was a short miniDebConf: we were lent the APUL union’s building for the weekend (thank you very much!); during Saturday, we had a cycle of talks, and on sunday we had more of a hacklab logic, having some unstructured time to work each on their own projects, and to talk and have a good time together.

We were five Debian people attending: {santiago|debacle|eamanu|dererk|gwolf}@debian.org. My main contact to kickstart organization was Martín Bayo. Martín was for many years the leader of the Technical Degree on Free Software at Universidad Nacional del Litoral, where I was also a teacher for several years. Together with Leo Martínez, also a teacher at the tecnicatura, they contacted us with Guillermo and Gabriela, from the APUL non-teaching-staff union of said university.

We had the following set of talks (for which there is a promise to get electronic record, as APUL was kind enough to record them! of course, I will push them to our usual conference video archiving service as soon as I get them)

Hour Title (Spanish) Title (English) Presented by
10:00-10:25 Introducción al Software Libre Introduction to Free Software Martín Bayo
10:30-10:55 Debian y su comunidad Debian and its community Emanuel Arias
11:00-11:25 ¿Por qué sigo contribuyendo a Debian después de 20 años? Why am I still contributing to Debian after 20 years? Santiago Ruano
11:30-11:55 Mi identidad y el proyecto Debian: ¿Qué es el llavero OpenPGP y por qué? My identity and the Debian project: What is the OpenPGP keyring and why? Gunnar Wolf
12:00-13:00 Explorando las masculinidades en el contexto del Software Libre Exploring masculinities in the context of Free Software Gora Ortiz Fuentes - José Francisco Ferro
13:00-14:30 Lunch    
14:30-14:55 Debian para el día a día Debian for our every day Leonardo Martínez
15:00-15:25 Debian en las Raspberry Pi Debian in the Raspberry Pi Gunnar Wolf
15:30-15:55 Device Trees Device Trees Lisandro Damián Nicanor Perez Meyer (videoconferencia)
16:00-16:25 Python en Debian Python in Debian Emmanuel Arias
16:30-16:55 Debian y XMPP en la medición de viento para la energía eólica Debian and XMPP for wind measuring for eolic energy Martin Borgert

As it always happens… DebConf, miniDebConf and other Debian-related activities are always fun, always productive, always a great opportunity to meet again our decades-long friends. Lets see what comes next!

18 March, 2024 04:00AM

March 17, 2024

hackergotchi for Daniel Pocock

Daniel Pocock

Flashback 2003: Debian has always had a toxic culture

People are estimating that Debian has spent over $200,000 paying women to be volunteers through Outreachy. At the end of their Outreachy programs, they all disappear. Would it be better to use this money to get advice about fixing the culture? The payments to women are an admission that Debian culture is bad and women won't have anything to do with it voluntarily.

Despite everybody knowing the culture of the group is the root of all evil, they continue to look for scapegoats. If they can just punish one more person, everybody else will behave nicely, Debian will be "safe" and women will join.

Here is an email from the debian-private (widely leaked) gossip network giving an insight into the culture in 2003. It looks a lot like the culture today. In 20 years, despite all the forced resignations and expulsions nothing really changed.

Subject: Re: Fwd: Rejecting NM applicant Norman Walsh <ndw@nwalsh.com>
Date: Thu, 3 Jul 2003 20:47:58 +0000 (UTC)
From: Martin Wheeler <msw@startext.demon.co.uk>
To: mark@dulug.duke.edu
CC: debian-private@lists.debian.org

On Wed, 2 Jul 2003 mark@dulug.duke.edu wrote:

> > Dang. Maybe we should streamline our process.
> Double dang. If we can't find a way to get Norm in (who BTW offered to maintain
> all the DocBook packages), then something about the application process needs to
> be fixed.

 . . .

> > I am rejecting the Debian New Maintainer Norman Walsh <ndw@nwalsh.com> on
> > his own request. Norman, unfortunatly, does not have enough time to spend
> > for the NM process

I heartily concur.

I too, have abandoned the process of attempting to become an NM.
And, I suspect, for many of the same reasons.
Having had to wait for over a year for any real response to my initial
enthusiasm, I had already lost most of my interest in becoming a DD
(for documentation only), and had only lukewarm reactions to the mails I
eventually received.  (Mainly upbraiding me with comments like: "you have to
really, really want this, you know" -- at the same time making me wonder why
the hell I ever thought I might want to join this group of narcissistic
navel-gazers -- and generally attempting to make me feel like a fourth-class
citizen because my interests lie only in lowly documentation, NOT in the
highly-valued elite skills of programming/packaging.)

Overall, I was given a very strong impression that DDs regard themselves as
being the 'l33test of the 'l33t; that in going through the NM process it is
more important to be recognised as being a putative member of a highly
exclusive undergraduate-style sorority / club than it is to have any
expertise to offer to the group; and that unwarranted sobbery and attitudes
of exclusivity of the group reign supreme.  (Really.  This attitude came
to me more strongly than any other -- which surprised me greatly, as I am
personally acquainted with a few DDs, none of whom comes over to me in that
way at all.)

Frankly though, I eventually lost interest.  (Is it any wonder?)  To the
point where I couldn't even be bothered to reply any more to any of the
I received.  (Round about the P&P stage.)  There was NO real or effective
dialogue between myself and the group I thought I could offer something to;
and in fact, very little real desire to offer anything any more, on my part.
Is it any wonder then that in these circumstances once-enthusiastic
folks just
quietly drift away?

My last dealings with the NM process were when I went on an irc channel
-- to
be met instantly with a hostile: "what are you doing here?  I thought we got
rid of you two weeks ago."

Why on earth should I persist in trying to offer my skills to a group like

Genuinely puzzled,

Here is what the thread looks like. Women seem to have a nose for this type of thing. They feel really uncomfortable when their name appears in something like this so they don't even begin to get involved.

Norman Walsh, Debian, gossip

17 March, 2024 10:30PM


Plagiarism: Axel Beckert (ETH Zurich) & Debian Developer list hacking

University of Western Australia Law Review [Vol 51(2):46] has recently published a paper on Copyright Nazi Plunder: How the Nazis Aryanized Jewish Works. (backup copy). It is written by Lior Zemer and Anat Lior.

The paper begins by considering the concept of Aryanization. This term is most widely associated with the looting of physical goods such as paintings and gold bars from the homes of wealthy Jews. The paper contends that the misappropriation of Jewish intellectual property rights was on par with the looting of physical goods:

The narrative of the ‘Aryanization’ process focuses entirely on physical property and its economic effects in the interwar period. However, this process also took place with regards to intellectual property which was forcefully transferred from Jewish authors to non-Jews individuals in Nazi Germany.

The paper considers various types of intellectual property, including sheet music, fiction novels and non-fiction novels. On the topic of non-fiction, Zemer and Lior note:

As mentioned, when the Nazis rose to power, books that were considered “un-German” were burnt. However, another category of non-fiction books presented a different type of challenge. Those books’ content was apolitical, they were extremely popular, loved, and useful. The only problem was that they were authored by Jews. This led their publishers, who were usually implicated with the Nazi regime, to Aryanize them maintaining the vast majority of the content, but republishing under a non-Jew name.

We can see the same phenomena emerging in Debian today. The victims are not necessarily Jewish but the tactics are the same.

We can see the Debian trademark is used this way: the name Debian is given more prominent exposure than the names of the individual authors. If some of the authors (Debian Developers) are snuffed out altogether, the only thing left to see is the trademark.

In 2016, rogue developers used the Debian Project to disseminate falsified harassment stories about Dr Jacob Appelbaum.

Appelbaum is an obviously Jewish name. Dr Appelbaum's Wikipedia profile tells us he is of Jewish ancestry but identifies as an atheist. In an earlier blog, we examined the fact that people of Jewish ancestry would still be treated like Jews even if they renounced their religion.

During the Debian-private lynching of Dr Appelbaum, the following comment appeared trivializing Dr Appelbaum's contributions as a co-author of Debian:

Subject: Re: What is true and what is false in accusations against Jacob Appelbaum
Date: Sat, 13 Aug 2016 23:22:13 +0200
From: Nicolas Dandrimont <olasd@debian.org>
To: Debian Private List <debian-private@lists.debian.org>

* Andreas Tille <andreas@an3as.eu> [2016-08-13 23:07:52 +0200]:

> Hi folks,
> <snip>
> What do we in Debian really know about all this for sure?  Its not that
> I trust an article since its just in the news, but I never read any
> detailed information that has backed up our decision.

We know for sure that Members of the Debian Project have come forward with
their testimonies of misconduct by Jacob Appelbaum.

We know for sure that some Debian Contributors, as well as some prospective
contributors, would feel threatened by his continued presence in the project.

We know for sure that his contributions to Debian are non-existent.

Do we really need to rehash this over and over again?
Nicolas Dandrimont

BOFH excuse #311:
transient bus protocol violation

Nicolas Dandrimont is a member of the Debian Account Managers team. He works for the Software Heritage Foundation, a non-profit affiliated with the United Nations Educational, Scientific and Cultural Organization (UNESCO). What we see in Dandrimont's email from 2016 is that he was exhibiting the same pattern of behavior that Zemer and Lior called "Copyright Nazi Plunder". He claims that Dr Appelbaum's contributions to Debian are non-existent and therefore Dr Appelbaum can be rubbed out.

In fact, the very first time the name of a Debian Developer was obfuscated in this way was the case of Shaya Potter. Shaya, like Appelbaum, an obviously Jewish name. Potter maintained the hebcal package, the Perpetual Jewish Calendar in Debian.

We have seen the same line of attack used against another Debian Developer, Daniel Pocock. Pocock explains how two Italians, Enrico Zini and Mattia Rizzolo have removed his name from the list of authors (Debian Developers). He published this screenshot of the plagiarism:

Enrico Zini, Mattia Rizzolo, plagiarism, Debian

Now we have more evidence of a deliberate plagiarism from Axel Beckert at the ETH Zurich. Beckert has already been exposed engaging in perjury. Here is where Beckert tries to trivialize Mr Pocock's right to recognition for his co-authorship of Debian:

Axel Beckert, ETH Zurich, plagiarism, Debian

Translated to English and paraphrased to help us see through the use of jargon, the statement says:

Mr Pocock continues to present himself as a co-author (Debian Developer) even though Debian cabal members prohibited him from taking credit for his work.

The legal document is signed by Beckert:

Axel Beckert, ETH Zurich, Debian, perjury

Beckert's employer, ETH Zurich, is one of Europe's leading research institutions. One would expect their employees to set an example of giving each and every author proper credit for their work. Beckert's rogue behavior is the polar opposite of what we would expect.

Swiss law on copyright states (Copyright Act / Droit d'auters):

Protection expires: ... in the case of computer programs, 50 years after the death of the author

There is nothing the Copyright Act giving co-authors the power to extinguish the rights of their peers.

The Debian.ch association does not pay the authors (Debian Developers) for their work. The only consideration they have promised is the public recognition for their work. Removing the name from the list denies co-authors their proper recognition. It is not only plagiarism, it is also a lot like bouncing a cheque.

Other victims of Debian plagiarism

The names of these people were involuntarily removed from the list of Debian Developers, denying them proper recognition for their works of authorship.

17 March, 2024 07:00PM

Thomas Koch

Minimal overhead VMs with Nix and MicroVM

Posted on March 17, 2024

Joachim Breitner wrote about a Convenient sandboxed development environment and thus reminded me to blog about MicroVM. I’ve toyed around with it a little but not yet seriously used it as I’m currently not coding.

MicroVM is a nix based project to configure and run minimal VMs. It can mount and thus reuse the hosts nix store inside the VM and thus has a very small disk footprint. I use MicroVM on a debian system using the nix package manager.

The MicroVM author uses the project to host production services. Otherwise I consider it also a nice way to learn about NixOS after having started with the nix package manager and before making the big step to NixOS as my main system.

The guests root filesystem is a tmpdir, so one must explicitly define folders that should be mounted from the host and thus be persistent across VM reboots.

I defined the VM as a nix flake since this is how I started from the MicroVM projects example:

  description = "Haskell dev MicroVM";

  inputs.impermanence.url = "github:nix-community/impermanence";
  inputs.microvm.url = "github:astro/microvm.nix";
  inputs.microvm.inputs.nixpkgs.follows = "nixpkgs";

  outputs = { self, impermanence, microvm, nixpkgs }:
      persistencePath = "/persistent";
      system = "x86_64-linux";
      user = "thk";
      vmname = "haskell";
      nixosConfiguration = nixpkgs.lib.nixosSystem {
          inherit system;
          modules = [
            ({pkgs, ... }: {

            environment.persistence.${persistencePath} = {
                hideMounts = true;
                users.${user} = {
                  directories = [
                    "git" ".stack"
              environment.sessionVariables = {
                TERM = "screen-256color";
              environment.systemPackages = with pkgs; [
                (haskell-language-server.override { supportedGhcVersions = [ "94" ]; })
              fileSystems.${persistencePath}.neededForBoot = nixpkgs.lib.mkForce true;
              microvm = {
                forwardPorts = [
                  { from = "host"; host.port = 2222; guest.port = 22; }
                  { from = "guest"; host.port = 5432; guest.port = 5432; } # postgresql
                hypervisor = "qemu";
                interfaces = [
                  { type = "user"; id = "usernet"; mac = "00:00:00:00:00:02"; }
                mem = 4096;
                shares = [ {
                  # use "virtiofs" for MicroVMs that are started by systemd
                  proto = "9p";
                  tag = "ro-store";
                  # a host's /nix/store will be picked up so that no
                  # squashfs/erofs will be built for it.
                  source = "/nix/store";
                  mountPoint = "/nix/.ro-store";
                } {
                  proto = "virtiofs";
                  tag = "persistent";
                  source = "~/.local/share/microvm/vms/${vmname}/persistent";
                  mountPoint = persistencePath;
                  socket = "/run/user/1000/microvm-${vmname}-persistent";
                socket = "/run/user/1000/microvm-control.socket";
                vcpu = 3;
                volumes = [];
                writableStoreOverlay = "/nix/.rwstore";
              networking.hostName = vmname;
              nix.enable = true;
              nix.nixPath = ["nixpkgs=${builtins.storePath <nixpkgs>}"];
              nix.settings = {
                extra-experimental-features = ["nix-command" "flakes"];
                trusted-users = [user];
              security.sudo = {
                enable = true;
                wheelNeedsPassword = false;
              services.getty.autologinUser = user;
              services.openssh = {
                enable = true;
              system.stateVersion = "24.11";
              systemd.services.loadnixdb = {
                description = "import hosts nix database";
                path = [pkgs.nix];
                wantedBy = ["multi-user.target"];
                requires = ["nix-daemon.service"];
                script = "cat ${persistencePath}/nix-store-db-dump|nix-store --load-db";
              time.timeZone = nixpkgs.lib.mkDefault "Europe/Berlin";
              users.users.${user} = {
                extraGroups = [ "wheel" "video" ];
                group = "user";
                isNormalUser = true;
                openssh.authorizedKeys.keys = [
                  "ssh-rsa REDACTED"
                password = "";
              users.users.root.password = "";
              users.groups.user = {};

    in {
      packages.${system}.default = nixosConfiguration.config.microvm.declaredRunner;

I start the microVM with a templated systemd user service:

Description=MicroVM for Haskell development

ExecStartPre=/usr/bin/sh -c "[ /nix/var/nix/db/db.sqlite -ot %h/.local/share/microvm/nix-store-db-dump ] || nix-store --dump-db >%h/.local/share/microvm/nix-store-db-dump"
ExecStartPre=ln -f -t %h/.local/share/microvm/vms/%i/persistent/ %h/.local/share/microvm/nix-store-db-dump
ExecStartPre=-%h/.local/state/nix/profile/bin/tmux new -s microvm -d
ExecStart=%h/.local/state/nix/profile/bin/tmux new-window -t microvm: -n "%i" "exec %h/.local/state/nix/profile/bin/nix run --impure %h/.local/share/microvm/vms/%i/flake"

The above service definition creates a dump of the hosts nix store db so that it can be imported in the guest. This is necessary so that the guest can actually use what is available in /nix/store. There is an effort for an overlayed nix store that would be preferable to this hack.

Finally the microvm is started inside a tmux session named “microvm”. This way I can use the VM with SSH or through the console and also access the qemu console.

And for completeness the virtiofsd service:

Description=serve host persistent folder for dev VM

ExecStart=%h/.local/state/nix/profile/bin/virtiofsd \
 --socket-path=${XDG_RUNTIME_DIR}/microvm-%i-persistent \
 --shared-dir=%h/.local/share/microvm/vms/%i/persistent \
 --gid-map :995:%G:1: \
 --uid-map :1000:%U:1:

17 March, 2024 12:00AM

March 16, 2024

hackergotchi for Sean Whitton

Sean Whitton

Eight years in Tucson

I spent eight years doing teaching and research in Philosophy at the University of Arizona, in Tucson, Arizona, from 2015 to 2023. I now have a love for America and its people, even though I am not sure I could ever live there again. Americans would say that Tucson is an outlier, an odd post-frontier town which is not reflective of the rest of the nation’s cities. And I only really visited New York, the Bay Area, and two towns in Mississippi, so I mostly take them at their word. But I could see something in common between these places that’s distinct from where else I’ve lived. I will not seek to capture that here, but instead focus on how life in Tucson was, and some things I learned.

When I first arrived I was very unsure about whether it would be a good idea to stay. I was ambivalent about reentering academia, and uneasy with the contractual terms under which I would be able to study there without paying any money for it. Once I did decide to stay for at least one semester, I tried to get myself set up with a daily routine that would be suitable for making progress with my classes, while also allowing me time to pursue my other interests. So I went to check out the library, that being where I’d done all my work as an undergraduate. I was appalled to find that there wasn’t a culture of silence. Supposedly the upper floors were designated as quiet, but the only way I could feel confident in not being interrupted was to find one of the small study desks sequestered in far corners, with those moveable shelves of books they have in university libraries between me and everyone else.

This initial problem with finding quiet and concentration somewhat epitomises a lot of my academic experiences in Tucson. I felt that the academic culture in the US was a noisy one: talking loudly to each other was valued a lot more highly than it had been in the UK, and real deep reading and thinking was something that people did on their own, at home, and didn’t talk about much. You talked about all the writing you had been doing, and indeed about what people you’d read had said, but with the latter it was as though the actual reading had happened outside of time, and the things happening within time were on-campus activities, and the hours of writing. You might say, well, it was grad school, of course the focus is more on producing one’s own work. But we did read a lot, in fact, and it’s not as though undergraduate Philosophy at Oxford didn’t involve regularly spending a lot of time writing, even if tute essays are something strange and staccato when compared to what we tried to write in grad school. And this is not to say that I didn’t learn and develop a great deal from many of those loud conversations, both in and out of seminar, but I think a productive campus needs more quiet, too.

We had two kinds of classes, lecture-style with both undergrad and graduate students, though in smaller groups than undergrad, and seminars with almost exclusively graduate students. Many people would take as many seminars as they were allowed to, and we all continued to join seminars once we’d completed coursework. But a few of us, including me, joined as many lectures as we could, even after completing coursework. I just love listening to masters of their domains of study. This was distinctly uncool – you’ve got to practice producing in order to become a philosopher yourself, would go the thought. But it’s not as if I didn’t produce too. And you can’t be disdainful of continuing to pump good philosophy into your head. Perhaps my attraction to the lecture classes was because it was somewhat closer to the deep reading with which I was familiar, that proved elusive on my American campus. You have to do the hard work to make philosophical progress, but you can’t engage with philosophy only by doing what feels like hard graft if you want to succeed, I think. You have to engage with it in other ways too, like just by listening.

A quality about the Americans I knew well which struck me early was their generosity with time, friendliness and just materially. I mean to include here peers who were my friends, as well as people who were part of my life for extended periods, but with whom I didn’t have enough in common for friendship. When I first arrived in Tucson I lived in a house in the Sam Hughes neighbourhood, owned by the parents of one of my two roommates, Nick. He was from Phoenix, and was taking a second undergraduate degree after deciding that he didn’t really want to follow in his father’s footsteps and become a doctor, but wanted to be a programmer. Nick and I would drive to the supermarket together every Saturday in his big Ford truck, and we developed a habit of listening to The Eagle’s Take It Easy on the ride back. I never signed a lease for living in that place. At one point I was short of American money after spending a lot on a summer trip, and I asked whether I could pay my rent erratically for a while, as my stipend came in over the following academic year, rather than transferring savings from the UK. It was no problem to do this. One Spring Break and one Thanksgiving, I joined Nick in driving up to Paradise Valley, Phoenix, to stay with his family. His mother had sat in the state House of Representatives as a Republican, and had two very yappy chihuahuas, traumatised as they had been by a previous owner. At one point they had to stay with us down in Tucson for a few days. One of them refused to walk on the tile floor, and we had to create a bridge of doormats between the carpeted room in which it was sleeping and the front door.

Nick introduced me to the American love for pulp cinema, which we don’t really have in the UK. Once Nick graduated and I developed closer friendships in my department, I watched a lot more such films with philosophers.

After living with Nick I lived alone, for nine months, in a small terraced bungalow, for barely any rent. The people around me were mostly economically deprived retirees, and some young people working jobs like driving some kind of tractor around on the extended grounds of the airport, on his own, far away from the planes. At one point a different corporation took over management of the properties, and they tried to make us pay an additional fee for the laundry room that had until then been included. They did this by installing a lock, and telling us we had to come down to the office to pay the new fee and receive a key. My neighbour Wilma and I took the bus down to the office and objected, and eventually got keys for free. Now that I think about it, I don’t know whether other existing tenants ended up paying for it. I improved my understanding of how the economically deprived, even in the West, can get casually abused by businesses, from this.

Wilma would sit behind her screen door in the evening, without the lights on, and a disembodied greeting would float out to me, among the crying cicadas, as I biked up to my own place. I had a nine month lease and I left that place right after because I was fed up with the insects infesting the place. But at the same time, living there was when I figured out how to be happy with my life in Tucson, and I maintained that happiness from then until the pandemic, when everything got hard for most everyone. Wilma was generous like Nick.

Before I said goodbye to Nick and moved in next door to Wilma, I tried to live a life involving the kind of variety that my life in Korea had had, before I went to Tucson. I was continually frustrated in this, because it was too distant from the lives that the people around me led for me to be able to figure out how to do it there, and more mundanely, because of how car-centric Tucson is. When I moved into my place on my own I somehow decided that I would try focusing entirely on my university work, and I also expanded that work a bit by registered for a seminar in Japanese literature up at the East Asian Studies department. My future PhD thesis supervisor Julia joined me for that seminar and one more the next semester, and I was able to draw upon some novels we read for my thesis.

I didn’t have Internet access at my little place, and we had finally got some designated-silent shared offices for grad students, in addition to the noisy ones where people held office hours, and talked loudly about philosophy. Suddenly my life got a lot more focused and quieter. I would get up and scramble an egg with some cheese and black pepper, and have it in a pitta bread-like thing which I sliced, froze, and defrosted in the toaster. I’d head to campus, early, and write. I’d do my classes and reading. Then I’d go swim in the big outside pool the university had, in the dark. I’d do one or two lengths at a time and then hold onto the edge and just think hard. I especially did this after my literature classes. They ran until 6pm, I think, and then I’d go to the pool, and do my lengths interspersed with thinking hard about the literature we’d discussed. Then after a long time out I’d go home late, and listen to pre-downloaded tabletop roleplaying podcasts. I slept the best I ever have, in the quiet among the noises of insects – it really was quieter despite all that noise – on this wonderful Japanese floor bed I’d found on Amazon. What I discovered during that time was the power of a simple life, I think. Or perhaps it was more about not trying to live a more complex life than the place you live allows. Or perhaps it wasn’t anything more than about the benefits of giving up fighting against a prevalent culture of workaholism – but at least, it was giving in to that situation in a way which strongly benefitted me. Going with the flow, or something.

I tried to build upon my new focus with the next phase of time in Tucson. I moved into the university’s grad student dorms, living right next to campus, in the middle of a commercial district for students that felt like one had left Tucson and gone somewhere more contemporary. This was a change I appreciated a lot, having, as I said, grown tired with all the bugs. At this time I got to know my now-fiancée Ke. I had finished with class credits but sat in on so many classes and reading groups, while still continuing to write a lot, that my work life didn’t change too much. While most people would start teaching their own classes at this point, I asked if I could continue to be assigned teaching assistant roles instead; I started teaching on my own only during the pandemic. My social life, aside from time with Ke and her roommate, mostly involved cycling East for forty minutes or so, to a house in which three fellow philosophers lived. I loved those evening rides there and nighttime rides back. Tucson is a dark city for the astronomy, and it’s also flat and bike-friendly, so for most of that journey I was on a route where various things had been set up to discourage cars from staying on the same roads as cyclists. The friends I had who lived in that house, Brandon, Tyler and Nathan, and later Nathan’s partner Meg and Tyler’s partner Amanda, were now the humblingly generous Americans in my life. We got two tabletop roleplaying groups going, with me and Nathan running a game each, and playing in each other’s. Later we were a pandemic pod, watching through Terrace House: Opening New Doors together.

I also significantly ramped up my involvement in Debian at around this time. Each Saturday morning I would visit a local coffee roasters, Caffe Lucè, have an excellent bagel and a couple of cups of coffee with half-and-half, and work on my packages.

I’ve described how a built for myself something of a sense of belonging studying Philosophy in Tucson. But ultimately, it did not compare in this regard to the place I was most content, which was in Balliol, my Oxford college. The Arizona grad students would go out for beer at a nice place called Time Market on some Friday nights, and while it was often a very good time, I would walk home with this heavy feeling of disappointment. I can now identify this as the lack of a sense of camraderie and belonging which I thought was essential to a productive academic environment. I can now also see that I had an intellectual kinship with Julia, Nathan, Tyler, Ke and others which was just as valuable, but it was still something had only with individuals, lacking a sense of being part of something not only bigger but also concrete, actually in the world. The pressures of professional academia in the US didn’t seem to leave us enough space to have what I remember us having had at Balliol. Not that the Balliol I inhabited still exists – it was dependent as much on the place as the people I was there with.

The advent of the pandemic, and the remainder of my time in Tucson after the pandemic, eroded this life I’d figured out. Our department eroding too was part of that – a lot of people moved away to be with their partners or families when lockdowns began, and faculty retired (and in one case tragically died), and so we lost a critical mass of intellectually energetic individuals. This hit me hard, and I did not have the emotional resources remaining, post-pandemic, to try to kick start things again, as previous versions of myself might have tried to do. I find, though, that most of my memories of life and Philosophy in Tucson are of the good times, and I find it easy, now at least, to write a post like this one.

When I think back to all the classes I took, discussions I had and essays I wrote and revised, I can see significant intellectual development. At the same time, it was as though my development in other senses was put on hold for those eight years, in a way that it had not been at Oxford and in Korea. (I even find myself wanting to say that my whole life was put on hold, but that would be hyperbolic even if it felt that way sometimes, for as I have said, I developed many important friendships.) Postgraduate Philosophy was just too consuming. I don’t know if it could have been other way, but I knew all along that it had to stop at some point; I knew that I couldn’t put all the other respects in which I wanted to grow on hold forever. Somehow, Oxford got this balance right: it managed to be just as satisfyingly intense and thrilling, without being quite all-consuming. Of course, I probably have rose-tinted glasses. It does seem, though, that European hard work manages to be more balanced, at least for what I seek to achieve, than American hard work.

During my final year, a current postdoc at Oxford happened to visit Tucson to speak at a political philosophy conference. Our quiet (to her), old-fashioned, relatively informal academic life out in the desert as grad students seemed to have a lot of advantages over hers in Oxford, despite how she had graduated from her doctorate and had obtained an academic job, and we were students. Until I met her, I had taken for granted, I think, all the ways that academic life in Tucson was quite like Balliol undergrad had been – she told me how her colleagues are all on Twitter, but none of us were, really. When I first arrived in Tucson I found it distressing how much more of an ivory tower it seemed, with Oxford being such a politically engaged place. In the end I am very glad I did a humanities PhD where I did, and am deeply grateful to America.

16 March, 2024 12:35AM

March 14, 2024

hackergotchi for Gregor Herrmann

Gregor Herrmann

teamwork in practice

teamwork, or: why I love the Debian Perl Group:

elbrus has introduced a (very untypical) package into the Debian Perl Group in 2022.

after changes of the default compiler options (-Werror=implicit-function-declaration) in debian, it didn't build any more & received an RC bug.

because I sometimes like challenges, I had a look at it & cobbled together a patch. as I hardly speak any C, I sent my notes to the bug report & (implictly) asked for help. – & went out to meet a friend.

when I came home, I found an email from ntyni, sent less than 2 hours after my mail, where he friendly pointed out the issues with my patch – & sent a corrected version.

all I needed to do was to adjust the patch & upload the package. one more bug fixed, one less task for us, & elbrus can concentrate on more important tasks :)
thanks again, niko!

14 March, 2024 10:10PM

hackergotchi for Matthew Garrett

Matthew Garrett

Digital forgeries are hard

Closing arguments in the trial between various people and Craig Wright over whether he's Satoshi Nakamoto are wrapping up today, amongst a bewildering array of presented evidence. But one utterly astonishing aspect of this lawsuit is that expert witnesses for both sides agreed that much of the digital evidence provided by Craig Wright was unreliable in one way or another, generally including indications that it wasn't produced at the point in time it claimed to be. And it's fascinating reading through the subtle (and, in some cases, not so subtle) ways that that's revealed.

One of the pieces of evidence entered is screenshots of data from Mind Your Own Business, a business management product that's been around for some time. Craig Wright relied on screenshots of various entries from this product to support his claims around having controlled meaningful number of bitcoin before he was publicly linked to being Satoshi. If these were authentic then they'd be strong evidence linking him to the mining of coins before Bitcoin's public availability. Unfortunately the screenshots themselves weren't contemporary - the metadata shows them being created in 2020. This wouldn't fundamentally be a problem (it's entirely reasonable to create new screenshots of old material), as long as it's possible to establish that the material shown in the screenshots was created at that point. Sadly, well.

One part of the disclosed information was an email that contained a zip file that contained a raw database in the format used by MYOB. Importing that into the tool allowed an audit record to be extracted - this record showed that the relevant entries had been added to the database in 2020, shortly before the screenshots were created. This was, obviously, not strong evidence that Craig had held Bitcoin in 2009. This evidence was reported, and was responded to with a couple of additional databases that had an audit trail that was consistent with the dates in the records in question. Well, partially. The audit record included session data, showing an administrator logging into the data base in 2011 and then, uh, logging out in 2023, which is rather more consistent with someone changing their system clock to 2011 to create an entry, and switching it back to present day before logging out. In addition, the audit log included fields that didn't exist in versions of the product released before 2016, strongly suggesting that the entries dated 2009-2011 were created in software released after 2016. And even worse, the order of insertions into the database didn't line up with calendar time - an entry dated before another entry may appear in the database afterwards, indicating that it was created later. But even more obvious? The database schema used for these old entries corresponded to a version of the software released in 2023.

This is all consistent with the idea that these records were created after the fact and backdated to 2009-2011, and that after this evidence was made available further evidence was created and backdated to obfuscate that. In an unusual turn of events, during the trial Craig Wright introduced further evidence in the form of a chain of emails to his former lawyers that indicated he had provided them with login details to his MYOB instance in 2019 - before the metadata associated with the screenshots. The implication isn't entirely clear, but it suggests that either they had an opportunity to examine this data before the metadata suggests it was created, or that they faked the data? So, well, the obvious thing happened, and his former lawyers were asked whether they received these emails. The chain consisted of three emails, two of which they confirmed they'd received. And they received a third email in the chain, but it was different to the one entered in evidence. And, uh, weirdly, they'd received a copy of the email that was submitted - but they'd received it a few days earlier. In 2024.

And again, the forensic evidence is helpful here! It turns out that the email client used associates a timestamp with any attachments, which in this case included an image in the email footer - and the mysterious time travelling email had a timestamp in 2024, not 2019. This was created by the client, so was consistent with the email having been sent in 2024, not being sent in 2019 and somehow getting stuck somewhere before delivery. The date header indicates 2019, as do encoded timestamps in the MIME headers - consistent with the mail being sent by a computer with the clock set to 2019.

But there's a very weird difference between the copy of the email that was submitted in evidence and the copy that was located afterwards! The first included a header inserted by gmail that included a 2019 timestamp, while the latter had a 2024 timestamp. Is there a way to determine which of these could be the truth? It turns out there is! The format of that header changed in 2022, and the version in the email is the new version. The version with the 2019 timestamp is anachronistic - the format simply doesn't match the header that gmail would have introduced in 2019, suggesting that an email sent in 2022 or later was modified to include a timestamp of 2019.

This is by no means the only indication that Craig Wright's evidence may be misleading (there's the whole argument that the Bitcoin white paper was written in LaTeX when general consensus is that it's written in OpenOffice, given that's what the metadata claims), but it's a lovely example of a more general issue.

Our technology chains are complicated. So many moving parts end up influencing the content of the data we generate, and those parts develop over time. It's fantastically difficult to generate an artifact now that precisely corresponds to how it would look in the past, even if we go to the effort of installing an old OS on an old PC and setting the clock appropriately (are you sure you're going to be able to mimic an entirely period appropriate patch level?). Even the version of the font you use in a document may indicate it's anachronistic. I'm pretty good at computers and I no longer have any belief I could fake an old document.

(References: this Dropbox, under "Expert reports", "Patrick Madden". Initial MYOB data is in "Appendix PM7", further analysis is in "Appendix PM42", email analysis is "Sixth Expert Report of Mr Patrick Madden")

comment count unavailable comments

14 March, 2024 09:11AM

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

ciw 0.0.1 on CRAN: New Package!

Happy to share that ciw is now on CRAN! I had tooted a little bit about it, e.g., here. What it provides is a single (efficient) function incoming() which summarises the state of the incoming directories at CRAN. I happen to like having these things at my (shell) fingertips, so it goes along with (still draft) wrapper ciw.r that will be part of the next littler release.

For example, when I do this right now as I type this, I see

edd@rob:~$ ciw.r
    Folder                   Name                Time   Size          Age
    <char>                 <char>              <POSc> <char>   <difftime>
1: waiting   maximin_1.0-5.tar.gz 2024-03-13 22:22:00    20K   2.48 hours
2: inspect    GofCens_0.97.tar.gz 2024-03-13 21:12:00    29K   3.65 hours
3: inspect verbalisr_0.5.2.tar.gz 2024-03-13 20:09:00    79K   4.70 hours
4: waiting    rnames_1.0.1.tar.gz 2024-03-12 15:04:00   2.7K  33.78 hours
5: waiting  PCMBase_1.2.14.tar.gz 2024-03-10 12:32:00   406K  84.32 hours
6: pending        MPCR_1.1.tar.gz 2024-02-22 11:07:00   903K 493.73 hours

which is rather compact as CRAN kept busy! This call runs in about (or just over) one second, which includes launching r. Good enough for me. From a well-connected EC2 instance it is about 800ms on the command-line. When I do I from here inside an R session it is maybe 700ms. And doing it over in Europe is faster still. (I am using ping=FALSE for these to omit the default sanity check of ‘can I haz networking?’ to speed things up. The check adds another 200ms or so.)

The function (and the wrapper) offer a ton of options too this is ridiculously easy to do thanks to the docopt package:

edd@rob:~$ ciw.r -x
Usage: ciw.r [-h] [-x] [-a] [-m] [-i] [-t] [-p] [-w] [-r] [-s] [-n] [-u] [-l rows] [-z] [ARG...]

-m --mega           use 'mega' mode of all folders (see --usage)
-i --inspect        visit 'inspect' folder
-t --pretest        visit 'pretest' folder
-p --pending        visit 'pending' folder
-w --waiting        visit 'waiting' folder
-r --recheck        visit 'waiting' folder
-a --archive        visit 'archive' folder
-n --newbies        visit 'newbies' folder
-u --publish        visit 'publish' folder
-s --skipsort       skip sorting of aggregate results by age
-l --lines rows     print top 'rows' of the result object [default: 50]
-z --ping           run the connectivity check first
-h --help           show this help text
-x --usage          show help and short example usage 

where ARG... can be one or more file name, or directories or package names.

  ciw.r -ip                            # run in 'inspect' and 'pending' mode
  ciw.r -a                             # run with mode 'auto' resolved in incoming()
  ciw.r                                # run with defaults, same as '-itpwr'

When no argument is given, 'auto' is selected which corresponds to 'inspect', 'waiting',
'pending', 'pretest', and 'recheck'. Selecting '-m' or '--mega' are select as default.

Folder selecting arguments are cumulative; but 'mega' is a single selections of all folders
(i.e. 'inspect', 'waiting', 'pending', 'pretest', 'recheck', 'archive', 'newbies', 'publish').

ciw.r is part of littler which brings 'r' to the command-line.
See https://dirk.eddelbuettel.com/code/littler.html for more information.

The README at the git repo and the CRAN page offer a ‘screenshot movie’ showing some of the options in action.

I have been using the little tools quite a bit over the last two or three weeks since I first put it together and find it quite handy. With that again a big Thank You! of appcreciation for all that CRAN does—which this week included letting this past the newbies desk in under 24 hours.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

14 March, 2024 12:03AM