December 16, 2014

Editing Debian online with

How cool would it be to fix that one bug you just found without having to download a source package? and without leaving your browser?

Inspired by github's online code editing, during Debconf 14 I worked on integrating an online editor on debsources (the software behind Long story short: it is available today, for users of chromium (or anything supporting chrome extensions).

After installing the editor for extension, go straight to and enjoy!

Go from simple debsources:

To debsources on steroids:

All in all, it brings:
  • Online editing of all of Debian
  • In-browser patch generation, available for download
  • Downloading the modified file
  • Sending the patch to the BTS
  • Syntax highlighting for over 120 file formats!
  • More hidden gems from Ace editor that can be integrated thanks to patches from you

Clone it or fork it:
git clone

For example, head to apt's source code, find a typo and correct it online: open, click on edit, make the changes, click on email patch. Yes! it can generate a mail template for sending the patch to the BTS: just add a nice message and your patch is ready to be sent.

Didn't find any typo to fix? how sad, head to codesearch and search Debian for a spelling mistake, click on any result, edit, correct, email! you will have contributed to Debian in less than 5 minutes without leaving your browser.

The editor was meant to be integrated into debsources itself, without the need of a browser extension. This is expected to be done when the requirements imposed by debsources maintainers are sorted out.

Kudos to Harlan Lieberman who helped debug some performance issues in the early implementations of the integration and for working on the packaging of the Ace editor.

April 01, 2014

Rant: no more squeeze LTS

Following my blog post about Long Term Support for Debian squeeze, the news was picked up by Slashdot, Reddit (again), Barrapunto, Twitter, and Phoronix (in spite of their skepticism).

Over 300 persons, some representing their companies, contacted the security team since the news about the LTS came out - it all seemed like things were finally rrolling.

However, a few days before the coordination mailing list was setup, a not-so-friendly mail was received from a legal officer of a company that produces a RPM derivative with Long Term Support and paid support contracts. The company-that-can't-be-named from here on, due to trademark abuse.

Long story short: the Debian Squeeze LTS project has been boycotted and threatened. Unfair competition (antitrust law) has been brought up against the project, among other threats.

So, great move company-that-can't-be-named, you got it - there won't be LTS, it's been decided and the interested parties have been notified. Perhaps you want to take over the actual development?

March 18, 2014

Debian squeeze LTS

As announced in the "Bits from the Security Team" (LWN copy) email a couple of weeks ago, it is possible that Debian squeeze will have Long Term Support, primarily in the way of security updates.

The news have made it to Softpedia and reddit and even though it has not been announced how long it would be supported, what use cases are planned, etc., the answer I can give is that it depends solely on people contributing to it.

I'd like to add that no, the LTS announcement is not related to the use of Debian on the ISS laptops, as mentioned in reddit - at least not that we are aware of. And to avoid possible confusion from the Softpedia article, the plan is LTS for the squeeze release.

From the emails we have received in response to the announcement, I do wonder however where are the people who expressed interest and signs of engagement last time there was a discussion about providing LTS for Debian.

Perhaps it wasn't stressed enough in the email, but those who are interested in benefiting from (and therefore contributing to) long term support, please do contact the security team NOW.

After all, the clock keeps ticking and Debian squeeze is going to reach its End of Life in less than two months otherwise.

November 13, 2013

A bashism a week: heredocs

One great feature of POSIX shells is the so-called heredoc. They are even available in languages such as Perl, PHP, and Ruby.

So where is the bashism?

It's in the implementation. What odd thing do you see below?

$ strace -fqe open bash -c 'cat <<EOF
EOF' 2>&1 | grep -v /lib
open("/etc/", O_RDONLY|O_CLOEXEC) = 3
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
[pid 6696] open("/tmp/sh-thd-1384296303", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3
[pid 6696] open("/tmp/sh-thd-1384296303", O_RDONLY|O_LARGEFILE) = 4
[pid 6696] open("/etc/", O_RDONLY|O_CLOEXEC) = 3
--- SIGCHLD (Child exited) @ 0 (0) ---

Yes, it uses temporary files!

So do ksh, pdksh, mksh, posh and possible other shells. Busybox's sh and dash do not use temporary files, though:

$ strace -fqe open dash -c 'cat <<EOF
EOF' 2>&1 | grep -v /lib
open("/etc/", O_RDONLY|O_CLOEXEC) = 3
[pid 6767] open("/etc/", O_RDONLY|O_CLOEXEC) = 3
--- SIGCHLD (Child exited) @ 0 (0) ---

Next time you want data to never hit a hard disk, beware that heredocuments and herestrings are best avoided.

October 09, 2013

A bashism a week: maths

You've probably already done some basic maths in shell scripts, but do you know what else you can actually do?

Pick at least 4 operations that you can do in bashisms-free shell scripts:


The POSIX:2001 standard defines the arithmetic expansion requirements, which leads us to selecting all of the above operations except two:


"--" and "++" are not required to be implemented, and in some cases they may lead to unexpected results, such as the following:

$ bash -c 'n=1; echo $((++n))'
$ dash -c 'n=1; echo $((++n))'

Remember, if you rely on any non-standard behaviour or feature make sure you document it and, if feasible, check for it at run-time.

October 08, 2013

Faster, more stable and new opportunities

A new version of the code behind was deployed a few days ago. It has proved to be far more stable, faster, and scalable compared to the previous mod_perl-based deployment.

There were a couple of glitches during the earlier roll-out for IPv6 users, fixed thanks to the reports by Cyril Brulebois, Michael Stapelberg and Robert Drake.

What's behind?
The redirector is now a plack application (with no middlewere) running under the Starman server with an apache fronted. Requests are processed faster than before and there mod_perl-induced system overload is finally gone.

The redirector is now easier to test and develop. Deploying the live instance is not yet fully streamlined, but it has seen a lot of improvement. Some important changes to the way the redirector works are already on their way to see the light and I am going to be announcing them when they do. Fork the repository and hack a few changes, contributions are welcome :)

It's probably time to move it under, and finish making it the default everywhere. It's even made its way into the installation manual.

October 02, 2013

A bashism a week: dangerous exports

As a user of a shell you have most likely had the need to export a variable to another process; i.e. set/modify an environment variable.

Now, how do you stop exporting an environment variable? can you export anything else?

The bash shell offers the -n option of the export built-in, claiming it "remove[s] the export property". However, this feature is not part of the POSIX:2001 standard and is, therefore, a bashism.

A portable way to stop exporting an environment variable is to unset it. E.g. the effect of "export MY_VAR=foo" can be reverted by calling "unset MY_VAR" - surely enough, this will also destroy the content of the variable.

An equivalent could then be:

# to stop exporting/"unexport" the MY_VAR environment variable:
my_var="$MY_VAR" ; unset MY_VAR ;
MY_VAR="$my_var" ; unset my_var ;

The above code will make a copy of the variable before destroying it and then restoring its content.

How about exporting other things? did you know that you can export shell functions?

With the bash shell, you can export a function with the -f parameter of the export built-in. Needless to say, this is a bashism. Its secret? it's just an environment variable with the name of the function and the rest of the function definition as its value.

Try this:

$ echo="() { /bin/echo 'have some bash' ; }" bash -c 'echo "Hello World!"'
have some bash

Yes, this means that if you can control the content of an environment variable passed to bash you can probably execute whatever code you want. It comes handy when you want to alter a script's behaviour without modifying the script itself.

Possibilities are endless thanks to bash's support for non-standard characters in function names. Functions with slashes can also be exported, for example:

/sbin/ifconfig() {
echo "some people say you should be using ip(1) instead" ;

Are you into bug hunting? export exec='() { echo mount this ; }'