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

Re: Signing Packages.gz

Anthony Towns <aj@azure.humbug.org.au> writes:

> 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. If it affects some of
those packages, I will notice and alert the mainainer.

> 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:

Package: cvs
Version: 1.10.7-7
Priority: optional
installed-size: 944
Signature-DSS: @06X@86QT97)N871I=F4@:6YF;RUF:6QE('9I97=E<@H`

Package: cvs-buildpackage
Signature-DSS: L5')Y(&!U=65N8V]D92`M+6AE;'`G(&9O<B!M;W)E(&EN9F]R;6%T:6]N+@H`


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.

> Per-package signatures would naturally accompany the package, not the
> Packages.gz file.

No, see above.

> 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, no amount of
fiddling with the debian machines could corrupt the source packages
this developer uploaded without you noticing. Because .dsc files are
signed by their maintainer's key. This won't work for binary packages,
though. And that could be changed.

> 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). 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

> Huh? .debs are never created and uploaded without any intervention,
> as I understand it. Including ports.

Aha. Sorry for being ignorant. So per-package signing could use either
the maintainer's key, or the porter's. It would have been a problem if
building port had been automated.


Reply to: