Planet Debian

The OpenCV people decided to break their C API. Except (at least as of OpenCV 3.x) they didn't really remove or deprecate the API, they just stopped testing it. So when things start to break, you just get errors for no reason. Case in point: I have an application that now throws linker error when built without optimizations:

$ gcc -O0 application.c -lopencv_core ... /usr/bin/ld: /tmp/cc8R0Ote.o: in function `cvPointFrom32f': tst.c:(.text+0x557): undefined reference to `cvRound' /usr/bin/ld: tst.c:(.text+0x56d): undefined reference to `cvRound' /usr/bin/ld: /tmp/cc8R0Ote.o: in function `cvReadInt': tst.c:(.text+0xdb1): undefined reference to `cvRound' collect2: error: ld returned 1 exit status

Great. I'm not actually calling cvRound() anywhere, and looking into the sources, this breakage was easily avoidable if they actually cared.

A workaround is to define my own cvRound(). Something like this works:

#include <math.h> static inline int cvRound(float value) { return (int)roundf(value); } #include <opencv2/calib3d/calib3d_c.h>

This compiles and links with or without optimizations. Defining this before the OpenCV #include is significant, and you need to link with -lm to get the implementation of roundf().

This is with OpenCV 3.2, as shipped by Debian. I can imagine later releases either un-breaking this, or actually removing the APIs entirely. That would be the impetus for me to finally dump this library. Which would be a good thing overall, to be honest.

Accumulated one-off purchases over the past few months. Have to make sure I have plenty to read in the new year (spoiler: this will definitely not be a problem).

Lundy Bancroft — Why Does He Do That? (non-fiction)
Gavin de Becker — The Gift of Fear (non-fiction)
Cennydd Bowles — Future Ethics (non-fiction)
Julie E. Czerneda — Search Image (sff)
Ali Davis — True Porn Clerk Stories (non-fiction)
Abby Franquemont — Respect the Spindle (non-fiction)
N.K. Jemisin — How Long 'til Black Future Month? (sff collection)
Daniel Keys Moran — Tales of the Continuing Time and Other Stories (sff collection)
T. Kingfisher — Swordheart (sff)
Kate Manne — Down Girl (non-fiction)
Barry Marcus — Watches I Have Known (non-fiction)
Claire O'Dell — A Study in Honor (sff)
Michael Oher & Don Yaeger — I Beat the Odds (non-fiction)
Laurie Penny — Everything Belongs to the Future (sff)
Matt Potter — The Last Goodbye (non-fiction)
K Arsenault Rivera — The Phoenix Empress (sff)
John Scalzi — The Consuming Fire (sff)
Ryk E. Spoor — Spheres of Influence (sff)
Rebecca Traister — Good and Mad (non-fiction)
M. Mitchell Waldrop — The Dream Machine (non-fiction)
Martha Wells — Artificial Condition (sff)
Martha Wells — Rogue Protocol (sff)
Martha Wells — Exit Strategy (sff)

Some of these I've already read and reviewed. There's a lot of non-fiction in here that has shown up on my radar recently. I know I'm excessively optimistic about the number of books I pick up, but I do have some hope for 2019 being a strong reading year.

It's been a relatively productive year for the packaging of Kiwix, an offline Wikipedia reader, in Debian. My minimum expectations for the Buster release scheduled in mid-2019 are that all necessary C/C++ libraries to build the latest versions of Kiwix are in Debian.

• libzim is at v4.0.4, and basically ready to go.
• libkiwix is prepared for v3.0.3, but is waiting on the FTP masters to approve the new version that is in the NEW queue (fifth oldest binary-NEW package as of this post...). Once that is approved, I have the v3.1.1 upgrade prepared as well.
• ctpp2 was a bit of a struggle, but is ready to go as well. However, it looks like the upstream website has vanished (it was inactive for years), so it's good that Kiwix is planning to replace ctpp2 in the future.

There are three main user facing packages that are in the pipeline right now:

• zimwriterfs is waiting in the NEW queue. I'm hopeful that we can get this included in time for Debian Buster.
• kiwix-tools is a bundle of command-line utilities, the most useful of which is kiwix-serve. There's one upstream issue relating to how JavaScript code is embedded, but the packaging prep work is basically done. It's blocked on the new libkiwix anyways.
• kiwix-desktop or just "Kiwix" is the most interesting thing for typical users who want to read offline content, but it's probably the farthest away. I spent some time this week figuring out how to get it to compile, and mostly got it to work. Probably something to aim for the next Debian release. There's also work underway to provide it as a flatpak, which will benefit even more people.

I also created a "Kiwix team" in the Debian Package Tracker, so you can subscribe to different notifications for all of the Kiwix-related packages (though it might be spammy if you're not very interested in Debian internals).

And, thank you to the Kiwix developers for always being receptive to my bug reports and patches - and providing extra chocolate and stickers :-)

I've started to contribute to debootstrap in March.

Since then, triaged and squashed a half of bugs (and sometimes made some regressions ;)

After two semesters of hard work, I'm happy to say I've finished all the classes I had to take for my Master's degree. If I work hard enough, I should be able to finish writing my thesis by the end of August.

Last night, I handed out the final paper for my History of the Economic Thought class. Titled "From Cooperation to Competition or How Code Became Proprietary", it is a research paper on the evolution of the Copyright Law in the United States with regards to computer code.

Here's the abstract:

With the emergence of computer science as a academic research domain in the 60s, a new generation of students gain access to computers. This generation will become the first wave of hackers, a community based on a strong ethos promoting curiosity and knowledge sharing. The hazy legal framework of computer code intellectual property at the time enables this community to grow and to put forward cooperation as a mean of economic production. Meanwhile in the 60s, the American politicians take advantage of the revision of the Copyright Act to think about the implications of applying copyright to computer code. After failing to tackle computer issues in the 1976 revision of the Copyright Act, the Senate creates the Commission on New Technological Uses of Copyrighted Works (CONTU). The final report of the CONTU will eventually lead computer code to be recognised as a literary work and thus copyrightable. A few years later, American courts finally create a strong case law on these issues with the 1983 Apple v. Franklin court case.

Sadly, I haven't had time to translate the whole paper to English yet (it's in French). Maybe if enough people are interested by theses issues I'll take the time to do so.

If you want to read my paper in French, you can download the PDF here.

My offgrid, solar powered, zero-battery-use fridge has sucessfully made it through spring, summer, fall, and more than enough winter.

I've proven that it works. I've not gotten food poisoning, though I did lose half a gallon of milk on one super rainy week. I have piles of data, and a whole wiki documenting how I built it. I've developed 3 thousand lines of control software. It purrs along without any assistance.

Fridge0 consists of a standard chest freezer, an added thermal mass, an inverter, and computer control. It ties into the typical offfgrid system of a solar charge controller, battery bank, and photovoltaic panels.

This isn't going to solve global warming or anything, but it does seem much less expensive than traditional offgrid fridge systems, and it ties in with thinking on renewable power such as Low Tech magazine's Redefining Energy Security "To improve energy security, we need to make infrastructures less reliable."

I mostly wanted to share the wiki, in case someone wants to build something like this. And to post some data. Here's the summer and fall temperature data.

(More on temperature ranges here.)

I want to be upfront that this is not guaranteed to work in every situation. Here's that time that the milk spoiled. A tropical storm was involved. Most of the time milk stays good 2 to 3 weeks in my fridge.

Some things I might get around to doing eventually:

• Using a supercapacitor to provide power while shutting down on loss of solar power, instead of the current few minutes of use of batteries.
• Also running a freezer, dividing up solar power between them.
• A self-contained build with its own solar panels and electronics, instead of the current build that uses my house's server and solar panels.
• A full BOM or kit, just add solar panels and chest freezer to quickly build your own.

I probably won't be devoting much time to this in the upcoming year, but if anyone wants to build one I'm happy to help you.

Previously: v4.19.

Linux kernel v4.20 has been released today! Looking through the changes, here are some security-related things I found interesting:

stackleak plugin

Alexander Popov’s work to port the grsecurity STACKLEAK plugin to the upstream kernel came to fruition. While it had received Acks from x86 (and arm64) maintainers, it has been rejected a few times by Linus. With everything matching Linus’s expectations now, it and the x86 glue have landed. (The arch-specific portions for arm64 from Laura Abbott actually landed in v4.19.) The plugin tracks function calls (with a sufficiently large stack usage) to mark the maximum depth of the stack used during a syscall. With this information, at the end of a syscall, the stack can be efficiently poisoned (i.e. instead of clearing the entire stack, only the portion that was actually used during the syscall needs to be written). There are two main benefits from the stack getting wiped after every syscall. First, there are no longer “uninitialized” values left over on the stack that an attacker might be able to use in the next syscall. Next, the lifetime of any sensitive data on the stack is reduced to only being live during the syscall itself. This is mainly interesting because any information exposures or side-channel attacks from other kernel threads need to be much more carefully timed to catch the stack data before it gets wiped.

Enabling CONFIG_GCC_PLUGIN_STACKLEAK=y means almost all uninitialized variable flaws go away, with only a very minor performance hit (it appears to be under 1% for most workloads). It’s still possible that, within a single syscall, a later buggy function call could use “uninitialized” bytes from the stack from an earlier function. Fixing this will need compiler support for pre-initialization (this is under development already for Clang, for example), but that may have larger performance implications.

raise faults for kernel addresses in copy_*_user()

Jann Horn reworked x86 memory exception handling to loudly notice when copy_{to,from}_user() tries to access unmapped kernel memory. Prior this, those accesses would result in a silent error (usually visible to callers as EFAULT), making it indistinguishable from a “regular” userspace memory exception. The purpose of this is to catch cases where, for example, the unchecked __copy_to_user() is called against a kernel address. Fuzzers like syzcaller weren’t able to notice very nasty bugs because writes to kernel addresses would either corrupt memory (which may or may not get detected at a later time) or return an EFAULT that looked like things were operating normally. With this change, it’s now possible to much more easily notice missing access_ok() checks. This has already caught two other corner cases even during v4.20 in HID and Xen.

spectre v2 userspace mitigation

The support for Single Thread Indirect Branch Predictors (STIBP) has been merged. This allowed CPUs that support STIBP to effectively disable Hyper-Threading to avoid indirect branch prediction side-channels to expose information between userspace threads on the same physical CPU. Since this was a very expensive solution, this protection was made opt-in (via explicit prctl() or implicitly under seccomp()). LWN has a nice write-up of the details.

jump labels read-only after init

Ard Biesheuvel noticed that jump labels don’t need to be writable after initialization, so their data structures were made read-only. Since they point to kernel code, they might be used by attackers to manipulate the jump targets as a way to change kernel code that wasn’t intended to be changed. Better to just move everything into the read-only memory region to remove it from the possible kernel targets for attackers.

VLA removal finished

As detailed earlier for v4.17, v4.18, and v4.19, a whole bunch of people answered my call to remove Variable Length Arrays (VLAs) from the kernel. I count at least 153 commits having been added to the kernel since v4.16 to remove VLAs, with a big thanks to Gustavo A. R. Silva, Laura Abbott, Salvatore Mesoraca, Kyle Spiers, Tobin C. Harding, Stephen Kitt, Geert Uytterhoeven, Arnd Bergmann, Takashi Iwai, Suraj Jitindar Singh, Tycho Andersen, Thomas Gleixner, Stefan Wahren, Prashant Bhole, Nikolay Borisov, Nicolas Pitre, Martin Schwidefsky, Martin KaFai Lau, Lorenzo Bianconi, Himanshu Jha, Chris Wilson, Christian Lamparter, Boris Brezillon, Ard Biesheuvel, and Antoine Tenart. With all that done, “-Wvla” has been added to the top-level Makefile so we don’t get any more added back in the future.

Given the holidays, Linus opened the merge window before v4.20 was released, letting everyone send in pull requests in the week leading up to the release. v4.21 is in the making. :) Happy New Year everyone!

Edit: clarified stackleak details, thanks to Alexander Popov.

© 2018, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

(What follows is an excerpt from my master’s thesis, almost all of section 2.1, quickly introducing Go to people familiar with CS)

Go is an imperative programming language for concurrent programming created at and mainly developed by Google, initially mostly by Robert Griesemer, Rob Pike, and Ken Thompson. Design of the language started in 2007, and an initial version was released in 2009; with the first stable version, 1.0 released in 2012 1.

Go has a C-like syntax (without a preprocessor), garbage collection, and, like its predecessors devloped at Bell Labs – Newsqueak (Rob Pike), Alef (Phil Winterbottom), and Inferno (Pike, Ritchie, et al.) – provides built-in support for concurrency using so-called goroutines and channels, a form of co-routines, based on the idea of Hoare’s ‘Communicating Sequential Processes’ 2.

Go programs are organised in packages. A package is essentially a directory containing Go files. All files in a package share the same namespace, and there are two visibilities for symbols in a package: Symbols starting with an upper case character are visible to other packages, others are private to the package:

func PublicFunction() { fmt.Println("Hello world") } func privateFunction() { fmt.Println("Hello package") } Types

Go has a fairly simple type system: There is no subtyping (but there are conversions), no generics, no polymorphic functions, and there are only a few basic categories of types:

1. base types: int, int64, int8, uint, float32, float64, etc.
2. struct
3. interface - a set of methods
4. map[K, V] - a map from a key type to a value type
5. [number]Type - an array of some element type
6. []Type - a slice (pointer to array with length and capability) of some type
7. chan Type - a thread-safe queue
8. pointer *T to some other type
9. functions

10. named type - aliases for other types that may have associated methods:

    type T struct { foo int } type T *T type T OtherNamedType

    Named types are mostly distinct from their underlying types, so you cannot assign them to each other, but some operators like + do work on objects of named types with an underlying numerical type (so you could add two T in the example above).

Maps, slices, and channels are reference-like types - they essentially are structs containing pointers. Other types are passed by value (copied), including arrays (which have a fixed length and are copied).

Conversions

Conversions are the similar to casts in C and other languages. They are written like this:

TypeName(value) Constants

Go has “untyped” literals and constants.

1 // untyped integer literal const foo = 1 // untyped integer constant const foo int = 1 // int constant

Untyped values are classified into the following categories: UntypedBool, UntypedInt, UntypedRune, UntypedFloat, UntypedComplex, UntypedString, and UntypedNil (Go calls them basic kinds, other basic kinds are available for the concrete types like uint8). An untyped value can be assigned to a named type derived from a base type; for example:

type someType int const untyped = 2 // UntypedInt const bar someType = untyped // OK: untyped can be assigned to someType const typed int = 2 // int const bar2 someType = typed // error: int cannot be assigned to someType Interfaces and ‘objects’

As mentioned before, interfaces are a set of methods. Go is not an object-oriented language per se, but it has some support for associating methods with named types: When declaring a function, a receiver can be provided - a receiver is an additional function argument that is passed before the function and involved in the function lookup, like this:

type SomeType struct { ... } func (s *SomeType) MyMethod() { } func main() { var s SomeType s.MyMethod() }

An object implements an interface if it implements all methods; for example, the following interface MyMethoder is implemented by *SomeType (note the pointer), and values of *SomeType can thus be used as values of MyMethoder. The most basic interface is interface{}, that is an interface with an empty method set - any object satisfies that interface.

type MyMethoder interface { MyMethod() }

There are some restrictions on valid receiver types; for example, while a named type could be a pointer (for example, type MyIntPointer *int), such a type is not a valid receiver type.

Control flow

Go provides three primary statements for control flow: if, switch, and for. The statements are fairly similar to their equivalent in other C-like languages, with some exceptions:

• There are no parentheses around conditions, so it is if a == b {}, not if (a == b) {}. The braces are mandatory.

• All of them can have initialisers, like this

  if result, err := someFunction(); err == nil { // use result }

• The switch statement can use arbitrary expressions in cases

• The switch statement can switch over nothing (equals switching over true)

• Cases do not fall through by default (no break needed), use fallthrough at the end of a block to fall through.

• The for loop can loop over ranges: for key, val := range map { do something }

Goroutines

The keyword go spawns a new goroutine, a concurrently executed function. It can be used with any function call, even a function literal:

func main() { ... go func() { ... }() go some_function(some_argument) } Channels

Goroutines are often combined with channels to provide an extended form of Communicating Sequential Processes 2. A channel is a concurrent-safe queue, and can be buffered or unbuffered:

var unbuffered = make(chan int) // sending blocks until value has been read var buffered = make(chan int, 5) // may have up to 5 unread values queued

The <- operator is used to communicate with a single channel.

valueReadFromChannel := <- channel otherChannel <- valueToSend

The select statement allows communication with multiple channels:

select { case incoming := <- inboundChannel: // A new message for me case outgoingChannel <- outgoing: // Could send a message, yay! } The defer statement

Go provides a defer statement that allows a function call to be scheduled for execution when the function exits. It can be used for resource clean-up, for example:

func myFunc(someFile io.ReadCloser) { defer someFile.close() /* Do stuff with file */ }

It is of course possible to use function literals as the function to call, and any variables can be used as usual when writing the call.

Error handling

Go does not provide exceptions or structured error handling. Instead, it handles errors by returning them in a second or later return value:

func Read(p []byte) (n int, err error) // Built-in type: type error interface { Error() string }

Errors have to be checked in the code, or can be assigned to _:

n0, _ := Read(Buffer) // ignore error n, err := Read(buffer) if err != nil { return err }

There are two functions to quickly unwind and recover the call stack, though: panic() and recover(). When panic() is called, the call stack is unwound, and any deferred functions are run as usual. When a deferred function invokes recover(), the unwinding stops, and the value given to panic() is returned. If we are unwinding normally and not due to a panic, recover() simply returns nil. In the example below, a function is deferred and any error value that is given to panic() will be recovered and stored in an error return value. Libraries sometimes use that approach to make highly recursive code like parsers more readable, while still maintaining the usual error return value for public functions.

func Function() (err error) { defer func() { s := recover() switch s := s.(type) { // type switch case error: err = s // s has type error now default: panic(s) } } } Arrays and slices

As mentioned before, an array is a value type and a slice is a pointer into an array, created either by slicing an existing array or by using make() to create a slice, which will create an anonymous array to hold the elements.

slice1 := make([]int, 2, 5) // 5 elements allocated, 2 initialized to 0 slice2 := array[:] // sliced entire array slice3 := array[1:] // slice of array without first element

There are some more possible combinations for the slicing operator than mentioned above, but this should give a good first impression.

A slice can be used as a dynamically growing array, using the append() function.

slice = append(slice, value1, value2) slice = append(slice, arrayOrSlice...)

Slices are also used internally to represent variable parameters in variable length functions.

Maps

Maps are simple key-value stores and support indexing and assigning. They are not thread-safe.

someValue := someMap[someKey] someValue, ok := someMap[someKey] // ok is false if key not in someMap someMap[someKey] = someValue

1. Frequently Asked Questions (FAQ) - The Go Programming Language https://golang.org/doc/faq#history [return]
2. HOARE, Charles Antony Richard. Communicating sequential processes. Communications of the ACM, 1978, 21. Jg., Nr. 8, S. 666-677. [return]

This Christmas I'm visiting the Balkans again. It is the seventh time in the last two years that I have been fortunate enough to visit this largely undiscovered but very exciting region of Europe.

A change of name

On Saturday I visited Skopje, the capital of Macedonia. Next month their country will finalize their name change to the Republic of Northern Macedonia.

Prishtina

From Skopje, I travelled north to Prishtina, the capital of Kosovo.

I had dinner with four young women who have become outstanding leaders in the free software movement in the region, Albiona, Elena, Amire and Enkelena.

The population of Kosovo is over ninety percent Muslim, not everybody observes Christmas as a religious festival but nonetheless the city of Prishtina is decorated beautifully with several large trees in the pedestrianised city centre.

I've put new debootstrap version 1.0.112 into unstable today, it gets more speed than the previous one. Kudos to Thomas Lange for the hack.
If you find any trouble with it, please let me know.

I'm pleased to have teamed up with AT&T to bring you this illustrated guide to effective bug tracking.

The original issue description was "noise / static on line", and as we can see, AT&T have very effectively closed the ticket: There is no longer any noise, of any kind, on the phone line.

No electrons == no noise, so this is the absolute simplest and most effective fix possible. Always start with the simplest such fix, and be sure to close the problem ticket immediately on fixing. Do not followup with the issue reporter, or contact them in any way to explain how the issue was resolved.

While in the guts of the system fixing such a bug report, you'll probably see something that could be improved by some light refactoring. It's always a good idea to do that right away, because refactoring can often just solves an issue on its own somehow. (Never use your own issue tracking system to report issues to yourself to deal with later, because that would just be bonkers.)

But don't go overboard with refactoring. As we see here, when AT&T decided to run a new line between two poles involved in my bug report, they simply ran it along the ground next to my neighbor's barn. A few festive loops and bows prevent any possible damage by tractor. Can always refactor more later.

The only other information included in my bug report was "house at end of loong driveway". AT&T helpfully limited the size of the field to something smaller than 1 (old-style) tweet, to prevent some long brain dump being put in there.

You don't want to hear that I've lived here for 7 years and the buried line has never been clean but's been getting a bit more noisy lately, or that I noticed signs of water ingress at two of the junction boxes, or that it got much much worse after a recent snow storm, to the point that I was answering the phone by yelling "my phone line is broken" down the line consumed with static.

Design your bug tracking system to not let the user really communicate with you. You know what's wrong better than them.

And certianly don't try to reproduce the circumstances of the bug report. No need to visit my house and check the outside line when you've already identified and clearly fixed the problem at the pole.

My second bug report is "no dial tone" with access information "on porch end of long driveway". With that, I seem to be trying to solicit some kind of contact outside the bug tracking system. That is never a good idea though, and AT&T should instruct their linemen to avoid any possible contact with the user, or any attempts to convey information outside the issue tracking system.

AT&T's issue tracking system reports "Service Restore Date: 12/25/2018 at 12:00 AM" but perhaps they'll provide more effective issue tracking tips for me to share with you. Watch this space.

Continuing in Aurelien Gateau‘s release month, where I recently joined in with Kookbook, I’m now also following up with Kolorfill, an app I also described in the past.

It is a simple flood filling game written using the amazing Kirigami framework.

Have fun with it.

I have this systemd timer unit

[Unit] Description=Run i3-rotate-wallpaper daily [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target

which says to start the i3-rotate-wallpaper.service unit at each midnight.

Persistent=true is meant to ensure that the unit is triggered immediately when the system resumes from suspend or is powered on, if at the most recent midnight it was suspended or powered off. The idea is that when I first use my computer each day, the wallpaper gets changed – I delight in seeing the wallpapers I’ve downloaded.

The problem is that Persistent=true only works if the timer has been triggered at least once when the system is not suspended and powered on. But my computer is almost never on at midnight. I don’t want to have to leave it turned on just for the first wallpaper change, or keep track of that when reinstalling the machine’s operating system.

The fix:

% mkdir -p "$HOME/.local/share/systemd/timers" % touch "$HOME/.local/share/systemd/timers/stamp-i3-rotate-wallpaper.timer"

I would like to push a release of Debian Policy but I want to include the patches in the following two bugs. If you are a DD, please consider reviewing and seconding the patches in these bugs so that I can do that.

• debian-policy: virtual packages: dbus-session-bus, dbus-default-session-bus

• Please firmly deprecate vendor-specific series files (the patch simply implements a ctte decision)

EDIT 2018/xii/23: these are both now seconded – thanks gregor!

• More bugs, organised by difficulty, here

• Our guide to contribution

I talk a lot about user freedom, but have never explained what that actually means. The more I think about user freedom as a term, the less certain I am about what it is. This makes it hard to define. My thoughts on user freedom are the synthesis of about ten years, first thinking about the Good behind developmental models enabled by open source through to today, where I think about the philosophical implications of traffic lights.

I think I picked up the term from Christopher Lemmer Webber and it’s become integral to how I think and talk about free software and it’s value to society.

User freedom is based in the idea that we have fundamental rights (I’ll use the UN’s Universal Declaration of Human Rights as my metric*) and that these extend to the digital spaces we inhabit. In order to protect these in a world ruled by software, in order to see them in practice, we need the opportunity (and freedom) to use, examine, modify, and share this software. Software freedom is what happens when our software affords us these freedoms. Free and open source software is the software embodying the spirit of software freedom.

Software freedom is also necessary to ensure our rights in the physical world. Let’s take Article 10 as an example.

Everyone is entitled in full equality to a fair and public hearing by an independent and impartial tribunal, in the determination of his rights and obligations and of any criminal charge against him.

There is so much thoroughly opaque proprietary software in and around legal matters. This includes software people are choosing to use, like Case Management Software; software is used to gather and manage data and evidence being used against someone and sometimes this evidence isn’t even accessible to those being charged unless they pay licensing and access fees; breathalyzers are little more than small computers that have been subject to tampering since 1988; in Patent 10049419 “Motorola patents a robocop autonomous car that breathalyzes, mirandizes you, calls your lawyer and collects your bail”; and facial recognition technology is available and being used and tested by governments.

The right to a fair and public hearing also extends to digital spaces, your actions there, and your digital life. Your digital activities are monitored, cataloged, and treated with equal judgment as those in physical spaces.

User freedom is important to different people for different reasons. For me, the most important reason ties into the freedom to study software. I think user consent — consent to interacting with technology. Unless software is free, unless we can study it, we cannot understand it, and when we cannot understand something we don’t fully have the autonomy to consent.**

I said a lot of words, but failed to provide a concise definition to user freedom largely because I lack a concise definition. User freedom is the freedom we need to protect, for which we use software freedom and free software, though it extends far beyond those two critical components. User freedom is itself a tool used to uphold and defend human rights when applied to computing technologies. User freedom creates the possibility for knowledge, which gives us autonomy and consent.

* This idea is shared with Chris Webber.
** I’d like to attribute my ideas around autonomy and consent to Dr. Holly Andersen.

Around a month ago, someone mentioned the existence of HTTP/2 in an IRC channel I lurk in. For some reason, I had never heard of it and some of the features of this new protocol (like mutiplexing requests without having to open multiple TCP connections) seemed cool.

To be honest, I had just finished re-writing the Puppet code that manages our backup procedures and enabling HTTP/2 seemed like a productive way to procrastinate before moving on to an another large project. How hard could this be?

Turns out it took me around 25 hours of work... Sit back and put on comfortable slippers, for this is a tale of HTTP/2!

Cursed Be the HTTP/1.1

When I first looked up how to enable HTTP/2 on Apache it seemed a pretty simple task. The documentation mentioned loading the http2 module and making sure to prioritise the new protocol via a configuration file like this one:

Protocols h2 h2c http/1.1 H2Push on H2PushPriority * after H2PushPriority text/css before H2PushPriority image/jpeg after 32 H2PushPriority image/png after 32 H2PushPriority application/javascript interleaved

This would of course have been too easy. Even if everything in Apache was set up properly, websites kept being served as HTTP/1.1. I was obviously doing something right though, since my websites were now sending a new HTTP header: Upgrade: h2, h2c.

After wasting a good deal of time debugging TLS ciphers (HTTP/2 is incompatible with TLS 1.1), I finally found out the problem was that we weren't using the right multi-processing module for Apache.

Turns out Apache won't let you serve HTTP/2 while using mpm_prefork (the default MPM), as it is not supported by mod_http2. Even though there are two other MPM you can use with Apache, only mpm_prefork supports mod_php. Suddenly, adding support for HTTP/2 meant switching all our webapps built in PHP to PHP-FPM...

Down the Rabbit Hole

For the longest time, a close friend has been trying to convince me of the virtues of PHP-FPM. As great as it looked on paper, I never really did anything about it. It seemed so ... complicated. Regular ol' mod_php did the trick just fine and other things required my attention.

This whole HTTP/2 thing turned out to be the perfect excuse for me to dive into it after all. Once I understood how FPM pools worked, it was actually pretty easy to set up. Since I had to rewrite the Puppet profiles we're using to deploy websites, also I took that opportunity to harden a bunch of things left and right.

PHP-FPM let's you run websites under different Unix users for added separation. On top of that, I decided it was time for PHP code on our servers to be ran in read-only mode and had to tweak a bunch of things for our Wordpress, Nextcloud, KanBoard and Drupal instances to stop complaining about it.

After too much time passed automating tasks in Puppet, I finally was able to turn off mod_php and mpm_prefork everywhere and to enable mpm_event and mod_http2. The speed bonus offered by PHP-FPM and HTTP/2 is nice, but more than anything I'm happy this whole ordeal forced me to harden the way our Apache servers deal with PHP.

Debian distributes the R language for statistical analysis, data mining or bioinformatics (among others). Satellite to R are hundreds of packages (kind of function libraries), mostly distributed by CRAN and Bioconductor, which contribute a lot to the richness and versatility of the R ecosystem. Debian redistributes some of these packages in the Debian format. Like in all similar cases of "redistribution of a distribution", there is a tension between Debian's goals for its stable version, and the expectations of novelty for the users (in part because the development cycle of R is 6 months), and one sometimes wonder if there is a point for using the packages through Debian and not through the upstream repositories.

Today, after installing a minimal system in a "schroot" container, I installed a R package and all its dependencies natively, that is by downloading their sources through the R command line, which made me wait for 90 minutes until everything compiles, while the R packages redistributed in Debian are already compiled. 90 minutes of compilation for 10 minutes of work; 90 minutes of waiting that I could have avoided with a couple of well-chosen "apt install" commands. Thus, many thanks to all who maintain R packages in Debian!

So, your machine now needs minutes to boot before you can ssh in where it used to be seconds before the Debian Buster update?

Problem

Linux 3.17 (2014-10-05) learnt a new syscall getrandom() that, well, gets bytes from the entropy pool. Glibc learnt about this with 2.25 (2017-02-05) and two tries and four years after the kernel, OpenSSL used that functionality from release 1.1.1 (2018-09-11). OpenSSH implemented this natively for the 7.8 release (2018-08-24) as well.

Now the getrandom() syscall will block1 if the kernel can't provide enough entropy. And that's frequenty the case during boot. Esp. with VMs that have no input devices or IO jitter to source the pseudo random number generator from.

First seen in the wild January 2017

I vividly remember not seeing my Alpine Linux VMs back on the net after the Alpine 3.5 upgrade. That was basically the same issue.

Systemd. Yeah.

Systemd makes this behaviour worse, see issue #4271, #4513 and #10621.
Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times2 when /var/lib/urandom/random-seed (that you still have lying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.

#4167 is a re-opened discussion about systemd eating randomness early at boot (hashmaps in PID 0...). Some Debian folks participate in the recent discussion and it is worth reading if you want to learn about the mess that booting a Linux system has become.

While we're talking systemd ... #10676 also means systems will use RDRAND in the future despite Ted Ts'o's warning on RDRAND [Archive.org mirror and mirrored locally as 130905_Ted_Tso_on_RDRAND.pdf, 205kB as Google+ will be discontinued in April 2019].

Debian

Debian is seeing the same issue working up towards the Buster release, e.g. Bug #912087.

The typical issue is:

[    4.428797] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: data=ordered
[ 130.970863] random: crng init done

with delays up to tens of minutes on systems with very little external random sources.

This is what it should look like:

[    1.616819] random: fast init done
[    2.299314] random: crng init done

Check dmesg | grep -E "(rng|random)" to see how your systems are doing.

If this is not fully solved before the Buster release, I hope some of the below can end up in the release notes3.

Solutions

You need to get entropy into the random pool earlier at boot. There are many ways to achieve this and - currently - all require action by the system administrator.

Kernel boot parameter

From kernel 4.19 (Debian Buster currently runs 4.18) you can set RANDOM_TRUST_CPU at compile time or random.trust_cpu=on on the kernel command line. This will make Intel / AMD system trust RDRAND and fill the entropy pool with it. See the warning from Ted Ts'o linked above.

Using a TPM

The Trusted Platform Module has an embedded random number generator that can be used. Of course you need to have one on your board for this to be useful. It's a hardware device.

Load the tpm-rng module (ideally from initrd) or compile it into the kernel (config HW_RANDOM_TPM). Now, the kernel does not "trust" the TPM RNG by default, so you need to add

rng_core.default_quality=1000

to the kernel command line. 1000 means "trust", 0 means "don't use". So you can chose any value in between that works for you depending on how much you consider your TPM to be unbugged.

VirtIO

For Virtual Machines (VMs) you can forward entropy from the host (that should be running longer than the VMs and have enough entropy) via virtio_rng.

So on the host, you do:

kvm ... -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x7

and within the VM newer kernels should automatically load virtio_rng and use that.

You can confirm with dmesg as per above.

Or check:

# cat /sys/devices/virtual/misc/hw_random/rng_available
virtio_rng.0
# cat /sys/devices/virtual/misc/hw_random/rng_current
virtio_rng.0 Patching systemd

The Fedora bugtracker has a bash / python script that replaces the systemd rnd seeding with a (better) working one. The script can also serve as a good starting point if you need to script your own solution, e.g. for reading from an entropy provider available within your (secure) network.

Chaoskey

The wonderful Keith Packard and Bdale Garbee have developed a USB dongle, ChaosKey, that supplies entropy to the kernel. Hard- and software are open source.

Jitterentropy_RNG

Kernel 4.2 introduced jitterentropy_rng which will use the jitter in CPU timings to generate randomness.

modprobe jitterentropy_rng

This apparently needs a userspace daemon though (read: design mistake) so

apt install jitterentropy-rngd (available from Buster/testing).

The current version 1.0.8-3 installs nicely on Stretch. dpkg -i is your friend.

But - drumroll - that daemon doesn't seem to use the kernel module at all.

That's where I stopped looking at that solution. At least for now. There are extensive docs if you want to dig into this yourself.

Haveged

apt install haveged

Haveged is a user-space daemon that gathers entropy though the timing jitter any CPU has. It will only run "late" in boot but may still get your openssh back online within seconds and not minutes.

It is also - to the best of my knowledge - not verified at all regarding the quality of randomness it generates. The haveged design and history page provides and interesting read and I wouldn't recommend haveged if you have alternatives. If you have none, haveged is a wonderful solution though as it works reliably. And unverified entropy is better than no entropy. Just forget this is 2018 .

1. it will return with EAGAIN in the GRND_NONBLOCK use case. The blocking behaviour when lacking entropy is a security measure as per Bug #1559 of Google's Project Zero. ↩

2. Update 18.12.2018: "SysVinit times" ::= "The times when most Linux distros used SysVinit over other init systems." So Wheezy and previous for Debian. Some people objected to the statement, so I added this footnote as a clarification. See the discussion in the comments below. ↩

3. there is no Buster branch in the release notes repository yet (2018-12-17) ↩

Last two months free software work

Keen readers probably noticed that I didn't produce a report in November. I am not sure why, but I couldn't find the time to do so. When looking back at those past two months, I didn't find that many individual projects I worked on, but there were massive ones, of the scale of archiving the entire government of Brazil or learning the intricacies of print media, both of which were slightly or largely beyond my existing skill set.

Calendar project

I've been meaning to write about this project more publicly for a while, but never found the way to do so productively. But now that the project is almost over -- I'm getting the final prints today and mailing others hopefully soon -- I think this deserves at least a few words.

As some of you might know, I bought a new camera last January. Wanting to get familiar with how it works and refresh my photography skills, I decided to embark on the project of creating a photo calendar for 2019. The basic idea was simple: take pictures regularly, then each month pick the best picture of that month, collect all those twelve pictures and send that to the corner store to print a few calendars.

Simple, right?

Well, twelve pictures turned into a whopping 8000 pictures since January, not all of which were that good of course. And of course, a calendar has twelve months -- so twelve pictures -- but also a cover and a back, which means thirteen pictures and some explaining. Being critical of my own work, it turned out that finding those pictures was sometimes difficult, especially considering the medium imposed some rules I didn't think about.

For example, the US Letter paper size imposes a different ratio (1.29) than the photographic ratio (~1.5) which means I had to reframe every photograph. Sometimes this meant discarding entire ideas. Other photos were discarded because too depressing even if I found them artistically or journalistically important: you don't want to be staring at a poor kid distressed at going into school every morning for an entire month. Another advice I got was to forget about sunsets and dark pictures, as they are difficult to render correctly in print. We're used to bright screens displaying those pictures, paper is a completely different feeling. Having a good vibe for night and star photography, this was a fairly dramatic setback, even though I still did feature two excellent pictures.

Then I got a little carried away. At the suggestion of a friend, I figured I could get rid of the traditional holiday dates and replace them with truly secular holidays, which got me involved in a deep search for layout tools, which in turn naturally brought me to this LaTeX template. Those who have worked with LaTeX (or probably any professional layout tool) know what's next: I spent a significant amount of time perfecting the rendering and crafting the final document.

Slightly upset by the prices proposed by the corner store (15$CAD/calendar!), I figured I could do better by printing on my own, especially encouraged by a friend who had access to a good color laser printer. I then spent multiple days (if not weeks) looking for the right paper, which got me in the rabbit hole of paper weights, brightness, texture, and more. I'll just say this: if you ever thought lengths were ridiculous in the imperial system, wait until you find out how you find out about how paper weights work. I finally managed to find some 270gsm gloss paper at the corner store -- after looking all over town, it was right there -- and did a first print of 15 calendars, which turned into 14 because of trouble with jammed paper. Because the printer couldn't do recto-verso copies, I had to spend basically 4 hours tending to that stupid device, bringing my loathing of printers (the machines) and my respect for printers (the people) to an entirely new level.

The time spent on the print was clearly not worth it in the end, and I ended up scheduling another print with a professional printer. The first proof are clearly superior to the ones I have done myself and, in retrospect, completely worth the 15$ per copy.

I still haven't paid for my time in any significant way on that project, something I seem to excel at doing consistently. The prints themselves are not paid for, but my time in producing those photographs is not paid either, which clearly outlines my future as a professional photographer, if any, lie far away from producing those silly calendars, at least for now.

More documentation on the project is available, in french, in calendrier-2019. I am also hoping to eventually publish a graphical review of the calendar, but for now I'll leave that for the friends and family who will receive the calendar as a gift...

Archival of Brasil

Another modest project I embarked on was a mission to archive the government of Brazil following the election the infamous Jair Bolsonaro, dictatorship supporter, homophobe, racist, nationalist and christian freak that somehow managed to get elected president of Brazil. Since he threatened to rip apart basically the entire fabric of Brazilian society, comrades were worried that he might attack and destroy precious archives and data from government archives when he comes in power, in January 2019. Like many countries in Latin America that lived under dictatorships in the 20th century, Brazil made an effort to investigate and keep memory of the atrocities that were committed during those troubled times.

Since I had written about archiving websites, those comrades naturally thought I could be of use, so we embarked on a crazy quest to archive Brazil, basically. We tried to create a movement similar to the Internet Archive (IA) response to the 2016 Trump election but were not really successful at getting IA involved. I was, fortunately, able to get the good folks at Archive Team (AT) involved and we have successfully archived a significant number of websites, adding terabytes of data to the IA through the backdoor that is AT. We also ran a bunch of archival on a special server, leveraging tools like youtube-dl, git-annex, wpull and, eventually, grab-site to archive websites, social network sites and video feeds.

I kind of burned out on the job. Following Brazilian politics was scary and traumatizing - I have been very close to Brazil folks and they are colorful, friendly people. The idea that such a horrible person could come into power there is absolutely terrifying and I kept on thinking how disgusted I would be if I would have to archive stuff from the government of Canada, which I do not particularly like either... This goes against a lot of my personal ethics, but then it beats the obscurity of pure destruction of important scientific, cultural and historical data.

Miscellaneous

Considering the workload involved in the above craziness, the fact that I worked on less project than my usual madness shouldn't come as a surprise.

• As part of the calendar work, I wrote a new tool called moonphases which shows a list of moon phase events in the given time period, and shipped that as part of undertime 1.5 for lack of a better place.

• AlternC revival: friends at Koumbit asked me for source code of AlternC projects I was working on. I was disappointed (but not surprised) that upstream simply took those repositories down without publishing an archive. Thankfully, I still had SVN checkouts but unfortunately, those do not have the full history, so I reconstructed repositories based on the last checkout that I had for alternc-mergelog, alternc-stats, and alternc-slavedns.

• I packaged two new projects into Debian, bitlbee-mastodon (to connect to the new Mastodon network over IRC) and python-internetarchive (a command line interface to the IA upload forms)

• my work on archival tools led to a moderately important patch in pywb: allow symlinking and hardlinking files instead of just copying was important to manage multiple large WARC files along with git-annex.

• I also noticed the IA people were using a tool called slurm to diagnose bandwidth problems on their networks and implemented iface speed detection on Linux while I was there. slurm is interesting, but I also found out about bmon through the hilarious hollywood project. Each has their advantages: bmon has packets per second graphs, while slurm only has bandwidth graphs, but also notices maximal burst speeds which is very useful.

Debian Long Term Support (LTS)

This is my monthly Debian LTS report. Note that my previous report wasn't published on this blog but on the mailing list.

Enigmail / GnuPG 2.1 backport

I've spent a significant amount of time working on the Enigmail backport for a third consecutive month. I first published a straightforward backport of GnuPG 2.1 depending on the libraries available in jessie-backports last month, but then I actually rebuilt the dependencies as well and sent a "HEADS UP" to the mailing list, which finally got peoples' attention.

There are many changes bundled in that possible update: GnuPG actually depends on about half a dozen other libraries, mostly specific to GnuPG, but in some cases used by third party software as well. The most problematic one is libgcrypt20 which Emilio Pozuelo Monfort said included tens of thousands of lines of change. So even though I tested the change against cryptsetup, gpgme, libotr, mutt and Enigmail itself, there are concerns that other dependencies that merit more testing as well.

This caused many to raise the idea of aborting the work and simply marking Enigmail as unsupported in jessie. But Daniel Kahn Gillmor suggested this should also imply removing Thunderbird itself from jessie, as simply removing Enigmail will force people to use the binaries from Mozilla's add-ons service. Gillmor explained those builds include a OpenPGP.js implementation of dubious origin, which is especially problematic considering it deals with sensitive private key material.

It's unclear which way this will go next. I'm taking a break of this issue and hope others will be able to test the packges. If we keep on working on Enigmail, the next step will be to re-enable the dbg packages that were removed in the stretch updates, use dh-autoreconf correctly, remove some mingw pacakges I forgot and test gcrypt like crazy (especially the 1.7 update). We'd also update to the latest Enigmail, as it fixes issues that forced the Tails project to disable autocrypt because of weird interactions that make it send cleartext (instead of encrypted) mail in some cases.

Automatic unclaimer

My previous report yielded an interesting discussion around my work on the security tracker, specifically the "automatic unclaimer" designed to unassign issues that are idle for too long. Holger Levsen, with his new coordinator hat, tested the program and found many bugs and missing features, which I was happy to implement. After many patches and back and forth, it seems the program is working well, although it's ran by hand by the coordinator.

DLA website publication

I took a look at various issues surrounding the publication of LTS advisories on the main debian.org website. While normal security advisories are regularly published on debian.org/security about 500+ DLAs are missing from the website, mainly because DLAs are not automatically imported.

As it turns out, there is a script called parse-dla.pl that is designed to handle those entries but for some reason, they are not imported anymore. So I got to work to import the backlog and make sure new entries are properly imported.

Various fixes for parse-dla.pl were necessary to properly parse messages both from the templates generated by gen-DLA and the existing archives correctly. then I tested the result with two existing advisories, which resulted in two MR on the webml repo: add data for DLA-1561 and add dla-1580 advisory. I requested and was granted access to the repo, and eventually merged my own MRs after a review from Levsen.

I eventually used the following procedure to test importing the entire archive:

rsync -vPa master.debian.org:/home/debian/lists/debian-lts-announce . cd debian-lts-announce xz -d \*.xz cat \* > ../giant.mbox mbox2maildir ../giant.mbox debian-lts-announce.d for mail in debian-lts-announce.d/cur/\*; do ~/src/security-tracker/./parse-dla.pl $mail; done

This lead to 82 errors on an empty directory, which is not bad at all considering the amount of data processed. Of course, there many more errors in the live directory as many advisories were already present. In the live directory, this resulted in 2431 new advisories added to the website.

There were a few corner cases:

• The first month or so didn't use DLA identifiers and many of those were not correctly imported even back then.

• DLA-574-1 was a duplicate, covered by the DLA-574-2 regression update. But I only found the Imagemagick advisory - it looks like the qemu one was never published.

• Similarly, the graphite2 regression was never assigned a real identifier.

• Other cases include for example DLA-787-1 which was sent twice and the DLA-1263-1 duplicate, which was irrecuperable as it was never added to data/DLA/list

Those special cases will all need to be handled by an eventual automation of this process, which I still haven't quite figured out. Maybe a process similar to the unclaimer will be followed: the coordinator or me could add missing DLAs until we streamline the process, as it seems unlikely we will want to add more friction to the DLA release by forcing workers to send merge requests to the web team, as that will only put more pressure on the web team...

There are also nine advisories missing from the mailing list archive because of a problem with the mailing list server at that time. We'll need to extract those from people's email archives, which I am not sure how to coordinate at this point.

PHP CVE identifier confusion

I have investigated CVE-2018-19518, mistakenly identified as CVE-2018-19158 in various places, including upstream's bugtracker. I requested the latter erroneous CVE-2018-19158 to be retired to avoid any future confusion. Unfortunately, Mitre indicated the CVE was already in "active use for pre-disclosure vulnerability coordination", which made it impossible to correct the error at that level.

I've instead asked upstream to correct the metadata in their tracker but it seems nothing has changed there yet.

Yesterday, I got word that my FOSDEM 2019 talk was accepted! Here's the preliminary abstract:

Futatabi is a free software solution for doing instant replay, e.g. for sports production. It supports multiple cameras, high-quality realtime slow motion on the GPU through optical flow, and seamless integration with Nageru, my live video mixer. We'll talk a bit about how interpolation through optical flow works, challenges in transporting the streams back and forth, and demonstrate a real-world sports production done earlier this year using Nageru and Futatabi.

Futatabi has been in the making for a long time, but most of that was various forms of planning and research—the first git commit in the repository was only in June this year. (However, it's grown rapidly; at the moment, it's about 9000 lines of C++, a 1000 lines more of GLSL, and then some more that's shared with Nageru.) There are still rough edges, of course, but it's definitely usable in practice; we used an early version for Trøndisk, and have been incorporating the experience from that to fix various warts and bugs. This was especially centered around I/O issues, but also to add a couple of new features.

As far as I know, this is the first time you can do anything like this using free software. Actually, even doing it using non-free software is hard; the only thing I know of that's comparable in terms of feature set/workflow is vMix Pro, which will set you back $1200 and as far as I know doesn't have interpolation. (Of course, vMix has a very large feature set in general, and does a lot of other stuff in addition to replay, so it's not fair to say that Futatabi is plain-out better.) The next step up is dedicated replay devices, which start at around $10k and go steeply up from there; even the controllers are typically around $1k.

The talk is Saturday February 2nd, 15:00 in room H.1309. As far as I know, it will be streamed and recorded, too, although FOSDEM's 25 fps streams will probably have issues reproducing the interpolated 59.94 fps streams faithfully without lots of stuttering :-) So see you there!