Date: Sun, 22 Mar 1998 12:25:18 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Derek Flowers <djflow@portwwwbus.tc.cc.va.us> Cc: Wes Peters - Softweyr LLC <softweyr@xmission.com>, "Daniel O'Callaghan" <danny@panda.hilink.com.au>, stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <Pine.BSF.3.96.980322121221.358A-100000@trojanhorse.pr.watson.org> In-Reply-To: <Pine.BSF.3.96.980321132448.8704A-100000@portwwwbus.tc.cc.va.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 21 Mar 1998, Derek Flowers wrote: > > > Why not model it after RPM? If the size and md5 do not match, return an > > > error. Allow the user to overide the check if they wish to do so. > > > > > > Just to get a feel for pkg_add, what are the stpes taken to add the > > > software? I'm thinking the check could be done in the install script, > > > assuming it executes a script like make would. > > > > Errr. How do you know that the md5 is right? Digital signatures have to > > come into this somewhere :). Or secure trusted transmission (i.e., the > > HTTPS idea). > > Sorry, forgot to mention that RPM uses PGP fingerprints also. > > The MD5 can be stored on ftp.freebsd.org where everybody can check it. I think you fundamentally misunderstand. MD5's are a one-way hash of the data. They can be used for error checking, or for digital signatures. By default, they merely detect changes in the file -- but you need some way to verify that the hash you retrieve is correct! Two common approaches to this are shared secret and public/private key. In shared secret, there are two approaches: 1) Include the key in the data md5'd -- when verifying, append the shared secret, generate the md5, and compare. 2) Use the key to encrypt the md5, and ship that with the data. To verify, generate an md5, encrypt it with the shared secret, and compare the result. Both ways, you have the have the secret, which has to be distributed somehow. With public private key, they typical approach is to generate the md5, then encrypt that using the private key, and ship it along. When you want to verify, md5 the data, then decrypt the version sent along (using the public key) and compare them. Both ways, you have a key distribution problem. And both ways, you may need code that cannot be exported; at least, not in source code, and probably without a license. Either way, you cannot just "Store the md5s on ftp.freebsd.org" because there is no way to know that they are securely retrieved :). One answer is to use https and your netscape browser's certificate verification (and built in certificates). People download the browser in the clear (foolish), but now that they have it (and apparently trust it), we might as well take advantage of it. Key distribution is a fundamental problem; shipping out the public keys on the CD-ROM might not be a bad idea, btw. Robert Watson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980322121221.358A-100000>