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

Re: dpkg-sig support wanted?

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. 

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

> I think the final judgment in this issue is going to come down to personal
> taste and needs more than anything else.

That's fine for personal repositories, it's not sufficient for Debian's

> > > At the very least, though, I can't find a hole which makes binary package
> > > signatures, done properly, any less secure than per-archive signing.
> > That's easy: you trust the Packages file to be correct when using apt,
> > and it's not verified at all by per-package signatures.
> 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.

> The only thing that comes to mind is wasting some time and
> bandwidth on downloading dodgy debs (or their equally-dodgy dependencies),
> but if the system checks the signatures before installing anything, can
> anything actually be damaged?

There are plenty of packages signed by developers, or that have been
included in the archive, that have exploitable security issues.

> > My objection is that it's *useless* for *Debian*. Debian has too many
> > sources for packages for key management to be plausible, and keeps
> > packages unchanged over too long a period for the keys to be guaranteed
> > secure for the lifetime of a package. Additionally, packages can be
> > authenticated both via Packages.gz files and .changes files, which
> > already exist and are usable.
> Don't the same arguments about key longevity apply to checking the
> signatures on .changes files, too?

Sure, that's why we don't encourage users to worry about them.

The advantage is there's no great difficulty to providing new detached
certificates with new signatures, if the need arises. The debs only need
to be changed if they're actual content needs to change. (Which is also
an advantage for users, who correspondingly don't have to worry about
redownloading them)

> > Hrm, I see queue/done (which contains .changes files going back to the
> > dark ages) isn't even being mirrored to merkel properly at the moment.
> > That's not so constructive.
> Is there a publically accessable form of queue/done somewhere that people
> can download the .changes files from?  

No, there isn't anything, apparently the mirroring to merkel got disabled
due to the inode usage / rsync time. There's some 700k odd changes
files. I think the theory is they'll start getting regularly tar.bz2'ed
up and made available with an index file.

> That would be quite handy for people
> to use to verify binary packages (and would be a darn sight easier to use
> than trolling d-d-c archives).

No lie.


Attachment: signature.asc
Description: Digital signature

Reply to: