Re: How to improve archive verification possibilities for the future
Isaac Jones <firstname.lastname@example.org> writes:
> Marc Haber <email@example.com> writes:
> >> The Release files for unstable and testing still have to be signed
> >> automatically, but I'd really prefer to have that done by
> >> downloading the file to a non-public machine, signing there and
> >> re-uploading. Additionally, I'd like to have snapshots (for
> >> example all four weeks) to be signed manually with an off-line key.
> Since the signing of the Release files is probably one of the weakest
> points in the chain, perhaps the key which hosts this key should be
> running SELinux or something? That doesn't help if the build servers
> are cracked, but it does defend against some attacks.
>From various discussions and falmes on irc I condensed a probable
attack vector against the debian archive. Is there anything we missed
that prevents the following from happening?
1. The attacker compromises ftp-master.debian.org and gains access to
2. The attacker replaces lets say the bash deb with a compromised one.
3. The attacker regenerates the Packages and Release files or rather
the underlying databases for this.
4. dinstall runs, installs new debs and a new signed Release.gpg file
If 1-3 is timed right there is only a minimal window in which the
bash.deb, Packages and Release file doesn't match the Release.gpg
file. Note that the gpg key is not compromised here. Offsite or manual
signing does not prevent this attack.
I know that anyone subscribe to the *-changes lists can verify the
signatures on the changes files agains the debs or Packages files but
is anyone doing so?