This is my monthly report, published on the mailing list as I haven't
found time to do my personal report on my blog in over a month now...
## Enigmail / GnuPG 2.1 backport
I've spent a significant amount of time working on the Enigmail
backport for a third consecutive month. I first [published](https://email@example.com) a
straightforward backport of GnuPG 2.1 depending on the libraries
available in jessie-backports last month, but then I actually [rebuilt
the dependencies as well]([🔎] firstname.lastname@example.org">https://lists.debian.org/[🔎] email@example.com) and sent a "HEADS UP" to the mailing
list, which finally got peoples' attention.
There are many changes bundled in that possible update: GnuPG actually
depends on about half a dozen other libraries, mostly specific to
GnuPG, but in some cases used by third party software as well. The
most problematic one is [[!debpkg libgcrypt20]] which Emilio Pozuelo
Monfort [said]([🔎] firstname.lastname@example.org">https://lists.debian.org/[🔎] email@example.com) included tens of thousands of lines of change. So
even though I tested the change against cryptsetup, gpgme, libotr,
mutt and Enigmail itself, there are concerns that other dependencies
that merit more testing as well.
This caused many to raise the idea of aborting the work and simply
marking Enigmail as unsupported in jessie. But Daniel Kahn Gillmor
[suggested]([🔎] firstname.lastname@example.org">https://lists.debian.org/[🔎] email@example.com) this should also imply removing Thunderbird itself from
jessie, as simply removing Enigmail will force people to use the
binaries from Mozilla's add-ons service. Gillmor [explained]([🔎] firstname.lastname@example.org">https://lists.debian.org/[🔎] email@example.com) those
builds include a OpenPGP.js implementation of dubious origin, which is
especially problematic considering it deals with sensitive private key
It's unclear which way this will go next. I'm taking a break of this
issue and hope others will be able to test the packges. If we keep on
working on Enigmail, the next step will be to re-enable the `dbg`
packages that were removed in the stretch updates, use dh-autoreconf
correctly, remove some `mingw` pacakges I forgot and [test gcrypt like
crazy]([🔎] firstname.lastname@example.org">https://lists.debian.org/[🔎] email@example.com) ([especially the 1.7 update]([🔎] 20181220130018.GA5213@argenau.bebt.de">https://lists.debian.org/[🔎] 20181220130018.GA5213@argenau.bebt.de)). We'd also update to the
latest Enigmail, as it fixes issues that forced the Tails project to
[disable autocrypt](https://redmine.tails.boum.org/code/issues/16186) because of [weird interactions](https://redmine.tails.boum.org/code/issues/15923) that make it
send cleartext (instead of encrypted) mail in some cases.
## Automatic unclaimer
My [previous report] yielded an [interesting discussion](https://lists.debian.org/debian-lts/2018/11/msg00097.html) around
my work on the security tracker, specifically the "automatic
unclaimer" designed to unassign issues that are idle for too
long. Holger Levsen, with his new coordinator hat, tested the program
and found many bugs and missing features, which I was happy to
implement. After many patches and back and forth, it seems the program
is working well, although it's ran by hand by the coordinator.
[previous report]: https://lists.debian.org/debian-lts/2018/11/msg00090.html
## DLA website publication
I took a look at various issues surrounding the publication of LTS
advisories on the main debian.org website. While normal security
advisories are regularly published on [debian.org/security](https://www.debian.org/security/) [about
500+ DLAs are missing from the website](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859122), mainly because [DLAs are
not automatically imported](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123).
As it turns out, there is a script called `parse-dla.pl` that is
designed to handle those entries but for some reason, they are not
imported anymore. So I got to work to import the backlog and make sure
new entries are properly imported.
[Various fixes for parse-dla.pl](https://salsa.debian.org/webmaster-team/webwml/merge_requests/43) were necessary to properly parse
messages both from the templates generated by `gen-DLA` and the
existing archives correctly. then I tested the result with two
existing advisories, which resulted in two MR on the webml repo: [add
data for DLA-1561](https://salsa.debian.org/webmaster-team/webwml/merge_requests/41) and [add dla-1580 advisory](https://salsa.debian.org/webmaster-team/webwml/merge_requests/42). I requested and
was granted access to the repo, and eventually merged my own MRs after
a review from Levsen.
I eventually used the following procedure to test importing the entire
rsync -vPa master.debian.org:/home/debian/lists/debian-lts-announce .
xz -d \*.xz
cat \* > ../giant.mbox
mbox2maildir ../giant.mbox debian-lts-announce.d
for mail in debian-lts-announce.d/cur/\*; do
This lead to 82 errors on an empty directory, which is not bad at all
considering the amount of data processed. Of course, there many more
errors in the live directory as many advisories were already
present. In the live directory, this resulted in [2431 new advisories
added to the website](https://salsa.debian.org/webmaster-team/webwml/merge_requests/47).
There were a few corner cases:
* The [first month or so](https://lists.debian.org/debian-lts-announce/2014/06/) didn't use DLA identifiers and many of
those were not correctly imported even back then.
* DLA-574-1 was a duplicate, [covered by the DLA-574-2 regression
update](https://firstname.lastname@example.org). But I only found the Imagemagick advisory - it looks
like the qemu one was never published.
* Similarly, the [graphite2 regression](https://email@example.com) was never assigned a real
* Other cases include for example DLA-787-1 which was sent twice and
the [DLA-1263-1 duplicate](https://lists.debian.org/20180129183752.GA13672@bogon.m.sigxcpu.org), which was irrecuperable as it was
never added to `data/DLA/list`
Those special cases will all need to be handled by an eventual
automation of this process, which I still haven't quite figured
out. Maybe a process similar to the unclaimer will be followed: the
coordinator or me could add missing DLAs until we streamline the
process, as it seems unlikely we will want to add more friction to the
DLA release by forcing workers to send merge requests to the web team,
as that will only put more pressure on the web team...
There are also [nine advisories missing from the mailing list
archive](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913426) because of a problem with the mailing list server at that
time. We'll need to extract those from people's email archives, which
I am not sure how to coordinate at this point.
## PHP CVE identifier confusion
I have investigated [[!debcve CVE-2018-19518]], mistakenly identified
as [[!debcve CVE-2018-19158]] in various places, including [upstream's
bugtracker](https://bugs.php.net/bug.php?id=77153). I requested the latter erroneous CVE-2018-19158 to be
retired to avoid any future confusion. Unfortunately, Mitre indicated
the CVE was already in "active use for pre-disclosure vulnerability
coordination", which made it impossible to correct the error at that
I've instead asked upstream to correct the metadata in their tracker
but it seems nothing has changed there yet.
The lazy man does not stand in the way of progress. When he sees
progress roaring down upon him he steps nimbly out of the way
- Christopher Morley, "On Laziness"