Re: .deb integrity check
Brian May wrote:
> Suggestion: Why not just sign the packages file?
>
> APT already checks the MD5SUMS with that in the packages file, so if
> you can prove that the packages file hasn't been tampered with, you can
> prove that all packages are OK.
Sure, that would work in general. I have a few problems with it though:
- It would require the Packages file be signed by an automated process.
Which pretty much means a key on a network connected machine, unless
something very tricky (and probably involving manual steps) is done. Crack
the machine and you can replace that key.
- It would mean individual developers cannot put up a package on the net
for download at the spur of the moment like they can now, and still let
people verify that they built the package. Instead they'd have to generate
a Packages file and sign it. Not a big objection since most people
generate Packages files now to make it apt-able anyway.
- If a third party (non-developer) wants to make a CD with a subset of the
packages in Debian, they have to make a custom Packages file for it. So
they can't use the signed Packages file. Since they arn't on the keyring,
they can't usefully sign the new file. Compare with individually signed
packages where they could copy in any set of packages and users could
check their signatures.
- If a developer went AWOL and became not trusted by the project,
individually signed debs would make it easy to determine every package they
had uploaded and get rid of them.
> 1. What happens in the case a package is signed by someone who is not
> the maintainer? Would this be allowed?
Signature checking could (probably should) be an option. If the package is
signed by someone not in your keyring, dpkg would continue as normal unless
you had told it to only accept known keys. At least, that's how rpm does it..
--
see shy jo
Reply to: