[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

Hey again.

On Wed, 2014-10-29 at 22:07 -0700, Russ Allbery wrote: 
> If you don't read the mail, you're going to miss some really vital
> information, like packages that we are no longer supporting.  I am very
> much opposed to giving people the impression they can just monitor the
> security archive and not read the DSAs.
All that kind of stuff should IMO rather move to some machine controlled
system as well.

I mean, in that area (package installation, upgrade, maintenance) we
have actually several things which should be goals:

- Debian shouldn't ship packages that enable network listening services
per default (unless perhaps very few special examples). At least this
services should try to come in a localhost-only fashion.
Not having packages like postgresql/httpd/etc. start and initialise
automatically would actually be the natural way and... well I don't know
what suse does but I think the other distros don't do that thing.

- Debian should ship a default set of firewall rules. Are we the only
distro which doesn't do this? I mean a basic ruleset which drops
incoming, accepts outgoing and accepts related,establised is so easy to
do... and it would help for all those cases where services are started
but not yet finally configured/secured by the admin.

- There should be a central system, that checks whether something needs
to be restarted after package upgrades. Some package just
unconditionally restart their services on upgrade (even when there is no
technical need to do so), some (e.g. libc) check whether other packages
need to be restarted.
I think this should rather be moved to something like needrestart, even
though needrestart currently only looks at services, and not at any
other processes which also make use of old libraries/etc.
Apart from that, a package should only restart its own service, when
there is a strict technical need that stop/start needs to be made
before/after the upgrade, e.g. one should be able to upgrade sshd
without the need to restart it.
The decision whether restarts are made, should then be centrally
delegated to e.g. needrestart.

- And last but not least to address your concerns about packages which
are no longer security supported.
For that we already have debian-security-support... and it should
ultimately be the canonical point to handle this question.

If you still think that the DSAs themselves need to be distributed to
the users in a secure way (which is an idea I'd support) than this
should perhaps go to the package as well. Like a file DSA.Debian,
similar in style to the NEWS.Debian and it could be displayed by

> > To be honest, it's really awkward to see how much all this is apparently
> > fought against.
> I don't think people are fighting against you.
First I've said how much *all this* is fought, and not how much *I* am
fought ;-)

But, seriously?! Remember our last dance about strengthening crypto
algos in Debian?
It wasn't that I proposed to implement something impossible or
completely awkward, just to take a concentrated effort to phase out the
usage of algos (or key sizes or DH group sizes, etc.) which have already
known flaws - or at least to disable them from being used automatically.
And history simply proves me right, that it's better to do this
proactively, even when something is still safe (for the very moment) or
when upstream is slow.
Not doing this is, why we still have MD5 in several places, where it's
probably not the best idea to use it.
The typical arguments then are... "xyz is still safe", which often turns
out to be a "for a few months or years at best"; or "we use only xyz for
performance reasons", which is kind of a strange argument in all those
places where performance isn't crucial and where a few extra ms that
e.g. SH512 needs over SHA256 just don't matter.

And actually I got several mails by people and other cryptographers
after that last discussion, which supported my views and were kinda
disturbed of the what has been styled as a commonly accepted opinion
amongst cryptographers.

Or remember the thing with the downloader packages?

And for this issue it's the same? I think the current top argument is
"we don't need to do anything, since LWN provides people with secure

So please apologise me if I sometimes get the impressions that people
rather just search for reasons not to do something. And so far, noone
has really given me a solid technical argument why and of these issues
wouldn't be real. The only "arguments" are rather things like "most
users don't care" or things at that level.
E.g. to quote yourself from below: "esoteric security gains compared to
all the other things that they could be working on"

The funny thin it that one gets arguments like these in all these
fields, and an attacker is probably not too smug to exploit such a
meta-security-hole just because Debian calls it esoteric. :-(

> I think people are
> unconvinced that all of the machinery that you want to put in place is
> worth it
Well actually the machinery is already there isn't it? Someone had the
great idea to add validity times to the Release files - it's just not
used well enough to match our typical upgrade release periods.

> for some pretty marginal and esoteric security gains compared to
> all the other things that they could be working on.
An attacker will typically always attack the weakest chain element in
If he can easily break an algo, he'll do that. If not, but he can do
social engineering, there he goes.
If he can run a meta-attack, why not? And if he's powerful enough
(governments) and finds no other way, he simply comes after you, beats
you up and tortures you so severely until you give him everything he
wants with pleasure.

Software will always have bugs, government will always be stronger than
you, people will always be tricked into social engineering, and sooner
or later, all algorithms (unless OTP if implemented correctly) will be
But none of this means that we shouldn't try to make each single chain
stronger if we can.

Sure we could work on other things, start auditing software for
example,... but this won't happen just because we drop work on

> And, on top of that,
> you argue for them by writing encyclopedic tomes that are kind of hard to
> digest.
Hehe, *guily*... well I guess that comes with fighting windmills,...
either one gives up, which I sooner or later do, or at least you try to
argue, explain, etc.

> Also, most of the people responding to you are not people who have the
> power to implement the changes you want.
Uhm agreed,... but neither have I.
These things I've brought up in the recent years aren't single holes in
software XYZ which can be fixed by avoiding a buffer overrun.
By their nature they must be dealt with on a larger scale.
But I don't think that it's impossible to handle them. Take the issue
with the downloader packages,... if people would just agree on actually
taking action on this, one could add it to Debian Policy, add some
heuristics to lintian which check for potential downloaders in packages
and give a small how-to to maintainers how to correctly deal with that.

> I don't know that you're going to like this advice, and I know it's kind
> of unsatisfying, but you keep picking up causes that are structured so as
> to require people other than you to go do work.
Sure, that's the easiest?! ;-)
No seriously,... you don't know what efforts I make to improve security
in those areas where I can do this on my own, do you?

btw: I would't say that identifying such meta-attacks and thinking about
solutions is like no work. o.O

> Can you find a solution
> to one of these security issues that you see that you can just fix
> yourself?  Like, in this case, a better tool for monitoring security
> status of packages?
Russ, you should perhaps rethink that whole issue with the validity
By definition there is no way[0] to improve one's security, without
having the shorter validity times (and thus more often the guaranteed,
signed statement from e.g. Debian "yes, all your packages are still up
to date, no new security upgrades in the meantime).

> There is *way* more to be done in Debian than we can ever possibly
> accomplish, particularly in the security arena.  People are prioritizing.
> You get to pick your own priorities, but so does everyone else.  Your
> priorities aren't in line with the people who have to make the changes you
> want to see.  That's super frustrating, but that doesn't mean they're
> obligated to change their priorities.  There are limited hours in the day;
> some very good ideas are not going to get done.  If you are getting
> frustrated by being blocked on other people... work on things that don't
> block on other people.  After you do some of that, you'll often find that
> other people are more willing to jump into shared projects with you.
Sure... but I think in none of these issues we ever came to the place
where the question was "who starts with the concrete work now", did we?
Agreeing on something like "we want to regulate downloader packages
according to the following rules" or "we want to take countermeasures
against downgrade/blocking attacks" would already be half the goal.
Even if the people in charge don't have time immediately (or ever) this
would at least enable others to work on this one by one.
But no one can expect non-core-people to deeply work into complex
systems like apt or the mirror infrastructure, just to be told "na we
don't want to do that at all" when they'd provide first patches.

> > I really wonder how you can do that with the above means.
> I read the mailing list.  In practice, it works fine.
I questioned how you make sure, that you actually get all the mails and
that Mallory isn't blocking those that apply to you.
But when this is just an esoteric threat model for you, then of course
reading the lists will be fine.


[0] Unless perhaps you give me a direct secure path to the master
mirrors. Which would probably mean TLS... and well let's say: I'm happy
that secure APT isn't dependant/based on TLS ;-)

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

Reply to: