Re: monthly report
[Ugh. Sorry about that last email, the markup was terrible - I
copy-pasted from Emacs' markdown mode which ellipsises links... Here's a
better formatted one.]
## 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][] 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][] and sent a "HEADS UP" to the mailing list,
which finally got peoples' attention.
[rebuilt the dependencies as well]: [🔎] 87zht94219.fsf@curie.anarc.at">https://lists.debian.org/[🔎] 87zht94219.fsf@curie.anarc.at
[published]: https://lists.debian.org/87r2fqnja0.fsf@curie.anarc.at
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 [libgcrypt20][] which Emilio Pozuelo
Monfort [said][] 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.
[libgcrypt20]: https://tracker.debian.org/libgcrypt20
[said]: [🔎] 6a8835ce-f54d-faa6-2689-aeb91b1b60fa@debian.org">https://lists.debian.org/[🔎] 6a8835ce-f54d-faa6-2689-aeb91b1b60fa@debian.org
This caused many to raise the idea of aborting the work and simply
marking Enigmail as unsupported in jessie. But Daniel Kahn Gillmor
[suggested][] 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][] those
builds include a OpenPGP.js implementation of dubious origin, which is
especially problematic considering it deals with sensitive private key
material.
[explained]: [🔎] 878t0mzlv2.fsf@fifthhorseman.net">https://lists.debian.org/[🔎] 878t0mzlv2.fsf@fifthhorseman.net
[suggested]: [🔎] 87pntxxg6h.fsf@fifthhorseman.net">https://lists.debian.org/[🔎] 87pntxxg6h.fsf@fifthhorseman.net
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][] ([especially the 1.7 update][]). We'd also update to the
latest Enigmail, as it fixes issues that forced the Tails project to
[disable autocrypt][] because of [weird interactions][] that make it
send cleartext (instead of encrypted) mail in some cases.
[weird interactions]: https://redmine.tails.boum.org/code/issues/15923
[disable autocrypt]: https://redmine.tails.boum.org/code/issues/16186
[especially the 1.7 update]: [🔎] 20181220130018.GA5213@argenau.bebt.de">https://lists.debian.org/[🔎] 20181220130018.GA5213@argenau.bebt.de
[test gcrypt like crazy]: [🔎] 1c1ca626-de3c-1f72-3c95-e280c1bdf1d7@debian.org">https://lists.debian.org/[🔎] 1c1ca626-de3c-1f72-3c95-e280c1bdf1d7@debian.org
## Automatic unclaimer
My [previous report][] yielded an [interesting discussion][] 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.
[interesting discussion]: https://lists.debian.org/debian-lts/2018/11/msg00097.html
[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][] [about
500+ DLAs are missing from the website][], mainly because [DLAs are
not automatically imported][].
[DLAs are not automatically imported]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123
[about 500+ DLAs are missing from the website]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859122
[debian.org/security]: https://www.debian.org/security/
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][] 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][] and [add dla-1580 advisory][]. I requested and
was granted access to the repo, and eventually merged my own MRs after
a review from Levsen.
[add dla-1580 advisory]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/42
[add data for DLA-1561]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/41
[Various fixes for parse-dla.pl]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/43
I eventually used the following procedure to test importing the entire
archive:
rsync -vPa master.debian.org:/home/debian/lists/debian-lts-announce .
cd 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
~/src/security-tracker/./parse-dla.pl $mail;
done
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][].
[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][] 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][]. But I only found the Imagemagick advisory - it looks
like the qemu one was never published.
* Similarly, the [graphite2 regression][] was never assigned a real
identifier.
* Other cases include for example DLA-787-1 which was sent twice and
the [DLA-1263-1 duplicate][], which was irrecuperable as it was
never added to `data/DLA/list`
[first month or so]: https://lists.debian.org/debian-lts-announce/2014/06/
[covered by the DLA-574-2 regression update]: https://lists.debian.org/20170328203550.xsqxsbmbut5qg7gy@curie.anarc.at
[graphite2 regression]: https://lists.debian.org/7aadd04c-c561-ca25-4472-4f52719036ae@balintreczey.hu
[DLA-1263-1 duplicate]: https://lists.debian.org/20180129183752.GA13672@bogon.m.sigxcpu.org
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][] 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.
[nine advisories missing from the mailing list archive]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913426
## PHP CVE identifier confusion
I have investigated [CVE-2018-19518][], mistakenly identified
as [CVE-2018-19158][] in various places, including [upstream's
bugtracker][]. 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
level.
[CVE-2018-19158]: https://security-tracker.debian.org/CVE-2018-19158
[CVE-2018-19518]: https://security-tracker.debian.org/CVE-2018-19518
[upstream's bugtracker]: https://bugs.php.net/bug.php?id=77153
I've instead asked upstream to correct the metadata in their tracker
but it seems nothing has changed there yet.
--
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty.
Beauty is not love. Love is not music.
Music is the best. - Frank Zappa
Reply to: