debian on bisco.org

Status update, February - April 2026

Sun, 03 May 2026 06:28:51 +0100

Due to health reasons I did not have the energy to write individual status updates for February & March, so I’ll just combine them with the April update:

In February I cleaned out my GitHub account and moved all remaining projects to Codeberg. I archived the repositories on GitHub and added links to the new repositories on Codeberg. GitHub is a platform that is more and more frustrating to use. I still have to use it for my dayjob, though. The number of pull requests and issues that are written either by bots or by users that use bots increased in the last two years. Combined with that, GitHub provides a very low barrier for entitled users who do not want to contribute to a productive environment. GitHub now feels like the Twitter/X of git forges. Codeberg on the other hand is a community project. I feel a lot more at home there and the platform itself feels a lot more responsive than GitHub.

Uploaded wayback 0.3-1 to experimental
Uploaded slurp 1.6.0-1 to unstable
Uploaded first a prerelease of sway to experimental to be able to test wlroots 0.20.0 and then uploaded rc1, rc2 and rc3 of the upcoming 1.12 release
Uploaded waybar 0.15.0-1 to unstable
Uploaded kanshi 1.9.0-1 to unstable, which was possible because the dependency libscfg finally went through NEW
Uploaded libscfg 0.2.0-1 to unstable
Uploaded swaybg 1.2.2-1 to unstable
Uploaded labwc 0.9.4-1, 0.9.5 & 0.9.6 to unstable
Fixed the packaging of vali and uploaded version 0.1.1-1 to unstable; then added vali to the build dependencies of kanshi and reuploaded 1.9.0-2 thereof
Uploaded swaylock 1.8.5-1 to unstable
Uploaded fcft 3.3.3-1 to unstable
Uploaded foot 1.26.1-1 to unstable
Uploaded swayimg 5.0-1 and 5.1-1 to unstable
Fixed some packaging metadata in libsfdo and uploaded 0.1.4-2 to unstable
Reverted the upload of slurp from 1.6.0-1 to 1.6.0really1.5.0-1 because the upstream release of 1.6.0 was made by mistake and yanked a week later. Maybe I should add a cooldown period before uploading new releases ;)
Uploaded mako-notifier 1.11.0-1 to unstable
Uploaded cage 0.3.0-1 to experimental which uses wlroots 0.20.0
Uploaded xdg-desktop-portal-wlr 0.8.2-1 to unstable
Voted

I took part in the DHD 2026 Conference in Vienna, including a hands-on workshop of the dhinfra project.

I released 0.60.0, 0.61.0 and 0.62.0 of apis-core-rdf. We rewrote the configuration format for the importer. We previously used TOML files, but that does not give us inheritance. So we now use simply Python classes as configuration format.

I implemented a new backend for our apis-bibsonomy Django package. The package is meant to provide a datamodel for storing reference data that links to Bibsonomy or Zotero. Given that we don’t use Bibsonomy anymore we now dropped the Bibsonomy backend but added a Zotero backend that allows to cache the entries locally.

Status update, January 2026

Fri, 06 Feb 2026 06:28:51 +0100

January was a slow month, I only did three uploads to Debian unstable:

xdg-desktop-portal-wlr updated to 0.8.1-1
swayimg updated to 4.7-1
usbguard updated to 1.1.4+ds-2, which closed #1122733

I was very happy to see the new dfsg-new-queue and that there are more hands now processing the NEW queue. I also finally got one of the packages accepted that I uploaded after the Trixie release: wayback which I uploaded last August. There has been another release since then, I’ll try to upload that in the next few days.

There was a bug report for carl asking for Windows support. carl used the xdg create for looking up the XDG directories, but xdg does not support windows systems (and it seems this will not change) The reporter also provided a PR to replace the dependency with the directories crate which more system agnostic. I adapted the PR a bit and merged it and released version 0.6.0 of carl.

At my dayjob I refactored django-grouper. django-grouper is a package we use to find duplicate objects in our data. Our users often work with datasets of thousands of historical persons, places and institutions and in projects that run over years and ingest data from multiple sources, it happens that entries are created several times. I wrote the initial app in 2024, but was never really happy about the approach I used back then. It was based on this blog post that describes how to group spreadsheet text cells. It uses sklearns TfidfVectorizer with a custom analyzer and the library sparse_dot_topn for creating the matrix. All in all the module to calculate the clusters was 80 lines and with sparse_dot_topn it pulled in a rather niche Python library. I was pretty sure that this functionality could also be implemented with basic sklearn functionality and it was: we are now using DictVectorizer because in a Django app we are working with objects that can be mapped to dicts anyway. And for clustering the data, the app now uses the DBSCAN algorithm (with the manhattan distance as metric). The module is now only half the size and the whole app lost one dependency! I released those changes as version 0.3.0 of the app.

At the end of January together with friends I went to Brussels to attend FOSDEM. We took the night train but there were a couple of broken down trains so the ride took 26 hours instead of one night. It is a good thing we had a one day buffer and FOSDEM only started on Saturday. As usual there were too many talks to visit, so I’ll have to watch some of the recordings in the next few weeks.

Some examples of talks I found interesting so far:

a talk about supporting Python web deployments with Rust in the Rust Developer room
a talk about duckdb in the Python Developer room
an introduction to particleos in the Distributions Developer room

Status update, December 2025

Fri, 02 Jan 2026 06:28:51 +0100

December 2025 started off with a nice event, namely a small gathering of Vienna based DDs. Some of us were at DebConf25 in Brest and we thought it might be nice to have a get-together of DDs in Vienna. A couple of months after DebConf25 I picked up the idea, let someone else ping the DDs, booked a table at a local cafe and in the end we were a group of 6 DDs. It was nice to put faces to names, names to nicknames and to hear what people are up to. We are definitely planning to repeat that!

December also ended with a meeting of nerds: the 39th Chaos Communication Congress in Hamburg. As usual, I did not really have that much time to watch many talks. I tend to bookmark a lot of them in the scheduling app in advance, but once I’m at the congress the social aspect is much more important and I try to only attend workshop or talks that are not recorded. Watching the recordings afterward is possible anyway (and I actually try to do that!).

There was also a Debian Developers meetup at day 3, combined with the usual time confusion regarding UTC and CET. We talked about having a Debian table at 40c3, so maybe the timezone won’t be that much of a problem in the next time.

Two talks I recommend are CSS Clicker Training: Making games in a “styling” language and To sign or not to sign: Practical vulnerabilities in GPG & friends.

Regarding package uploads this month did not happen that much, I only uploaded the new version (0.9.3) of labwc.

I created two new releases for carl. First a 0.5 release that adds Today and SpecifiedDate as properties. I forwarded an issue about dates not being parsed correctly to the icalendar issue tracker and this was fixed a couple of days later (thanks!). I then created a 0.5.1 release containing that fix. I also started planning to move the carl repository back to codeberg, because Github feels more and more like an AI Slop platform.

The work on debiverse also continued. I removed the tailwind CSS framework, and it was actually not that hard to reproduce all the needed CSS classes with custom CSS. I think that CSS frameworks make sense to a point, but once you start implementing stuff that the framework does not provide, it is easier if everything comes out of one set of rules. There was also the article Vanilla CSS is all you need which goes into the same direction and which gave me some ideas how to organize the CSS directives.

I also refactored the filter generation for the listing filters and the HTML filter form is now generated from the FastAPI Query Parameter Model.

For navigation I implemented a sidebar, that is hidden on small screens but can be toggled using a burger menu.

I also stumbled upon An uncomfortable but necessary discussion about the Debian bug tracker, which raises some valid points. I think debiverse could be a solution to the first point of “What could be a way forward?”, namely: “Create a new web service that parses the existing bug data and displays it in a “rich” format”.

But if there is ever another way than email to interact with bugs.debian.org, than this approach should not rely on passing on the commands via mail. If I click a button in a web interface to raise the severity, the severity should be raised right away - not 10 minutes later when the email is received. I think the individual parts (web, database, mail interface) should be decoupled and talk to each other via APIs.

Status update, November 2025

Tue, 02 Dec 2025 06:28:51 +0100

I started this month with a week of vacation which was followed by a small planned surgery and two weeks of sick leave. Nonetheless, I packaged and uploaded new releases of a couple of packages:

swayidle updated to version 1.9.0-1
swaylock updated to version 1.8.4-1
foot updated to version 1.25.0-1
swayimg updated to version 4.6-1
scdoc updated to version 1.11.4-1
wofi updated to version 1.5.1-1
xdg-desktop-portal-wlr updated to version 0.8.0-1

Besides that I reactivated I project I started in summer 2024: debiverse.org. The idea of that was to have interfaces to Debian bugs and packages that are usable on mobile devices (I know, ludicrous!). Back then I started with Flask and Sqlalchemy, but that soon got out of hand. I now switched the whole stack to FastAPI and SQLModel which makes it a lot easier to manage. And the upside is that it comes with an API and OpenAPI docs. For the rendered HTML pages I use Jinja2 with Tailwind as CSS framework. I am currently using udd-mirror as database backend, which works pretty good (for this single user project). It would be nice to have some of the data in a faster index, like Typesense or Meilisearch. This way it would be possible to have faceted search or more performant full text search. But I haven’t found any software that could provide this that is packaged in Debian.

Status update, October 2025

Mon, 03 Nov 2025 06:28:51 +0100

At the beginning of the month I uploaded a new version of the sway package to Debian. This contains two backported patches, one to fix reported WM capabilities and one to revert the default behavior for drag_lock to disabled.

I also uploaded new releases of cage (a kiosk for Wayland), labwc, the window-stacking Wayland compositor that is inspired by Openbox, and wf-recorder, a tool for creating screen recordings of wlroots-based Wayland compositors.

If I don’t forget I try to update the watch file of the packages I touch to the new version 5 format.

Simon Ser announced vali, a C library for Varlink. The blog post also mentions that this will be a dependency of “the next version of the kanshi Wayland output management daemon” and the PR to do so is now already merged. So I created ITP: vali – A Varlink C implementation and code generator, packaged the library and it is now waiting in NEW. In addition to libscfg this is now the second dependency of kanshi that is in NEW.

On the Rust side of things I fixed a bug in carl. The fix introduces new date properties which can be use to highlight a calendar date. I also updated all the dependencies and plan to create a new release soon.

Later I dug up a Rust project that I started a couple of years ago, where I try to use wasm-bindgen to implement interactive web components. There is a lot I have to refactor in this code base, but I will work on that and try to publish something in the next few months.

Miscellaneous

Two weeks ago I wrote A plea for <dialog>, which made the case for using standardized HTML elements instead of resorting to JavaScript libraries.

I finally managed to update my shell Server to Debian 13.

I created an issue for the nextcloud-news android client because I moved to a new phone and my starred articles did not show up in the news app, which is a bit annoying.

I got my ticket for 39C3.

In my dayjob I continued to work on the refactoring of the import logic of our apis-core-rdf app. I released version 0.56 which also introduced the “#snackbar” as the container for the toast message, as described in the <dialog> block post. At the end of the month I released version 0.57 of apis-core-rdf, which got rid of the remaining leftovers of the old import logic.

A couple of interesting articles I stumbled upon (or finally had the time to read):

A plea for

Mon, 20 Oct 2025 06:28:51 +0100

A couple of weeks ago there was an article on the Freexian blog about Using JavaScript in Debusine without depending on JavaScript. It describes how JavaScript is used in the Debusine Django app, namely “for progressive enhancement rather than core functionality”. This is an approach I also follow when implementing web interfaces and I think developments in web technologies and standardization in recent years have made this a lot easier.

One of the examples described in the post, the “Bootstrap toast” messages, was something that I implemented myself recently, in a similar but slightly different way.

In the main app I develop for my day job we also use the Bootstrap framework. I have also used it for different personal projects (for example the GSOC project I did for Debian in 2018, was also a Django app that used Bootstrap). Bootstrap is still primarily a CSS framework, but it also comes with a JavaScript library for some functionality. Previous versions of Bootstrap depended on jQuery, but since version 5 of Bootstrap, you don’t need jQuery anymore. In my experience, two of the more commonly used JavaScript utilities of Bootstrap are modals (also called lightbox or popup, they are elements that are displayed “above” the main content of a website) and toasts (also called alerts, they are little notification windows that often disappear after a timeout). The thing is, Bootstrap 5 was released in 2021 and a lot has happened since then regarding web technologies. I believe that both these UI components can nowadays be implemented using standard HTML5 elements.

An eye opening talk I watched was Stop using JS for that from last years JSConf(!). In this talk the speaker argues that the Rule of least power is one of the core principles of web development, which means we should use HTML over CSS and CSS over JavaScript. And the speaker also presents some CSS rules and HTML elements that added recently and that help to make that happen, one of them being the dialog element:

The <dialog> HTML element represents a modal or non-modal dialog box or other interactive component, such as a dismissible alert, inspector, or subwindow.

– The Dialog element at MDN

The baseline for this element is “widely available”:

This feature is well established and works across many devices and browser versions. It’s been available across browsers since March 2022.

– The Dialog element at MDN

This means there is an HTML element that does what a modal Bootstrap does!

Once I had watched that talk I removed all my Bootstrap modals and replaced them with HTML <dialog> elements (JavaScript is still needed to .show() and .close() the elements, though, but those are two methods instead of a full library). This meant not only that I replaced code that depended on an external library, I’m now also a lot more flexible regarding the styling of the elements.

When I started implementing notifications for our app, my first approach was to use Bootstrap toasts, similar to how it is implemented in Debusine. But looking at the amount of HTML code I had to write for a simple toast message, I thought that it might be possible to also implement toasts with the <dialog> element. I mean, basically it is the same, only the styling is a bit different. So what I did was that I added a #snackbar area to the DOM of the app. This would be the container for the toast messages. All the toast messages are simply <dialog> elements with the open attribute, which means that they are visible right away when the page loads.

<div id="snackbar">
  {% for message in messages %}
    <dialog class="mytoast alert alert-{{ message.tags }}" role="alert" open>
      {{ message }}
    </dialog>
  {% endfor %}
</div>

This looks a lot simpler than the Bootstrap toasts would have.

To make the <dialog> elements a little bit more fancy, I added some CSS to make them fade in and out:

.mytoast {
    z-index: 1;
    animation: fadein 0.5s, fadeout 0.5s 2.6s;
}

@keyframes fadein {
    from {
        opacity: 0;
    }

    to {
        opacity: 1;
    }
}

@keyframes fadeout {
    from {
        opacity: 1;
    }

    to {
        opacity: 0;
    }
}

To close a <dialog> element once it has faded away, I had to add one JavaScript event listener:

window.addEventListener('load', () => {
    document.querySelectorAll(".mytoast").forEach((element) => {
        element.addEventListener('animationend', function(e) {
            e.animationName == "fadeout" && element.close();
        });
    });
});

(If one would want to use the same HTML code for both script and noscript users, then the CSS should probably adapted: it fades away and if there is no JavaScript to close the element, it stays visible after the animation is over. A solution would for example be to use a close button and for noscript users simply let it stay visible - this is also what happens with the noscript messages in Debusine).

So there are many “new” elements in HTML and a lot of “new” features of CSS. It makes sense to sometimes ask ourselves if instead of the solutions we know (or what a web search / some AI shows us as the most common solution) there might be some newer solution that was not there when the first choice was created. Using standardized solutions instead of custom libraries makes the software more maintainable. In web development I also prefer standardized elements over a third party library because they have usually better accessibility and UX.

In How Functional Programming Shaped (and Twisted) Frontend Development the author writes:

Consider the humble modal dialog. The web has <dialog>, a native element with built-in functionality: it manages focus trapping, handles Escape key dismissal, provides a backdrop, controls scroll-locking on the body, and integrates with the accessibility tree. It exists in the DOM but remains hidden until opened. No JavaScript mounting required.

[…]

you’ve trained developers to not even look for native solutions. The platform becomes invisible. When someone asks “how do I build a modal?”, the answer is “install a library” or “here’s my custom hook,” never “use <dialog>.”

– Ahmad Alfy

Status update, September 2025

Wed, 01 Oct 2025 06:28:51 +0100

Regarding Debian packaging this was a rather quiet month. I uploaded version 1.24.0-1 of foot and version 2.8.0-1 of git-quick-stats. I took the opportunity and started migrating my packages to the new version 5 watch file format, which I think is much more readable than the previous format.

I also uploaded version 0.1.1-1 of libscfg to NEW. libscfg is a C implementation of the scfg configuration file format and it is a dependency of recent version of kanshi. kanshi is a tool similar to autorandr which allows you define output profiles and kanshi switches to the correct output profile on hotplug events. Once libscfg is in unstable I can finally update kanshi to the latest version.

A lot of time this month in finalizing a redesign of the output rendering of carl. carl is a small rust program I wrote that provides a calendar view similar to cal, but it comes with colors and ical file integration. That means that you can not only display a simple calendar, but also colorize/highlight dates based on various attributes or based on events on that day. In the initial versions of carl the output rendering was simply hardcoded into the app.

This was a bit cumbersome to maintain and not configurable for users. I am using templating languages on a daily basis, so I decided I would reimplement the output generation of carl to use templates. I chose the minijinja Rust library which is “based on the syntax and behavior of the Jinja2 template engine for Python”. There are others out there, like tera, but minijinja seems to be more active in development currently. I worked on this implementation on and off for the last year and finally had the time to finish it up and write some additional tests for the outputs. It is easier to maintain templates than Rust code that uses write!() to format the output. I also implemented a configuration option for users to override the templates.

Additional to the output refactoring I also fixed couple of bugs and finally released v0.4.0 of carl.

In my dayjob I released version 0.53 of apis-core-rdf which contains the place lookup field which I implemented in August. A couple of weeks later we released version 0.54 which comes with a middleware to show pass on messages from the Django messages framework via response header to HTMX to trigger message popups. This implementation is based on the blog post Using the Django messages framework with HTMX. Version 0.55 was the last release in September. It contained preparations for refactoring the import logic as well as a couple of UX improvements.

Status update, August 2025

Mon, 01 Sep 2025 06:28:51 +0100

Due to the freeze I did not do that many uploads in the last few months, so there were various new releases I packaged once Trixie was released. Regarding the release of Debian 13, Trixie, I wrote a small summary of the changes in my packages.

I uploaded an unreleased version of cage to experimental, to prepare for the transition to wlroots-0.19. Both sway and labwc already had packages in experimental that depended on the new wlroots version. When the transition happened, I uploaded the cage version to unstable, as well as labwc 0.9.1 and sway 1.11.

I updated

foot to 1.23.1
waybar to 0.14.0
swaylock to 1.8.3
git-quick-stats to 2.7.0
swayimg to 4.5
usbguard to 1.1.4
fcft to 3.3.2
fnott to 1.8.0
wdisplays to 1.1.3
wev to 1.1.0
wlopm to 1.0.0
wmenu to 0.2.0
libsfdo to 0.1.4

Most of the packages I uploaded using git-debpush, some of them could not be uploaded this way due to upstream using git submodules (this is 1107219). I also created 1112040 - git-debpush: should also say which tag it created and 1111504 - git-debpush: pristine-tar check warns about pristine-tar data thats not present (which is already fixed).

I uploaded wayback 0.2 to NEW, where it is waiting for review, (ITP).

In my dayjob I added extended the place lookup form of apis-core-rdf to allow searching places and selecting them on a map using leaflet and the nominatim API. Another issue I worked on was about highlighting those inputs of our generic list filter that are used to filter the results. I released a couple of bugfix releases for the v0.50 release, then v0.51 and two bugfix releases and then v0.52 and another couple of bugfix releases. v0.53 will land in a couple of days. I also released v0.6.2 of apis-highlighter-ng, which is sort of a plugin for apis-core-rdf, that allows to highlight parts of a text and link them to whatever Django object (in our case relations).

Updates and additions in Debian 13 Trixie

Sat, 16 Aug 2025 06:28:51 +0100

Last week Debian 13 (Trixie) was released and there have been some updates and additions in the packages that I maintain, that I wanted to write about. I think they are not worth of being added to the release notes, but I still wanted to list some of the changes and some of the new packages.

sway

Sway, the tiling Wayland compositor was version 1.7 in Bookworm. It was updated to version 1.10 (and 1.11 is already in experimental and waiting for an upload to unstable). This new version of sway brings, among a lot of other features, updated support for touchpad gestures and support for the ext-session-lock-v1 protocol, which allows for more robust and secure screen locking. The configuration snippet that activates the default sway background is now shipped in the sway-backgrounds package instead of being part of the sway package itself.

The default menu application was changed from dmenu to wmenu. wmenu is a Wayland native alternative to dmenu which I packaged and it is now recommended by sway.

There are some small helper tools for sway that were updated: swaybg was bumped from 1.2.0 to 1.2.1, swaylock was bumped from 1.7.2 to 1.8.2.

The grimshot script, which is a script for making screenshots, was part of the sway’s contrib folder for a long time (but was shipped as a separate binary package). It was removed from sway and is now part of the sway-contrib project. There are some other useful utilities in this source package that I might package in the future.

slurp, which is used by grimshot to select a region, was updated from version 1.4 to version 1.5.

labwc

I uploaded the first labwc package two years ago and I’m happy it is now part of a stable Debian release. Labwc is also based on wlroots, like sway. It is a window-stacking compositor and is inspired by openbox. I used openbox for a long time back in the day before I moved to i3 and I’m very happy to see that there is a Wayland alternative.

foot

Foot is a minimalistic and fast Wayland terminal emulator. It is mostly keyboard driven. foot was updated from version 1.13.1 to 1.21.0. The probably most important change for users updating might be the fact that:

Control+Shift+u is now bound to unicode-input instead of show- urls-launch, to follow the convention established in GTK and Qt

show-urls-launch now bound to Control+Shift+o

et cetera

The Wayland kiosk cage was updated from 0.1.4 to 0.2.0.

The waybar bar for wlroots compositors was updated from 0.9.17 to 0.12.0.

swayimg was updated from 1.10 to 3.8 and now brings support for custom key bindings, support for additional image types (PNM, EXR, DICOM, Farbfeld, sixel) and a gallery mode.

tofi, another dmenu replacement was updated from 0.8.1 to 0.9.1, wf-recorder a tool for screen recording in wlroots-based compositors, was updated from version 0.3 to version 0.5.0. wlogout was updated from version 1.1.1 to 1.2.2. The application launcher wofi was updated from 1.3 to 1.4.1. The lightweight status panel yambar was updated from version 1.9 to 1.11. kanshi, the tool for managing and automatically switching your output profiles, was updated from version 1.3.1 to version 1.5.1.

usbguard was updated from version 1.1.2 to 1.1.3.

added

fnott - a lightweight notification daemon for wlroots based compositors
fyi - a utility to send notifications to a notification daemon, similar to notify-send
pipectl - a tool to create and manage short-lived named pipes, this is a dependency of wl-present. wl-present is a script around wl-mirror which implements output mirroring for wlroots-based compositors
poweralertd - a small daemon that notifies you about the power status of your battery powered devices
wlopm - control power management of outputs
wlrctl - command line utility for miscellaneous wlroots Wayland extensions
wmenu - already mentioned, the new default launcher of sway
wshowkeys - shows keypresses in wayland sessions, nice for debugging
libsfdo - libraries implementing some freedesktop.org specs, used by labwc

Status update, July 2025

Fri, 01 Aug 2025 06:28:51 +0100

In beginning of July I got my 12" framework laptop and installed Debian on it. During that setup I made some updates to my base setup scripts that I use to install Debian machines.

Due to the freeze I did not do much package related work. But I was at DebConf and I uploaded a new release of labwc to experimental, mostly to test the tag2upload workflow.

I started working on packaging wlr-sunclock which is a small Wayland widget that displays the sun’s shadows on the earth. I also created an ITP for wayback. Wayback is an X11 compatibility layer to allow to run X11 desktop environments using Wayland.

In my dayjob I did my usual work on apis-core-rdf, which is our Django application for managing prosopographic data. I implemented a password change interface and did some restructuring of the templates. We released a new version which was followed by a bugfix release a couple of days later.

I also implemented a rather big refactoring in pfp-api. PFP-API is a FastAPI based REST API that uses rdfproxy to fetch data from a Triplestore, converts the data to Pydantic models and then ships the models as JSON. Most of the work is done by rdfproxy in the background, but I adapted the existing pfp-api code to make it easier to add new entity types.

My DebConf 25 review

Sat, 26 Jul 2025 06:28:51 +0100

DebConf 25 happened between 14th July and 19th July and I was there. It was my first DebConf (the big one, I was at a Mini DebConf in Hamburg a couple of years ago) and it was interesting. DebConf 25 happened at a Campus University at the outskirts of Brest and I was rather reluctant to go at first (EuroPython 25 was happening at the same time in Prague), but I decided to use the chance of DebConf happening in Europe, reachable by train from Vienna. We took the nighttrain to Paris, then found our way through the maze that is the Paris underground system and then got to Brest with the TGV. On our way to the Conference site we made a detour to a supermarket, which wasn’t that easy because is was a national holiday in France and most of the shops were closed. But we weren’t sure about the food situation at DebConf and we also wanted to get some beer.

At the conference we were greeted by very friendly people at the badge station and the front desk and got our badges, swag and most important the keys to pretty nice rooms on the campus. Our rooms had a small private bathroom with a toilet and a shower and between the two rooms was a shared kitchen with a refrigerator and a microwave. All in all, the accommodation was simple but provided everything we needed and especially a space to have some privacy.

During the next days I watched a lot of talks, met new people, caught up with old friends and also had a nice time with my travel buddies. There was a beach near the campus which I used nearly every day. It was mostly sunny except for the last day of the conference, which apparently was not common for the Brest area, so we got lucky regarding the weather.

Given that we only arrived in the evening of the first day of DebConf, I missed the talk When Free Software Communities Unite: Tails, Tor, and the Fight for Privacy (recording), but I watched it on the way home and it was also covered by LWN.

On Tuesday I started the day by visiting a talk about tag2upload (recording). The same day there was also an academic track and I watched the talk titled Integrating Knowledge Graphs into the Debian Ecosystem (recording) which presented a property graph showing relationships between various entities like packages, maintainers or bugs (there is a repository with parts of a paper, but not much other information). The speaker also mentioned the graphcast framework and the ontocast framework which sound interesting - we might have use for something liked this at $dayjob.

In the afternoon there was a talk about the ArchWiki (recording) which gave a comprehensive insight in how the ArchWiki and the community behind it works. Right after that was a Debian Wiki BoF. There are various technical limitations with the current wiki software and there are not enough helping hands to maintain the service and do content curation. But the BoF had some nice results: there is now a new debian-wiki mailinglist, an IRC channel, a MediaWiki installation has been set up during DebConf, there are efforts to migrate the data and most importantly: and handful of people who want to maintain the service and organize the content of the wiki. I think the input from the ArchWiki folks gave some ideas how that team could operate.

Wednesday was the day of the daytrip. I did not sign up for any of the trips and used the time to try out tag2upload, uploaded the latest labwc release to experimental and spent the rest of the day at the beach.

Other noteworthy session I’ve attended were the Don’t fear the TPM talk (recording), which showed me a lot of stuff to try out, the session about lintian-ng (no recording), which is an experimental approach to make lintian faster, the review of the first year of wcurls existence (no recording yet) and the summary of Rust packaging in Debian (no recording yet). In between the sessions I started working on packaging wlr-sunclock (#1109230).

What did not work

Vegan food.

I might be spoiled by other conferences. Both at EuroPycon last year (definitely bigger, a lot more commercial) and at PyCon CZ 23 (similar in size, a lot more DIY) there was catering with explicitly vegan options.

As I’ve mentioned in the beginning, we went to a supermarket before we went to the conference and we had to go there one more time during the conference. I think there was a mixture between a total lack of awareness and a LOT of miscommunication. The breakfasts at the conference consisted of pastries and baguettes - I asked at the first day what the vegan options were and the answer was “I don’t know, maybe the baguette?” and we were asked to only take as much baguette as the people who also got pastries.

The lunch was prepared by the “Restaurant associatif de Kernévent” which is a canteen at the university campus. When we asked if there is vegan food, the people there said that there was only a vegetarian option so we only ate salad. Only later we heard via word of mouth that one has to explicitly ask for a vegan meal which was apparently prepared separatly and you had to find the right person that knows about it (I think thats very Debian-like 😉). But even then a person once got a vegetarian option offered as vegan food.

One problem was also the missing / confusing labeling of the food. At the conference dinner there was apparently vegan food, but it was mixed with all the other food. There were some labels but with hundreds of hungry people around and caterers removing empty plates and dropping off plates with other stuff, everything gets mixed up. In the end we ate bread soaked in olive oil, until the olive oil got taken away by the catering people literally while we were dipping the bread in it.

And when these issues were raised, some of the reactions can be summarized as “You’re holding it wrong” which was really frustrating.

The dinners at the conference hall were similar. At some point I had the impression that “vegan” and “vegetarian” was simply seen as the same thing.

If the menus would be written like a debian/copyright file it would probably have looked like this:

Food: *
Diet: Vegan or Vegetarian

But the thing is that Vegan and Vegetarian cannot be mixed. Its similar to non compatible licenses. Once you mix vegan food with vegan food with vegetarian food it’s not vegan anymore.

Don’t get me wrong, I know its hard to organize food for hundreds of people. But if you don’t know what it means to provide a vegan option, just communicate the fact so people can look alternatives in advance. During the week some of the vegan people shared food, which was really nice and there were also a lot of non-vegan people who tried to help, organized extra food or simply listened to the hangry rants. Thanks for that!

Paris

Saturday was the last day of DebConf and it was a rainy day. On Sunday morning we took the TGV back to Paris and then stayed there for one night because the next night train back to Vienna was on Monday. Luckily the weather was better in Paris. The first thing we did was to look up a vegan burger place. In the evening we strolled along the Seine and had a couple of beers at the Jardins du Trocadéro. Monday the rain also arrived in Paris and we mostly went from one cafe to the next, but also managed to visit Notre Dame.

Conclusio

The next DebConf will be in Argentina and I think its likely that DebConf 27 will also not happen anywhere in trainvelling distance. But even if, I think the Mini DebConfs are more my style of happening (there is one planned in Hamburg next spring, and a couple of days ago I learned that there will be a Back to the Future musical show in Hamburg during that time). Nonetheless I had a nice time and I stumbled over some projects I might get more involved in. Thanks also to my travel buddies who put up with me 😋

My first tag2upload upload

Thu, 17 Jul 2025 09:28:51 +0100

Following the DebConf25 talk by Ian Jackson tag2upload - upload simply by pushing a signed git tag I decided to use the quiet time during the day of the DayTrip on DebConf 25 to try out uploading a package using tag2upload.

Given the current freeze a couple of the packages I maintainer have new releases waiting. I decided on uploading the new version of labwc to experimental. Labwc is a Wayland compositor based on the wlroots compositor library (the library that sway is using). Labwc is inspired by the Openbox window manager. The upstream team of Labwc released version 0.9.0 last week, the first version that is based on wlroots 0.19.x. Wlroots 0.19.x is also only available in experimental, so that was a good fit for trying an upload with tag2upload.

I first used my usual workflow, going into my package repository, doing get fetch origin, checking out the tag of the new release and tagging that with git tag upstream/0.9.0. Then I bumped the version in the debian/experimental branch, adapted the debian/control file for the changed wlroots dependency, committed and built the package using git-buildpackage to check if it builds fine and there are no lintian errors. Then I moved on to look at tag2upload.

As a starting point for using tag2upload I read the blogpost by Jonathan Carter My first tag2upload upload. It pointed me to one very important option of git debpush, namely the --baredebian option which I have to use because I use the bare Debian git layout. Given that the last upload of labwc I did was to unstable, I also had to add the --force=changed-suite.

I also started right away to use the --tag-only option, because for my first tests I only wanted to have local changes and nothing pushed to anywhere. I also used the --dry-run option. This led to the following command:

> git debpush --baredebian --force=changed-suite --dry-run --tag-only
tags 0.9.0, upstream/0.9.0 all exist in this repository
tell me which one you want to make an orig.tar from: git deborig --just-print '--version=0.9.0-1' TAG
git-debpush: git-deborig failed; maybe try git-debpush --upstream=TAG

This was a bit confusing, because the error message talked about git-deborig, but I was using git-debpush. I also did not want to make an orig.tar! The --upstream option in the git-debpush(1) manual gave an explanation for this:

When pushing a non-native package, git-debpush needs a tag for the upstream part of your package.

By default git-debpush asks git-deborig(1), which searches for a suitable tag based on the upstream version in debian/changelog.

So apparently git-debpush can not find out what the correct tag for the upstream version is, because git-deborig can not find out what the correct tag for the upstream version is. git-debpush simply calls git deborig --just-print --version="$version" in line 437. This fails because I initially created a second upstream/0.9.0 to the existing 0.9.0 release tag. I do this for git-buildpackage to find the upstream sources, but with multiple tags git-deborig is not sure which one is the tag it should use (although both point to the same commit).

So I removed the upstream/0.9.0 tag and ran git debpush again and now there was no error message (besides the warning regarding the changed suite) but it also did not give an feedback about what is happening. So I tried without the --dry-run option. Again, no output whatsoever, other than the warning about the changed release, BUT my gnupg asked me for permission to sign via my yubikey! And when I looked at the list of tags, I saw that there is now a debian/0.9.0-1 tag that was not there before! Looking at the tag I saw that it was a tag in the format described in the tag2upload(5) manual page, containing the following lines:

labwc release 0.9.0-1 for experimental

[dgit distro=debian split --quilt=baredebian]
[dgit please-upload source=labwc version=0.9.0-1 upstream-tag=0.9.0 upstream=4beee3851f75b53afc2e8699c594c0cc222115bd]

and the tag was signed by me. The 4beee3851f75b53afc2e8699c594c0cc222115bd commit ID is the commit the 0.9.0 tag points to.

Now that I had a signed commit tag in the correct format, I went to the labwc packaging repository on salsa and enabled the webhook to trigger the tag2upload service (I just saw that the documentation was updated and there is now a global webhook on salsa, so this step is not needed anymore).

Finally I pushed the tags using git push --tags. I could also have used git-debpush for this step, but I’d rather use git directly. I then looked at the tag2upload queue and saw how a worker built and uploaded the newest labwc release and I also got an email from the tag2upload service [tag2upload 275] uploaded labwc 0.9.0-1. And a couple of minutes later I got the confirmation that labwc 0.9.0-1 was accepted into experimental. Great!

So, to conclude: for tag2upload to work we simply need a git tag in the correct format. The tag2upload service now gets triggered by every pushed tag on salsa but only acts on tags that adhere to the tag2upload(5) format. git-debpush is a simply bash script that creates such a tag and by default also pushes the tag.

I think the script could be a bit more verbose, for example telling me that it created a tag and the name of that tag. I think the dependency on git-deborig is also a problem. I use git-buildpackage to build my packages and by default git-buildpacakge assumes upstream tags are of the form upstream/%(version)s (source). I could now change that for all the packages I maintain, but I also think it makes sense to control the tag myself and not use a tag that is controlled by upstream. Upstream could change or delete that tag or I might need to create a tag for a version that is not tagged by upstream.

I also think git-debpush is a rather mileading command name, given that the main task of the script is to create a tag in the correct format.

Other than that, I’m pretty happy about this service. I have a rather crappy uplink at home and it is not so uncommon for my uploads to fail because the connection dropped during dput. Using a simple git based upload approach makes these problems a thing of the past. I might look into other ways to create the needed tag, though.

Debian on Framework 12

Mon, 07 Jul 2025 06:28:51 +0100

For some time now I was looking for a device to replace my Thinkpad. Its a 14" device, but thats to big for my taste. I am a big fan of small notebooks, so when frame.work announced their 12" laptop, I took the chance and ordered one right away.

I was in one of the very early batches and got my package a couple of days ago. When ordering, I chose the DIY edition, but in the end there was not that much of DIY to do: I had to plug in the storage and the memory, put the keyboard in and tighten some screws. There are very detailed instructions with a lot of photos that tell you which part to put where, which is nice.

My first impressions of the device are good - it is heavier than I anticipated, but very vell made. It is very easy to assemble and disassemble and it feels like it can take a hit.

When I started it the first time it took some minutes to boot because of the new memory module, but then it told me right away that it could not detect an operating system. As usual when I want to install a new system, I created a GRML live usb system and tried to boot from this USB device. But the Framwork BIOS did not want to let me boot GRML, telling me it is blocked by the current security policy. So I started to look in the BIOS where I could find the SecureBoot configuration, but there was no such setting anywhere. I then resorted to a Debian Live image, which was allowed to boot.

I only learned later, that the SecureBoot setting is in a separate section that is not part of the main BIOS configuration dialog. There is an “Administer Secure Boot” icon which you can choose when starting the device, but apparently only before you try to load an image that is not allowed.

I always use my personal minimal install script to install my Debian systems, so it did not make that much of a difference to use Debian Live instead of GRML. I only had to apt install debootstrap before running the script.

I updated the install script to default to trixie and to also install shim-signed and after successful installation booted into Debian 13 on the Framwork 12. Everthing seems to work fine so far. WIFI works. For sway to start I had to install firmware-intel-graphics. The touchscreen works without me having to configure anything (though I don’t have frame.work stylus, as they are not yet available), also changing the brightness of the screen worked right away. The keyboard feels very nice, likewise the touchpad, which I configured to allow tap-to-click using the tap enabled option of sway-input.

One small downside of the keyboard is that it does not have a backlight, which was a surprise. But given that this is a frame.work laptop, there are chances that a future generation of the keyboard will have backlight support.

The screen of the laptop can be turned all the way around to the back of the laptops body, so it can be used as a tablet. In this mode the keyboard gets disabled to prevent accidently pushing keys when using the device in tablet mode.

For online meetings I still prefer using headphones with cables over bluetooth once, so I’m glad that the laptop has a headphone jack on the side.

Above the screen there are a camera and a microphone, which both have separate physical switches to disable them.

I ordered a couple of expansion cards, in the current setup I use two USB-C, one HDMI and one USB-A. I also ordered a 1TB expansion card and only used this to transfer my /home, but I soon realized that the card got rather hot, so I probably won’t use it as a permanent expansion.

I can not yet say a lot about how long the battery lasts, but I will bring the laptop to DebConf 25, I guess there I’ll find out. There I might also have a chance to test if the screen is bright enough to be usable outdoors ;)

Another round of rust

Fri, 11 Aug 2023 09:52:51 +0100

A couple of weeks ago I had to undergo surgery, because one of my kidneys malfunctioned. Everything went well and I’m on my way to recovery. Luckily the most recent local heat wave was over just shortly after I got home, which made being stuck at home a little easier (not sure yet when I’ll be allowed to do sports again, I miss my climbing gym…).

At first I did not have that much energy to do computer stuff, but after a week or so I was able to sit in front of the screen for short amounts of time and I started to get into writing Rust code again.

carl

The first thing I did was updating carl. I updated all the dependencies and switched the dependency that does coloring from ansi_term, which is unmaintained, to nu-ansi-term. When I then updated the clap dependency to version 4 I realized that clap now depends on the anstyle crate for text styling - so I updated carls coloring code once again so it now uses anstyle, which led to less dependencies overall. Implementing this change I also did some refactoring of the code.

carl how also has its own website as well as a subdomain¹.

I also added a couple of new date properties to carl, namely all weekdays as well as odd and even - this means it is now possible choose a separate color for every weekday and have a rainbow calendar:

This is included in version 0.1.0 of carl, which I published on crates.io.

typelerate

Then I started writing my first game - typelerate. It is a copy of the great typespeed, without the multiplayer support.

To describe the idea behind the game, I quote the typespeed website:

Typespeed’s idea is ripped from ztspeed (a DOS game made by Zorlim). The Idea behind the game is rather easy: type words that are flying by from left to right as fast as you can. If you miss 10 or more words, game is over.

Instead of the multiplayer support, typelerate works with UTF-8 strings and it also has another game mode: in typespeed you only type whats scrolling via the screen. In typelerate I added the option to have one or more answer strings. One of those has to be typed instead of the word flying across the screen. This lets you implement kind of an question/answer game. To be backwards compatible with the existing wordfiles from typespeed², the wordfiles for the question/answer games contain comma separated values. The typelerate repository contains wordfiles with Python and Rust keywords as well as wordfiles where you are shown an Emoji and you have to type the corresponding Github shortcode. I’m happy to add additional wordfiles (there could be for example math questions…).

marsrover

Another commandline game I really like, because I am fascinated by the animated ASCII graphics, is the venerable moon-buggy. In this game you have to drive a vehicle across the moon’s surface and deal with obstacles like craters or aliens.

I reimplemented the game in rust and called it marsrover:

I published it on crates.io, you can find the repository on github. The game uses a configuration file in $XDG_CONFIG_HOME/marsrover/config.toml - you can configure the colors of the elements as well as the levels. The game comes with four levels predefined, but you can use the configuration file to override that list of levels with levels with your own properties. The level properties define the probabilities of obstacles occuring on your way on the mars surface and a points setting that defines how many points the user can get in that level (=the game switches to the next level if the user reaches the points).

[[levels]]
prob_ditch_one = 0.2
prob_ditch_two = 0.0
prob_ditch_three = 0.0
prob_alien = 0.5
points = 100

After the last level, the game generates new ones on the fly.

thanks to the service from https://cli.rs. ↩︎
actually, typelerate is not backwards compatible with the typespeed wordfiles, because those are not UTF-8 encoded ↩︎

Introducing carl

Mon, 03 Jan 2022 09:52:51 +0100

For some time now I wanted to learn Rust, but I either didn’t have the time or couldn’t come up with a nice beginner project. Given that I recently found myself to be without a job and we had another lockdown in the part of the world I happen to live in, I decided to give that idea another go (no pun intended).

There is apparently a trend to reimplement existing Unix tools in Rust (see exa, a ‘modern replacement for ls’, delta, a syntax highlighting pager for git, diff and grep output, bat, a ‘cat clone with wings’, zellij, a terminal workspace, ripgrep, a line-oriented search tool …). I looked around what else was out there, but what I wasn’t able to find was an implementation of cal(1) in Rust (maybe I wasn’t looking hard enough, feel free to point anything out to me I might have overlooked). No cal in Rust even though a calendar implementation would provide the potential to go over the top with terminal colors, which is also very important when writing reimplementations of older CLI tools! So I started writing and soon had a simple prototype of a cal reimplementation. A couple of weeks later I can now present carl, a cal implementation in Rust:

The default output of carl is what you would expect from a commandline calendar tool. It prints the days of the current month and highlights the current day. Other than the cal tools I tried, carl by default also prints days that are in the past in grey. Like cal it can also print three month if you use the -3 switch or the whole year if you use the -y switch.

Colors

You can use a theme file to change the colors carl uses for various dates. The name of the theme is set in carls configuration file (in XDG_CONFIG_HOME/.carl/config.toml or system-wide in XDG_CONFIG_DIRS/.carl/config.toml) using the theme setting - carl looks for the theme in the file ${themename}.theme in the configuration folders. A custom theme could for example look like this:

You can change the foreground color, background color and/or style of a date using a combination of various stylenames like BGRed, Bold and FGCyan. The README lists all possible stylenames. A list of date properties defines which dates the specific style should affect- date properties are for example CurrentDate, AfterCurrentDate or FirstDayOfMonth. Again, the README lists the existing date properties and I’m happy to implement more of them, if you have ideas.

Ical support

I also added the option to list .ical files in the configuration file. carl can display the dates from the ical file(s) with a separate style. There can either be a global style for all the dates from all the ical files by using the IsEvent date property or a separate style for the dates of a specific *.ical file.

Using the --agenda commandline switch carl also shows an agenda of dates from the ical files.

Installation

I have uploaded carl to crates.io, so you can install carl using cargo: cargo install carl. I also plan to upload it to Debian at some point. If you find bugs or have feature requests, please don’t hesitate to create issues.

An Analysis of 5 Million OpenPGP Keys

Fri, 23 Oct 2020 19:54:51 +0200

In July I finished my Bachelor’s Degree in IT Security at the University of Applied Sciences in St. Poelten. During the studies I did some elective courses, one of which was about Data Analysis using Python, Pandas and Jupyter Notebooks. I found it very interesting to do calculations on different data sets and to visualize them. Towards the end of the Bachelor I had to find a topic for my Bachelor Thesis and as a long time user of OpenPGP I thought it would be interesting to do an analysis of the collection of OpenPGP keys that are available on the keyservers of the SKS keyserver network.

So in June 2019 I fetched a copy of one of the key dumps of the one of the keyservers (some keyserver publish these copies of their key database so people who want to join the SKS keyserver network can do an initial import). At that time the copy of the key database contained 5,499,675 keys and was around 12GB. Using the hockeypuck keyserver software I imported the keys into an PostgreSQL database. Hockeypuck uses a table called keys to store the keys and in there the column doc stores the OpenPGP keys in JSON format (always with a data field containing the original unparsed data).

For the thesis I split the analysis in three parts, first looking at the Public Key packets, then analysing the User ID packets and finally studying the Signature Packets. To analyse the respective packets I used SQL to export the data to CSV files and then used the pandas read_csv method to create a dataframe of the values. In a couple of cases I did some parsing before converting to a DataFrame to make the analysis step faster. The parsing was done using the pgpdump python library.

Together with my advisor I decided to submit the thesis for a journal, so we revised and compressed the whole paper and the outcome was now

PUBLISHED

in the Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications (JoWUA).

I think the work gives some valuable insight in the development of the use of OpenPGP in the last 30 years. Looking at the public key packets we were able to compare the different public key algorithms and for example visualize how DSA was the most used algorithm until around 2010 when it was replaced by RSA. When looking at the less used algorithms a trend towards ECC based crytography is visible.

What we also noticed was an increase of RSA keys with algorithm ID 3 (RSA Sign-Only), which are deprecated. When we took a deeper look at those keys we realized that most of those keys used a specific User ID string in the User ID packets which allowed us to attribute those keys to two software projects both using the Bouncy Castle Java Cryptographic API (resp. the Spongy Castle version for Android). We also stumbled over a tutorial on how to create RSA keys with Bouncycastle which also describes how to create RSA keys with code that produces RSA Sign-Only keys. In one of those projects, this was then fixed.

By looking at the User ID packets we did some statistics about the most used email providers used by OpenPGP users. One domain stood out, because it is not the domain of an email provider: tellfinder.com is a domain used in around 45,000 keys. Tellfinder is a Big Data analysis software and the UID of all but two of those keys is TellFinder Page Archiver- Signing Key <support@tellfinder.com>.

We also looked at the comments used in OpenPGP User ID fields. In 2013 Daniel Kahn Gillmor published a blog post titled OpenPGP User ID Comments considered harmful in which he pointed out that most of the comments in the User ID field of OpenPGP keys are duplicating information that is already present somewhere in the User ID or the key itself. In our dataset 3,133 comments were exactly the same as the name, 3,346 were the same as the domain and 18,246 comments were similar to the local part of the email address

Last but not least we looked at the signature subpackets and the development of some of the preferences (Preferred Symmetric Algorithm, Preferred Hash Algorithm) that are being published using signature packets.

Analysing this huge dataset of cryptographic keys of the last 20 to 30 years was very interesting and I learned a lot about the history of PGP resp. OpenPGP and the evolution of cryptography overall. I think it would be interesting to look at even more properties of OpenPGP keys and I also think it would be valuable for the OpenPGP ecosystem if these kinds analysis could be done regularly. An approach like Tor Metrics could lead to interesting findings and could also help to back decisions regarding future developments of the OpenPGP standard.

Fosdem 2020

Tue, 04 Feb 2020 22:02:51 +0100

Today I returned from Brussels, where I attended FOSDEM. It was my first time in Brussels and it was my first FOSDEM.

The days before FOSDEM, from Wednesday to Friday, there was a MiniDebCamp in the local Hackerspace. The Hackerspace is located at Studio CityGate, a collective space which was apparently an old factory for textile and medical equipment and can now be used by cultural projects (though I think its only temporary). There is a Bar at the ground floor, a recording studio in the basement, a skate park and a climbing wall and much more. The building and the yard reminded me a bit of the collective art space Fux, where the Hamburg MiniDebConfs 2018 and 2019 were located.

I only visited DebCamp on Friday and did a bit of work on the debian timeline (researched dates/events to be added) and on sway related packages.

The two days of FOSDEM were very interesting, although draining. There were talks and discussions all the time in multiple rooms of every size. On Saturday I found the policy debates in the Legal and Policy Issues devroom to be very interesting and entertaining. The culture of debate competition is something I didn’t know at all before (besides from movies) and it was a fascinating experience to see people so eloquently defend views they actually don’t really hold. There were also some points raised about ethical licensed that gave me a lot to think about.

On Sunday I started the day by watching a short introduction to hard disk encryption in Linux suspend mode with cryptsetup-suspend which I’m looking forward to try out (though I’ll need support for suspend to RAM on the Pinebook first). Later that day I watched a couple of talks in the Community devroom. There was a great talk about Building Ethical Software Under Capitalism by Deb Nicholson from Software Freedom Conservancy and Megan Sanicki from Google gave a talk about Leadership in Open Source (“Every contributor is a leader”). The last talk of the day I watched was Who will Decentralise the Fediverse? about Mastodon et al and the challenges of decentralization in federated networks.

I actually planned to do some tests of the Pinebook Pro during FOSDEM, but in the end I only opened the notebook once a day for a short time. I even forgot to stop by at the Pine64 stand.

All in all, it were interesting days. Apart from the talks I met some new people, some old friends and had inspiring discussions. What I’ll definitely skip next time is the Beer Event, that’s not my kind of evening activity but I’ll plan to spend more time at the DebCamp (if it happens again).

Installing Debian on the Pinebook Pro

Sun, 26 Jan 2020 18:30:51 +0100

@brion on mastodon:

If you want the Linux-circa-2004 experience back, just try Linux on ARM!

everything compiles slowly

distro-hopping to find better hardware support

oops, you need proprietary drivers for that

forum posts hold the authoritative documentation and code for your distro

:D

In November last year, I ordered a Pinebook Pro from Pine64. The Pinebook Pro is a 14" (1080p) ARM laptop based on a RK3399 SOC. It has an eMMC built in and it is possible to add an NVMe SSD drive using an adapter. In addition it also has a micro SD card reader and can boot from that. The notebook is very lightweight and the case seems solid. The bottom cover is attached using normal Philips head screws and there is a lot of detailed documentation in the wiki about the parts of the board and how to access the internals.

I’m not really a fan of the keyboard, because in my opinion it feels a bit cheap - pressing the keys does not feel as smooth as I’m used to from other keyboards, like from the Thinkpad x230 or the 2012 MacBook Air. In addition to that I made the mistake of choosing an ANSI keyboard, which makes it harder for me to reach the Enter key. The big advantage of the device is definitely the battery. In the first week of playing around with the device (not using it that much, but doing a lot of tests with booting different images) I didn’t even unpack the power supply. Another nice feature are the privacy switches - when you press F1, F2 or F3 for 10 seconds you cut the power for the BT/WiFI module (F1), the webcam (F2) or the microphone (F3). At least that’s the theory, it does not work with my Pinebook, but there is a firmware update for the keyboard that I did not yet install, which might fix that.

I also really like how the Pinebook Pro creators keep you up to date with news regarding their products and related software. They publish monthly updates about updates in their blog, they also try to take part in the discussions in the pine64 forum and they have a presence on the fediverse (there are more communication channels, but those are the ones I follow/used).

There are a couple of different pre built operating system images one can dd to SD cards or the eMMC and there are also some scripts to install (instead of dding) systems. The laptop comes preinstalled with what is usually (in the forums and the wiki) called Debian Desktop. It is a Debian based image with a Mate Desktop and a lot of modifications. The images for this system are distributed via a github repository. I did not find any source code for the images nor documentation about the changes from upstream Debian, so I have no idea how they are built (the archives behind the Source code links on the release page of the images only contain the README.md file). I only started the preinstalled system once or twice, but it seemed to work very well (suspend worked) and it ships a lot of useful software for end users. But I did not take a deeper look at this image. There are also two Ubuntu based images listed in the Pine64 wiki, one of which comes with LXDE as desktop system, the other one with the Mate Desktop. They are also distributed via github release pages, but in these cases the repository also contains the code of the build scripts. Manjaro, an Arch Linux based distribution, also provides images for the Pinebook Pro. Besides those there are Armbian images, Android images, Chromium images and some more.

I did not really want to use any of the provided images, but rather install my own Debian system. There is an installer script which installs Debian on a SD card or the eMMC using debootstrap. This script does a lot of useful stuff, and a good part of my approach of installing Debian is based on it.

I installed Debian on an SD card using my older HP laptop. There are two main parts one needs that are not part of Debian yet, a heavily patched kernel on the one hand and the u-boot bootloader, also with some patches. There is a great tutorial on how to build an (almost) upstream u-boot for the Pinebook. This is based on this git repository which contains the u-boot upstream sources modified to work on the Pinebook and with some changes to the boot order. The main path is this one which was posted to the u-boot mailinglist in November, but I’m not sure whats the status of it. Lets hope it will be merged upstream for the next release of u-boot.

For the kernel there is a repository in the manjaor gitlab and the maintainer of this kernel repository announced that they plan on mainlining the patches. The only thing not working yet is suspend to RAM. I’m currently using the v5.5-rc7-panfrost-fixes branch of the kernel.

To crossbuild the kernel, I had to first prepare my build machine (which is AMD64):

apt install crossbuild-essential-arm64 flex bison fakeroot build-essential bc libssl-dev

then I cloned the repository and copied the configuration the Manjaro kernel is using from their kernel package repository. I also had to disable compression of kernel modules.

git clone https://gitlab.manjaro.org/tsys/linux-pinebook-pro
cd linux-pinebook-pro
wget https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinebookpro/raw/master/config -O .config
scripts/config --set-str LOCALVERSION -custom
scripts/config --disable MODULE_COMPRESS
make -j`nproc` ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- KBUILD_IMAGE=arch/arm64/boot/Image deb-pkg

The developer who maintains the kernel also published a repository with firmware for the Broadcom Wifi module and the DisplayPort. Another manjaro repository contains the firmware for the bluetooth chip.

Next step was to bootstrap Debian. First I installed the packages to bootstrap a system with another architecture and then I prepared the SD card:

apt install qemu-user-static binfmt-support
sfdisk /dev/sdc < gpt.sfdisk
mkfs.ext4 /dev/sdc1
cryptsetup luksFormat /dev/sdc2
cryptsetup luksOpen /dev/sdc2 sdc2_crypt
mkfs.ext4 /dev/mapper/sdc2_crypt

With gpt.sfdisk containing the following partition layout:

label: gpt
unit: sectors

/dev/sdc1 : start=      442368, size=     1024000, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="Boot"
/dev/sdc2 : start=     1466368,                    type=0FC63DAF-8483-4772-8E79-3D69D8477DE4

Then I created a temporary folder, mounted the partitions and used qemu-debootstrap to install the base system:

CHROOT=`mktemp -d`
mount /dev/sdc2_crypt $CHROOT
mkdir $CHROOT/boot
mount /dev/sdc1 $CHROOT/boot

sudo qemu-debootstrap --arch=arm64 --include=u-boot-menu,initramfs-tools,sudo,network-manager,cryptsetup,cryptsetup-initramfs bullseye $CHROOT

Then I copied the kernel package I built on the SD card and installed it in the chroot. Part of the linux image is also a *.dtb file for the RK3399, which I had to copy to /boot (because u-boot needs this file and the /-filesystem is encrypted).

mount -o bind /dev $CHROOT/dev
mount -o bind /sys $CHROOT/sys
mount -t proc /proc $CHROOT/proc
chroot $CHROOT
dpkg -i linux-image-5.5.0-rc7-custom+_5.5.0-rc7-custom+-1_arm64.deb
cp /usr/lib/linux-image-5.5.0-rc7-custom+/rockchip/rk3399-pinebook-pro.dtb /boot/

echo UUID=$(blkid -s UUID -o value /dev/mapper/sdc2_crypt) / ext4 defaults 0 1 >> /etc/fstab
echo sdc2_crypt PARTUUID=$(blkid -s PARTUUID -o value /dev/sdc2 ) none luks,discard,initramfs >> /etc/crypttab
echo UUID=$(blkid -s UUID -o value /dev/sdc1) /boot ext4 defaults 0 1 >> /etc/fstab

Finally I pointed the u-boot-update script to the *.dtb file and added my user account:

# in /etc/defaults/u-boot
U_BOOT_FDT="rk3399-pinebook-pro.dtb"
U_BOOT_PARAMETERS="console=tty1"

adduser bisco
adduser bisco sudo

In the running system I then also enabled s2idle, because suspend to RAM does not work yet.

I haven’t had time to do any more tests on this device, but I hope I’ll get to that in February. If I manage to set up the system to a usable state, I’ll bring it to FOSDEM, which will be its first outside test…

On the software side most stuff until now works fine. The main downside is the missing TorBrowser package, but this is tracked upstream. Alacritty does not work and won’t in the near future, it seems. When I tried to use tilix, that led to #949952, so I’m using rxvt-unicode for now…

There is now also a wiki page for the Debian installer script which lists some issues and tips how to fix them.

Converting ikiwiki to hugo

Wed, 20 Nov 2019 18:30:51 +0100

Sometimes I play around with Tails and on rare occasions I also build a Tails image myself. One thing that makes the build of Tails a bit tedious is that it a also builds the Tails Website, which contains the whole documentation (which is really cool, because that way users have the most up to date documentation on their desktop!). The problem is, that the website takes a looooong time to build- on my Laptop (i7-5600U) it takes around 11 minutes.

I was curious if it was possible to convert the whole website, which is based on ikiwiki, to the hugo static site generator which is known to be pretty fast ("with its amazing speed and flexibility, Hugo makes building websites fun again" as the hugo website puts it ;)). I did some research if there was some tooling to do so- the Hugo website lists some migration tools but nothing for ikiwiki, but I stumbled upon anarcat’s conversion notes which has a lot of information and also links to the write up jak did on his conversion. Anarcat also published a python script to convert ikiwiki to hugo which I tried, but there were some important parts missing. As it happened I also had to prepare for an exam at that time and I am a bit of a procrastinator, so I started adapting the script for the Tails wiki and then rewrote some parts and now its just another ikiwiki2hugo script:

What does it do?

For every ikiwiki *.mdwn or *.html file, it creates a Markdown file with hugo frontmatter. The information for the hugo frontmatter comes from parsing the [[!meta directives in the files.

If there is a *.po file with the same name, the script creates a *.XX.md file with the strings translated.

Then the content is converted:

The content of the Markdown files is a copy of the content of the ikiwiki files with the ikiwiki directives replaced by hugo shortcodes. There are a lot of directives out there and I only implemented replacements for some of them. My test ikiwiki instance was the the Tails ikiwiki source, so I mostly implemented directives used there. Merge requests or patches for additional directives are welcome- to add a replacement for a directive, look in the directives folder, all the replacement python modules inherit from the Directive class. The shortcode files are assets/shortcodes folder.

What does it not do?

Probably the more important question ;)

There are a lot of directives whose replacements are not implemented. Most important probably the [[!inline directive with multiple (and negative) arguments and the [[!map directive.

Also, Hugo is more strict regarding Markdown syntax. It does not convert markdown syntax that is embedded in <div>...</div> and other block-level elements.

The result

Disclaimer: This comparison only looks at the build time- there is a lot of functionality of ikiwiki that hugo does not provide, for example the possibility to edit websites through the browser, which is used for the Tails blueprints. Another feature are the traillink directives which i simple replaced by normal markdown links.

Anarcat also provides a nice oneliner to check which directives are used in the ikiwiki repository:

grep -h -r '\[\[!' * | sed 's/\[\[!/\n[[!/g' | grep '\[\[!' | sed 's/ .*//' | sort | uniq -c | sort -n

Before running the script (I’ve removed listings of directives that occure less than 100 times):

    ...
    ...
    122 [[!wikipedia\n"
    124 [[!debsa2012
    130 [[!debsa2018
    134 [[!tails_roadmap
    152 [[!debsa2014
    188 [[!debsa2015
    204 [[!debsa2017
    219 [[!tails_gitweb_branch
    222 [[!debsa2016
    247 [[!tails_website
    283 [[!mfsa
    604 [[!cve
    655 [[!toggleable
    696 [[!tails_roadmap]]
    775 [[!"
    806 [[!tails_gitweb
   1143 [[!toggle
   1203 [[!wikipedia
   1704 [[!traillink
   2411 [[!pagetemplate
   2434 [[!toc
   2572 [[!tag
   5627 [[!inline
   5747 [[!tails_ticket
   8673 [[!img
  13577 [[!meta

After the conversion :

      1 [[!immagine
      1 [[!parent]]`.
      1 [[!tails_gitweb
      1 [[!tails_ticket
     30 [[!map
     66 [[!inline

(I think the immagine is a typo in a translation; I also found a couple of other typos which are fixed now; the tails_ticket directive is a code-quote from the release process document and the tails_gitweb is the one occurence of this directive which lists the description before the path ;))

Hugo takes nearly two seconds to build the website:

                   | DE  |  EN  | ES  | FA  | FR  | IT  | PT
+------------------+-----+------+-----+-----+-----+-----+-----+
  Pages            | 286 | 1023 | 286 | 286 | 286 | 286 | 286
  Paginator pages  |   0 |    0 |   0 |   0 |   0 |   0 |   0
  Non-page files   |   9 |  400 |   9 |   9 |  14 |   9 |   9
  Static files     |   0 |    0 |   0 |   0 |   0 |   0 |   0
  Processed images |   0 |    0 |   0 |   0 |   0 |   0 |   0
  Aliases          |   1 |    0 |   0 |   0 |   0 |   0 |   0
  Sitemaps         |   2 |    1 |   1 |   1 |   1 |   1 |   1
  Cleaned          |   0 |    0 |   0 |   0 |   0 |   0 |   0

Total in 1711 ms

Finally, a screeshot of the Tails website built with hugo- it looks pretty broken. Most of the syntax that does not work is because its embedded in HTML tags. Apparently hugo thinks about switching to another markdown renderer, so that could make a conversion from systems with a lot of mixed HTML/Markdown code easier.

Installing and running Signal on Tails

Thu, 03 Oct 2019 09:52:51 +0100

❗ This article is very outdated. You should look for more recent instructions. ❗

Because the topic comes up every now and then, I thought I’d write down how to install and run Signal on Tails. These instructions are based on the 2nd Beta of Tails 4.0 - the 4.0 release is scheduled for October 22nd. I’m not sure if these steps also work on Tails 3.x, I seem to remember having some problems with installing flatpaks on Debian Stretch.

The first thing to do is to enable the Additional Software feature of Tails persistence (the Personal Data feature is also required, but that one is enabled by default when configuring persistence). Don’t forget to reboot afterwards. When logging in after the reboot, please set an Administration Password.

The approach I use to run Signal on Tails is using flatpak, so install flatpak either via Synaptic or via commandline:

sudo apt install flatpak

Tails then asks if you want to add flatpak to your additional software and I recommend doing so. The list of additional software can be checked via Applications → System Tools → Additional Software. The next thing you need to do is set up the directories- flatpak installs the software packages either system-wide in $prefix/var/lib/flatpak/[¹] or per user in $HOME/.local/share/flatpak/ (the latter lets you manage your flatpaks without having to use elevated permissions). User specific data of the apps goes into $HOME/.var/app. This means we have to create directories on our Peristent folder for those two locations and then link them to their targets in /home/amnesia.

I recommend putting these commands into a script (i.e. /home/amnesia/Persistent/flatpak-setup.sh) and making it executable (chmod +x /home/amnesia/Persistent/flatpak-setup.sh):

Update (2022/07): added fixes reported by reader

#!/bin/sh

mkdir -p /home/amnesia/Persistent/flatpak
mkdir -p /home/amnesia/.local/share

if ! file /home/amnesia/.local/share/flatpak | grep -q 'symbolic link'; then
        rm -rf --one-file-system /home/amnesia/.local/share/flatpak
        ln -s /home/amnesia/Persistent/flatpak /home/amnesia/.local/share/flatpak
fi

mkdir -p /home/amnesia/Persistent/app
mkdir -p /home/amnesia/.var
ln -s /home/amnesia/Persistent/app /home/amnesia/.var/app

Now you need to add a flatpak remote and install signal:

amnesia@amnesia:~$ torify flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
amnesia@amnesia:~$ torify flatpak install flathub org.signal.Signal

This will take a couple of minutes.

To show Signal the way ~~to the next whiskey bar~~ through Tor the HTTP_PROXY and HTTPS_PROXY environment variables have to be set. I recommend again to put this into a script (i.e. /home/amnesia/Persistent/signal.sh)

#!/bin/sh

export HTTP_PROXY=socks://127.0.0.1:9050
export HTTPS_PROXY=socks://127.0.0.1:9050
flatpak run org.signal.Signal

Yay it works!

To update signal you have to run

amnesia@amnesia:~$ torify flatpak update

To make the whole thing a bit more comfortably, the folder softlinks can be automatically created on login using a Gnome autostart script. For that to work you have to have the Dotfiles feature of Tails enabled. Then you can create a /live/persistence/TailsData_unlocked/dotfiles/.config/autostart/FlatpakSetup.desktop file:

[Desktop Entry]
Name=FlatpakSetup
GenericName=Setup Flatpak on Tails
Comment=This script runs the flatpak-setup.sh script on start of the user session
Exec=/live/persistence/TailsData_unlocked/Persistent/flatpak-setup.sh
Terminal=false
Type=Application

By adding /live/persistence/TailsData_unlocked/dotfiles/.local/share/applications/Signal.desktop file to the dotfiles folder, Signal also shows as part of the Gnome applications with a nice Signal icon:

[Desktop Entry]
Name=Signal
GenericName=Signal Desktop Messenger
Exec=/home/amnesia/Persistent/signal.sh
Terminal=false
Type=Application
Icon=/home/amnesia/.local/share/flatpak/app/org.signal.Signal/current/active/files/share/icons/hicolor/128x128/apps/org.signal.Signal.png

It is also possible to configure additional system wide installation locations, details are documented in flatpak-installation(5) ↩︎

Installing Debian with encrypted boot using GRML

Thu, 21 Mar 2019 19:28:51 +0100

A couple of days ago an interesting step-by-step guide on how to install Debian with full disk encryption, including /boot, using debian-installer was posted on the debian-boot mailinglist. This reminded me of the steps I used and wrote down a couple of month ago to create a similar setup. These steps describe a full disk (including /boot) encrypted setup on a non coreboot enabled system using the great [grml live distro] (http://grml.org/). (And just to be sure I just redid the same setup on a test device with the newest grml release Gnackwatschn):

The first step was to set up the network using grml-network after which I started by preparing the disk. I wiped the disks old partition table using sgdisk(8) and then created a 512MB EFI System partition and used the rest of the disk for a Linux partition:

sgdisk --zap-all /dev/sda
sgdisk -n1:1M:+512M -t1:EF00 /dev/sda
sgdisk -n2:0:0 -t2:8300 /dev/sda

Then I initialized the LUKS partition, set a passphrase and opened the LUKS device:

cryptsetup luksFormat /dev/sda2
cryptsetup luksOpen /dev/sda2 sda2_crypt

The LUKS device is then used to create a LVM volume group which in this example is called vg-2560p. In that volume group I created a logical volume for the /root filesystem:

pvcreate /dev/ampper/sda2_crypt
vgcreate vg-2560p /dev/mapper/sda2_crypt
lvcreate -L 120G vg-2560p -n root

The next step was to create an ext4 filesystem on the /root volume and a msdos filesystem with a 32bit file allocation table and the label EFI on the EFI System partition:

mkfs.ext4 /dev/vg-2560p/root
mkdosfs -F 32 -n EFI /dev/sda1

I then mounted the root partition, debootstrapped buster onto the partition, mounted the EFI partition and remounted /dev, /proc, /sys and /run into the new system:

mount /dev/vg-2560p/root /mnt
debootstrap buster /mnt http://deb.debian.org/debian
mkdir /mnt/boot/efi
mount /dev/sda1 /mnt/boot/efi
mount --rbind /dev /mnt/dev/
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /run /mnt/run

After that I used chroot(8) to change into the buster installation and do some initial configuration. I first told apt(8) not to install recommended packages and then installed a kernel, grub, cryptsetup, lvm2 and sudo:

chroot /mnt /bin/bash
echo "Apt::Install-Recommends 0;" >> /etc/apt/apt.conf.d/local-recommends
apt install linux-image-amd64 cryptsetup lvm2 grub-efi-amd64 sudo

On the new system, the /etc/fstab file is empty and so I added the filesystems and I also added information about the encrypted disk to the /etc/crypttab file:

echo PARTUUID=$(blkid -s PARTUUID -o value /dev/sda1) /boot/efi vfat nofail,x-systemd.device-timeout=1 0 1 >> /etc/fstab
echo UUID=$(blkid -s UUID -o value /dev/mapper/vg--2560p-root) / ext4 defaults 0 1 >> /etc/fstab
echo sda2_crypt PARTUUID=$(blkid -s PARTUUID -o value /dev/sda2) none luks,discard,initramfs >> /etc/crypttab

I also had to tell grub to enable device decryption:

echo "GRUB_ENABLE_CRYPTODISK=y" >> /etc/default/grub
update-initramfs -c -k all
update-grub
grub-install --target=x86_64-efi

The final step, which I forget nearly every time when i install a system using debootstrap(8), was to ad a user account:

adduser bisco
adduser bisco sudo

PS: On the laptop I installed a couple of month ago, I had to set the path to the EFI Grub file (\EFI\debian\grubx64.efi) in bios. On the laptop i used to reproduce the above steps, i didn’t find that setting in bios (its from 2011, maybe a bios update would have helped), but I was able to choose the file during boot.

30minutes Django introduction

Sat, 02 Mar 2019 17:52:51 +0100

Yesterday i had to give a short, 30 minutes, introduction to Django and show how to create a small webapplication using Django. These are the my notes to this workshop:

Introduction

Django is a webframework written in Python. It was started in 2003 and in 2005 it was released under the BSD License. In 2008 the Django software foundation took over development of Django. End of 2017 the version 2.0 of Django was released, which was the first Python 3 only release. About every two years there is a LTS release which is supported for at least three years. Famous websites using Django are the website of the Washington Post or the website of the NASA.

Django follows the Model View Controller (MVC) pattern, though in the case of Django it is often described as Model View Template pattern, given that Django doesn’t adhere the MVC pattern completely.

The advantage of a webframework following the MVC pattern is, that the work with data, the presentation of data and the processing of data has only to be dealt with on an abstract layer. This means, one doesn’t have to directly work with database connections, it is not necessary to write SQL statements and also Webforms are handled by Django.

A Django project is started by the command django-admin startproject projectname. This command creates a folder containgin a Python module and a management Python script.

user@calculator:~ tree
.
├── manage.py
└── projectname
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

1 directory, 5 files

The management script can be used to handle various configuration tasks, like generating the database structure, creating an admin account or starting the built-in development webserver.

The Python module contains a configuration file which contains settings like the chosen database backend (sqlite by default) and it lets you deactivate the DEBUG mode. The DEBUG mode should be deactivated before moving a Django project to production, because with the activated DEBUG mode, error messages also contain a lot of debugging information about the system. If the DEBUG mode is deactivated, the error messages are replaced with a 404 page.

Another important file is the urls.py file. It maps paths in the URI to functionality in the Django project. The last file is the wsgi.py file, WSGI is the Web Server Gateway Interface and it is a standard for webservers passing requests to Python scripts.

Bookmanagement Example

To give a small example what a Django web application could look like, i’ve created a book management applications. It stores books in a database and lets you add, view, modify, list and delete book entries. This example was written with Django 2.1. If you want to try it, you’ll have to 1) install Django, 2) run ./manage.py migrate to create the db.sqlite file and populate it with the database structure and 3) run ./manage.py runserver to start the development webserver. You can then access the webapp on http://localhost:8000

First we have to add an app to our Django project. This app is a simple Python module and it can be created with the command ./manage.py startapp bookmanagent (where bookmanagement is the name of our app). To make this app known to the Django project, we also have to add the app name to the list of INSTALLED_APPS in the settings.py file.

The first thing to create is a model. Every task in this web application works on book entries, so we first have to create a model Book. A model is like an object in object oriented programming and in Django it is a Python class. We define a model in the file bookmanagement/models.py:

class Book(models.Model):
    title = models.CharField(max_length=255)
    author = models.CharField(max_length=255)
    year = models.PositiveSmallIntegerField()

This is a definition of the model Book with the attributes title, author and year. title and author are character fields, the year attribute is an integer field. Django contains around 25 different field types, i.e. for dates, email addresses or text input. After defining a model, we have to run ./manage.py makemigrations bookmanagement and ./manage.py migrate to create the needed tables in the database for our model.

To work with our model, the next step is to create views to add, modify, delete, display and list books. Views are Djangos method to process web requests. Views go in the bookmanagement/views.py file. Django comes with a lot of generic views and we can write Python classes that inherit from those generic views to implement all the methods we need for the bookmanagement application:

class BookList(ListView):
    model = Book

class BookCreate(CreateView):
    model = Book
    fields = ['title', 'author', 'year']
    success_url = '/books'

class BookDetail(DetailView):
    model = Book

class BookUpdate(UpdateView):
    model = Book
    fields = ['title', 'author', 'year']
    success_url = '/books'

class BookDelete(DeleteView):
    model = Book
    success_url = '/books'

As mentioned before, we use the urls.py file to map the paths in the URI to the functionality of the Django project:

path('createbook/', views.BookCreate.as_view(), name='createbook'),
path('book/<int:pk>', views.BookDetail.as_view(), name='bookdetail'),
path('books/', views.BookList.as_view()),
path('deletebook/<int:pk>', views.BookDelete.as_view(), name='deletebook'),
path('updatebook/<int:pk>', views.BookUpdate.as_view(), name='updatebook'),

Now we have the paths, the views to operate on data and the model that describes the data structure. The only additional piece of the puzzle are templates. Templates are files that define how a view returns data to a webbrowser. In our case they contain HTML and some template specific statements. In most of my Django projects i use a generic body.html file that defines the overall structure of the web pages (like including a style sheet or defining a navigation bar) and all the view-specific templates then inherit the content of this file (boomanagement/templates/body.html):

<html>
<head>
  <meta charset="utf-8">
  <title>Bookmanagement</title>
  <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
</head>
<body class="bg-light">
    <nav class="navbar navbar-dark navbar-expand-md bg-dark mb-4">
        <a class="navbar-brand" href="/books">Bookmanagement</a>
        <ul class="navbar-nav mr-auto">
            <li class="nav-item"><a class="nav-link" href="{% url 'createbook' %}">Add Book</a></li>
        </ul>
    </nav>
    <div class="container">
        <div class="jumbotron mt-5">
{% block content %}
{% endblock %}
        </div>
    </div>
</body>
</html>

The template for the listview (bookmanagement/templates/bookmanagement/book_list.html) then only has to extend this template. The list view passes a list of objects to the template and in the template we can just iterate through this list and create links for the details of a book, a link for modifying a book and a link for deleting a book.

{% extends 'body.html' %}

{% block content %}
<ul>
{% for object in object_list %}
<li>
    <a href={% url 'bookdetail' object.pk %}>{{ object.title }}</a>, {{ object.year }}, <a href="{% url 'deletebook' object.id %}">Delete</a>, <a href="{% url 'updatebook' object.id %}">Update</a>
</li>
{% endfor %}
</ul>
{% endblock %}

The template file for the input form (bookmanagement/templates/bookmanagement/book_form.html), too, extends the body.html template and then simply shows the form that is passed from the create or update view:

{% extends 'body.html' %}

{% block content %}
<form method="post">{% csrf_token %}
        {{ form.as_p }}
            <input type="submit" value="Save">
</form>
{% endblock %}

The important thing with form templates is the statement {% csrf_token %} which includes a token to protect against Cross Site Request Forgery.

This is all to have a working bookmanagement web application. There is one other feature of Django, that makes it especially helpful for internal use, that is the admin interface. Django comes with an admin interface that you can access on http://localhost:8000/admin. This can also be used to manage model objects. If you add

from .models import Book
admin.site.register(Book)

to the file bookmanagement/admin.py you can manage all your book entries in a login protected area without having to create views or templates. This can be useful for very basic internal web applications.

SimpleView

One more thing about views: As mentioned above, views process web requests. In the views for the bookmanagement application, we didn’t have to touch any of the functions of these classes, but if we want, we can override the request processing. In the following snipplet, i’ve implemented methods for GET, POST and DELETE requests. Django provides us the HttpResonse object to respond to a request. As you can see in the get() method, we can simply pass a string and also give the desired status code as an argument. The post() method also simply returns a string- but to test this method, i had to remove the csrf protection from this view. This is done in the dispatch() method using a method_decorator. Last but not least there is the delete() method, which returns a JsonResponse to show that Django can also be used to implement APIs. In addition, this method also sets a header field X-Clacks-Overhead:

class SimpleView(View):

    @method_decorator(csrf_exempt)
    def dispatch(self, request):
        return super().dispatch(request)

    def get(self, request):
        return HttpResponse("I'm a teapot!", status=418)

    def post(self, request):
        return HttpResponse("Going postal!")

    def delete(self, request):
        response = JsonResponse({'deleted':'foobar', 'useragent': request.META['HTTP_USER_AGENT']})
        response['X-Clacks-Overhead'] = "GNU Terry Pratchett"
        return response

If we test the views get() method using httpie:

user@calculator:~ http http://localhost:8000/simpleview/
HTTP/1.1 418 Unknown Status Code
Content-Length: 13
Content-Type: text/html; charset=utf-8
Date: Sat, 02 Mar 2019 16:41:47 GMT
Server: WSGIServer/0.2 CPython/3.7.2+
X-Frame-Options: SAMEORIGIN

I'm a teapot!

The post() method:

user@calculator:~ http POST http://localhost:8000/simpleview/
HTTP/1.1 200 OK
Content-Length: 13
Content-Type: text/html; charset=utf-8
Date: Sat, 02 Mar 2019 16:42:50 GMT
Server: WSGIServer/0.2 CPython/3.7.2+
X-Frame-Options: SAMEORIGIN

Going postal!

… and the delete() method:

user@calculator:~ http DELETE http://localhost:8000/simpleview/
HTTP/1.1 200 OK
Content-Length: 50
Content-Type: application/json
Date: Sat, 02 Mar 2019 16:44:01 GMT
Server: WSGIServer/0.2 CPython/3.7.2+
X-Clacks-Overhead: GNU Terry Pratchett
X-Frame-Options: SAMEORIGIN

{
    "deleted": "foobar",
    "useragent": "HTTPie/0.9.8"
}

You can find the code of the bookmanagement webapplication in my 30mindjango git repository on gitlab.

Sway in experimental

Sun, 17 Feb 2019 20:52:51 +0100

A couple of days ago the 1.0-RC2 version of Sway, a Wayland compositor, landed in Debian experimental. Sway is a drop in replacement for the i3 tiling window manager for wayland. Drop in replacement means that, apart from minor adaptions, you can reuse your existing i3 configuration file for Sway. On the Website of sway you can find a short introduction video that shows the most basic concepts of using Sway, though if you have worked with i3 you will feel at home soon.

In the video the utility swaygrab is mentioned, but this tool is not part of Sway anymore. There is another screenshot tool now though, called grim which you can combine with the tool slurp if you want to select regions for screenshots. The video also mentions swaylock, which is a screen locking utility similar to i3lock. It was split out of the main Sway release a couple of weeks ago but there also exists a Debian package by now. And there is a package for swayidle, which is a idle management daemon, which comes handy for locking the screen or for turning of your display after a timeout. If you need clipboard manager, you can use wl-clipboard. There is also a notification daemon called mako (the Debian package is called mako-notifier and is in NEW) and if you don’t like the default swaybar, you can have a look at waybar (not yet in Debian, see this RFS). If you want to get in touch with other Sway users there is a #sway IRC channel on freenode. For some tricks setting up Sway you can browse the wiki.

If you want to try Sway, beware that is is a release candiate and there are still bugs. I’m using Sway since a couple of month and though i had crashes when it still was the 1.0-beta.1 i hadn’t any since beta.2. But i’m using a pretty conservative setup.

Sway was started by Drew DeVault who is also the upstream maintainer of wlroots, the Wayland compositor library Sway is using and who some might now from his sourcehut project (LWN Article). He also just published an article about Wayland misconceptions. The upstream of grim, slurp and mako is Simon Ser, who also contributes to sway. A lot of thanks for the Debian packaging is due to nicoo who did most of the heavy lifting and to Sean for having patience when reviewing my contributions. Also thanks to Guido for maintaining wlroots!

New OpenPGP Key

Sat, 11 Aug 2018 17:28:51 +0100

After 5 years i thought it would be time for a new OpenPGP key. Also i wanted to migrate to an offline master key and subkeys that are stored on an OpenPGP smartcard.

My old key will continue to be valid for some time, but i prefer all future correspondence to come to the new one. I would also like this new key to be integrated into the web of trust. There is also a plaintext version of this message that is signed by both keys to certify the transition.

the old key was:

pub   rsa4096 2013-11-20 [SC] [expires: 2018-09-27]
      CBF53E306528F800E3AA4EAF32C61D34C09C6A34

And the new key is:

pub   rsa4096 2018-08-11 [C] [expires: 2020-08-10]
      C5BC7498F466D885188CB397CB06EA7B78DBE151

To fetch my new key from a public key server, you can simply do:

gpg --recv-key C5BC7498F466D885188CB397CB06EA7B78DBE151

If you already know my old key, you can now verify that the new key is signed by the old one:

gpg --check-sigs C5BC7498F466D885188CB397CB06EA7B78DBE151

If you are satisfied that you’ve got the right key, and the UIDs match what you expect, I’d appreciate it if you would sign my key:

gpg --sign-key C5BC7498F466D885188CB397CB06EA7B78DBE151

Lastly, if you could send me these signatures, i would appreciate it.

Please let me know if there is any trouble, and sorry for the inconvenience.

Final GSOC 2018 Report

Wed, 08 Aug 2018 14:30:43 +0100

This is the final report of my 2018 Google Summer of Code project. It also serves as my final code submission.

Short overview:

Nacho, a web frontend for registering and managing LDAP accounts: https://salsa.debian.org/bisco-guest/nacho
Evaluation of existing SSO solutions https://salsa.debian.org/bisco-guest/sso-evals/
Add oauth2 authentication to existing Debian service https://salsa.debian.org/bisco-guest/nm.debian.org/tree/ssoauth2

Description

The main project was nacho, the web frontend for the guest accounts of the Debian project. The software is now in a state where it can be used in a production enviroment and there is already work being done to deploy the application on Debian infrastructure. It was a lot of fun programming that software and i learned a lot about Python and Django. My mentors gave me valuable feedback and pointed me in the right direction in case i had questions. There are still some ideas or features that can be implemented and i’m sure some feature requests will come up in the future. Those can be tracked in the issue tracker in the salsa repository. An overview of the activity in the project, including both commits and issues, can be seen in the activity list.

The SSO evaluations i did give an overview of existing solutions and will help in the decision making process. The README in the evaluation repository has a table taht summarizes the findings of the evaluations.

The branch of nm.debian.org that implements oauth2 authentication against an oauth2 provider provides a proof of concept of how the authentication can be implemented and it can be used to integrate the functionality into other services.

I’ve learned a lot in the last few month and it was a pleasure to work with babelouest and formorer. Debian is an interesting project and i plan to keep on contributing or maybe even intensify the contributions. Maybe i can use the the oauth2 authentication on nm.debian.org for my own application soon ;)

Reports

The list of reports in chronological order from top to bottom:

Sixth GSoC Report

Fri, 27 Jul 2018 06:28:51 +0100

After finishing the the evaluations of the SSO solutions, formorer asked me to look into integrating one of the solutions into the existing Debian SSO infrastructure. Sso.debian.org is a Django application that basically provides a way of creating and managing client certificates. It does not do authentication itself, but uses the REMOTE_USER authentication source of Django. I tested integration with lemonldap-ng, and after some troubles setting up the sso.debian.org clone on my infrastructure (thanks to Enrico for pointing me in the right direction) the authentication using the apaches authnz module worked. To integrate lemonldap-ng i only had to add a ProxyPass and a ProxyPassReverse directive in the apache config. I tested the setup using gitlab and it worked.

I’ve also added some additional features to nacho: on the one hand, i’ve added a management command that removes stale temporary accounts that have never been activated. The idea is to run that command in regular intervals via cron (or systemd timers). To implement that feature, i basically followed the howto for writing custom django-admin commands from the django manual. Based on that knowledge i then implemented two other commands that provide backup and restore functionality. The backup command prints the contents of the LDAP database on stdout in LDIF format. The restore command expects LDIF on stdin and writes those values to the ldap database. I also did some cleanup in the codebase and documented the test cases.

The third big project i looked into was to implement oauth2 authentication for one of the existing websites that use sso.debian.org. I chose nm.debian.org for that, because it is based on Django. I used a lot of time to look for existing modules for Django that implement oauth2 authentication and tesed some of them. There is for example django-allauth that provides authentication against a lot of authentication providers. I did manage to create an addiational authentication provider for Keycloak, but it seemed a bit overengineered to use such a big application for only one provider. So i sat down and wrote a small Django app that does oauth2 authentication. As soon as that worked with a clean Django installation, it took just some small adjustments to use it for the newmaintainer interface. You can find the branch on salsa

Fifth GSoC Report

Fri, 13 Jul 2018 06:28:51 +0100

No shiny screenshots this time ;-)

In the last two weeks i’ve finished evaluating the SSO solutions. I’ve added the evaluation of ‘ipsilon’, a python based single sign on solution. I’ve also updated the existing evaluations with a bit more information about their possibility to work with multiple backends. And i’ve added gitlab configuration snippets for some of the solutions. Formorer asked me to create a tabular overview of the outcome of the evaluations, so i did that in the README of the corresponding salsa repository. I’ve also pushed the code for the test client application i used to test the SSO solutions.

This week i used to look into the existing Debian SSO solution that works with certificates. The idea is not to change it, but to integrate it with the chosen OAuth2/SAML solution. To test this, i’ve pulled the code and set up my own instance of it. Fortunatly it is a Django application, so i now have some experience with that. Its not working yet, but i’m getting there.

I’ve also reevaluated a design desicion i made with nacho and came to the same conclusion: that storing the temporary accounts in ldap too is the way to go. There are also still some small feature requests i want to implement.

Fourth GSoC Report

Fri, 29 Jun 2018 06:28:51 +0100

As announced in the last report, i started looking into SSO solutions and evaluated and tested them. At the begining my focus was on SAML integration, but i soon realized that OAuth2 would be more important.

I started with installing Lemonldap-NG. LL-NG is a WebSSO solution writting in perl that uses ModPerl or FastCGI for delivering Webcontent. There is a Debian package in stable, so the installation was no problem at all. The configuration was a bit harder, as LL-NG has a complex architecture with different vhosts. But after some fiddling i managed to connect the installation to our test LDAP instance and was able to authenticate against the LL-NG portal. Then i started to research how to integrate an OAuth2 client. For the tests i had on the one hand a gitlab installation that i tried to connect to the OAuth2 providers using the omniauth-oauth2-generic strategy. To have a bit more fine grained control over the OAuth2 client configuration i also used the python requests-oauthlib module and modified the web app example from their documentation to my needs. After some fiddling and a bit of back and forth on the lemonldap-ng mailinglist i managed both test clients to authenticate against LL-NG.

The second solution i tested was Keycloak, an identity and access management solution written in java by Redhat. There is no debian package, but nonetheless it was very easy to get it running. It is enough to install jre-default from the package repositories and then run the standalone script from the extracted keycloak folder. Because keycloak only listens on localhost and i didn’t want to get into configuring the java webserver stuff, i installed nginx and configured is as a proxy. In Keycloak too the first step was to configure the LDAP backend. When i was able to successfully login using my LDAP credentials, i looked into configuring an OAuth2 client, which wasn’t that hard either.

The third solution i looked into was Glewlwyd, written by babelouest. There is a Debian package in buster, so i added the buster sources, set up apt pinning and installed the needed packages. Glewlwyd is a system service that listens on localhost:4593, so i also used nginx in this case. The configuration for the LDAP backend is done in the configuration file which is on Debian /etc/glewlwyd/glewlwyd-debian.conf. Glewlwyd provides a webinterface for managing users and clients and it is possible to store all the values in LDAP.

The next steps will be to test the last candidate, which is ipsilon and also test all the solutions for some important features, like multiple backends and exporting of configurable attributes. Last but not least i want to create a table to have an overview of all the features and drawbacks of the solutions. All the evaluations are public in a salsa repository

I also carried on doing some work on nacho, though most of the issues that have to be fixed are rather small. I reguarly stumble upon texts about Python or Django, like for example the Django NewbieMistakes and try to read all of them and use that for improving on my work.

Third GSoC Report

Fri, 15 Jun 2018 06:28:51 +0100

The last two weeks went by pretty fast, probably also because the last courses this semester started and i have a lot of additional work to do.

I closed the last report with writing about the implementation of the test suite. I’ve added a lot more tests since then and there are now around 80 tests that are run with every commit. Using unit tests that do some basic testing really makes life a lot easier- next time i start a software project i’ll definitly start early on with writing tests. I’ve also read a bit about the difference of integration and unit tests. A unit test should only test one specific functionality, so i refactored some of the old tests and made them more granular.

I then also looked into coding style checkers and decided to go with flake8. There were a huge pile of coding style violations in my code, most of them lines that were more than 79 characters. I’ve integrated flake8 in the test suite and removed all the violations. One more thing about python: i’ve read python3 with pleasure which gives a great overview about some of the new features of python3 and i’ve made some notes about stuff i want to integrate (i.e. pathlib)

Regarding the functionality of nacho i’ve added the possibility to delete an account. SSH keys are now validated on upload and it is possilbe to configure the key types that are allowed. I initially just checked if the key string consists of valid base64 encoded data, but that was not really a good solution so i decided to use sshpubkeys to check the validity of the keys. Nacho now also checks the profile image before storing it in the LDAP database- it is possible to configure the image size and list allowed image types, which is verified using python-magic. I also made a big change concerning the configuration: all the relevant configuration options are now moved to a seperate configuration file in json format, which is parsed when nacho is started. This makes it also a lot easier to have default values and to let users override them in their local config. I also updated the documentation and the debian package.

Now that the issues with nacho are slowly becoming smaller, i’ll start to look into existing SSO solutions that then can be used with the LDAP backend. There are four solutions i’ve on my list at the moment, that are keycloak, ipsilon, lemonldap-ng and glewlwyd.

Second GSoC Report

Fri, 01 Jun 2018 07:28:51 +0100

A lot has happened since the last report. The main change in nacho was probably the move to integrate django-ldapdb. This abstracts a lot of operations one would have to do on the directory using bare ldap and it also provides the possibility of having the LDAP objects in the Django admin interface, as those are addressed as Django models. By using django-ldapdb i was able to remove around 90% of the self written ldap logic. The only functionality that still remains where i have to directly use the ldap library are the password operations. It would be possible to implement these features with django-ldapdb, but then i would have to integrate password hashing functionality into nacho and above all i would have to adjust the hashing function for every ldap server with a different hashing algorithm setting. This way the ldap server does the hashing and i won’t have to set the algorighm in two places.

This led to the next feature i implemented, which was the password reset functionality. It works as known from most other sites: one enters a username and gets an email with a password reset link. Related to this is also the mofification operation of the mail attribute: i wasn’t sure if the email address should be changeable right away or if a new address should be confirmed with a token sent by mail. We talked about this during our last mentors-student meeting and both formorer and babelouest said it would be good to have a confirmation for email addresses. So that was another feature i implemented.

Two more attribute that weren’t part of nacho up until now were SSH Keys and a profile image. Especially the ssh keys led to a redesign of the profile page, because there can be multiple ssh keys. So i changed the profile container to be a bootstrap card and the individual areas are tabs in this card:

For the image i had to create a special upload form that saves the bytestream of the file directly to ldap which stores it as base64 encoded data. The display of the jpegPhot field is then done via

<img src=data:image/png;base64,...

This way we don’t have to store the image files on the server at all.

A short note about the ssh key schema

We are using this openssh-ldap schema. To include the schema in the slapd installation it to be converted to an ldif file. For that i had to create a temporary file, lets call it schema_convert.conf with the line

include /path/to/openssh-ldap.schema

using

sudo slaptest -f schema_convert.conf -F /tmp/temporaryfolder

one gets a folder containing the ldif file in /tmp/temporaryfolder/cn=config/cn=schema/cn={0}openssh-ldap.ldif. This file has to be edited (remove the metadata) and can then be added to ldap using:

ldapadd -Y EXTERNAL -H ldapi:/// -f openssh-ldap.ldif

What else happend

Another big improvement is the admin site. Using django-ldapdb i have a model view on selected ldap tree areas and can manage them using the webinterface. Using the group mapping feature of django-auth-ldap i was able to give management permissions to groups that are also stored in ldap.

I updated the nacho debian package. Now that django-ldapdb is in testing, all the dependecies can be installed from Debian packages. I started to use the salsa issue tracker for the issues which makes it a lot easier to keep track of things to do. I took a whole day to start getting into unit tests and i started writing some. On day two of the unit test experience i started using the gitlab continuous integration feature of salsa. Now every commit is being checked against the test suite. But there are only around 20 tests at the moment and it only covers registration and login and password reset- i guess there are around 100 test cases for all the other stuff that i still have to write ;)

Mini Debconf in Hamburg

Wed, 30 May 2018 09:28:51 +0100

Last week i attended my very first Debian Conference, the Mini Debconf in Hamburg. It gave me the opportunity to personally meet one of my gsoc mentors, formorer, and i’ve also met some other folks, both Debian contributors and people who are not. It was my first time experiencing Hamburg with warm and sunny weather- i went to Hamburg multiple times in the years when the Chaos Communication Congress was held there. The first day of my stay i took the time and looked around the city and was also curious about the state of the congress center- it looks like they are very thorough with the reconstruction.

From the Debconf i only attended the conference itself, not the Debcamp part. There were a couple of interesting talks, one of them was about CADUS, an organisation that works in combining technology and humanitarian aid. They built a mobile hospital from and old truck and they are researching and creating other really useful stuff. They also did a talk at the 34c3 in Leipzig last year.

After the CADUS talk there was formorers talk about the migration to salsa and the end of alioth.d.o. He also talked about some interesting features of the gitlab instance. Then there was a talk about “package security beyond signatures and reproducible builds” which proposed solutions to distribute software with apt that would help to detect targeted backdoors. Definitly an interesting topic, but i think i’ll have to watch the recording of the talk again to understand the approach (or do some reading about merkle trees ;)). Another interesing talk was about the Civil Infrastructure Platform, which aims to provide support for Linux systems for infrastructure that runs up to 30 years.

The recordings of the talks are in the meeting archive

First GSoC Report

Mon, 21 May 2018 09:28:51 +0100

To whom it may concern, this is my report over the first few weeks of gsoc under the umbrella of the Debian project. I’m writing this on my way back from the minidebconf in Hamburg, which was a nice experience, maybe there will be another post about that ;)

So, the goal of my GSOC project is to design and implement a new SSO solution for Debian. But that only touches one part of the projects deliveries. As you can read in the description Alexander Wirth originally posted in the Debian Wiki¹, the project consists of two parts, where the first one is the design and coding of a new backend and self-service interface for Debian guest users (this includes the accounts of Debian Maintainers).

It should also allow creating and selfservice for guest users and DMs. Those users belong into their own backend and should be suffixed with -guest

So after getting in touch with my two mentors, Alexander (formorer) and Nicolas (babelouest), we talked a bit about how to communicate and organize meetings; then i started looking into possible solutions for the guest backend. This is actually the more time critical part, as the current -guest accounts are stored on alioth and alioth will be shut down at the end of may. But Alexander assured that he will maintain the guest user database by hand for the time being, until the new -guest account solution can go into production.

Even before the official acceptance for GSOC i thought about how to implement this and i also talked a bit about that with Alexander. The first decision to make was to choose a data store for the backend. LDAP was a candidate but it would also have been possible to use relational databases. But LDAP is already being used in Debian in the userdir-ldap project and there is also more support for LDAP from potential existing SSO solutions, so it was an obvious choice. There second decision to make was to choose a Webframework for the self service web frontend. I already had some experience with Ruby and Rails, but there are some Django applications in Debian ecosystem (i.e. tracker.d.o.) and i wanted to learn something new. Also i had to do a Python course at the university so wanted to bring the mostly theoretical knowledge to practical use.

Alexander asked me to write a design document for the guest-backend, which i [published a few weeks ago] (/notes/debian-guest-account-backend-design/). Nicolas gave some feedback on the document right away and Alexander and i reviewed the design document again this weekend during MiniDebConf which resulted in some additional requirements for the backend, like the support of groups.

In the few weeks after writing the design document, i looked more into the possibilities of the different ldap-django extensions. There are two ldap extensions that allow authentication against an ldap server in the debian archive (django-auth-ldap and django-python3-ldap), where the former has a slightly better popcon score. And there is also django-ldapdb, which maps the objects from ldap to django models; django-ldapdb was not packaged yet, but the day i wanted to create an ITP, #898750 was created and the package was uploaded a few days ago. Also i started getting into Django coding itself. I went through most of the Writing your first Django app tutorial and started by writing simple webapps. Also simpleisbetterthancomplex has a lot of helpful Django resources.

I then also started coding the self service web application and had a basic prototype ready after a week. The prototype allows to register an account, which will only become active after the email address has been confirmed using a token. Activated accounts can login and modify their profile, which at the moment only means changing the password; the next step will be to implement a password reset feature, implement an admin interface, add some more fields to the user profile, etc…

You can see some screenshots of the prototype below:

I’ve named the webapp ‘nacho’, you can see the code in my salsa repo.

https://wiki.debian.org/SummerOfCode2018/Projects#SummerOfCode2018.2FProjects.2FNewDebianSSO.Successor_of_the_Debian_SSO_Service ↩︎

Debian guest-account backend design

Tue, 01 May 2018 19:28:51 +0100

Design of the Debian SSO guest backend

The guest backend solution consists of two parts: a database for storing account data and a frontend for self-management for guest users. The solution should provide the following functionality:

users should be able to register a guest user account
existing guest users should be able to change their passwords
existing guest users should be able to change their profile information
existing guest users should be able to reset lost or forgotten passwords
admins should be able to manage guest user accounts in case of malfunctions
the current and any future SSO service should be able to authenticate users against the guest backend

Backend-Database

Because the existing Debian SSO already uses LDAP (Leightweight Directory Access Protocol¹) to authenticate Debian Developers and because LDAP is more or less a standard for directory services, it stands to reason to also use LDAP as a database backend for storage of user accounts.

LDAP stores data in a Tree using objects with attributes and values. The set of attributes are defined in the objectclasses the object itself has as attributes. An LDAP object is uniquely identified by its Distinguished Name, which can be described as the path to the object from the databases root entry.

Tree

The directory structure of the backend could be very simple- as there are only accounts stored in the database and no groups or addressbooks (which is what ldap is used for often).

The Domain Componenet of the LDAP tree should reflect the infrastructure it is running on, i.e. dc=guestldap,dc=debian,dc=org if hosted on Debian infra or dc=guestldap,dc=debian,dc=net if hosed somewhere else. The container for the accounts should follow the best practice and be called ou=people.

Accounts

A guest accounts basically consists of a username and a password hash. In LDAP there are various objectclasses that provide these attributes, like posixAccount or shadowAccount. Both are described in rfc2307². Every objectClass has attibutes the object MUST have and attributes it MAY have. For our usecase the objectclass shadowAccounts is a better fit, because posixAccount has multiple attibutes we would have to store that are not useful in our setup (i.e. uid, gid, homeDirectory).

The shadowAccount objectclass has the following definition³:

objectClasses: ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount'
  DESC 'Additional attributes for shadow passwords'
  SUP top AUXILIARY MUST uid MAY ( userPassword $ shadowLastChange
  $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive
  $ shadowExpire $ shadowFlag $ description ) )

So by using this objectclass we have to only use the uid and it also provides the attribute userPassword for storing the password hash of the users password.

Account reset

The requirements at the beginning of this document also specify that the user should be able to reset the password for their account. This means we have to store some kind of account reset information. It is popular to use an email address for these kind of situations. As apparent from the objectclass defintion above, the shadowAccount objectclass does not provide an email field. Thus we have to include another objectclass in the guest account entries. There are multiple objectclasses that provide an email attribute. One often used objectclass is inetOrgPerson, which is defined in rfc2798⁴:

 objectclass ( 2.16.840.1.113730.3.2.2
   NAME 'inetOrgPerson'
   DESC 'RFC2798: Internet Organizational Person'
   SUP organizationalPerson
   STRUCTURAL
   MAY ( audio $ businessCategory $ carLicense $ departmentNumber $
    displayName $ employeeNumber $ employeeType $ givenName $
    homePhone $ homePostalAddress $ initials $ jpegPhoto $
    labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $
    roomNumber $ secretary $ uid $ userCertificate $
    x500uniqueIdentifier $ preferredLanguage $
    userSMIMECertificate $ userPKCS12 )
   )

inetOrgPerson provides the mail attribute. The objectclass has no MUST attributes, but it is derived from organisationalPerson which is itself derived from person, which has the attributes cn (commonName) and sn (surname) as MUST attributes.

In conclusion, a guest user entry would have to have the following entries:

uid
userPassword
cn
sn
mail

Security considerations

The ldap server should not allow anonymous bind. The password hash in the userPassword attribute should use a current hashing algorithm. OpenLDAP provides built in support for MD5, MD5 salted, SHA-1 and SHA-1 salted, which are all not recommended anymore. There is the possibilty to pass hashing and verification to the operating systems crypt⁵ function though. In linux the crypt function can use different hashing schemes. The hashing scheme used for the password hash in prepended to the password hash and forms a PHC string as defined in the PHC string format⁶. (I’ve asked DSA for information about preferred hashing algorithms on Debian systems, but got no answer back.)

Frontend

As described in the preamble, users should be able to register an account and be able to do basic self service, like change the password and reset the password in case it gets lost. Also there should be an admin interface for user management.

Most users are accustomed to do such tasks via a webinterface, which is also the most common solution. There are multiple techonolgies out there that could help in writing such a webinterface- the most common solutions in the Debian project are perl scripts and Django⁷ based webprojects (like tracker.d.o).

Django is a web framework that is based on the Model-View-Controller pattern. It provides the building blocks to easily create basic Webapplications. Moreover it comes with an integrated admin interface and user and group models.

Djangos default database backends include MySQL, sqlite and other relational databases, but not LDAP. There are two approaches to use Django with LDAP:

It is possible to use Django plugins for authenticating against an LDAP database (like python-django-auth-ldap or python-django-python3-ldap). The problem with these plugins is, that they are only for authentication, which means that any write operations on the LDAP Database would have to be programmed by hand. The upside is, that this approach provides a more granular control on the permissions the Django application needs for working with the LDAP Backend.

The second approach would be to use django-ldapdb⁸, which uses LDAP as a data storage backend. The benefit of this approach is a better integration in the Django framework (i.e. the user model could be reused which makes it easily accessible in the Django admin console). The downside is, that the Django application need read and write access to the whole ou=people subtree, to be able to perform its tasks. django-ldapdb is not packaged for Debian yet.

Webinterface and Backend-Database

The Webinterface and the LDAP Database can basically run on the same server, but the services can also be distributed to to servers. Regardless of the servers, the Webinterface should access the LDAP Database via an encrypted channel (ldaps).

Application for Google Summer of Code 2018

Fri, 27 Apr 2018 17:28:51 +0100

To Whom It May Concern, this is my student application for this years google summer of code for the debian SSO project- i removed the boring parts about myself ;)

Student Application

Description of the Project

Status Quo

For some time now, the Debian project has a single sign on (SSO) solution¹ that users can use to authenticate against on tracker.debian.org, nm.debian.org, contributors.debian.org and paste.debian.net. The SSO solution² uses client browser certificates and is maintained by Enrico Zini (enrico@debian.org). It does not bring its own user database, but forwards authentication to mod_ldap³. There are two authentication backends, ldaps://db.debian.org, which is the main debian developers database, and ldaps://alioth.debian.org. Alioth.debian.org was/is a FusionForge installation, which acted as the main code management system for the debian project. And in connection with sso.debian.org it acted as a backend for ‘guests’ and Debian Maintainers. Alioth was replaced by salsa.debian.org, which is a gitlab installation that went live in december 2017 and left beta in the beginning of 2018. But salsa.debian.org does not provide an authentication backend for sso.debian.org, which means, as soon as alioth.debian.org will be gone, there is one backend missing. Sso.debian.org is also only a single sign on solution, but not a user management solution. There is no way for users to reset their password or to delete their account. Another interesting feature would be to provide an interface to manage SSH or OpenPGP keys. And last but not least, sso.debian.org only provides an SSO solution based on certificates. There are other technologies like Oauth2 or SAML, that are more widespread and integrated in wide range of products. Some solutions have been mentioned in a discussion about the sso.debian.org service on debian-devel in August last year⁴. There is also a wiki page⁵ collecting facts about the SSO service and listing some ideas for a makeover.

Project Goal / Devilerables

As described above, there are two main tasks:

sso.debian.org frontend: for one there is the expansion or replacement of sso.debian.org with Oauth2 and/or SAML. There have been some proposals on debian-devel about this topic, whic will have to be tested. If there is no suitable solution the existing sso.debian.org solution has to be extended with additional authentication mechanism or a new single sing on solution has to be implemented.
sso.debian.org backend: the second task is the design, development and implementation of the guest-backend of sso.debian.org. This platform should provide means to manage one’s own account data, reset a password, manage keys for OpenPGP or SSH and delete an account. As with the sso solution, there will be one part research in existing solutions as well as development of an own solution and subsequently the design and development of the solution.

Any Work, be it research or be it programming tasks will be documented and published in git. If it turns out that it would be practical to spread the work over multiple repositories, that won’t be a problem (thats what submodules are for). To accompany the work there can be regular written by mail and/or blog post.

Rough Timeline

April 23 - Mai 14: Get to know the existing sso solution as well as the userdir-ldap system that the Debian project uses to manage the debian developer accounts ⁶. Read and test different SSO solutions. Talk to DSA about requirements/wishes for the SSO platform as well as possible Test-VMs. Maybe talk to package maintainers of possible solutions about their relationship with upstream and upstreams responsivness. Compose an implementation plan, devide in two steps and write an email to debian-devel about it, asking for input. From May 3rd to May 5th there will be the Vienna Linux Weeks which would be interesting- also to get in contact with Debian contributors. But there will also be an big exam on May 4th. It’s not clear yet if that leaves time for attending the Linux Weeks.
May 14 - June 11: If time permits, go to Mini-DebConf in Hamburg, which will happen from May 16-20 to do some community bonding and talk over some ideas. Start with step one with designing the LDAP database for the backend and at the same time start implementing the chosen SSO solution on a test server. The goal to have basic prototypes for both the backend and the frontend before June 11. Give regular updates to mentors about progress and/or obstacles.
June 11 16:00 UTC Mentors and students can begin submitting Phase 1 evaluations
June 15 16:00 UTC Phase 1 Evaluation deadline
June 15 - July 9: Start with step 2: implement a webinterface for the management of the backend. Refine the existing prototypes; find and remove bugs, check deliverables. Create a test application that authenticates against the chosen SSO solution or even propose a patch for an existing debian service to make that service authenticate against the new solution.
July 9 16:00 UTC Mentors and students can begin submitting Phase 2 evaluations
July 13 16:00 UTC Phase 2 Evaluation deadline
July 13 - August 4 Bugfixing, testing, puppetize existing setup; report to debian-devel about the project status; Start writing down future features;
August 6 - 14 16:00 UTC Final week: Students submit their final work product and their final mentor evaluation

Coreboot on the x230

Fri, 16 Mar 2018 19:28:51 +0100

After living with my old coreboot installation for more than 18 month, i recently decided to build a new image and flash it. So i downloaded a coreboot 4.7 archive, extracted it and started building. I wanted a coreboot image with grub as a payload, but this time i didn’t want to build the grub payload myself, but let coreboot do the dirty work. To these are the changes i made to the default coreboot config:

Mainboard vendor (Lenovo)
Mainboard model (ThinkPad X230)
ROM chip size (4096 KB (4 MB))
Add a payload (GRUB2)  --->
GRUB2 version (2.02)  --->
(cryptodisk luks lvm gcry_rijndael gcry_sha256 usbserial_ftdi usbserial_pl2303) Extra modules to include in GRUB image
Include GRUB2 runtime config file into ROM image
(grub.cfg) Path of mygrub.cfg

and this is the corresponding mygrub.cfg file- it is based on the common.cfg grub config from the libreboot project:

function try_isolinux_config {
	set root="${1}"
	for dir in '' /boot; do
		if [ -f "${dir}"/isolinux/isolinux.cfg ]; then
			syslinux_configfile -i "${dir}"/isolinux/isolinux.cfg
		elif [ -f "${dir}"/syslinux/syslinux.cfg ]; then
			syslinux_configfile -s "${dir}"/syslinux/syslinux.cfg
		fi
	done
}
function search_isolinux {
	for i in 0 1; do
		# raw devices
		try_isolinux_config "(${1}${i})"
		for part in 1 2 3 4 5; do
			# MBR/GPT partitions
			try_isolinux_config "(${1}${i},${part})"
		done
	done
}

function decrypt {
        insmod luks
        insmod cryptodisk
        cryptomount (ahci0,msdos1)
        insmod lvm
}

menuentry 'Load Operating System (incl. fully encrypted disks)  [l]' --hotkey='l' {
        decrypt
        if [ -f (lvm/vg--x230-root)/boot/grub.cfg ] ; then
                root=(lvm/vg--x230-root)
                configfile /boot/grub.cfg
        fi
}

menuentry 'Debian GNU/Linux [d]' --hotkey='d' {
        decrypt
        root=(lvm/vg--x230-root)
        linux /vmlinuz
        initrd /initrd.img
}

menuentry 'Debian GNU/Linux Old [o]' --hotkey='o' {
        decrypt
        root=(lvm/vg--x230-root)
        linux /vmlinuz.old
        initrd /initrd.img.old
}

menuentry 'Search ISOLINUX menu (AHCI)  [a]' --hotkey='a' {
	search_isolinux ahci
}
menuentry 'Search ISOLINUX menu (USB)  [u]' --hotkey='u' {
	search_isolinux usb
}
menuentry 'Search ISOLINUX menu (CD/DVD)  [c]' --hotkey='c' {
	insmod ata
	for dev in ata0 ata1 ata2 ata3 ahci1; do
		try_isolinux_config "(${dev})"
	done
}
menuentry 'Poweroff  [p]' --hotkey='p' {
	halt
}
menuentry 'Reboot  [r]' --hotkey='r' {
	reboot
}