On Thu, 2014-09-25 at 21:56 +0200, Joerg Jaspert wrote: > It also sounds quite stupid that suddenly all users have no working > mirror anymore, should there be an outage of ftp-master or > security-master longer than the signing time. Well I don't see why this must necessarily happen. Even if ftp-master and or the signing services went down for a longer time period, then nothing has really changed,... of course the Release files will no longer be valid, but what then should happen is simply this:
1) Programs that use secure APT fail if nothing else has been specified manually by the user/admin - and this is exactly what we (should) want. If a critical hole, like the shellshock comes out and we fix it quickly, than no attacker should be able to keep some systems from reacting either by our current long validity times OR by simply [D]DoSing ftp-master. If the secure APT is used manually, than the user/admin will immediately see that something is fishy an can react appropriately. If secure APT is somehow used automatically, than a properly configured system should send the user/admin notifications that updates/upgrades no longer work, and again, appropriate measures can be taken. Now to deal with your concern of larger outages: 2) Just because there are no valid [In]Release* files, it doesn't mean that those mirrors and their repositories can't be used any longer. The data is still there as it was before. An application like apt/aptitude/etc. could simply give the user an error, telling that the files have expired for hh:mm and could give the user and option to nevertheless trust them. And the same options could be provided for batch modes. The only difference is, that now users can notice and can decide themselves (like trusting files expired for 1 hour, but not for 29 days) or can take appropriate measures (like looking around in the news or debian.org/security, whether anything big is going on). I mean the validity is just a like a flag, that allows software to decide - but the default should be that - if something is fishy - the software gives an error/warning and the validity periods should be short enough to match the typical package update cycle for each repo. > Or a release going on, during which we commonly turn off the archive > and ALL cronjobs. Until we are sure that it is all fine again. > No, a full release doesn't go through in less than a dinstalls time. > > Even down to two dinstall intervals is short and would require us to add > one more level of complexity to our working. Well don't fully understand this, to my understanding, it would be mainly security and sid archives, which should have very short validity periods of a few hours, since those are the archives where people expect their security updates on a fast track. Apart from that: The validity-period should IMHO be mainly considered as a security-related property and not related to the technical periods of how the repo data is distributed. And the apropriate value should be aligned to the typical time that it needs for updates to go into that repo (on master - not on all mirrors). I.e. that means if our security team is so fast that it sometimes provides updates within 1 hour of a hole becoming public, that should mean that the appropriate validity time is that. If this leads technical problems, than either there is a design problem in the current distribution model,... or we simply need our clients (apt/aptitude) to notice the user and leave the choice up to him. IMHO it's quite dangerous if people start to negotiate security for technical reasons, the wellness-factor of users or for historical reasons. Attackers simply don't care about this. And yes, security always comes at price, also for the end-user (like in our case that he could sometimes face expired meta-data and would have to decide what to do),... This is why we have a lousy X.509 based security infrastructure in the web instead of a properly meshed PKI like e.g. OpenPGP would provide it. This is why Debian still enables network services per default after installing them, even though this is quite stupid from a security POV. And I'm sure that there were already people in the past who wondered about the stupid "features" that bash provides, but for sure they would have failed to convince upstream to remove them. Security is not negotiable. Cheers, Chris. btw: I did some PoCs on some of my own servers (respectively such which are under my control under the university) with shellshock. As soon as you can MitM, you can do such downgrade attack, and hide any updates to bash from the systems (which in our case run check_apt via Icinga)... so noone would notice and take appropriate actions. Okay that this works, was probably clear to everyone. But you even don't need to be able for a direct MitM. Many systems netselect-apt, so all you need to do is: run a mirror that is considered the closest to your attack-target, wait for a suitable security hole, stop that mirror from resyncing. Then you have the current long validity period to attack your targets.
smime.p7s
Description: S/MIME cryptographic signature
