Blog | Raul Benencia

The best dependency is the one you don't need

Fri, 19 Jun 2026 22:38:56 -0300

Antoine de Saint-Exupéry, best known for Le Petit Prince, wrote in Terre des hommes that:

Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher.

This is normally translated to English as:

Perfection is finally obtained not when there is no longer anything to add, but when there’s no longer anything to take away.

This philosophy can also be applied to software. The UNIX adage “make each program do one thing well” encourages slim applications that are not bloated with features or dependencies.

In this article I want to focus on dependencies. Every dependency is also a trust relationship: in upstream maintainers, their release process, their response to vulnerability disclosures, and the continued availability of their maintenance time. Dependencies are therefore delegated maintenance and delegated trust. Some are worth that delegation; some are not. The constant stream of supply chain attacks is a reminder that dependencies can be a liability.

Eight years ago I wrote Shoelaces, a tool for automating server bootstrapping. Back in the day, the company I was working for ran entirely on-premises, and we were scaling fast. My role as an SRE was full-stack in the broadest sense: it ranged from fine-tuning complex distributed systems to the mundane work of screwing hundreds of disks into drive caddies before inserting them into servers. We automated everything we could.

Shoelaces was our solution to server bootstrapping automation. Whenever a server was turned on, it would show up on a webpage and allow the operator to choose from a list of recipes. In this way we simplified the installation of bare-metal servers such as Kubernetes workers, Xen virtualizers, and various database servers, among other systems. Shoelaces would also support fully unattended bootstrapping: a CIDR could be associated with a recipe, and every device attempting an iPXE boot on that network would get a full OS installation. This was useful for configuring appliances that would later get shipped to customers.

As my company moved to the cloud, we stopped using Shoelaces in favor of other technologies. Server bootstrapping was replaced with API calls, autoscaling groups, etc. My software fulfilled its task and metaphorically sank with the data center we left behind. However, Shoelaces kept receiving an occasional pull request or bug report, and a small user base started growing. When time allowed, I would spend some cycles applying patches, updating minor dependencies and doing general maintenance.

A task that is slightly more involved is to upgrade dependencies to new major versions. It’s normally not difficult, but it’s repetitive and cumbersome. The advent of LLMs makes these chores more straightforward: a simple prompt can go through a changelog and refactor all code to conform with the new version. In most circumstances, this is good and is the desired outcome. However, simply updating dependencies means that in a few months, or even days, they will be outdated again. Like Sisyphus in the Greek myth, the operator will be condemned to push a boulder up a hill, only for it to roll back down with the next vulnerability disclosure.

I want to point out an alternative to constant patching: prune out unnecessary bloat. Revisit dependencies to understand what is mandatory, and what’s there to make developers’ lives slightly simpler in the short term, at the expense of maintenance toil in the long term. Shoelaces is a small piece of software, and most of its dependencies were used minimally. The backend dependencies included libraries for HTTP routing, middleware chaining, configuration from command-line flags and structured logging. The frontend dependencies included Bootstrap CSS/JS for navbar, grids, and other elements. Bootstrap bundled legacy icon fonts, but there were no first-party references, so they were effectively unused. jQuery was used for AJAX requests, DOM manipulation, event handlers, and fade effects. All in all, these dependencies are nice to have, but they’re not mandatory. I’m neither actively maintaining Shoelaces nor developing new features for it, so the best use of my time is to prepare it for the software afterlife by trimming out anything that’s not compulsory.

I released a new minor version of Shoelaces with that vision in mind. In the backend, most Go dependencies were decommissioned in favor of standard library implementations (the standard library now includes many features that were not present in the previous version of Shoelaces), along with small, focused implementations developed with LLM assistance. I used LLM assistance here in a bounded way: not to introduce new abstractions, but to replace small, well-understood dependency usages with local code that could be reviewed directly. In the frontend, JavaScript and CSS code was replaced with local implementations that now leverage the browser DOM APIs. The interface looks slightly less polished, but the trade-off was well worth making. In this release, the Go dependency set went from 10 module entries to 1, while roughly 800 KB of vendored Bootstrap, jQuery, and font assets were replaced with about 15 KB of local CSS and JavaScript. This simplification also has consequences beyond the Shoelaces tree itself. A few dependencies that had been packaged exclusively for Shoelaces can now be dropped from the Debian archive, reducing not only the application’s dependency graph but also the maintenance surface around it.

Dependencies can be a liability. They might save a few hours of coding in the short term at the expense of Sisyphean patching sessions in the long run. With LLMs, implementing small features normally covered by dependencies is much cheaper. However, I’m not suggesting to reinvent the wheel for every piece of software because that has its own risks as well: more code to maintain and, of course, a larger attack surface. While Antoine de Saint-Exupéry was writing about airplanes when describing his concept of perfection, his words fit the software industry perfectly. Software can gain longevity not through new features, but by reducing the amount of code, process, and external trust it asks future maintainers to carry.

Org Tempus

Mon, 01 Jun 2026 08:23:41 -0300

Time management is a tricky business. Ideally we should spend our precious time in Earth doing things that we’re interested in for as long as we want. Unfortunately that’s not how the life of a modern human works. We have responsibilities, chores, busy work, etc. We have activities that we enjoy doing, and tasks that we have to get over, and ideally we should make progress in all of them. We’re in a constant state of context switching. Additionally, we need to take regular breaks to ensure our brain is not overly engaged.

As an Emacser, I’m an avid user of Org Mode. I find it essential to keep track of my perennial list of tasks, both personal and at work. Org has a handy clocking feature that allows you to track the time you spent on each task. This feature is essential to ensure I don’t overwork, or underwork, in any of my responsibilities. However, it’s a bit of a hassle to clock in and clock out all the time, particularly if you take regular breaks.

Enter Org Tempus, an Emacs package I’ve written on top of Org Mode to automate many parts of my workflow. In particular, Org Tempus allows setting up a default task to auto clock-in when activity is detected in the workstation. This default task is how I track administrative work: catching up with emails, messages, and capturing new work items. How “activity” is detected is configurable and extendable: it can be activity coming from Emacs itself, or activity coming from a desktop environment such as GNOME. The package also permits setting intervals for breaks (similar to the Pomodoro technique) and total worked time, and sends notifications when the thresholds are reached.

Overall, Org Tempus has enabled me to be more intentional with how I spend my computing time. Check the README for the full list of features. I’ve just released version 0.0.2.

Emacs server, systemd and XAUTHORITY

Tue, 30 May 2023 00:00:00 +0000

Running Emacs as a systemd service should be relatively straightforward if using its Debian package, given that it comes with a systemd unit.

Here’s a fragment:

$ cat /usr/lib/systemd/user/emacs.service | head -n7
[Unit]
Description=Emacs text editor
Documentation=info:emacs man:emacs(1) https://gnu.org/software/emacs/

[Service]
Type=notify
ExecStart=/usr/bin/emacs --fg-daemon

However, I’ve faced the following problem: when running emacsclient from a graphical interface, nothing happened, and it was not clear what to do next.

To unravel these kind of problems, we should always start by checking the logs. An interesting line showed up:

$ journalctl  --user -u emacs.service
...
May 18 16:51:51 zorzal emacs[1308]: Authorization required, but no authorization protocol specified
...

After some digging, I realized this happens because the Emacs server was started before the XAUTHORITY variable was set, and we need that variable to communicate with the display server.

A quick search didn’t show a straightforward or clean solution. Remediating this problem should be relatively simple: we just need to instruct systemd to start the Emacs server after the graphical session. systemd comes preloaded with a special target that can be used for this purpose: graphical-session.target.

A systemd drop-in file can be used to establish this dependency:

$ cat ~/.config/systemd/user/emacs.service.d/override.conf
[Unit]
Requires=graphical-session.target

To pick-up the override, we must remember to run: systemd --user daemon-reload.

Why isn’t this a default in the shipped unit file? I suppose we can’t assume the user will always have a graphical session when launching an Emacs server, so it wouldn’t be safe to make it a default.

Debian contributions — October 2021

Sun, 10 Oct 2021 00:00:00 +0000

Greetings, and welcome to another round of Debian contributions.

fortunes-it

Prepared NMU that fixes the following typo bugs:
- #787140
- #788097
- #792271
- #833062

devscripts

Reported #996392. The bug describes a typo in “nmudiff” manpage. Included a patch.
Reported #996565. The bug describes a misleading situation with the delay header when nmudiff is run by a non-DD. Included a patch.

foremost

Foremost is a program to recover files based on their headers, footers, and internal data structures.

Closed #912365. The bug was tagged “moreinfo” for more than a year, no info has been provided and it seems unreproducible.

rotix

The “rotix” package allows you to generate rotational obfuscations, like the world-famous ROT-13.

In this batch of contributions, I’ve:

Revamped and modernized the packaging.
Fixed the NL translation and submitted the patch to upstream.

Misc

Updated my Debian wiki profile.
Added myself to the low threshold NMU list.

Debian contributions — September 2021

Wed, 29 Sep 2021 00:00:00 +0000

Greetings from San Francisco, and welcome to another round of Debian contribution logs. Days are getting darker and shorter as summer breezes out unamusingly. Perhaps it was not my coldest winter, but it was chilly anyway.

San Francisco's Bay Bridge

Shoelaces

Shoelaces is a tool for automating servers bootstrapping. I gave a talk about it on DebConf 19. On these contributions batch, I’ve:

Uploaded golang-github-namsral-flag version 1.7.4~alpha+git20170814.67f268f2-2 and golang-github-justinas-alice version 1.2.0-1. These packages are Shoelaces’s dependencies. I’ve prepared their release the month before, but didn’t have write permissions on their git repo. Tina kindly gave them to me. Thank you!

Prometheus Nginx VTS exporter

The prometheus-nginx-vts-exporter package is a Prometheus exporter for Nginx VTS metrics.

Shortly after I created this package for Debian, support was added for exporting Prometheus metrics directly from the plugin itself. Consequently, upstream decided to stop the development of this exporter. Being no longer useful to have this package on Debian, I filed a removal request.

Emacs theme — Zenburn

This package provides a low contrast color theme for Emacs. Zenburn is designed to minimise eye strain during long periods of work.

After reviewing the current packaging situation, I expressed my intent to adopt zenburn-emacs.
I’ve prepared a new upstream release and brushed up its packaging. Then, I’ve requested sponsorship. Sean Whitton kindly uploaded it for me.
#988297 was opened, in what must be the highest record between adopting a package and getting a bug reported on it. I’ve prepared a fix release.

Emacs theme — Clues

The clues-emacs package provides a theme for Emacs. I adopted it during DebConf 19.

Updated VCS to include a non-maintainer upload.

The Mole

The Mole is an automatic SQL Injection exploitation tool.

Updated VCS to include a non-maintainer upload.

Foremost

Foremost is a program to recover files based on their headers, footers, and internal data structures.

Uploaded foremost version 1.5.7-11, which includes a rediff of its patches to use gbp pq and a fix to bug #994067.

Debian contributions — April 2021

Thu, 29 Apr 2021 00:00:00 +0000

Greetings from a windy San Francisco. This blog is a bit quiet; let’s fix that. I will start making some noise by sharing my contributions to the Debian project.

A view of San Francisco downtown, from Dolores Park.

Debsources

Debsources is the software behind sources.debian.org.

2021-03-26: Fixed Docker build and updated HACKING instructions for running the Docker environment; I wanted to give a shot to the bugs tagged newcomer, but the first challenge I found was that — on master — the Docker-build instructions were not working. This contribution fixed that. After submitting it, though, I was made aware that the Docker build was already fixed on another branch.
2021-03-27: Fixed Flake8 E741: A simple contribution to get familiar with the debsources code base. This contribution was put on hold. We decided to wait until the current effort for migrating from Python 2 to Python 3 is finished.
2021-03-28: Fixed test_news test. I faced several issues with this test, so I fixed them.
2021-04-06: Added CI. Debsources used to have a Travis CI but it stopped working at some point. This merge request started the discussion for using Salsa CI.
2021-04-09: Enhanced Docker-build’s Makefile, as it was not using the same targets than the main Makefile. This patch fixed that situation, making it consistent.

This contribution was part of the same merge request I started on 2021-04-06.
2021-04-17: Fixed #783832. This bug was opened about six years ago to track tests that were failing to run on a CI (Travis, on those remote times). I’ve successfully ran all tests with Salsa CI, so this bug was finally closed.

This contribution was part of the same merge request I started on 2021-04-06.

Kudos to Matthieu Caneill for patiently sponsoring these contributions. Thank you!

Carnivore

The Carnivore project — maintained by the QA team — is a database that plenty of Debian services use under the hood. From its README:

Goal is to reliably correlate identities with each other, that is, alternative email addresses, and the like, for the purpose of having all sorts of QA scripts, including DDPO, MIA, lintian, etc. etc. be able to show data grouped by maintainer, even though a single maintainer might be using multiple different email addresses.

I wanted to tackle some its bugs:

2021-04-01: My first conclusion after analyzing the code base was that a small change will have big impact, so testing was paramount. The project does not describe how to do local testing, and I suspect there’s no direct way of doing so. This contribution adds a Docker test environment to ease local testing.

I’m still looking for someone to sponsor this contribution.
2021-04-03: carnivore gathers the name for a given identity from packages — using Maintainer and Uploaders field —, from GPG keys on the Debian keyrings, and from LDAP (DDs only). Some identities will have multiple names associated. Sometimes, this behavior is unwanted:
- #963210 — carnivore: DDPO still using old name
- #694081 — carnivore: should not import name from revoked gpg key
This contribution allows setting a preferred name for a given identity.

I’m still looking for someone to sponsor this contribution.

Emacs theme — Clues

The clues-emacs package provides a theme for Emacs. I adopted it during DebConf 19.

2021-04-07: Commited an NMU patch to the VCS.
2021-04-12: Prepared version 1.0.1-3. This version updates the packaging and adds CI. I was still missing DM upload permissions and Josue kindly gave them to me. Thank you!

Shoelaces

Shoelaces is a tool for automating servers bootstrapping. I gave a talk about it on DebConf 19.

2021-04-10: Uploaded version shoelaces_1.2.0+ds-1. This version packages a new upstream release, and also updates the packaging in general.
2021-04-18: Prepared golang-github-namsral-flag version 1.7.4~alpha+git20170814.67f268f2-2. This package is a shoelaces dependency.
2021-04-20: Prepared golang-github-justinas-alice version 1.2.0-1. This package is a shoelaces dependency.

The Mole

The Mole is an automatic SQL Injection exploitation tool.

2021-04-11: Uploaded version 0.3-3. This version updates the packaging and adds CI.

Foremost

Foremost is a program to recover files based on their headers, footers, and internal data structures.

2021-04-16: Uploaded foremost version 1.5.7-10. I’ve updated the packaging, added CI and fixed a FTBFS on the way. I’ve also attended to a long-standing merge request from the Ubuntu team, and updated their bug report.

DebConf 19

Tue, 30 Jul 2019 00:00:00 +0000

After many years of virtually assisting DebConf — the annual Debian conference — I’ve finally had the opportunity of going and enjoying it in-person. This year it was held in Curitiba, Brasil.

Parque Tanguá, Curitiba.

It was a unique experience; not only did I get to put a face to the names and nicks — and nicks and names to many new faces — I also got to present Shoelaces to the wider Debian community.

As I mentioned in the talk, I wanted the talk to spark some interest on any DD that was willing to sponsor the Shoelaces package into the Debian archive, but I was lucky enough to get it even before the talk. Thank you, Dererk! It’s official, Shoelaces is available on Debian.

Kudos to the DebConf Video Team for doing an amazing job with the recording, and to the DebConf Team in general for having organized such a wonderful event. Overall, I’m quite happy with the experience and would definitely do it again.

Kafka Topics: Pitfalls and Insights

Sat, 30 Mar 2019 00:00:00 +0000

A few weeks ago I published an article on ThousandEyes’ blog describing my experiences with Kafka Topics.

Do check it out if you’re interested.

Debian Maintainer

Wed, 25 Jul 2018 00:00:00 +0000

As of yesterday, I’ve been bestowed the title of Debian Maintainer.

Those who know me knows how much I admire the Debian project, so it’s truly an honor to get this recognition and be able to keep giving back to the community in a more autonomous way.

I’d like to thank Lisandro for advocating this process.

Shoelaces

Sun, 20 May 2018 00:00:00 +0000

Some days ago I announced the release of Shoelaces, a tool for automating servers bootstrapping. It’s particularly useful on on-premise data centers environments.

Check the original blog post for more details.

LibrePlanet 2018

Fri, 23 Mar 2018 00:00:00 +0000

This year I was fortunate enough to be able to travel to Boston, Massachusetts, to the annual Libreplanet conference.

It’s been a long trip from San Francisco, I didn’t get a lot sleep, but all the sleepiness went away during my first impressions of the city. See, it doesn’t snow in the city where I’m originally from, so seeing the snow piled-up next to the side-walk has certain charm that I like.

Boston University Bridge

Next to the Charles River, Boston is awakening

Anyway, if you are around at the conference, come, chat, exchange GPG keys! Today I’ll be going to SpinachCon and later in the day to the FSF Open House.

See you around!

Using notmuch-emacs along with other folder-based MUA

Wed, 24 Jun 2015 00:00:00 +0000

I’ve started to leave my mutt niche in order to start using notmuch-emacs MUA. All in all, I can see the see the speed advantage of using notmuch, among other little perks. Nevertheless, the approach of tagging emails instead of organizing them in IMAP folders makes the use of notmuch a little non-portable for others folder based user agents. I wouldn’t mind that, but I like receiving my emails on my mobile phone and as far as I know there is no such thing as a mobile notmuch MUA.

In this blog post I’ll share my approach for using a notmuch based agent, as notmuch-emacs, along with other folder based agents, as Thunderbird or K-9 Mail. The first thing to do is to define the layout of our IMAP folders. In our examples we’ll use something like this:

$ ls -1 ~/Maildir
archive
cur
debian
debian.devel
debian.haskell
debian.haskell.commits
debian.haskell.maintainers
debian.haskell.maintainers.junk
debian.misc
debian.project
new
tmp

So, here I have my inbox folder along with an archive maildir and a hierarchy of folders containing Debian mailing lists. In my folder based mobile agent, K-9, I won’t be bothered with notifications of new mailing list emails, as the agent is configured to only check for new emails in the inbox folder. On the other hand, in a default notmuch setup each time I run notmuch new the database will be filled with all the emails in all the folders and will tag the new ones with inbox. Now, when I’m using notmuch-emacs, I like that my inbox emails be only the ones in my inbox folder. Besides, I’ll also like to add a tag that matches the name of the folder the email is in. In notmuch language:

#!/bin/sh

notmuch new

notmuch tag +archive -inbox "path:archive/**"
notmuch tag +debian -inbox "path:debian/**"
notmuch tag +debian-devel -inbox "path:debian.devel/**"
notmuch tag +debian-project -inbox "path:debian.project/**"
notmuch tag +debian-haskell -inbox "path:debian.haskell/**"
notmuch tag +debian-haskell-commits -inbox "path:debian.haskell.commits/**"
notmuch tag +debian-haskell-maintainers -inbox "path:debian.haskell.maintainers/**"
notmuch tag +debian-haskell-maintainers-junk -inbox -unread "path:debian.haskell.maintainers.junk/**"
notmuch tag +debian-misc -inbox "path:debian.misc/**"

With this method we can use a folder based approach with notmuch tags. Let’s move to another topic. In the notmuch world, archiving an email means removing the inbox tag. If we only do this, all the archived emails will still be in our inbox folder, so what we’ll like to do is to move to the archive folder all the emails from the inbox folder that don’t have the inbox tag. In other words:

function archive() {
    if [ $# -ne 2 ]; then
       echo "Incorrent parameters. Send INBOX and ARCHIVE"
       return 1
    fi

    for e in $(notmuch search --output=files "path:$1/**" and not tag:inbox); do
        mv $e $2
    done

    return 0
}

archive cur ${MAILDIR}/archive/cur

Finally, one little detail is left: spam. In a folder based agent, we’ll usually have a spam folder. In the notmuch world, when we tag an email with spam, a decent client won’t show it in the results of notmuch searches, but it will remain in the folder it was found. So, what we have to do is to move all the spam tagged email to our spam folder.

for e in $(notmuch search --output=files tag:spam and not "path:spam/**"); do
    mv $e $MAILDIR/spam/cur
done

So, if we cron this little script we’ll be able to use a notmuch based MUA along with an IMAP folder based one. Enjoy!

Chess and C, day 3

Wed, 01 Apr 2015 00:00:00 +0000

Finally, after setting the skeleton of the game on day 1 and day 2, I’ve managed to get a chess board where you can actually play. Of course, it’s quite rudimentary and you’ll have to input the coordinates by typing them, but I think that for the moment it’ll do.

The first thing to think about is how are we going to represent a movement in our game. Basically, a movement is a couple of coordinates representing the origin and destination of a piece. Let’s capture that idea in a type.

typedef struct {
    Coord orig;
    Coord dest;
} Move;

As you can see, the type is quite simple and will suit perfectly our needs. Anyway, the type alone won’t serve us if we don’t have a way of inputting the movements. How are we going to implement the input system will depend on the interface we will be using. For the moment our interface is CLI based, but we should think that in a future we may be able to implement something using curses or GTK. For that reason, the input system should be as detached as possible from the logic of the game. I’ve decided to encapsulate all the input related logic in the function Move input_move() and a bunch of static declared sub-functions. The final result is something similar to the following output.

White's turn.
Orig coordinate: e9
Invalid coordinate. Write something like "e2": e2
Dest coordinate: e4

As you may have guessed, this input will move the pawn on square e2 to e4. Due to the decoupling of the input system and the logic of the game it’s possible to implement more than one input system without any pain. In a future, maybe, I’ll implement an input system using algebraic coordinates.

Now that we have a representation of the movements and a way of input them, we can start implementing the main game loop. It’s implementation is quite trivial and looks very similar to the following piece of code.

    while (!game_is_checkmate(board, current_player)) {
        print_board(board, current_player);

        move_valid = 0;
        while (!move_valid) {
            m = input_move();

            if (game_is_move_valid(board, current_player, m))
                move_valid = 1;
            else
                printf("Invalid move. Please, try again. ");
        }

        board = board_make_move(board, m);
        current_player = current_player == WHITE ? BLACK : WHITE;
    }

As you can see, in this implementation the real logic of chess rules lives in the functions int game_is_checkmate(Board, Color) and int game_is_move_valid(Board, Color, Move) which, for the moment, aren’t implemented and always return 0 and 1 respectively.

Finally, thanks to all the abstraction and modular code we’ve written it’s possible to implement a tiny short main() function like the following one.

#include "board.h"
#include "game.h"

int main() {
    board_delete(game_loop(board_init()));

    return 0;
}

And that’s it! We have a working interface were we can play. Here is how will look the board after a few moves.

  +---|---|---|---|---|---|---|---+
8 | R | N | B | Q | K | B | N | R |
  +---|---|---|---|---|---|---|---+
7 | P | P | P |   | / | P | P | P |
  +---|---|---|---|---|---|---|---+
6 |   | / |   | P |   | / |   | / |
  +---|---|---|---|---|---|---|---+
5 | / |   | / |   | P |   | / |   |
  +---|---|---|---|---|---|---|---+
4 |   | / |   | / | p | / |   | / |
  +---|---|---|---|---|---|---|---+
3 | / |   | / |   | / | n | / |   |
  +---|---|---|---|---|---|---|---+
2 | p | p | p | p |   | p | p | p |
  +---|---|---|---|---|---|---|---+
1 | r | n | b | q | k | b | / | r |
  +---|---|---|---|---|---|---|---+
    a   b   c   d   e   f   g   h

White's turn.
Orig coordinate:

Chess and C, day 2

Sat, 28 Mar 2015 00:00:00 +0000

Yesterday I’ve started a blog post series where about writing a small chess interface in C. I’ve set up the types Color, PieceType, Piece, Square and Board, and talked about the general idea of the game. Finally, I’ve shown some of the logic behind printing and initializing the Board.

One of the problems I’ve talked about yesterday was the fact that I’m hardcoding the initial positions to the inner representation of the board.

Board _pawns(Board b) {
    short white_pawns_row = 1, black_pawns_row = 6, i;

    for (i = 0; i < SIZE; i++)
        b[white_pawns_row][i].piece = new_piece(WHITE, PAWN);

This is quite ugly because I’m tying the initialization to the types and in a future we might find this to be pretty restrictive. Another case where this approach isn’t useful is in the print_board(Board) function. Yesterday what I did was something similar to the following piece of code.

    for (i = 0; i < SIZE; i++) {
        for (j = 0; j < SIZE; j++) {
            print_square(b[i][j]);

Now, let suppose that we want to print the board from the black player perspective. Auch. We might need to code a print_board_backwards(Board) function. Ugly ugly. Sounds like we’re repeating code. So, what do we do? We add a layer of indirection. Let’s introduce the Coord type!

typedef struct {
    char row;
    char col;
} Coord;

Now, after coding some utility functions it’s possible to do something like this:

static Board _kings(Board b) {
    _set_new_piece(b, coord_init("e1"), WHITE, KING);
    _set_new_piece(b, coord_init("e8"), BLACK, KING);

Pretty neat, isn’t it? By the way, yesterday I forgot to make static all the internal functions, so I’ve also fixed that. Anyway, how can this representation help us to, say, use only one function to print the board both forwards and backwards? Well, I’ve implemented the following functions.

/*
 * Returns the next coordinate. Useful for traversing the board forwards.
 */
Coord coord_next(Coord);

/*
 * Returns the previous coordinate. Useful for traversing the board backwards.
 */
Coord coord_prev(Coord);

We’ll see how this functions are used in a minute. Meanwhile, we’ll need to add a new parameter to the board printing function: the side or perspective we will use for the board, i.e. if we are the black player or the white player. Let’s use the already defined Color type! Here is the complete implementation.

void print_board(Board b, Color side) {
    Coord c = _next_coord(coord_null(), side);
    char current_row = coord_get_row(c);

    _print_row_separator();
    while (!coord_is_null(c)) {
        // Print row if it's the first column
        if (_first_column(coord_get_col(c), side))
            printf("%c ", current_row);

        // Print the square
        print_square(board_get_square(b, c));

        // Shall we move forward or backwards?
        c = _next_coord(c, side);

        // If the row changed then we must start a new line
        if (coord_get_row(c) != current_row) {
            printf("|\n");
            _print_row_separator();

            current_row = coord_get_row(c);
        }
    }

    _print_columns(side);
}

The magic of the implementation is in the _next_coord(c, side), which allow us to code the printing function without paying too much attention to the side of the board we’re printing. As you may have guessed, its implementation is quite simple.

static Coord _next_coord(Coord c, Color side)  {
        if (side == WHITE)
            return coord_next(c);
        else
            return coord_prev(c);
}

Finally, here is how the chess board will be printed from a white player perspective.

  +---|---|---|---|---|---|---|---+
8 | R | N | B | Q | K | B | N | R |
  +---|---|---|---|---|---|---|---+
7 | P | P | P | P | P | P | P | P |
  +---|---|---|---|---|---|---|---+
6 |   | / |   | / |   | / |   | / |
  +---|---|---|---|---|---|---|---+
5 | / |   | / |   | / |   | / |   |
  +---|---|---|---|---|---|---|---+
4 |   | / |   | / |   | / |   | / |
  +---|---|---|---|---|---|---|---+
3 | / |   | / |   | / |   | / |   |
  +---|---|---|---|---|---|---|---+
2 | p | p | p | p | p | p | p | p |
  +---|---|---|---|---|---|---|---+
1 | r | n | b | q | k | b | n | r |
  +---|---|---|---|---|---|---|---+
    a   b   c   d   e   f   g   h

And here is the black player perspective.

  +---|---|---|---|---|---|---|---+
1 | r | n | b | k | q | b | n | r |
  +---|---|---|---|---|---|---|---+
2 | p | p | p | p | p | p | p | p |
  +---|---|---|---|---|---|---|---+
3 |   | / |   | / |   | / |   | / |
  +---|---|---|---|---|---|---|---+
4 | / |   | / |   | / |   | / |   |
  +---|---|---|---|---|---|---|---+
5 |   | / |   | / |   | / |   | / |
  +---|---|---|---|---|---|---|---+
6 | / |   | / |   | / |   | / |   |
  +---|---|---|---|---|---|---|---+
7 | P | P | P | P | P | P | P | P |
  +---|---|---|---|---|---|---|---+
8 | R | N | B | K | Q | B | N | R |
  +---|---|---|---|---|---|---|---+
    h   g   f   e   d   c   b   a

Stay tuned for the following blog post of the series! I’ll add a user input system so we can start playing real chess. ;-)

Chess and C, day 1

Fri, 27 Mar 2015 00:00:00 +0000

I’ve been programming in Haskell as my main language for almost a year now. Among other things, I love the concept of purity and expressiveness it provides. In fact, I’ve gotten so used to the functional paradigm that I’m having problems when writing code in other languages, as C, which kind of sucks because I’m a teaching assistant of a subject where we use that language.

In order to remove the dust from my C skills I’ve decided to write a small chess game. Nothing fancy, just a program with a small interface to receive user movements and maybe a PGN re-player. As I’m thinking about portability, I’ll avoid the use of non-portable libraries.

As good ol’ Haskell teach us, let’s start by defining some types. We’ll start with the very basics, the pieces. I can’t help thinking about algebraic data types when coding this :-).

typedef enum {WHITE, BLACK} Color;
typedef enum {PAWN, ROCK, KNIGHT, BISHOP, QUEEN, KING} PieceType;

And then a struct to contain these enums.

typedef struct {
    Color color;
    PieceType type;
} Piece;

A Piece will be placed in square, so let’s also define it a type. We can reuse our Color type.

typedef struct {
    Color color;
    Piece* piece;
} Square;

When a Square is empty, it’s piece field will be NULL. I have to admit that when I designed the type I really missed the functional approach of a Maybe data type because it would easily allow me to express an empty square by using Nothing.

Last but no least, we’ll need a type for containing our sixty-four squares. For the moment let’s use this simple type synonym.

typedef Square** Board;

All right, now that we have defined the types, let’s start coding some logic. We’ll start by initializing a Board with its squares and piece positions.

I’ve defined the function Board board_init() which will allocate memory for the board and then call the function Board _initial_setup(Board).

Board _setup_pieces(Board b) {
    return _pawns(_rocks(_knights(_bishops(_queens(_kings(b)))))); // :-)
}

Board _initial_setup(Board b) {
    return _setup_pieces(_setup_colors(b));
}

As you may have guessed, when coding _setup_pieces I used the functional approach of function composition. The smalls functions that set up the pieces just malloc memory for a Piece and set it up in its initial position. For example, here is the function that initialize the pawns.

Board _pawns(Board b) {
    short white_pawns_row = 1, black_pawns_row = 6, i;

    for (i = 0; i < SIZE; i++)
        b[white_pawns_row][i].piece = new_piece(WHITE, PAWN);

    for (i = 0; i < SIZE; i++)
        b[black_pawns_row][i].piece = new_piece(BLACK, PAWN);

    return b;
}

I’m not happy with directly using the matrix indices. I’ll probably make an API for using chess coordinates.

Aside from initializing the board I’m also interested in watching it appear on the screen, so I’ve coded a print_board(Board) function that loops trough the board and calls print_square(Square) which, if the square is not empty, will call print_piece(Piece). This last function will call int piece_character(Piece) to get the piece representation of our choice. I would like to implement something like:

int piece_character(Piece p) {
    switch (p.color) {

    case WHITE:
        switch (p.type) {
        case PAWN:   return '♙';
        case ROCK:   return '♖';

… but I’ve yet to understand how to use UTF-8 characters in a portable way. For the moment I will stay with the following implementation:

    switch (p.type) {

    case PAWN:   res =  'p'; break;
    case ROCK:   res =  'r'; break;
    case KNIGHT: res =  'n'; break;
    case BISHOP: res =  'b'; break;
    case QUEEN:  res =  'q'; break;
    case KING:   res =  'k'; break;
    }

    if (p.color == BLACK)
        return toupper(res);
    
    return res;

Finally, here is the small main() I’ve implemented:

int main() {
    Board b = board_init();
    print_board(b);
    board_delete(b);

    return 0;
}

And here is how the board will be printed on the screen:

➜  chess git:(master) ./main 
+---|---|---|---|---|---|---|---+
| r | n | b | k | q | b | n | r |
+---|---|---|---|---|---|---|---+
| p | p | p | p | p | p | p | p |
+---|---|---|---|---|---|---|---+
|   | / |   | / |   | / |   | / |
+---|---|---|---|---|---|---|---+
| / |   | / |   | / |   | / |   |
+---|---|---|---|---|---|---|---+
|   | / |   | / |   | / |   | / |
+---|---|---|---|---|---|---|---+
| / |   | / |   | / |   | / |   |
+---|---|---|---|---|---|---|---+
| P | P | P | P | P | P | P | P |
+---|---|---|---|---|---|---|---+
| R | N | B | K | Q | B | N | R |
+---|---|---|---|---|---|---|---+

Stay tuned for the following post! I’ll add a coordinate system and user input.

CVE-2013-1436

Fri, 26 Jul 2013 00:00:00 +0000

I’ve just made an advisory about CVE-2013-1436. It was quite interesting to discover and exploit. A patch with a fix is already available. If you use xmonad along with xmobar or dzen, you should patch and re-compile your xmonad binary as soon as posible, or you’ll be exposed to a remote command injection vulnerability.

I would like to thank Joachim Breitner and the Debian Security Team for their help in disclosing this issue.

Controlling nVidia cards fans with nouveau in Debian

Mon, 25 Mar 2013 00:00:00 +0000

Unlike few years ago, current nouevau drivers work like a charm. The only major feature I was missing was the ability to control the fans because by default they’re very noisy, and for me silence is a feature. Fortunately, as Christmas gift one of the last commits of 2012 introduced this functionality.

Yesterday I finally found some time to play with this feature, and here I’ll describe the steps I’ve followed to make it work in Debian. My video card is a GTS 250, but this procedure should also work on similar cards. I’m using sid, but I don’t see why this shouldn’t work in wheezy. Be aware, we’ll have to change the kernel and this may very well introduce bugs in your system.

Anyway, lets begin. The feature to play with nVidia cards fans was merged in the Linux kernel 3.7 or 3.8, I’m not sure, so we’ll have to install one of them in our system. One option to do it is to download and compile the kernel from kernel.org, but an easier way is to install it from the Debian experimental repository, as at the moment of writing this wheezy and sid have Linux kernel version 3.2. In order to do it, add the experimental repository to your sources.list:

# echo "deb http://debian.unlp.edu.ar/debian/ experimental main" >> /etc/apt/sources.list

Our next step is to install the kernel:

# apt-get update && apt-get -t experimental install linux-image-3.8-trunk-amd64

Note that this step will quickly be outdated, as in a few months this kernel version will reach sid.

Before rebooting your system to try your shiny new kernel, you may have to do one extra step. I had to do it with my GTS 250 card in order to make this procedure work. Whenever you load the nouveau module, you have to load it with an extra parameter. I’ve decided to do it from GRUB, but you can choose to do it with modprobe. In order to do it from GRUB, add the nouveau.perflvl_wr=7777 parameter to the variable GRUB_CMDLINE_LINUX_DEFAULT in the /etc/default/grub file. It should look like this:

cat /etc/default/grub | grep nouveau
GRUB_CMDLINE_LINUX_DEFAULT="quiet nouveau.perflvl_wr=7777"

Then we have to tell GRUB to re-generate the menu. As root:

# update-grub2

Go now and reboot your system. You should have the followings files available:

ls /sys/class/drm/card0/device | grep pwm1
pwm1
pwm1_enable
pwm1_max
pwm1_min

pwm1_enable represents the current fan management mode (NONE, MANUAL or AUTO). pwm1 represents the current power percentage of the fan. Ours steps we’ll be to put the fan in MANUAL management mode and then lower the power percentage to something reasonable. Lets try it:

# echo 1 > /sys/class/drm/card0/device/pwm1_enable
# echo 40 > /sys/class/drm/card0/device/pwm1

You should be now enjoying silence. In order to do this automatically whenever your system boots, just add the previous command to /etc/rc.local file.

CVE-2012-0220

Thu, 17 May 2012 00:00:00 +0000

Two days ago I was playing with ikiwiki’s login methods and its templates. After that came the turn of the comments plugin and its input fields. Almost accidentaly, I discovered that the contents of comment’s author input field weren’t correctly sanitized, having as a consequence a stored XSS.

I spent the rest of that day trying to figure out where the bug was. A couple of details slowed my search down for hours:

I didn’t know how ikiwiki’s code was structured
I dislike perl’s syntax

It was 3 AM when I realized my brain wasn’t working properly anymore, and decided to get some sleep. Next day, after spending hours debugging ikiwiki’s code, I finally found out where the bug was.

I contacted Joey Hess (ikiwiki’s creator) and the Debian Security Team in order to disclose the vulnerability. Their work was flawless and fast, and a few hours later the bug was disclosed with CVE ID CVE-2012-0220. An advisory was made with DSA ID DSA-2474.