Reflecting on users and security updates
Hi!
Our security team and their response to CVE-2014-0160 was yet another clear
demonstration of some of the things that makes Debian so great. Thank you and
well done for providing fixes and information. It was also wonderful to see a
few extra faces around in #debian and #debian-next helping out the increased
support load that an event like this brings. Thanks to all involved.
A few distinct patterns emerged from the flood of people through our support
channels in the few days that followed the release of these updates. Now that
we're not busily running around updating machines or renewing certificates, it
would be good to reflect on how we do things with an aim of seeing if we can
improve what we do -- some of this is just simple wording changes or linking
to information but we also need to figure out how to educate our users better
in some pretty basic parts of the Debian system.
All of these things can be explained as "users did something silly" but I'd
like to think we can reduce the opportunities for users to do silly things and
thereby make Debian better. If we can come up with a way of turning these
thoughts into things that can be implemented, I'm happy to file bugs in
appropriate places and even attach patches where possible ;)
== sources.list
Many users of stable releases don't have security.debian.org in the
sources.list. I can only wildly speculate as to how this happens... if the
installer doesn't find a network connection at install time it leaves a pretty
weird looking sources.list and we know lots of people manage to not fix
properly. The sources.list that the installer leaves in this case is certainly
sub-optimal.
Why do we have a separate archive for security at all? "Separate teams" and
"hysterical raisins" are possible reasons. Not waiting for a mirror pulse to
push out updates is another. Is there any technical reason right now to
not copy security updates into the stable release at the next dinstall run
rather than waiting a few months for a point release? What would be required
to merge these and simplify life for our users?
== DSA wording
The DSAs always read "For the testing distribution, this problem has been fixed
in version ____." While this is strictly correct, this fixed package is not
actually *in* the testing distribution at the time of writing and may be some
days away from being available in that distribution. A simple change of s/has
been/will be/ would be much clearer for users who naturally wonder why they
can't find the package that has been referenced. Perhaps adding a comment to
the effect that it is "currently in unstable if you want it right now,
otherwise it will appear in testing soon" would help.
A very common problem we saw in #debian was people only upgrading the openssl
binary package and not the much more important libssl1.0.0 package. Perhaps
DSAs could include a list of the binary packages involved too? (yes,
libssl1.0.0 was even mentioned in the DSA, but...). Or alternatively, a
command that will list the potentially affected packages on their system, such
as:
aptitude search '?source-package($package)?installed'
With a flaw like this, users often want to know how to verify that things are
actually fixed. It was interesting to see how many users didn't know how to
look up the version of the libssl1.0.0 package that was installed on their
systems (made worse by the long version string that dpkg -l truncates). How
can we better highlight this information to users?
Along with upgrading the openssl binary package instead of the libssl1.0.0
package, many users were quite confused about the output of "openssl version"
(I assume there were websites out there telling them this was a way of
checking your openssl version). This string doesn't include any distributor
patch level so after upgrading, there is no "evidence" that anything has
changed. It also is of course not the latest 1.0.1g but the 1.0.1e that was
originally in wheezy because our security team backports the patches. I assume
that we can't put a patch level into that output and we're not suddenly going
to start accepting new versions into stable releases, so how can we better
communicate to our users that the fix has been backported and they *are* safe
even though the public information tells them that all versions of openssl
prior to 1.0.1g are vulnerable (not true) and they can see an `openssl
version` that says 1.0.1e where 1.0.1e < 1.0.1g.
The correct answer is, of course, to check the package version of libssl1.0.0,
but some users demonstrated that even that version comparison is not as
straight forward as one might think. To understand that versions "prior to
1.0.1e-2+deb7u5 and 1.0.1g-1" are vulnerable you need to understand the
branching that has gone on within Debian. Is version 1.0.1e-3 vulnerable? Well
even though 1.0.1e-3 > 1.0.1e-2+deb7u5, it's actually a version that is prior
to 1.0.1e-2+deb7u5 (being a version in sid from around the time of wheezy's
release). How is an end user supposed to know that though? And yes, we had
more than one user with out-of-date boxes who was confused by this. How
can we better present the fixed/not fixed information so that end users don't
have to understand the gritty details of Debian's release process?
== public information
Over on the tracker of doom [1], the packages in wheezy are listed at the top
as:
Debian/stable package openssl is vulnerable.
Once again, this is strictly true as the package that is in wheezy rather than
wheezy/updates is vulnerable. It is, however, unhelpful. I became quite tired
of having that line quoted at me with a "see, debian is still vulnerable, why
you no fix it!!1!" over the course of a few days.
Sure, this is the security team's own tool but it's also public information
and people look at it and are taking away the wrong information from it. Could
it instead say
Debian/stable old package openssl is vulnerable but fixed in security
or something similar? (yes, better information about fixed versions is below
but this is about clarity of information and improving the accuracy of
people's understanding of the information, particularly when they're stressed
and not necessarily reading everything first)
[1] https://security-tracker.debian.org/tracker/DSA-2896-1 or
https://security-tracker.debian.org/tracker/CVE-2014-0160
Food for thought!
cheers
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: