Date: Sun, 22 Mar 1998 13:12:52 -0500 (EST) From: Derek Flowers <djflow@portwwwbus.tc.cc.va.us> To: Robert Watson <robert+freebsd@cyrus.watson.org> 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.980322130432.10969A-100000@portwwwbus.tc.cc.va.us> In-Reply-To: <Pine.BSF.3.96.980322121221.358A-100000@trojanhorse.pr.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Mar 1998, Robert Watson wrote: > 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 I see your point. What I was saying is that the md5 sums can be stored on a site where only the core members can change them. I think gnu is working on a public key encryption system that is free and availabe to people outside the US. Maybe it can be applied here. But you still have the problem of key distribution. You could post the public key on a site, but who is to say you won't have the same problem as with md5 distribution. Until a method of secure transfer is available, I think distributing the md5 sums on a known and reputable site is the best option. ---------------------------------------- Derek Flowers djflow@erols.com http://portwwwbus.tc.cc.va.us/~djflow "640K ought to be enough for anybody." -Bill Gates, circa 1981 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.980322130432.10969A-100000>