tech-pkg archive

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

Re: pkg_add functions and renovation



On Tue, Apr 22, 2008 at 05:21:47PM +0200, Joerg Sonnenberger wrote:
> (3) pkg_add -s is somewhat challenging as it makes problems with the
> unified remote/local code. It means I would have to go back and figure
> out if it was a local file etc. I would disable this function for now
> and provide a replacement later. An idea that doesn't conflict with
> streaming installation is to wrap the package in another tarball. You
> create a hash of every 16KB or whatever block of the real package, sign
> the list of hashes and include the signed hashes and the package in the
> tarball. An invalid block hash would be handled like a read error and
> result in a cancelled installation.

Once again - this functionality needs to remain (the ability to verify
a digital signature on a binary package before adding it to a system).

I don't care if it's rewritten, but if it is, NO REGRESSIONS ON ANY OF
ITS FUNCTIONALITY ARE ALLOWED.  Yes, this goes without saying, but... 
it's probably best said in this case.

Oh, and rather than wrapping it in yet another tarball, just append
the digital sig to the end of an existing tarball - that was mycroft's
suggestion some time ago, and was the same one I explained to you
yesterday. tar should treat the sig as noise. There is no need for
multiple hashes - either a package has been tampered with, or it hasn't,
and so one signature covering the whole binary package is sufficient.

But I always come back to the question - we already have something
that works - why are you reinventing the wheel as multiple square
objects?

Alistair


Home | Main Index | Thread Index | Old Index