My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it’s one of the best ways to find volunteers to work with me on projects that matter to me.

Debian LTS

This month I have been paid to work 12 hours on Debian LTS. I did the following tasks:

• CVE triage. I pushed 24 commits to the securitry tracker. I spent more time on this task than usually (see details below).
• I released DLA-143-1 on python-django (fixing 3 CVE). While I expected the update to be quick, my testing revealed that even though the patches applied mostly fine, they did not work as expected. I ended up spending almost 4 hours to properly backport the fixes and the corresponding tests (to ensure that the fixes are working properly).

I want to expand on two cases that I stumbled upon in my CVE triage work and that took quite long to investigate each. While my after-the-fact description is rather straightforward, the real process involved more iterations and data gathering that I do not mention here.

First I was investigating CVE-2012-6685 on libnokogiri-ruby and the upstream bug discussion revealed that libxml2 could also be part of the problem. Using the tests cases submitted there, I confirmed that libxml2 was also affected by an issue of its own… then I started to analyze the history of CVE of libxml2 to find out whether that issue got a CVE assigned: yes, that was CVE-2014-0191 (although the CVE description is unrelated). But this CVE was marked as fixed in all releases. Why? It turns out that the upstream fix for this CVE is just the complement of another commit that was merged way earlier (and that was used as a basis for the commit as the copy/paste of the comment shows). When the security teams integrated the upstream patch in wheezy/squeeze, they were probably not aware that a full fix required to also include something else. In the end, I thus reopened CVE-2014-0191 on our tracker (commit here).

The second problematic case was pound. Thijs Kinkhorst added pound related data on the multiple (high profile) SSL related issues. So it appeared on my radar of new vulnerable package in Squeeze because it was marked that CVE-2009-3555 was fixed in version 2.6-2 while Squeeze has 2.5-1. There was no bug reference in the security tracker and the Debian changelog for that version only mentioned an “anti_beast patch” which is yet another issue (CVE-2011-3389). I had to dig a bit deeper… in the end I discovered that the above patch also has provisions for the CVE that was of interest to me, except that Brian May recently reported in #765649 that the package was still vulnerable to this issue… I tried to understand where the above patch was failing and thus submitted my findings to the bug. And I updated the tracker data with my newly gained knowledge (commit 31751 and 31752).

Tryton

For me, January is always the month where I try to close the accounting books of Freexian. This year is no exception except that it’s the first year where I do this with Tryton. I first upgraded to Tryton 3.4 to have the latest version.

Despite this I discovered multiple problems while doing so… since I don’t want to have those problems next year, I reported them and prepared fixes for those related to the French chart of accounts:

• #4464: CSV export on tree views is unusable
• #4466: add missing deferral properties on accounts
• #4468: drop abusive reconcile properties on some accounts
• #4469: convert account 6354 into a real non-view account
• #4479: balance non-deferral accounts is broken with non-view parent accounts

Saltstack

I mentioned this idea last month… setting up and maintaining a lot of sbuild chroots can be tiresome so I wanted to automate this as much as possible. To achieve this I created three Salt formulas and got them added to the official Saltstack repository:

• debootstrap-formula
• schroot-formula
• sbuild-formula

Each one builds on top of the former. debootstrap-formula creates chroots with debootstrap or cdebootstrap. schroot-formula does the same and registers those chroots in schroot. And sbuild-formula does the same as schroot-formula but with different defaults that are more suited to sbuild chroots (and obviously ensures that sbuild is installed and that generated chroots are buildd chroots).

With the sbuild formula I can put this in pillar data:

sbuild:
  chroots:
    wheezy:
      architectures: [amd64, i386]
      extra_dists:
        - wheezy-backports
        - wheezy-security
      extra_aliases:
        - wheezy-backports
        - stable-security
        - wheezy-security
    jessie:
    [...]

And then a simple salt-call state.highstate (I’m running in standalone mode) will ensure that I have all the chroots properly setup.

Misc packaging

I packaged new upstream releases of Django in experimental and opened a pre-approval request to get the latest 1.7.x in jessie (#775892). It seems to be a difficult sell for the release team, which is a pity because we have active Debian developers, active upstream developers, and everybody is well aware of the no-new features rule to avoid regressions. Where is the risk?

I also filed an unblock request for Dolibarr (on the request of the security team which wants to see the CVE fix reach Jessie). I did small contributions to two bugs that were of special interest to some of my donators (#751339 and #774811), they were not under my responsibility but I tried to get them moving by pinging the relevant people.

I prepared a security upload for Django in Wheezy (python-django_1.4.5-1+deb7u9) and sent it to the security team. While doing this I discovered a small problem in their backported patch that I reported upstream in Django’s ticket #24239.

Debian France

With the new year, it’s again time to organize a general assembly with the election of a third of its board. So we solicited candidacies among the members and I’m pleased to see that we got 6 candidacies for the 3 seats. It’s a good sign that we still have enough persons caring about the association. One of them is even speaking of Debconf 17 in France… great plans!

On my side, I announced that I would not candidate to be president for the next year. I will stay on the board though to ensure we have a smooth transition.

Thanks

See you next month for a new summary of my activities.