Debian Long Term Support (LTS)

This is my monthly Debian LTS report. This time I worked on
Mercurial, sudo and Puppet.

Mercurial remote code execution

I issued DLA-1005-1 to resolve problems with the hg server
--stdio command that could be abused by "remote authenticated users to
launch the Python debugger, and consequently execute arbitrary code,
by using --debugger as a repository name" (CVE-2017-9462).

Backporting the patch was already a little tricky because, as is often
the case in our line of work, the code had changed significantly in
newer version. In particular, the commandline dispatcher had been
refactored which made the patch non-trivial to port. On the other
hand, mercurial has an extensive test suite which allowed me to make
those patches in all confidence. I also backported a part of the test
suite to detect certain failures better and to fix the output so that
it matches the backported code. The test suite is slow, however, which
meant slow progress when working on this package.

I also noticed a strange issue with the test suite: all hardlink
operations would fail. Somehow it seems that my new sbuild setup
doesn't support doing hardlinks. I ended up building a tarball schroot
to build those types of packages, as it seems the issue is related to
the use of overlayfs in sbuild. The odd part is my tests of overlayfs,
following those instructions, show that it does support
hardlinks, so there maybe something fishy here that I misunderstand.

This, however, allowed me to get a little more familiar with sbuild
and the schroots. I also took this opportunity to optimize the builds
by installing an apt-cacher-ng proxy to speed up builds, which
will also be useful for regular system updates.

Puppet remote code execution

I have issued DLA-1012-1 to resolve a remote code execution
attack against puppetmaster servers, from authenticated clients. To
quote the advisory: "Versions of Puppet prior to 4.10.1 will
deserialize data off the wire (from the agent to the server, in this
case) with a attacker-specified format. This could be used to force
YAML deserialization in an unsafe manner, which would lead to remote
code execution."

The fix was non-trivial. Normally, this would have involved fixing the
YAML parsing, but this was considered problematic because the ruby
libraries themselves were vulnerable and it wasn't clear we could fix
the problem completely by fixing YAML
parsing. The update I proposed took the bold step of switching
all clients to PSON and simply deny YAML parsing from the server. This
means all clients need to be updated before the server can be updated,
but thankfully, updated clients will run against an older server as
well. Thanks to LeLutin at Koumbit for helping in testing patches
to solve this issue.

Sudo privilege escalation

I have issued DLA-1011-1 to resolve an incomplete fix for a
privilege escalation issue (CVE-2017-1000368 from
CVE-2017-1000367). The backport was not quite trivial as
the code had changed quite a lot since wheezy as well. Whereas
mercurial's code was more complex, it's nice to see that sudo's code
was actually simpler and more straightforward in newer versions, which
is reassuring. I uploaded the packages for testing and uploaded
them a year later.

I also took extra time to share the patch in the Debian
bugtracker, so that people working on the issue in stable may benefit
from the backported patch, if needed. One issue that came up during
that work is that sudo doesn't have a test suite at all, so it is
quite difficult to test changes and make sure they do not break
anything.

Should we upload on fridays?

I brought up a discussion on the mailing list regarding uploads
on fridays. With the sudo and puppet uploads pending, it felt really
... daring to upload both packages, on a friday. Years of sysadmin
work hardwired me to be careful on fridays; as the saying goes: "don't
deploy on a friday if you don't want to work on the weekend!"

Feedback was great, but I was surprised to find that most people are
not worried worried about those issues. I have tried to counter some
of the arguments that were brought up: I wonder if there could be a
disconnection here between the package maintainer / programmer work
and the sysadmin work that is at the receiving end of that
work. Having myself to deal with broken updates in the past, I'm
surprised this has never come up in the discussions yet, or that the
response is so underwhelming.

So far, I'll try to balance the need for prompt security updates and
the need for stable infrastructure. One does not, after all, go
without the other...

Debiman

Local server maintenance

I upgraded my main server to Debian stretch. This generally went well,
althought the upgrade itself took way more time than I would have
liked (4 hours!). This is partly because I have a lot of cruft
installed on the server, but also because of what I consider to be
issues in the automation of major Debian upgrades. For example, I was
prompted for changes in configuration files at seemingly random
moments during the upgrade, and got different debconf prompts to
answer. This should really be batched together, and unfortunately I
had forgotten to use the home-made script I established when i
was working at Koumbit which shortens the upgrade a bit.

I wish we would improve on our major upgrade mechanism. I documented
possible solutions for this in the AutomatedUpgrade wiki page,
but I'm not sure I see exactly where to go from here.

I had a few regressions after the upgrade:

the infrared remote control stopped working: still need to
investigate

gdm3 breaks bluetooth support (Debian bug #805414 - to be fair,
this is not a regression in stretch, it's just that I switched my
workstation from lightdm to gdm3 after learning that the latter can
do rootless X11!)

Docker and Subsonic

I did my first (and late?) foray into Docker and containers. My
rationale was that I wanted to try out Subsonic, an impressive
audio server which some friends have shown me. Since Subsonic is
proprietary, I didn't want it to contaminate the rest of my server and
it seemed like a great occasion to try out containers to keep things
tidy. Containers may also allow me to transparently switch to
the FLOSS fork LibreSonic once the trial period is over.

I have learned a lot and may write more about the details of that
experience soon, for now you can look at the contributions I made
to the unofficial Subsonic docker image, but also
the LibreSonic one.

Since Subsonic also promotes album covers as first-class citizens, I
used beets to download a lot of album covers, which was really
nice. I look forward to using beets more, but first I'll need to
implement twoplugins.

Wallabako

I did a small release of wallabako to fix the build with the
latest changes in the underlying wallabago library, which led me to
ask upstream to make versionned releases.

I also looked into creating a separate documentation site but it
looks like mkdocs doesn't like me very much: the table of
contents is really ugly...

Subsonic is propietary
But it wasn't always so. There is libresonic that forked from the last free version. You might want to check it out.
Comment by
Felipe
— tard dans l'après-midi de Monday, July 3rd, 2017

comment 2
I knew about Libresonic! I even linked to it in the article, although maybe that wasn't very clear. I've updated the article to make a more obvious reference.
Comment by
anarcat
— Monday en soirée, July 3rd, 2017

docker!
Docker is amazing! It's been like learning git for me; hard to wrap my head around at first but the more I know about it the more I can't imagine living without it.
Comment by
mvc
— tard Monday en soirée, July 3rd, 2017