On Wed, Mar 29, 2000 at 01:12:39PM +0200, Robert Bihlmeyer wrote:
> > Well, it'd be nice to be able to do so, to verify that a mirror hasn't
> > been compromised, but no, you're right.
> Actually I don't care that much if the mirror is compromised, if it
> affects only packages that I don't install.
It would be nice for a compromised mirror to be able to easily work out
which packages were compromised.
> > Actually, now I think about it, the Packages file itself is valuable
> > information. Consider a Packages file that doesn't actually changes the
> > .deb's, but changes the netbase entry, say to read:
> > Package: netbase
> > Depends: vim
> > Conflicts: nvi, emacsen
> > and leaves everything else the same.
>
> Nice one. Though, not possible the way I envision the "signed
> Packages.gz". Imagine the following:
Which, again, is not a method that I, at least, have ever seen proposed
before.
> Package: cvs
> Version: 1.10.7-7
> Priority: optional
> [...]
> installed-size: 944
> Signature-DSS: @06X@86QT97)N871I=F4@:6YF;RUF:6QE('9I97=E<@H`
It has quite a few problems. The first is that it's not in a format
that tools can (currently) process easily. That's likely to kill it
straight away. (By `easily' I mean, writing a tidy ten line shell script
that'll verify a given Packages entry).
Another is that these signatures are not currently made by
maintainers. That means you need to get every maintainer, and every porter
to manually recheck and re-sign and possibly reupload all their packages.
Another is that this doesn't cope with the fact that Packages files are
generated both from the .deb's themselves and from the overrides file
(which has the correct sections and priorities of .debs, as opposed
to what's listed in the .debs themselves) --- the Packages file isn't
the combined responsibility just of a bunch of maintainers it's the
responsibility of dinstall on master too.
Another problem is that maintaining these signatures would require changing
the way dinstall operates significantly.
Basically, it doesn't strike me as very practical.
> The `Signature-DSS' field contains a signature over all the fields,
> excluding itself. Since this includes the MD5sum, the package content
> can't be corrupted. But this also protects the package metadata.
Another difficulty (one that's not overly difficult to resolve, but could
be awkward implementation-wise) is that you'll need to specify an order
to your fields for this.
> > Speaking about `more secure than the debian machines themselves' is
> > meaningless. If you can compromise the debian machines themselves,
> > you're home and hosed. You can do anything and everything.
> Not true! If you have a trusted key of a developer,
If you have the trusted key of a trusted developer even, you can't verify
that some guy in Azerbaijan is actually a developer or not. The Debian
web of trust isn't connected.
And what about all those people that haven't ever met a developer
in person? Should they just buy RedHat instead?
> no amount of
> fiddling with the debian machines could corrupt the source packages
> this developer uploaded without you noticing.
Congratulations. You can be completely confident xtictactoe hasn't been
compromised.
And again, what happens if a maintainer who's kicked out doesn't want to
admit the fact? He's still in the web of trust, and if he can compromise
a mirror (which may well have been the /reason/ he was kicked out), he
can make sure the updated debian-keyring never makes its way to you, and
insert his own hax0red but signed packages into pub/debian/dists. With
a completely signed Packages.gz the best he can do is make you miss out
on getting upgrades.
Note that this isn't *much* of a vulnerability: his PGP key's already been
linked with his real-life identity by Debian, and his hacked packages have
been signed with his PGP key, so there could easily be repurcussions, but
it's still an /avoidable/ risk.
> > No, it doesn't. And what would such a mirror actually *do*? Just mirror
> > master as it gets compromised, and end up compromised itself?
> The premise was that master is not easily compromised (and if it is,
> we're hosed anyway at the moment).
If master is not easily compromised then there isn't a concern with having
dinstall have a PGP key.
> But remember that users can't
> download from master, they have to use a by definition less secure
> mirror. A direct mirror under the auspices of the Debian admin-team
> would be a possibility for users to get it "straight from the horse's
> mouth".
Do you mean like ftp.debian.org?
The machine that can barely cope with the huge number of downloads
and connections? The machine that has trouble finding sponsors because
it uses more bandwidth than some not-particularly-small ISPs?
Now, we seem to have established that master can be considered
reasonably secure. What, exactly, is the /problem/ with having a single
widely-publicised `dinstall' key that automatically signs the various
Packages files? Where, exactly, is the vulnerability that makes it so
obviously insecure?
And note this is not to say that we shouldn't /also/ have keys added
to the .deb's themselves, just that we can get most of the security
we might like --- certainly for all the common cases --- simply by
adding an automatically generated Packages.gpg that Apt can trivially
be taught about.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpcawcAlYBkm.pgp
Description: PGP signature