[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, 2014-10-30 at 01:29 -0400, Michael Gilbert wrote: 
> There is also LWN as a mechanism for independent verification.
Don't they just take up the information from Debian themselves?

> Although there is often more than a day long delay on that, and more
> on weekends
Which makes it inadequate to deal with the issue we were talking about.

>  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.
I actually regularly look at LWN, but I wouldn't bother to remember
which updates they've listed and whether there's anything I've missed on
d-s-a or in apt.

> 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.
Just FIY: I definitely wasn't criticising that mails or the data on the
web may have been delayed in some cases... actually that's what I've
naturally expect in most cases: First pushing the updates... and only
then starting to write some prose text about it :)

> > 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?
I would need to look at debsecan whether it avoids the issues we have in

But I mean at least to me it sounds quite appealing of having it secured
there (apt/aptitude).
It's the central place for package management, it's what my 3rd party
tools any nagios checks 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.
I don't feel that this is the way to go, since it rather seems like just
working around an issue... but you'd need to explain in more detail,
what you actually imagine.
At it still has the problem that not all people would secure themselves
via that plugin.
Some may use their home-brewed shell scripts that query apt and install
security packages automatically, some may use existing packages for
that, and so on.

> 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).
Well I did notice that, but two problems remain open:

- if we have so many mirrors, that are that slow, then one would still
need to distribute the re-signed files on a fast track.
Otherwise all the people who actually choose to tighten their validity
times may end up having problems every now and then.

- it still leaves the broad majority which either don't care or simply
doesn't know "vulnerable"
So I personally (and I know that I have a more extreme security POV than
most here) feel, that we should actually want that people get errors,
when the master servers in Debian get down.
People should somehow be notified and see... "aha, something is going on
there, I may not longer get security upgrades".
Now people of course fear such changes and possible breakage, but to
repeat myself: giving the user a warning on what's happening, allowing
him to override the validity check and accept the expired Release file
isn't something that will stop the world from turning.
It's not so much different to the possibility of seeing
"unauthenticated" errors that came with the introduction of APT.
It happens very rarely, people get an adequate warning and can deal with

> 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.
Well unless I'm appointed ftp-master, then it's probably unlikely that I
can do/decide much in that are, can I? ;-)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: