RSS Atom Add a new post titled:

Debian LTS Logo

Here is my transparent report for my work on the Debian Long Term Support (LTS) project, which extends the security support for past Debian releases, as a paid contributor.

In June, the monthly sponsored hours were split evenly among contributors depending on their max availability - I declared max 30h and got 17h.

I mostly spent time on tricky updates. Uploading one with literally thousands of reverse dependencies can be quite a challenge. Especially when, as is sadly common, the CVE description is (willingly?) vague, and no reproducer is available.

Posted Sun Jun 30 20:16:37 2019 Tags:

Debian LTS Logo

Here is my transparent report for my work on the Debian Long Term Support (LTS) project, which extends the security support for past Debian releases, as a paid contributor.

In May, the monthly sponsored hours were split evenly among contributors depending on their max availability - I declared max 30h and got 18h.

  • firefox-esr: jessie-security update, security-ish issue with modules signing authority, backporting stretch's
  • CVE-2018-19969/phpmyadmin: attempt backporting the 49 patches and decide against it since they merely mitigate the CSRF issues but certainly break the testsuite
  • CVE-2018-20839/systemd: attempt to reproduce issue in Jessie, conclude no-dsa due to non-reproducibility and regressions introduced by the patch
  • CVE-2019-2697/openjdk-7: triage (sync with previous uploaders, conclude "not-affected")
  • CVE-2019-0227/axis: triage (clarify SSRF situation, sync with packager, conclude "unfixed")
  • dns-root-data: discuss potential update, conclude not relevent due to no reverse dependencies
  • gradle, kdepim: update triage info

Incidentally, last month I mentioned how regularly updating a 19MB text file caused issues in Git - it appears it's even breaking! Sadly conversation between involved parties appears difficult.

If you'd like to know more about LTS security, I recommend you check:

Posted Fri May 31 15:22:10 2019 Tags:

Debian LTS Logo

Here is my transparent report for my work on the Debian Long Term Support (LTS) project, which extends the security support for past Debian releases, as a paid contributor.

In April, the monthly sponsored hours were split evenly among contributors depending on their max availability - I declared max 30h and got 17.25h.

Most of my time was spent on frontdesk duties, in particular vulnerabilities (CVE) triaging, so other contributors quickly know what to work on.
In all honesty I spent more time than assigned, as I took upon myself to dig how things work. Fun facts:

  • The (stable, non-LTS) Debian Security Team has a dozen members but the vast majority of the work is done by 2 people - every single day.
  • The main workflow is: import a daily list of new (public) CVEs from MITRE, batch classify for-us/not-for-us, locate information (patches...), determine severity, and possibly fix. I'm not sure how we're notified of private (embargoed) issues, they are rare.
  • The CVE list grew to a 19MB text file, which Git is pathologically bad at handling. Be ready to git gc regularly and forget about git blame (which is annoying when tracking the evolution of a particular vulnerability).
  • We discussed how to justify whether to fix a vulnerability, with topics on funding and light justifications ("minor issue").
  • Dealing with MITRE is still difficult, I couldn't get CVE-2018-19211 properly marked as duplicate and we had to de-dup on our side; however they did right on not rejecting CVE-2018-19217 as I asked since we eventually tracked a totally different affected version.

Anyway, for a more formal report:

  • triage of new and past undetermined vulnerabilities for jessie: samba (dla-needed), evolution-ews (dla-needed + open bug), libpodofo (ignored), claws-mail (dla-needed + open bug), kgb-bot (refresh status), systemd (dla-needed), cacti (dla-needed), wireshark (5 dla-needed, 5 not-affected jessie, 3 not-affected stretch), android-platform-system-core (NFU/not for us), exiv2 (not-affected), spip (not-affected), twitter-bootstrap (no-dsa, minor), ncurses (undetermined to duplicate + already fixed, clarify with upstream and MITRE), xslt (still no info from Apple), wpa (2 ignored + dla-needed), webkit2gtk (unsupported), epiphany-browser (not affected), gradle (dla-needed + open bug), qt4-x11 (dla-needed), libxslt (dla-needed), axis (dla-needed + report wrong link), gpac (dla-needed)
  • ghostscript: jessie-security update, backporting stretch-security's
  • answer user request on debian-lts
  • workflow discussions: double-posting annoucements, justifying (non-)updates
  • doc updates (reference logos page, update mailing-lists URLs, clamav handling, triage process, www update rationale

If you'd like to know more about LTS security, I recommend you check:

Posted Mon Apr 29 11:17:16 2019 Tags:

Debian LTS Logo

In February I had requested to join the Debian LTS project, which extends the security support for past Debian releases, as a paid contributor.
Kuddos to Freexian for pulling this project out.

I was asked to demonstrate a full security update on my own (non paid) which I did with 2 DLAs (Debian LTS Advisory):

  • freedink-dfarc: jessie-security update, applying my own path traversal security fix
  • phmyadmin: jessie-security update, assessing 1 CVE as not affected and fixing another

Incidentally, every Debian Developer can make a direct security upload to jessie-security without prior validation (just follow the guide).


Following the spirit of transparency that animates Debian and Debian Security, here's my report for my first paid month.

In March, the monthly sponsored hours were split evenly among contributors depending on their max availability.
I got 29.5h, which I spent on:

  • nettle/gnutls: investigate local side-channel attack and conclude no-dsa / minor issue
  • symfony: helped test Roberto's update
  • sqlalchemy: jessie-security update for SQL injection, tested and discussed upstream's own backported patch
  • glib2.0: investigate denial of service and mark as no-dsa / no reproducible
  • ghostscript: investigate sandbox break and (lack of) test suite, and conclude we'll backport the next upstream release
  • pdns: jessie-security update for the 'remote' backend
  • Fixes/updates in dla-needed.txt, our (public) list of triaged security issues
  • Fixes in LTS wiki, templates and scripts, in particular wrt integration

If you'd like to know more about LTS security, I recommend you check:

Posted Wed Apr 3 13:55:56 2019 Tags:

Android Rebuilds, which provides freely-licensed Android development tools, starts a public repository with F-Droid :)

We're now trying to make it usable for sdkmanager, which should vastly ease the installation process (download what you need, rather than huge mono-version bundles).
Help is welcome to format the repository and possibly adding a way to override sdkmanager's default repositories, join the conversation!

Posted Sun Feb 24 19:28:40 2019 Tags:

I like the Ren'Py project, a popular game engine aimed at Visual Novels - that can also be used as a portable Python environment.

One limitation was that it required downloading games, while nowadays people are used to Flash- or HTML5- based games that play in-browser without having to (de)install.

Can this fixed? While maintaining compatibility with Ren'Py's several DSLs? And without rewriting everything in JavaScript?
Can Emscripten help? While this is a Python/Cython project?
After lots of experimenting, and full-stack patching/contributing, it turns out the answer is yes!

Live demo:
The Question Tutorial Your game

At last I finished organizing and cleaning-up, published under a permissive free software / open source license, like Python and Ren'Py themselves.
Python port:
Build system:

Development in going on, consider supporting the project!

Posted Tue Feb 19 18:38:01 2019 Tags:

As described in a previous post, Google is still click-wrapping all Android developer binaries with a non-free EULA.

I recompiled SDK 9.0.0, NDK r18b and SDK Tools 26.1.1 from the free sources to get rid of it:

with one-command, Docker-based builds:

This triggered an interesting thread about the current state of free dev tools to target the Android platform.

Hans-Christoph Steiner also called for joining efforts towards a repository hosted using the F-Droid architecture:

What do you think?

Posted Sun Dec 2 14:57:30 2018 Tags:

Why try to choose the host that sucks less, when hosting a single-file (S)CGI gets you decentralized git-like + tracker + wiki?


We gotta take the power back.

Posted Wed Jun 6 17:12:45 2018 Tags:

I'm working again on making reproducible .exe-s. I thought I'd share my process:


  • End users get a bit-for-bit reproducible .exe, known not to contain trojan and auditable from sources
  • Point releases can reuse the exact same build process and avoid introducing bugs


  • Generate a source tarball (non reproducibly)
  • Debian Docker as a base, with fixed version + sources.list
    • Dockerfile: install packaged dependencies and MXE(.cc) from a fixed Git revision
    • Dockerfile: compile MXE with SOURCE_DATE_EPOCH + fix-ups
  • Build my project in the container with SOURCE_DATE_EPOCH and check SHA256
  • Copy-on-release


Generate a source tarball (non reproducibly)

This is not reproducible due to using non-reproducible tools (gettext, automake tarballs, etc.) but it doesn't matter: only building from source needs to be reproducible, and the source is the tarball.

It would be better if the source tarball were perfectly reproducible, especially for large generated content (./configure, wxGlade-generated GUI source code...), but that can be a second step.

Debian Docker as a base

AFAIU the Debian Docker images are made by Debian developers but are in no way official images. That's a pity, and to be 100% safe I should start anew from debootstrap, but Docker is providing a very efficient framework to build images, notably with caching of every build steps, immediate fresh containers, and public images repository.

This means with a single:

sudo -g docker make

you get my project reproducibly built from scratch with nothing to setup at all.

I avoid using a :latest tag, since it will change, and also backports, since they can be updated anytime. Here I'm using stretch:9.4 and no backports.

Using in sources.list makes sure the installed packaged dependencies won't change at next build. For a dot release however (not for a rebuild), they should be updated in case there was a security fix that has an effect on built software (rare, but exists).

Last but not least, APT::Install-Recommends "false"; for better dependency control.

MXE is compilation environment to get MingGW (GCC for Windows) and selected dependencies rebuilt unattended with a single make. Doing this manually would be tedious because every other day, upstream breaks MinGW cross-compilation, and debugging an hour-long build process takes ages. Been there, done that.

MXE has a reproducible-boosted binutils with a patch for SOURCE_DATE_EPOCH that avoids getting date-based and/or random build timestamps in the PE (.exe/.dll) files. It's also compiled with --enable-deterministic-archives to avoid timestamp issues in .a files (but no automatic ordering).

I set SOURCE_DATE_EPOCH to the fixed Git commit date and I run MXE's build.

This does not apply to GCC however, so I needed to e.g. patch a __DATE__ in wxWidgets.

In addition, libstdc++.a has a file ordering issue (said ordering surprisingly stays stable between a container and a host build, but varies when using a different computer with the same distros and tools versions). I hence re-archive libstdc++.a manually.

It's worth noting that PE files don't have issues with build paths (and varying BuildID-s - unlike ELF... T_T).

Again, for a dot release, it makes sense to update the MXE Git revision so as to catch security fixes, but at least I have the choice.

Build project

With this I can start a fresh Docker container and run the compilation process inside, as a non-privileged user just in case.

I set SOURCE_DATE_EPOCH to the release date at 00:00UTC, or the Git revision date for snapshots.

This rebuild framework is excluded from the source tarball, so the latter stays stable during build tuning. I see it as a post-release tool, hence not part of the release (just like distros packaging).

The generated .exe is statically compiled which helps getting a stable result (only the few needed parts of dependencies get included in the final executable).

Since MXE is not itself reproducible differences may come from MXE itself, which may need fixes as explained above. This is annoying and hopefully will be easier once they ship GCC6. To debug I unzip the different .zip-s, upx -d my .exe-s, and run diffoscope.

I use various tricks (stable ordering, stable timestamping, metadata cleaning) to make the final .zip reproducible as well. Post-processing tools would be an alternative if they were fixed.


Any process is moot if it can't be tested.

reprotest helps by running 2 successive compilations with varying factors (build path, file system ordering, etc.), and check that we get the exact same binary. As a trade-off, I don't run it on the full build environment, just on the project itself. I plugged reprotest to the Docker container by running a sshd on the fly. I have another Makefile target to run reprotest in my host system where I also installed MXE, so I can compare results and sometimes find differences (e.g. due to using a different filesystem). In addition this is faster for debugging since changing anything in the early Dockerfile steps means a full 1h rebuild.


At release time I make a copy of the directory that contains all the self-contained build scripts and the Dockerfile, and rename it after the new release version. I'll continue improving upon the reproducible build system in the 'snapshot' directory, but the versioned directory will stay as-is and can be used in the future to get the same bit-for-bit identical .exe anytime.

This is the technique I used in my Android Rebuilds project.

Other platforms

For now I don't control the build process for other platforms: distros have their own autobuilders, so does F-Droid. Their problem :P

I have plans to make reproducible GNU/Linux AppImage-based builds in the future though. I should be able to use a finer-grained, per-dependency process rather than the huge MXE-based chunk I currently do.

I hope this helps other projects provide reproducible binaries directly! Comments/suggestions welcome.

Posted Sat Jun 2 17:12:59 2018 Tags:

Ever wanted to try this weird GNU FreeDink game, but never had the patience to install it?
Today, you can play it with a single click :)

Play GNU FreeDink

This is a first version that can be polished further but it works quite well.
This is the original C/C++/SDL2 code with a few tweaks, cross-compiled to WebAssembly (and an alternate version in asm.js) with emscripten.
Nothing brand new I know, but things are getting smoother, and WebAssembly is definitely a performance boost.

I like distributed and autonomous tools, so I'm generally not inclined to web-based solutions.
In this case however, this is a local version of the game. There's no server side. Savegames are in your browser local storage. Even importing D-Mods (game add-ons) is performed purely locally in the in-memory virtual FS with a custom .tar.bz2 extractor cross-compiled to WebAssembly.
And you don't have to worry about all these Store policies (and Distros policies^W^W^W.

I'm interested in feedback on how well these works for you in your browsers and devices:

I'm also interested in tips on how to place LibreJS tags - this is all free JavaScript.

Posted Fri May 25 23:37:39 2018 Tags:

This blog is powered by ikiwiki.