On Tue, Feb 20, 2001 at 05:05:52PM -0600, [EMAIL PROTECTED] wrote:
> On 20 Feb 2001, at 22:38, Mark Seiden wrote:
> 
> > i'm about to switch to oxygen, which i've built on 2.2.18 (i
> > hope...) for our beta test. 
> 
> Thanks for using Oxygen!
> 
> > when (not if) you run out of room on a single floppy, which
> > contains "trustworthy" software, how to download additional .lrps
> > in a trustworthy way? 
> 
> I'm not sure what you mean.... but read on.
> 
> Are you aware that you can download *.LRP files during the boot 
> process from an HTTP (web) server, from an FTP server, from a TFTP 
> server, or even from a GOPHER server?  This is Oxygen specific, 
> however.
> 

i would say i was "vaguely" aware of it.
actually fetching the files is not the problem i was trying 
to solve; but making sure you got what you expected is what
i'm concerned about.

> > so we're thinking of including on the floppy a public key
> > corresponding with the private key used to sign each package (some
> > sort of certificate), and checking each package as it's
> > downloaded. 
> 
> This requires something to handle the keys - presumably, pgp - which 
> doesn't yet exist in a package.

yes, i was imagining a conventional "hash and sign" operation.
the entire contents of the tar.gz (including all files and
directories, as well as their permissions) would be hashed.

the hash would be signed by the packager, using their
 private key.(let's ignore for now exactly how, but any kind of
digital signature supporting public key will do, for my purpose.)

on the client, the public key stored on the floppy would be used to
check the signature of the hash, which would determine its
authenticity.  the hash of the contents would be recalculated, to
determine whether any content had been altered after signature.

i don't need to worry about certificate revocation -- the cert
containing the public key is valid because it's on the client's root
floppy.)

the main important requirement is that the signature checking code
be *small*.  (gnupg.rpm is 800kB, openssl is 1.1MB (but less monolithic
than gnupg, so may be usable)).

> > this means using md5 or sha1 hashes with the signatures kept on
> > the floppy won't work (as we'll have to update the signatures each
> > time we update a package). 
> 
> > does the apkg format allow for signed content?
> 
> Really, it's not a "apkg" format but the *.lrp format - and it's just 
> a *.tar.gz file.

right, i know it's a tar.gz file.  (this is, of course, 
incredibly handy compared with something like rpm, that
supports signed content but is huge -- the rpm for rpm 4.0.4-i186
is 1.2MB.  not to mention that distributing the rpm program itself 
as an rpm presents an amusing circularity...)

so there is, the issue where to put the signed hash.

if it's within the tar file, you need a hashing program capable of
understanding the naming convention for that file, and ignoring it
when calculating the hash.

if it's a separate file it could get separated from the tar file.
but we already have <pkg>.txt files describing each of the lrps.
so why not <pkg>.sig files?

> Having said that, one of the things on my list of "ToDos" is to 
> change apkg to generate *.md5 for every file in the package for 
> checking purposes.  This would mean:
> 
> * When loading, the files would be checked using a list of files and 
> md5sums in <pkg>.md5
> 
> * When saving, this <pkg>.md5 file would be created on the fly and 
> saved.

saved where?  as a separate file, or part of the lrp file?

> 
> The main problem to date has been that not all things put in a *.lrp 
> are files - often they are directories, which cannot have a *.md5 sum 
> taken.
> 

hence the benefit of signing the entire package, including the
directories and their permissions.

i don't see a lot of advantage to calculating individual file hashes --
it would tell you which file(s) in a package were altered, but you'd still
have to run diffs to figure out just what the alteration was.

(i suppose one benefit would be that the order of files in the .lrp
would be unimportant.)

a single hash on the package would say *some* file was altered, and you'd
have to run diffs for exactly the same reason.

(the hashes are useful only if they can be reliably preserved.  any
bad guy deliberately altering a package would also deliberately alter
the hash file, hence the purpose of the signature).

> As a matter of record, I might note that Oxygen now comes with md5sum 
> loaded.  The challenge is this:
> 
> Given an input of:
> 
> /some/dir
> /some/wild*
> /some/file2
> /some/dir2/file*
> /some/dir2/dir*
> 
> Generate an output containing an md5sum of all files....
> 
> I've taken a quick stab at it - once I get busybox updated, it should 
> be nicer - the newest version contains support for find -type and 
> find -mtime ...and even find -perm ...
> 
> Should be easier (easy?) to do using find -type f ...
> 

or md5sum package.lrp >package.sig


> -- 
> David Douthitt
> UNIX Systems Administrator
> HP-UX, Linux, Unixware
> [EMAIL PROTECTED]
> 
> _______________________________________________
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/leaf-devel

-- 
mark seiden, [EMAIL PROTECTED], 1-(650) 592 8559 (voice) Pacific Time Zone

_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to