What is DKIM? DKIM (DomainKeys Identified Mail), as Wikipedia puts it, "is an email authentication method designed to detect forged sender addresses in emails (email spoofing), a technique often used in phishing and email spam". More prosaically, one of the reasons email spam is so abundant is that, given a certain email message, there is no simple way to know for certain who sent it and how reputable they are. So even if people having addresses @debian.org are very nice and well-behaving, any random spammer can easily send emails from whatever@debian.org, and even if you trust people from @debian.org you cannot easily configure your antispam filter to just accept all emails from @debian.org, because spammers would get in too. Since nearly ten years DKIM is there to help you. If you send an email from @debian.org with DKIM, it will have a header like this: The field d=debian.org is the domain this email claims to be from and the fields bh= and b= are a cryptographic public key signature certifying this fact. How do I check that the email is actually from @debian.org? I use the selector s=vps.gio.user to fetch the public key via DNS, and then use the public key to verify the signature. There it is! Debian declares in its DNS record that that key is authorized to sign outbound email from @debian.org. The spammer hopefully does not have access to Debian's DKIM keys, and they cannot sign emails. Many large and small email services have already deployed DKIM since years, while most @debian.org emails still do not use it. Why not? Because people send @debian.org emails from many different servers. Basically, every DD used their @debian.org address sends email from their own mail server, and those mail servers (fortunately) do not have access to Debian's DNS record to install their DKIM keys. Well, that was true until yesterday! :-) A few weeks ago I poked DSA asking to allow any Debian Developer to install their DKIM keys, so that DDs could use DKIM to sign their emails and hopefully reduce the amount of spam sent from @debian.org. They have done it (thank you DSA very much, especially adsb), and now it is possible to use it! How do I configure it? I will not write here a full DKIM tutorial, there are many around. You have to use opendkim-genkey to generate a key and then configure your mail server to use opendkim to digitally sign outbound email. There are a few Debian-specific things you have to care about, though. First the have to choose a selector, which is a string used to distinguish many DKIM keys belonging to the same domain. Debian allows you to installa a key whose selector is <something>.<uid>.user, where <uid> is your Debian uid (this is done both for namespacing reasons and for exposing who might be abusing the system). So check carefully that your selector has this form. Then you cannot edit directly Debian's DNS record. But you can use the email-LDAP gateway on db.debian.org to install your key in a way similar to how entries in debian.net are handled (see the updated documentation). Specifically, suppose that opendkim-genkey generated the following thing for selector vps.gio.user and domain debian.org: Then you have to carefully copy the content of the p= field (without being fooled by it being split between different strings) and construct a request of the form: and then send it GPG-signed to changes@db.debian.org: Then use host -t TXT vps.gio.user._domainkey.debian.org to chech the key gets published (it will probably take some minutes/hours, I don't know). Once it is published, you can enable DKIM in you mail server and your email will be signed. Congratulations, you will not look like a spammer any more! You can send an email to check-auth@verifier.port25.com to check that your setup is correct. They will reply with a report, including the success of DKIM test. Notice that currently Debian's setup only allows you to use RSA DKIM keys and doesn't allow you to set other DKIM fields (but you probably won't need to set them). EDIT DSA made an official announcement about DKIM support, which you might want to check out as well, together with its links. EDIT 2 Now ed25519 keys are supported, the syntax for specifying keys on LDAP is a little bit more flexible and you can also insert CNAME records. See the official documentation for the updated details. So we have solved our problems with spam? Ha, no! DKIM is only a small step. Useful, also because it enable other steps to be taken in the future, but small. In particular, DKIM enables you to say: "This particular email actually comes from @debian.org", but doesn't tell anybody what to do with emails that are not signed. A third-party mail server might wonder whether @debian.org emails are actually supposed to be signed or not. There is another standard for dealing with that, which is called DMARD, and I believe that Debian should eventually use it, but not now: the problem is that currently virtually no email from @debian.org is signed with DKIM, so if DMARC was enabled other mail servers would start to nuke all @debian.org emails, except those which are already signed, a minority. If people and services sending emails from @debian.org will start configuring DKIM on their servers, which is now possible, it will eventually come a time when DMARC can be enabled, and spammers will find themselves unable to send forged @debian.org emails. We are not there yet, but todays we are a little step closer than yesterday. Also, notice that having DKIM on @debian.org only counters spam pretending to be from @debian.org, but there is much more. The policy on what to accept is mostly independent on that on what you send. However, knowing that @debian.org emails have DKIM and DMARC would mean that we can set our spam filters to be more aggressive in general, but whitelist official Debian Developers and services. And the same can be done for other domains using DKIM and DMARC. Finally, notice that some incompatibilities between DKIM and mailing lists are known, and do not have a definitive answer yet. Basically, most mailing list engines modify either the body of the headers in forwarded emails, which means that DKIM does not validate any more. There are many proposed solutions, possibly none completely satisfying, but since spam is not very satisfying as well, something will have to be worked out. I wrote a lot already, though, so I wont't discuss this here.

The release team receives an extreme amount of unblock requests right now. For the past 22 days[1], we have been receiving no less than 408 unblock/ageing requests. That is an average of ~18.5/day. In the same period, the release team have closed 350 unblocks requests, averaging 15.9/day. This number does not account for number of unblocks, we add without a request, when we happen to spot when we look at the list of RC bugs[2]. Nor does it account for unblock requests currently tagged moreinfo , of which there are currently 25. All in all, it has been 3 intensive weeks for the release team. I am truly proud of my fellow team members for keeping up with this for so long! Also a thanks to the non-RT members, who help us by triaging and reviewing the unblock requests! It is much appreciated. :) Random bonus info:

• d (our diffing tool) finally got colordiff support during the Release Sprint last week. Prior to that, we got black n white diffs!
  • ssh coccia.debian.org -t /srv/release.debian.org/tools/scripts/d <srcpkg>
  • Though coccia.debian.org do not have colordiff installed right now. I have filed a request to have it installed.
• The release team have about 132 (active) unblock hints deployed right now in our hint files.

[1] We started receiving some in the 10 days before the freeze as people realised that their uploads would need an unblock to make it into Jessie. [2] Related topics: what is adsb? (the answer being: Our top hinter for Wheezy)

After thinking a while I thought I should record my weekly FLOSS work and I'm starting by this week. This week I'm on vacation and in home town so I could give bit more time for my FLOSS activity. So here it goes this weeks work Bug Squashing

• Fixed a RC bug filed on Debian-IN team 687176 thanks to the timely patch from Kartik
• Filed an important bug on fonts-taml which was missing a dependency on fonts-samyak-taml and fixed it myself :-) 687806

Both these packages are uploaded to unstable first RC bug was related to Debian Installer hence was unblocked before we could file unblock-request. Kartik filed an unblock-request and adsb unblocked it happily and both the packages landed in unstable. New Packages

• fonts-lohit-taml-classical is a new font for Tamil community developed by Lohit projects I don't know much about font itself but I cleared a wnpp bug with this package 681655
• fonts-teluguvijayam is new package containing 3 Telugu fonts which is released by Department of Information and Technology Andhra Pradesh. This package is pending upload and will clear wnpp bug 669238 and is a pending upload.
• I finally cleared all review comments by jwilk on surf package and now 0.5 version of surf is in experimental.

Both these packages will be backported once Wheezy freezes. One pending wnpp is left on Debian-IN which I've left for Kartik to finish ;-). Font Package Helper I bumped version on dh-make-font[1] to 0.3 now it accepts upstream URL with -u, --upstream switch this will be placed in Homepage: field of control file and in Source: field of copyright file. Probably I need to think of introducing xz compression to original source tarball where upstream is not giving any tarball and probably rewrite it using Perl so it can get included dh-make package. Already a bug filed to get it included in dh-make package 658154. [1] http://anonscm.debian.org/gitweb/?p=debian-in/dh-make-font.git;a=summary Misc and Learnings

• Helped Jonas to fix a minor issue in boxer. I still have to figure out one issue on boxer and add ramfs support to boxer. If you see boxer commit log you can find a few Thanks to Vasudev Kamath but I still didn't commit anything directly which is now in my TODO :-)
• Started learning Perl from Moder Perl book thanks to Jaldhar for pointing this book for me.

Well that is it for this week. Hopefully I will have new stuffs to put up here for the next week, till then Cya.

About 26-28 hours ago in #debian-release on IRC:

<nthykier> damn, a britney run in 5 minutes
<adsb> they happen
<adsb> you've been spoilt by never seeing b1 at her "finest" *cough*
<aba> you mean, running for more than a day?
<Ganneff> adsb wants night-long runs?
<aba> I can remember runs where we had to block certain packages to
      make sure the run could actually end *sometimes*
<adsb> I'm quite happy with just the memory of that sort of run,
       thanks 
<nthykier> I don't mind being spoiled if it stays at 5 minutes 

I took the liberty of collecting the resulting data for the Britney test suite. In its reduced state[1] in runs in 30 seconds on my machine. It is already my favourite live data sample in the test suite. [1] Only i386 and amd64 are considered, manual hints are ignored etc.

If you have been following Lintian s development closely, you will probably have noticed that I have not really done anything there for the past week. Instead I have turned my focus on our testing migration script, britney2. First, I have created a minimal test suite[1]. It started as 4 simple tests and by now it contains about 30 tests. The size of each test is rather small; the largest tests are about 1600 binary packages in total[2], but most are 2-20 binary packages in total. Thus the test suite is rather fast compared to a live data sample , which easily takes more than 10 minutes for a single run. Unfortunately, hand-crafting the test data is somewhat annoying and easy to get wrong. The test suite has a somewhat unfair focus on auto-hint [3] cases, so the current britney2 fails up to 14 tests. Some of these appears to fail because the auto-hinter (for some reason) receives incomplete information about the situation. To my knowledge we not been able to debug the situation, but Adam has a refactor branch that does not seem to have this issue. Personally I am hoping it will soon be merged into the master branch, especially because it seems to simplify a lot of common operations. Joachim Breitner (who has been working on a SAT-solver based britney) also contributed a couple of test cases[4]. Allegedly, SAT-britney does rather well on the test suite, failing only 2 tests as far as I can tell[5]. On the other hand, it does solve a some of the more interesting cases britney2 does not solve. On a more mathematical note, the britney2 implementation behaves like a function[6] with an attractive fixed point[7]. This is interesting, because for some cases it may take britney2 a couple of iterations to reach the right solution. This fixed point is somewhat simple to find by using the following steps (pseudo-code):

// Runtime complexity O(n * br * diff), where "n" is the number of iterations until
// a fixed point is reached, "br" is the complexity of "run_britney" and "diff" is
// the runtime of the "last != current" comparison.
function find_fixed_point(initial);
    last = run_britney(initial)
    current = run_britney(last)
    while last != current ; do
        last = current
        current = run_britney(last)
    od
    return current
end

This gives us a simple way to test if britney will eventually solve the issue herself (and when she will do it). Currently britney2 is automatically run twice a day, so for every 2 iterations (beyond the first) roughly translates to a 24-hours delay. So far the test suite does not have a lot of problems that requires more than one iteration. Personally I would be pleased if it turned out to stay that way as the test suite coverage grows. If you are interested in playing around with this, you can get sources from:

• britney2
  • Currently only works in stable (i.e. requires python2.5 and python-apt < 0.8 or so)
    • There some patches for this filed against release.debian.org.
  • See the INSTALL file for instructions
  • Adam s branch
    • use the p-u branch.
• SAT-britney
  • I haven t tested this one and I do not know the requirements here
• britney-tests
  • See the README file for instructions

Footnotes: [1] http://lists.debian.org/debian-release/2011/10/msg00178.html [2] These tests are auto-generated, so it is merely an up-scaled pattern . [3] Basically if two (or more) packages needs to migrate into testing at the exact same time, they need to be hinted in. [4] Not to mention all the copy-waste errors he pointed out in mine. Apparently, SAT-britney has stricter requirements to the data than britney2. [5] I assume the test called sat-britney-death (created by Joachim) was named that way for a reason. The second failure is caused by SAT britney not reading hints (yet?), so the approve tpu package test case should fail. [6] A function that maps an archive into another archive erh, I mean, it maps a set of packages into another set of packages [7] http://en.wikipedia.org/wiki/Fixed_point_%28mathematics%29 Assuming my claim to be true, the function will have more than one fixed point. The obtained fixed point depends on the initial state of testing. As an example:
y depends on x
x in testing has RC bugs If x is not in testing, it cannot migrate to testing (due to its RC bugs). If x is not in testing, then y cannot migrate into testing. But if x starts in testing, then y may be able to migrate. This can happen if x migrated to testing before an RC bug was filed against it. (Dis-)Proving my claim is an exercise left for the reader.

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now Release manager , a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen. You could expect the release managers to have some rest after a big release, but it s not really the case. With the long freeze, loads of transitions have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions. He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam. Who are you? I m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf. As well as being on the release team, I m a member of the maintainer teams for devscripts and lintian. Can you describe your journey in Debian and in the release team? I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels. When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9. As most readers will be aware, we unfortunately reached a point during last year where we didn t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say How much time do you usually spend working for the release team ? I ve been trying to work out how to usefully answer this question. My initial answer was approximately two hours each day , but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I ve decided to stick with my initial answer. During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I m reliably informed that at that point the correct answer to the question is too much time . What s your own retrospective of the Squeeze release? What went well and what needs to be improved? Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle. One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS s blocking functionality to indicate reasons why a request cannot be fulfilled right now. Are you in favor of time based freeze? I think there s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package. One thing I m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about. What are your plans for Debian Wheezy? The Wheezy to-do list I started before the final Squeeze release begins multiarch, multiarch, multiarch . It looks like we re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so and more transparent. With my package maintenance hats on, I d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian. Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing stable can be accommodated to support this? I m not yet convinced that the concept of a rolling, constantly usable distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The testing distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions. It s been suggested that testing and rolling could be basically the same for most of the cycle, with rolling then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that testing was intended to avoid (i.e. the old frozen suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time. What s the biggest problem of Debian? The thing that I ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves. That s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a do-ocracy then we need to permit people the freedom to do . Is there someone in Debian that you admire for their contributions? All previous release managers, for making the job look much easier than it seems when you re in the hot seat . Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.

---

Thank you to Adam for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

new year, new RC bugs most of the fixes below are for newly reported bugs in versions that don't affect squeeze. the rest are mainly uploads of packages or patches prepared by others.

• #566072 util-linux: "fsck now failing hard for unavailable filesystems"
  prepare a patch based on adsb's analysis. later fixed in maintainer upload
• #605912 runit: "runit: Upgrade failure lenny -> squeeze"
  sponsor NMU prepared by jonathan nieder
• #606370 libcgi-pm-perl: "CVE-2010-2761 CVE-2010-4410 CVE-2010-4411"
  upload package prepared by ntyni to unstable, testing-proposed-updates, and stable (pkg-perl)
• #607556 src:libconfig-model-itself-perl: "libconfig-model-itself-perl: failed tests"
  manual close, new version works again (pkg-perl)
• #609398 src:libfile-userconfig-perl: "libfile-userconfig-perl: Failing tests if home of building user is not available"
  set HOME to a writable directory in debian/rules (pkg-perl)
• #609402 src:libapache2-reload-perl: "libapache2-reload-perl: mkdir in home of building user"
  upload package prepared by periapt (pkg-perl)
• #609464 src:libfile-homedir-perl: "libfile-homedir-perl: Failing tests in t/02_main.t tests"
  set HOME to a writable directory in debian/rules (pkg-perl)
• #609467 src:libpath-dispatcher-declarative-perl: "libpath-dispatcher-declarative-perl: tests fail"
  upload new upstream release (pkg-perl)
• #609468 src:libtk-pod-perl: "libtk-pod-perl: cannot remove path when cwd is /tmp/tkpod_8LQuQjJc for /tmp/tkpod_8LQuQjJc: at /usr/share/perl/5.10/File/Temp.pm line 902"
  set HOME to a writable directory in debian/rules (pkg-perl)
• #609469 src:dh-make-perl: "dh-make-perl: Tries to mkdir directory in home of building user"
  set HOME to a writable directory in debian/rules. in svn, not yet uploaded (pkg-perl)
• #609472 src:libgraphics-gnuplotif-perl: "libgraphics-gnuplotif-perl: Build hangs"
  set HOME to a writable directory in debian/rules (pkg-perl)

(update: yesterday's version was using http://wiki.debian.org/Teams/ReleaseTeam as reference, while http://www.debian.org/intro/organization is the one that's up-to-date. Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!)...and Martin zobel (who's apparently forgotten on the page). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, luk, HE). Hat off, guys (only guys there, yet another place for d-w to show up).

Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, HE). Hat off....