dkg's New OpenPGP certificate in December 2023 In December of 2023, I'm moving to a new OpenPGP certificate. You might know my old OpenPGP certificate, which had an fingerprint of C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA. My new OpenPGP certificate has a fingerprint of: D477040C70C2156A5C298549BB7E9101495E6BF7. Both certificates have the same set of User IDs:

• Daniel Kahn Gillmor
• <dkg@debian.org>
• <dkg@fifthhorseman.net>

You can find a version of this transition statement signed by both the old and new certificates at: https://dkg.fifthhorseman.net/2023-dkg-openpgp-transition.txt The new OpenPGP certificate is:

-----BEGIN PGP PUBLIC KEY BLOCK-----
xjMEZXEJyxYJKwYBBAHaRw8BAQdA5BpbW0bpl5qCng/RiqwhQINrplDMSS5JsO/Y
O+5Zi7HCwAsEHxYKAH0FgmVxCcsDCwkHCRC7fpEBSV5r90cUAAAAAAAeACBzYWx0
QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmfUAgfN9tyTSxpxhmHA1r63GiI4v6NQ
mrrWVLOBRJYuhQMVCggCmwECHgEWIQTUdwQMcMIValwphUm7fpEBSV5r9wAAmaEA
/3MvYJMxQdLhIG4UDNMVd2bsovwdcTrReJhLYyFulBrwAQD/j/RS+AXQIVtkcO9b
l6zZTAO9x6yfkOZbv0g3eNyrAs0QPGRrZ0BkZWJpYW4ub3JnPsLACwQTFgoAfQWC
ZXEJywMLCQcJELt+kQFJXmv3RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVv
aWEtcGdwLm9yZ4l+Z3i19Uwjw3CfTNFCDjRsoufMoPOM7vM8HoOEdn/vAxUKCAKb
AQIeARYhBNR3BAxwwhVqXCmFSbt+kQFJXmv3AAALZQEAhJsgouepQVV98BHUH6Sv
WvcKrb8dQEZOvHFbZQQPNWgA/A/DHkjYKnUkCg8Zc+FonqOS/35sHhNA8CwqSQFr
tN4KzRc8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PsLACgQTFgoAfQWCZXEJywMLCQcJ
ELt+kQFJXmv3RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9y
ZxLvwkgnslsAuo+IoSa9rv8+nXpbBdab2Ft7n4H9S+d/AxUKCAKbAQIeARYhBNR3
BAxwwhVqXCmFSbt+kQFJXmv3AAAtFgD4wqcUfQl7nGLQOcAEHhx8V0Bg8v9ov8Gs
Y1ei1BEFwAD/cxmxmDSO0/tA+x4pd5yIvzgfGYHSTxKS0Ww3hzjuZA7NE0Rhbmll
bCBLYWhuIEdpbGxtb3LCwA4EExYKAIAFgmVxCcsDCwkHCRC7fpEBSV5r90cUAAAA
AAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmd7X4TgiINwnzh4jar0
Pf/b5hgxFPngCFxJSmtr/f0YiQMVCggCmQECmwECHgEWIQTUdwQMcMIValwphUm7
fpEBSV5r9wAAMuwBAPtMonKbhGOhOy+8miAb/knJ1cIPBjLupJbjM+NUE1WyAQD1
nyGW+XwwMrprMwc320mdJH9B0jdokJZBiN7++0NoBM4zBGVxCcsWCSsGAQQB2kcP
AQEHQI19uRatkPSFBXh8usgciEDwZxTnnRZYrhIgiFMybBDQwsC/BBgWCgExBYJl
cQnLCRC7fpEBSV5r90cUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBn
cC5vcmfCopazDnq6hZUsgVyztl5wmDCmxI169YLNu+IpDzJEtQKbAr6gBBkWCgBv
BYJlcQnLCRB3LRYeNc1LgUcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lh
LXBncC5vcmcQglI7G7DbL9QmaDkzcEuk3QliM4NmleIRUW7VvIBHMxYhBHS8BMQ9
hghL6GcsBnctFh41zUuBAACwfwEAqDULksr8PulKRcIP6N9NI/4KoznyIcuOHi8q
Gk4qxMkBAIeV20SPEnWSw9MWAb0eKEcfupzr/C+8vDvsRMynCWsDFiEE1HcEDHDC
FWpcKYVJu36RAUlea/cAAFD1AP0YsE3Eeig1tkWaeyrvvMf5Kl1tt2LekTNWDnB+
FUG9SgD+Ka8vfPR8wuV8D3y5Y9Qq9xGO+QkEBCW0U1qNypg65QHOOARlcQnLEgor
BgEEAZdVAQUBAQdAWTLEa0WmnhUmDBdWXX0ZlYAa4g1CK/fXg0NPOQSteA4DAQgH
wsAABBgWCgByBYJlcQnLCRC7fpEBSV5r90cUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmexrMBZe0QdQ+ZJOZxFkAiwCw2I7yTSF2Ox9GVFWKmA
mAKbDBYhBNR3BAxwwhVqXCmFSbt+kQFJXmv3AABcJQD/f4ltpSvLBOBEh/C2dIYa
dgSuqkCqq0B4WOhFRkWJZlcA/AxqLWG4o8UrrmwrmM42FhgxKtEXwCSHE00u8wR4
Up8G
=9Yc8
-----END PGP PUBLIC KEY BLOCK-----

When I have some reasonable number of certifications, i'll update the certificate associated with my e-mail addresses on https://keys.openpgp.org, in DANE, and in WKD. Until then, those lookups should continue to provide the old certificate.

This year I attended Debian Reunion Hamburg (aka MiniDebConf Germany) for the second time. My goal for this MiniDebConf was just to talk to people and make the most of the time I have there. No other specific plans or goals. Despite this simple goal, it was a very productive and successful event for me. Tuesday 23rd:

• Arrived much later than planned after about 18h of travel, went to bed early.

Wednesday 24th:

• Was in a discussion about individual package maintainership.
• Was in a discussion about the nature of Technical Committee.
• Co-signed a copy of The Debian System book along with the other DDs

• Submitted a BoF request for people who are present to bring issues to the attention of the DPL (and to others who are around).
• Noticed I still had a blog entry draft about this event last year, and posted it just to get it done.
• Had a stand-up meeting, was nice to see what everyone was working on.
• Had some event budgeting discussions with Holger.
• Worked a bit on a talk I haven t submitted yet called Current events (it s slightly punny, get it?) it s still very raw but I m passively working on it just in case we need a backup talk over the weekend.
• Had a discussion over lunch with someone who runs their HPC on Debian and learned about Octopus and Pac.
• TIL (from #debian-python) about pyproject.toml (https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/)
• Was in a discussion about amd64 build times on our buildds and referred them to DSA. I also e-mailed DSA to ask them if there s anything we can do to improve build times (since it affects both productivity and motivation).
• Did some premium cola tasting with andrewsh
• Had a discussion with Ilu about installers (and luks2 issues in Calamares), accessibility and organisational stuff.

Thursday 25th:

• Spent quite a chunk of the morning in a usrmerge BoF. I m very impressed by the amount of reading and research the people in the BoF did and gathering all the facts/data, it seems that there is now a way forward that will fix usrmerge in Debian in a way that could work for everyone, an extensive summary/proposal will be posted to debian-devel as soon as possible.
• Mind was in zombie mode. So I did something easy and upgraded the host running this blog and a few other hosts to bookworm to see what would break.
• Cheese and wine party, which resulted in a mao party that ran waaaay too late.

Friday 26th:

• Daytrip
• Was very saddened to learn that the Metallica concert in Hamburg that day was not a daytrip option.
• The Museum der Arbeit had lots of interesting machinery and history, there s also a giant drill bit outside it that was used to create the elb tunnels in Hamburg, we had a really nice dinner at a restaurant named after it.

Saturday 27th:

• Attended talks:
  • HTTP all the things The rocky path from the basement into the cloud
  • Running Debian on a Smartphone
  • debvm Ephemeral Virtual Debian Machines
  • Network Configuration on Debian Systems
  • Discussing changes to the Debian key package definition
  • Meet the Release Team
  • Towards collective decision-making and maintenance in the Debian base system
• Performed some PGP key signing.
• Edited group photo.

Sunday 28th:

• Had a BoF where we had an open discussion about things on our collective minds (Debian Therapy Session).
• Had a session on upcoming legislature in the EU (like CRA).
• Some web statistics with MrFai.
• Talked to Marc Haber about a DebConf bid for Heidelberg for DebConf 25.
• Closing session.

Monday 29th:

• Started the morning with Helmut and Jochen convincing me switch from cowbuilder to sbuild (I m tentatively sold, the huge new plus is that you don t need schroot anymore, which trashed two of my systems in the past and effectively made sbuild a no-go for me until now).
• Dealt with more laptop hardware failures, removing a stick of RAM seems to have solved that for now!

• Dealt with some delegation issues for release team and publicity team.
• Attended my last stand-up meeting.
• Wrapped things up, blogged about the event. Probably forgot to list dozens of things in this blog entry. It is fine.

Tuesday 30th:

• Didn t attend the last day, basically a travel day for me.

Thank you to Holger for organising this event yet again!

The Debian project is looking at possibly making automatic minor upgrades to installed packages the default for newly installed systems. While Debian has a reliable and stable package update system that has been an inspiration for multiple operating systems (the venerable APT), upgrades are, usually, a manual process on Debian for most users. The proposal was brought up during the Debian Cloud sprint in November by longtime Debian Developer Steve McIntyre. The rationale was to make sure that users installing Debian in the cloud have a "secure" experience by default, by installing and configuring the unattended-upgrades package within the images. The unattended-upgrades package contains a Python program that automatically performs any pending upgrade and is designed to run unattended. It is roughly the equivalent of doing apt-get update; apt-get upgrade in a cron job, but has special code to handle error conditions, warn about reboots, and selectively upgrade packages. The package was originally written for Ubuntu by Michael Vogt, a longtime Debian developer and Canonical employee. Since there was a concern that Debian cloud images would be different from normal Debian installs, McIntyre suggested installing unattended-upgrades by default on all Debian installs, so that people have a consistent experience inside and outside of the cloud. The discussion that followed was interesting as it brought up key issues one would have when deploying automated upgrade tools, outlining both the benefits and downsides to such systems.

Problems with automated upgrades An issue raised in the following discussion is that automated upgrades may create unscheduled downtime for critical services. For example, certain sites may not be willing to tolerate a master MySQL server rebooting in conditions not controlled by the administrators. The consensus seems to be that experienced administrators will be able to solve this issue on their own, or are already doing so. For example, Noah Meyerhans, a Debian developer, argued that "any reasonably well managed production host is going to be driven by some kind of configuration management system" where competent administrators can override the defaults. Debian, for example, provides the policy-rc.d mechanism to disable service restarts on certain packages out of the box. unattended-upgrades also features a way to disable upgrades on specific packages that administrators would consider too sensitive to restart automatically and will want to schedule during maintenance windows. Reboots were another issue discussed: how and when to deploy kernel upgrades? Automating kernel upgrades may mean data loss if the reboot happens during a critical operation. On Debian systems, the kernel upgrade mechanisms already provide a /var/run/reboot-required flag file that tools can monitor to notify users of the required reboot. For example, some desktop environments will popup a warning prompting users to reboot when the file exists. Debian doesn't currently feature an equivalent warning for command-line operation: Vogt suggested that the warning could be shown along with the usual /etc/motd announcement. The ideal solution here, of course, is reboot-less kernel upgrades, which is also known as "live patching" the kernel. Unfortunately, this area is still in development in the kernel (as was previously discussed here). Canonical deployed the feature for the Ubuntu 16.04 LTS release, but Debian doesn't yet have such capability, since it requires extra infrastructure among other issues. Furthermore, system reboots are only one part of the problem. Currently, upgrading packages only replaces the code and restarts the primary service shipped with a given package. On library upgrades, however, dependent services may not necessarily notice and will keep running with older, possibly vulnerable, libraries. While libc6, in Debian, has special code to restart dependent services, other libraries like libssl do not notify dependent services that they need to restart to benefit from potentially critical security fixes. One solution to this is the needrestart package which inspects all running processes and restarts services as necessary. It also covers interpreted code, specifically Ruby, Python, and Perl. In my experience, however, it can take up to a minute to inspect all processes, which degrades the interactivity of the usually satisfying apt-get install process. Nevertheless, it seems like needrestart is a key component of a properly deployed automated upgrade system.

Benefits of automated upgrades One thing that was less discussed is the actual benefit of automating upgrades. It is merely described as "secure by default" by McIntyre in the proposal, but no one actually expanded on this much. For me, however, it is now obvious that any out-of-date system will be systematically attacked by automated probes and may be taken over to the detriment of the whole internet community, as we are seeing with Internet of Things devices. As Debian Developer Lars Wirzenius said:

The ecosystem-wide security benefits of having Debian systems keep up to date with security updates by default overweigh any inconvenience of having to tweak system configuration on hosts where the automatic updates are problematic.

One could compare automated upgrades with backups: if they are not automated, they do not exist and you will run into trouble without them. (Wirzenius, coincidentally, also works on the Obnam backup software.) Another benefit that may be less obvious is the acceleration of the feedback loop between developers and users: developers like to know quickly when an update creates a regression. Automation does create the risk of a bad update affecting more users, but this issue is already present, to a lesser extent, with manual updates. And the same solution applies: have a staging area for security upgrades, the same way updates to Debian stable are first proposed before shipping a point release. This doesn't have to be limited to stable security updates either: more adventurous users could follow rolling distributions like Debian testing or unstable with unattended upgrades as well, with all the risks and benefits that implies.

Possible non-issues That there was not a backlash against the proposal surprised me: I expected the privacy-sensitive Debian community to react negatively to another "phone home" system as it did with the Django proposal. This, however, is different than a phone home system: it merely leaks package lists and one has to leak that information to get the updated packages. Furthermore, privacy-sensitive administrators can use APT over Tor to fetch packages. In addition, the diversity of the mirror infrastructure makes it difficult for a single entity to profile users. Automated upgrades do imply a culture change, however: administrators approve changes only a posteriori as opposed to deliberately deciding to upgrade parts they chose. I remember a time when I had to maintain proprietary operating systems and was reluctant to enable automated upgrades: such changes could mean degraded functionality or additional spyware. However, this is the free-software world and upgrades generally come with bug fixes and new features, not additional restrictions.

Automating major upgrades? While automating minor upgrades is one part of the solution to the problem of security maintenance, the other is how to deal with major upgrades. Once a release becomes unsupported, security issues may come up and affect older software. While Debian LTS extends releases lifetimes significantly, it merely delays the inevitable major upgrades. In the grand scheme of things, the lifetimes of Linux systems (Debian: 3-5 years, Ubuntu: 1-5 years) versus other operating systems (Solaris: 10-15 years, Windows: 10+ years) is fairly short, which makes major upgrades especially critical. While major upgrades are not currently automated in Debian, they are usually pretty simple: edit sources.list then:

    # apt-get update && apt-get dist-upgrade

But the actual upgrade process is really much more complex. If you run into problems with the above commands, you will quickly learn that you should have followed the release notes, a whopping 20,000-word, ten-section document that outlines all the gory details of the release. This is a real issue for large deployments and for users unfamiliar with the command line. The solutions most administrators seem to use right now is to roll their own automated upgrade process. For example, the Debian.org system administrators have their own process for the "jessie" (8.0) upgrade. I have also written a specification of how major upgrades could be automated that attempts to take into account the wide variety of corner cases that occur during major upgrades, but it is currently at the design stage. Therefore, this problem space is generally unaddressed in Debian: Ubuntu does have a do-release-upgrade command but it is Ubuntu-specific and would need significant changes in order to work in Debian.

Future work Ubuntu currently defaults to "no automation" but, on install, invites users to enable unattended-upgrades or Landscape, a proprietary system-management service from Canonical. According to Vogt, the company supports both projects equally as they differ in scope: unattended-upgrades just upgrades packages while Landscape aims at maintaining thousands of machines and handles user management, release upgrades, statistics, and aggregation. It appears that Debian will enable unattended-upgrades on the images built for the cloud by default. For regular installs, the consensus that has emerged points at the Debian installer prompting users to ask if they want to disable the feature as well. One reason why this was not enabled before is that unattended-upgrades had serious bugs in the past that made it less attractive. For example, it would simply fail to follow security updates, a major bug that was fortunately promptly fixed by the maintainer. In any case, it is important to distribute security and major upgrades on Debian machines in a timely manner. In my long experience in professionally administering Unix server farms, I have found the upgrade work to be a critical but time-consuming part of my work. During that time, I successfully deployed an automated upgrade system all the way back to Debian woody, using the simpler cron-apt. This approach is, unfortunately, a little brittle and non-standard; it doesn't address the need of automating major upgrades, for which I had to revert to tools like cluster-ssh or more specialized configuration management tools like Puppet. I therefore encourage any effort towards improving that process for the whole community. More information about the configuration of unattended-upgrades can be found in the Ubuntu documentation or the Debian wiki.

Note: this article first appeared in the Linux Weekly News.

I have created a new OpenPGP key 54265e8c and will be transitioning away from my old key. If you have signed my old key, I would appreciate signatures on my new key as well. I have created a transition statement that can be downloaded from https://josefsson.org/key-transition-2014-06-22.txt. Below is the signed statement.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
OpenPGP Key Transition Statement for Simon Josefsson
I have created a new OpenPGP key and will be transitioning away from
my old key.  The old key has not been compromised and will continue to
be valid for some time, but I prefer all future correspondence to be
encrypted to the new key, and will be making signatures with the new
key going forward.
I would like this new key to be re-integrated into the web of trust.
This message is signed by both keys to certify the transition.  My new
and old keys are signed by each other.  If you have signed my old key,
I would appreciate signatures on my new key as well, provided that
your signing policy permits that without re-authenticating me.
The old key, which I am transitioning away from, is:
pub   1280R/B565716F 2002-05-05
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
The new key, to which I am transitioning, is:
pub   3744R/54265E8C 2014-06-22
      Key fingerprint = 9AA9 BDB1 1BB1 B99A 2128  5A33 0664 A769 5426 5E8C
The entire key may be downloaded from: https://josefsson.org/54265e8c.txt
To fetch the full new key from a public key server using GnuPG, run:
  gpg --keyserver keys.gnupg.net --recv-key 54265e8c
If you already know my old key, you can now verify that the new key is
signed by the old one:
  gpg --check-sigs 54265e8c
If you are satisfied that you've got the right key, and the User IDs
match what you expect, I would appreciate it if you would sign my key:
  gpg --sign-key 54265e8c
You can upload your signatures to a public keyserver directly:
  gpg --keyserver keys.gnupg.net --send-key 54265e8c
Or email simon@josefsson.org (possibly encrypted) the output from:
  gpg --armor --export 54265e8c
If you'd like any further verification or have any questions about the
transition please contact me directly.
To verify the integrity of this statement:
  wget -q -O- https://josefsson.org/key-transition-2014-06-22.txt gpg --verify
/Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iLwEAQEKAAYFAlOnV+AACgkQ7aIelLVlcW89XgUAljJgYfReyR9/bU+Om6UHUttt
CAOgSRqdcQSQ2hT69vzuhb/bc8CslIQcBtGqTgxDFsxEFhbm5zKn+tSzy5MHNHqt
MsqHcZjlYuYVhMXDhka+cfyhtd9zIxjVE5vk8v+GqEGoh8DGYq0vPy3VfvcSz5Z3
MSUpSj8gN00jlU1z4nad3maEq0ApvsLr8EsLZmtxF5TNFvzJ8mmwY+gHBGHjVYkB
8AQBAQoABgUCU6dX4AAKCRAGZKdpVCZejD1eDp46XGL2puMp0le2OF75WIUW8xqf
TMiZeB99ruk3P/jvuLnGPP2J5o7SIKE50FkMEss0yvxi6jBlHk+cJeKWGXVjBpxU
0QHq063NU+kjbMYwDfi5ZxXqaKeYODJm8Xmfh3d7lRaWF5rUOosR8nC/OROSrhg4
TjlAbvbxpQsls/JPbbporK2gbAtMlzJPD8zC8z/dT+t0qjlce8fADugblVW3bACC
Kl53X4XpojzNd/U19tSXkIBdNY/GVJqci+iruiJ1WGARF9ocnIXVuNXsfyt7UGq4
UiM/AeDVzI76v1QnE8WpsmSXzi2zXe3VahUPhOU2nPDoL53ggiVsTY3TwilvQLfX
Av/74PIaEtCi1g23YeojQlpdYzcWfnE+tUyTSNwPIBzyzHvFAHNg1Pg0KKUALsD9
P7EjrMuz63z2276EBKX8++9GnQQNCNfdHSuX4WGrBx2YgmOOqRdllMKz6pVMZdJO
V+gXbCMx0D5G7v50oB58Mb5NOgIoOnh3IQhJ7LkLwmcdG39yCdpU+92XbAW73elV
kmM8i0wsj5kDUU2ys32Gj2HnsVpbnh3Fvm9fjFJRbbQL/FxNAjzNcHe4cF3g8hTb
YVJJlzhmHGvd7HvXysJJaa0=
=ZaqY
-----END PGP SIGNATURE-----

Hey, Mexican hackers! If anybody is interested in holding a small Free Software-related meeting (say, with up to 10-15 people) in the South of Mexico City, please tell me We have adapted a nice room at our house where we want to invite people to come and do activities Courses, meetings, whatever. It is not very big (~5 5 meters), but it has all of the needed amenities (some chairs, a projector, coffee-related amenities, and is very conveniently located). We are not charging for hosting your activities (but will of course want to schedule it beforehand with you). So, if you have something to teach, or some project to hack on, and want a nice place to do it in, please drop us a line/call. (hmh, yes, this is one of the posts that should probably be in Spanish But this blog has a long-standing policy for English content ;-)

Ok, so following the trend, I created some time ago a new GPG key, which I'm now transitioning too. I've set up a transition document, available at http://molly.corsac.net/~corsac/key-transition.txt. It's signed by both the old and the new keys and is reproduced below:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160,SHA512
Wed, 11 Nov 2009 13:44:05 +0100
I've recently set up a new RSA-based GPG key, and will be transitioning away
from my old DSA-based one.  The old key will be revoked soon, so I prefer all
future correspondence to use the new one.  I would also like to ensure that
this new key is well-integrated into the web of trust.  This message is signed
by both keys to certify the transition.
The old DSA key was:
pub   1024D/C5C05BAE 2004-11-11
      Key fingerprint = DE26 2FC4 7097 FFC6 DE2C  D8C0 4D44 C020 C5C0 5BAE
The new RSA key is:
pub   4096R/71EF0BA8 2009-05-06
      Key fingerprint = 4510 DCB5 7ED4 7040 60C6  6476 3055 0F78 71EF 0BA8
If you already know my old key, you can verify that the new key is
signed by the old one:
  gpg --check-sigs 71EF0BA8
If you don't already know my old key, or if you're extra-paranoid, you
can check the fingerprint against the one given above:
  gpg --fingerprint 71EF0BA8
If you have previously signed my old DSA key, and if you're satisfied
that you've got the correct new RSA key, then I'd appreciate it if you
would sign my new key as well:
  caff 71EF0BA8
The caff program is in the signing-party package in Debian.  Please be careful
to generate signatures that don't rely on the weakening SHA-1 hash algorithm,
which requires some careful configuration even if you've already configured
gpg correctly.  See http://www.gag.com/bdale/blog/posts/Strong_Keys.html for
the gory details.
Thanks,
- --
Yves-Alexis Perez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREDAAYFAkr6sqQACgkQTUTAIMXAW64HiACeIyabQueDHAeiAX8EkIeApiDj
++UAn2z7YkjHx0lQh0+s5WdhikG0YztiiQIcBAEBCgAGBQJK+rKkAAoJEDBVD3hx
7wuodUcQAKMbG9Rehxz+uZ6fST99cHt5Fjnv9TorY4hQaQK+85ZgiwPaHMHfYM1G
5hcrXI+JFUpz8j40deZuaWuspOdHBHwnHNQril8MqT0CJgtB6HFTo+w/7Lmmui5M
DDMMed39UJl7bF73hV9ywGecxPpeh+dtoVnh0VT16uK2xTvW6ICEZgaPw1xfPUHS
+jxQ7I05X1OWQkPpmhxXJqGclDyO+qx4CJZsOxUAvt2LphHxhZxB3QE5OUdudGKQ
AH6KhC4rpNQdJVMX20SG8PybL/AipN3Y8N/63VkoqVC2heRlaQ69HjsuqIAkIyan
hHnqmJH8Q+TDTbdKZvOQv6jcd4o3VSibz0T9MwnOfqQ0uRYyTpaXC0vLUH6lXaC4
eK+VVWbY8vCAFHR3h80Q61i2me2HU5ly7a/W22dz19zzDNNC5q9MO78uIYkUK78N
Z0wzJrmOxRyhvs5DOSOpNVlXZhffNQM1f42xxG8cUDaIf7pR5jK+xqHV7tIBQE1D
CrD0mt+YQCnngK0i4wQTO7VT/vjypf4A9W+VSsoJJpRhBbngU4pHu9JWqO84/7AA
j5FN8ug15MWysaS+FQ/EqzHmT7BGBWaTPv3yGlHKUjx0w4bPEpbH7y3fwHAcmOFf
xFRzvZFQ03zeer06yAqTVNuwr77HZgrCzgyQVgIkegAg6iUPiZcs
=CBT+
-----END PGP SIGNATURE-----

One week ago, I went to a branch office of Servicio de Administraci n Tributaria, the government office in charge of processing taxes. This year, I plan on doing something quite bold, as my Mexican friends will acknowledge: I will prepare my (quite simple, I hope) tax declaration by myself. I do not want to be held hostage of the accountant guild - So I might end doing some fuckup which in the end costs me money or time. I hope it is not the case.
Anyway... Last week I went to this office, as I needed either a CIECF (Clave de Identificaci n Electr nica Confidencial Fortalecida - Strengthened Confidential Electronic Identification Key) or a FIEL (Firma Electr nica Avanzada - Advanced Electronic Signature). No, please don't believe it is a security token, a card with printed numbers, a one-time-pad or the sort - The CIECF is... A password. Why is it strengthened? Because it has the feature of including a question, in case you forget the key, to allow you to change it. I guess the FIEL is a more reliable device, but I prefer not to even request it.
And as far as the questions go, the emergency questions for CIECF suck. First, I was not even asked the meta-question - I was not told why this information was needed. So imagine the clerk saying: Full name? ... Date of birth? ... RFC (Tax ID)? ... Favorite color? I was there just... Stunned. Why do you need it? Oh, just in case you forget your password. Ok... Don't you have any other questions which I am not prone to answer a different thing, and that are not dead obvious for a casual passer-by? (I guess that at least 1/4 of the public will say blue. Feel like brute-forcing SAT to its knees?) Other questions include your fathers' second family name, your favorite soccer team, your pet's name... It seems they took the first "security dos and don'ts" book off the wall, and started reading backwards.
But anyway, that's the system, and I must play nice with it. So I get back home, and decide to start hacking up my declaration. No, Mr. Policeman, I'm not saying I would try to break into the SAT - I just say it is a complex and non-obvious task to do. Now please release me. Thanks.
And I enter the system. Of course, I tried first with Iceweasel, knowing it would fail (it is documented: MSIE 5.5 recommended). I tried again with Konqueror. I tried, sigh, with MSIE from inside Wine. No luck. Well, even from within qemu's Windows 2000. Wrong password. WTF?! Stranger: It worked with SAT's My portal, although it didn't with the declaration, which is what matters now.
I cannot take the time every day to come to the SAT and move my data - It was a full week until I came back again. I insisted on fully logging in to the system, to be sure the password I entered this time was right. As well as my ber-secret safety question, of course.
And it failed.
Twice.
Until the clerk noticed something strange in the way I typed...
Sir, excuse me..., he muttered, why are you typing such a long password? Well, basically because I value my tax declaration, and I know brute force is a powerful force. (explain it, of course, in simple terms) Oh... No, the password must be eight characters long.
No wonder.
So I entered the first eight characters of my password, which was a true work of prose for their standards, at around 20 characters. And it worked.
Now, for bonus points: What do we gather from the fact that the long password works fine in one system, but in another system it only the short version? Why, but of course! I guess the passwords for every economically active Mexican is stored in their master database in plain text. Isn't it just beautiful?
Anyway, it seems I have a lot of work to do. If all goes as planned, maybe next year I will be for hire as a public accountant? Hmh, does not sound too much like fun, does it?

What's the best way to join a community, any community? Little by little.
I have been working with Ruby on Rails for well over a year already, even given a talk (at Encuentro Nacional Linux y Software Libre ENLi) inviting other people to use this very nice and well thought out environment. But, so far, I've been only a end-user, not really giving anything back besides minor bug reports.
Well, it's not as much as to say that I'm now a contributor - this is just a first statement of intent. I have worked a bit on several bits of code I keep repeating and hand-copying over my different Rails projects. Of course, that's completely not DRY - And completely not nice. So I decided to stop advancing on several projects, and learn my way on stting those bits of code as Rails plugins.
So far, it's been quite simple - and a good excercise on proper separation. I started, of course, with the easiest bit of code I could think of as useful in a general sense, and packaged it up as acts_as_catalog (of course, proper SVN tree and very basic, introductory README. And, of course, as I keep progressing with this work, I'll keep adding some plugins to my currently quite empty RubyForge page.
Anyway... Little by little, time will come where we have to think more seriously on how to properly bring together the Ruby on Rails style to work more tightly with Debian. Currently, the two have such different points of view on how to manage and ship components that I am not sure we will be able to truly bridge them together... But it is definitively worth trying. Hmh, looks like a task for Debconf! ;-)

What does this topic mean? Hmh... Maybe you don't know Goran Bregovi , a magical Bosnian musician, one of my all-time favorite artists. I have long loved Eastern European music (but I was mostly familiar with the Klezmer style, linked to Ashkenazi Jews but not necessarily performed by them anymore (i.e. Kroke), but it is thanks to Goran that I got familiar with the Balkan style... What can I say about it? It has an addictive rythm, and it has the folk sound of (even very similar instruments to) the Mexican tambora. It is a must-hear genre, in short. There are many magical Balkan music groups, I cannot just recommend one - But if I could, it would be Goran's :)
Now, why is he sending me northwards? Because Goran Bregovi is coming to Mexico - To the Northern city of Monterrey, some 1000Km north from Mexico City - He will be performing at the Forum Universal de las Culturas Monterrey 2007, on September 22, at the Explanada Plaza 400 a os.
I know already of a couple of friends who are definitively going, who are searching for the best airfare... This will be something to remember!

Hmh... It's hard to get to a decision on this aspect, although I'm mostly sure I'll vote for a "yes". I have read most posts on this subject on debian-vote and on the planet, and I'm still not too much at ease... Anyway, one of the most relevants so far is Joerg's - And not because he is so involved with the NM process, but because he drives me to what I think is a very important point few people have addressed:
For long, we have been saying that you don't have to be a programmer to help Debian - But so far, we have been unable to deliver except for this funny French guy. And although the current proposal still focuses on getting a step closer to DDness, and for many people this seems like geared at reducing the frustration when going over the NM process, my impression is that this will help us implement something similar for other areas.
Some people have complained about implementing decisions per policy instead of doing so gradually. Thing is, I feel, this kind of proposals have been reiterated over the years - and they have always dropped into the silence because some actions need to be taken by the people who are less willing to. Maybe the only way to break the inertia is to take a step by a GR vote. Maybe parts of it will have to be undone or re-done differently if we end up with the wrong results - but we will have broken the status-quo. Maybe, who knows, this will serve as an experiment - and after another long series of long flame threads we will end up in 2010 in the same position are we currently at - but it won't be because of inaction.

Scott complains on how Linux Format #93's articles comparing Ubuntu and other distributions often contradict each other, and blames it on the lack of any editorial direction or basic research.
I... Have to confirm this. But anyway, I can stand a bit on the different writers' side - Each article is written by a different person and, although the magazine must try to be coherent (of course, within certain limits - if the magazine suggests editor's picks in one article, they should not bash them to death in the next one).
I write the Linux column in the Spanish edition of PC Magazine. No, it's by far not a technical column, nor anything far like it. The magazine is end-user oriented, and clearly sponsorship-driven - In fact, my column was not part of the magazine for quite some time, as they gear it towards end-users, and sponsors (I cannot venture which sponsors, but your imagination will probably go to the same company as mine) do not like what I write about. All in all, I get the general topics which each month's edition will cover, and I just have to write an article about one of them. Of course, I don't know most of the other writers. There is no interaction at all.
And I guess that Linux Format is a typical magazine - If they run like PC Magazine, they just won't have the time to put all the articles together checking for inconsistencies. I think it is enough of a task to chase the contributors month after month (BTW, I'm a week late already :-/ But I cannot finish just today, as there's too much work to do, and I spend my time blogging... Hmh, time to finish this post, as coitus interruptus as it may seem).

I'm officially on vacation. That basically means there is nobody at my office. This time, though, it does not mean I will be the only sentient being in the building - I'll take most of the three weeks at home. I hope to be able to do some Debian work and catch up with some other projects... Anyway, part of not being at the office means I don't have my usual dose of coffee. At home, I very seldom drink coffee, although I really love to have it home-style (i.e. not made by the easy-to-massify drip coffee machine). In fact, for at least a month, we had not had any coffee.
Yesterday I bought 1/2 Kg of fresh ground coffee at a nearby store. Right away, I drank two large mugs of coffee. Yummy.
Today, I felt a bit more creative. One of the things that my nutriologist taught me in the last year (wow... it's been over a year I started dieting and excercising daily! Around 40Kg less. Not bad, huh? :D ) is that I was eating too little sugar, and ordered me to get at least two portions of sugar a day. So, I'm having today's second coffee. With kahl a (coffee liquor), which would be forbidden at my workplace. And I'm enjoying it terribly.
Hmh... I do hope I don't get too much sugar during vacations! ;-) (including the family dinners over holidays)

Tuxpaint could be a poster child for l10n. It has translations now for 68 different locales. The large number of locales poses somewhat of a problem for testing¹. Tuxpaint 0.9.16 just released. During the release preparation, the manual testing of all of these locales drove me nearly insane. So to help out next time, I created the following bash script using xautomation², imagemagick and xprop (from xbase-clients):

#!/bin/bash
testname="tuxpaint" 
root_geometry= xprop -root _NET_DESKTOP_GEOMETRY  cut -d= -f2 
root_x= echo $root_geometry  cut -d, -f1 
root_y= echo $root_geometry  cut -d, -f2 
xc=$((root_x/2-1))
yc=$((root_y/2-1))
capture_tuxpaint ()  
   tuxpaint --startblank --nolockfile --lang $1 --640x480 --windowed --nosound &
   sleep 1
   xte "mousemove $xc $yc" 
   xte "mouseclick 1" 
   sleep 1
   xte "key Escape" 
   sleep 2
   import -silent -window "Tux Paint" $testname-$1.png
   xte "mousermove -120 -40" 
   xte "mouseclick 1" 
 
for lang in  tuxpaint --lang help  awk '$1~/^[[:lower:]]/  print $1 ' ; do
   capture_tuxpaint $lang
done

I’m not entirely happy with it, but it’s at least a starting point. Ideally, I’d make .pat files to use with visgrep to find coordinates for the button images instead of hardwiring the approximate button positions. Also, the script needs a companion script to configure the system for testing (i.e. perform the locales configuration and install all fonts). Here are the resulting screenshots which show up a few problems with the translations. It looks like the quit dialog strings have been updated since they were first translated, so now we need retranslation for several languages. Also, there are some languages, like Swahili and Klingon, for which there are no locales in glibc in Debian. I’ll have to talk to the glibc maintainers about that. And for that matter, I don’t even know if a DFSG-free Klingon font exists. In any event, I’m delighted with the results, and look forward to using xautomation more for GUI testing.

¹ For one thing, several languages require special fonts. For another, there is no way to get tuxpaint to tell you what locales it supports. Granted, there is --lang help, but this is a crude approximation, as the mapping between language and locale is arbitrarily hardwired (which hmh on #debian-devel irc pointed out to me is just plain wrong). It doesn’t help me at all in the arduous task of configuring glibc locales so I can test them. For that, I need to look at i18n.c.

² I tried using xmacro at first, but xmacrorec just made my pointer jiggle back and forth. It seemed like it was updating the position for a short distance, and then X was resetting it back to the former position of the pointer. Some strange interaction with my window manager, perhaps? But ultimately I am happier with the xautomation approach anyway.