[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files



On Thu, Oct 30, 2014 at 12:09 AM, Christoph Anton Mitterer wrote:
> On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
>> Packages appearing on mirrors is not how we notify Debian users of
>> security updates.  We do that by issuing a security advisory.
> Aha,... well... sounds like nitpicking,... I guess the least of the
> users have subscribed the respective mailing list or look regularly at
> https://www.debian.org/security/.

There is also LWN as a mechanism for independent verification.
Although there is often more than a day long delay on that, and more
on weekends, it can be used as reliable indicator if has different
information than expected from the DSA mail.  That is a retroactive
process, so sure it isn't a preventative measure, but when something
does differ, at least you know that the events you observed for the
prior day were suspect.

> And apart from that:
> with respect to mail:
> - the mails seem to often lag behind the actual release of a fix, so
> there is the same problem that users may not be notified as fast as they
> could be

The mail and dak install are manual and independent actions, so the
timing difference is the human in the loop, and is rarely more than a
few minutes.  Maybe the two could be tied together, but someone needs
to volunteer to do that.

> - while mails can be secured, there is no guarantee at all that mails
> arrive the subscribers
>
> with respect to web:
> - that uses GANDI CA certs, so this is not really a secure way to be
> informed about that either.
>
>
>> Yes, it's
>> nice to protect against archive downgrade attacks, but validity periods
>> are not our primary defense against that.  Our primary defense is that we
>> send out a DSA telling people exactly what package versions they need.  If
>> those package versions aren't available, that should raise red flags.
> See above, both means of distributing DSAs seem not to protect against
> downgard/blocking attacks.

Why wouldn't a once per every TIME debsecan cron job not solve the
entire automation problem?

>> Teams that run Debian servers in production should be checking that all
>> packages on their hosts are upgraded to the necessary versions.
> Even apart from the above problems, I doubt that mail is the appropriate
> mean for many admins to get notified about security upgrades.
> People may deploy security upgrades automated or at least check for them
> via Nagios and friends, rather than reading mails, which they get for
> *all* DSAs and not just the packages they actually use.

If the problem really is the lack of a nagios plugin, then that seems
like a straightforward problem to solve, and a potentially positive
direction to focus this energy.

> To be honest, it's really awkward to see how much all this is apparently
> fought against.

It sure is awkward to see so much fight continuing with so little action.

>> It seems to me that if you want to lower the chances of a downgrade attack
>> for your systems, setting the validity period on your systems is exactly
>> the tool that you need.  There's no need for anything to change on the
>> server side for you to get that protection.
> Well I don't think it would work, would it?
> The Release file contains e.g.:
> Date: Thu, 30 Oct 2014 02:54:04 UTC
> Valid-Until: Thu, 06 Nov 2014 02:54:04 UTC
>
> When I now lower the validity to something very small, e.g. 4 hours,
> than beginning with 30 Oct 2014 06:54:04 UTC everything will fail for me
> unless a resigning mechanism was in place like such that was discussed
> in #752450.

I think ftpmaster said they would consider signing more often, but
they were not willing to consider reducing validity time (in case
something does go down).

And that change would obviously be useful, but has been entirely lost
in the noise (particularly the finger pointing and misguided public
shaming attempts).

Debian is about meritocracy.  If you're unwilling to do any of this
(or to have figured) it out yourself, then there is no reason forcibly
attempt to make others do it for you.

Best wishes,
Mike


Reply to: