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

Bug#499897: preventing replay attacks against the security archive



On Thursday 25 September 2008 18:48, Philipp Kern wrote:
> But releases do not expire.  Thus a valid-until does not make sense
> semantically, too, IMHO.  Of course security must have it.

Security updates also "do not expire", so the last remark is a non sequitur. 
However, I think it does make sense semantically but you're giving different 
semantics to it.

Valid-Until means not how long the release itself is valid, but how long the 
certification that "this is still the most current thing we've released" can 
be considered valid. So it's perfectly ok to just re-stamp and re-sign the 
file without any actual changes to the archive, if for some reason there was 
no other need to update the distribution in the meanwhile.

> And no, all important security-relevant updates are still present
> through security.d.o, which is protected.  All the user would not get
> due to an outdated or bad mirror are the updates from proposed-updates
> included into the latest point release.

I see a number of arguments why it would be good to implement this for all 
archives and not just security.

While the security archive is obviously the most important archive to protect, 
once we have the mechanism we may just as well use it to protect the other 
archives we carry. Point updates by definition carry important updates, 
including lesser priority security updates, we have the mechanism, so it 
makes sense to use it.

Also many important security fixes arrive through the regular archive for 
testing, so protection on the main archive needs to be implemented anyway.

From an implementation view, it would only make things more complex if we 
would have to special case 'stable' for not having this feature while the 
security and testing/unstable archives would need it.

To implement it in a way that it also works for stable, we could either:
- have it automatically re-signed daily/weekly, would need the release key 
available, but the security release key already is, so not sure if that's a 
problem; or
- have it expire in a period long enough so a new point release will have 
happened in the meantime, say half a year.


Thijs

Attachment: pgpDRmoH2oL8Z.pgp
Description: PGP signature


Reply to: