On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote:
> On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote:
> > But unfortunately that's not quite the choice I have either, since for
> > some reason that I can't fathom, people seem to think that a dinstall
> > key would be an abomination to man and God and I'd probably be summarily
> > kicked out of the project as soon as I tried sending a patch somewhere.
> > Or at least it'd never get applied.
> It seems you feel personally insulted.
Not insulted, just frustrated.
> I am sorry for this, but
> unfortunately it doesn't change the situation that the signed packages case
> adds a further point of weakness to the chain of trust.
And this is one of the reasons. It *leaves* a point of weakness in the
chain of trust, it doesn't add any.
> As dinstall verifies the keys on the packages (which already exist, btw,
> they are just not propagated), it puts itself in the middle of the chain:
Well, as Jason points out, they are propogated: by the -devel-changes
list.
They're not very /convenient/, though. I was figuring to make them convenient
enough to automate, you'd need to tack them on inside the .deb, like has
been proposed in the past. You're welcome to correct this assumption, if
you like.
> signed packages --> dinstall --> user
> 1 2
>
> Now link 2. It is currently absent. What you seem to suggest is to add a key
> (dinstall-key) here, so the user can verify the archive. This adds a point
> of weakness. As the dinstall key can't be used automatically and kept "truly"[1]
> secret (it directly depends on the security of master), this weakness is rather
> huge. This problem is avoided if the link 1 is propagated to the users:
I'm sorry, but that's a matter of opinion. If you're really *hugely* worried
about the security of master, then please, show us your scripts that you've
already had to write to cope with the fact that master's so insecure it's
probably already compromised.
Yes, it's a problem, but one you seem to be vastly overrating.
> signed packages --> dinstall
> \ 1
> \--> user
> 1
Really, what we have is:
maintainers ---------3---------.
| V
1 users
| ^
`--------->debian--2-------'
The first link is already checked completely. Debian knows that all the
packages it distributes are created by developers.
Link 2, which could be accurately implemented by signing Packages files
and nothing more (and is hence really easy to do, really easy to automate
and adds next to no overhead at all), allows a user to confidently say
"This distribution is Debian's." Hence, if Debian (ie, all our servers,
some of our important people, whatever) gets compromised, they're stuffed,
yes.
Do think about that though: Debian gets compromised. That's not some J.
Random Event that happens every day, every month, or every year. It's not
something you can just blithely work around, either. People installing
for the first time might be willing to trust www.debian.org to be controlled
by Debian, but they're not going to have any other way of verifying the
whole debian-keyring. If www.debian.org is compromised, there's no reason
for them not to accept some bizarrely wrong keyring as gospel.
Link 3, allows you to verify for yourself who built a particular package
that Debian distributes. Or at least, allows you to verify the key
they used. Verifying that they're an actual person, that they're really
someone you have a reason to trust, and that they themselves haven't been
compromised, is less trivial. (This is asserted by `Debian', but hey,
like you say, Debian could be compromised. Who'd wanna trust them?)
> In this situation, I don't have to trust anyone except the Debian developer.
> Not the admin team, not the security team, not master, not dinstall. Can't
> you see that this is a crucial advantage?
Can't you see that it's a crucial *flaw*? You have to trust *every*
person who's a developer. And guess what. That means you have to trust
the admin team and the security team. It means you have to assume that
every machine every developer stores a secret key on is maintained as or
more securely than master.
> If you also want a link 2 from dinstall to the user, I don't care. But don't
> tell the users that link 2 asserts that all packages come from Debian
> developers, it doesn't.
No, it asserts that all packages come from *Debian*. Debian itself states
that they'll only distribute packages that come from developers listed in
the keyring; and yes, it might turn out that Debian as an organisation has
been compromised, or hacked, or is just lying.
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:
pgpg10XYoJf2t.pgp
Description: PGP signature