Anthony Towns <aj@azure.humbug.org.au> writes:
> On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote:
>> Then there's the opposite argument about "why not do that inside the .deb?".
>
> Simple answers: unnecessary bloat, unwarranted feeling of security
> leading to bad decisions.
Where do you have an unwarranted feeling of security? You keep hinting
at debsig being insecure but nothing you have said makes it any
different (security wise) from changes files.
> Whenever anyone asks "how do you manage the keys", the answer is usually
> "automatically sign by dinstall" which means the deb is modified after it
> leaves the builders system (invalidating existing authentication methods)
> and usually means changing the deb after its entered the archive (for
> signatures identifying packages released as part of sarge / etch, or in
> the case where an old key expires).
That is just plain wrong. The only existing debsig signatures are all
done by the builder and/or DD prior to creating the changes file. And
that is all what the initial post in this thread was about.
Having dinstall _also_ sign debs is an option that can be implemented
or not. And it would only invalidate one authentication method: using
a plain md5sum and the changes files. The Packages files md5sum would
naturaly be the md5sum after signing and still work.
Let me repeat this for you: An automatic dinstall signature is just an
option.
...
>> That's a good point. However, what damage can be done with a bodgy Packages
>> file, if only well-signed .debs are actually accepted for installation on
>> the system?
>
> Add a "Depends: some-random-package" that you know has a security hole
> to dpkg's entry in the Packages and it'll be automatically installed by
> apt. Add a "Conflicts: dpkg" to some package's entry and it'll never be
> installed by apt or aptitude. You can possibly be trickier by pointing
> apt at a completely different file too, so that the user thinks they're
> installing foo, but end up with bar instead only noticing if they see
> dpkg say "Unpacking bar (from .../foo_*.deb)". IIRC, it's tricky to make
> that actually work.
All you do there is install a trusted package or sabotage installing a
package. An attacker still can't change any package. And all of that
you can do with or without package signatures. If the original package
is buggy too bad. That is what we have security.debian.org for.
Signed debs are not ment to protect the Packages file, we have the
Release file for that. Signed debs are ment to protect the deb itself.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
