Date: Wed, 14 Mar 2001 21:07:58 +0100 From: Adrian Chadd <adrian@freebsd.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314210758.A2405@roaming.cacheboy.net> In-Reply-To: <35525.984597779@critter>; from phk@critter.freebsd.dk on Wed, Mar 14, 2001 at 08:22:59PM %2B0100 References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 14, 2001, Poul-Henning Kamp wrote: > Adrian, > > That SITE MD5 would amount to innovation and progress. We don't do > that in FreeBSD (any more). > </IRONY> hah. > I think SITE MD5 should be added, so we can get some experience with > it. If it isn't a good idea, we'll drop it again, if it is, we > will propagate it. > > The only argument I've seen against was "Uhm, we want to loose our > current ftpd in favour of XXX" for some value of XXX. I don't think > it is important which version of ftpd we implement it in, so that > is hardly an argument against. I think o'brien and a few other irc people pointed out that you can't trust the md5 coming back from the user, so the only thing you *can* do is download the file and check it yourself. Ok, I've thought about this. Assume you trust the ports. If you trust the ports, you trust the URL(s) and MD5(s) in the port. But you don't trust the sites hosting the file. So, you can't trust that the returned filename, size, mtime or md5 are "real". Therefore, you have to download the file to verify. Ok, I understand that. So, working with an untrusted md5. If you don't trust the server itself for whatever reason (black/grey admin or hacker, or some "md5 caching" gone wrong) you can either ignore what it tells you, or treat what it tells you as a "hint". So, if you're downloading files for a port, you don't trust the md5 returned by the server - you md5 it and check it yourself. But, if you're mirroring and/or consistency checking, by trusting a returned md5 you're simply getting a false hit (or miss) and so you either download a new file, or you don't download a file at all. Think of those last two consequences. If you're consistency checking, you either end up wasting bandwidth, or recording a false positive. If you're wasting bandwidth, you still end up MD5ing the file. You would have downloaded it anyway, so there is no loss. Ok, that path is solved. If you record a false positive, then your automatic scripts don't pick up the inconsistency. So, when a user makes a port, he downloads the file, md5s it, finds it inconsistent. No change there. If you're mirroring, then consider the last two consequences again. If you're consistency checking, you either end up wasting bandwidth, or you keep your local copy. Since your local copy is already untrusted to start with, you haven't gained or lost trust. So, if you waste bandwidth- as mentioned before, you would have wasted the bandwidth to start with, so there's no loss. Next, if you recorded a false positive, then you don't change the local copy you already have. An black/grey admin or hacker could do this on a "master server" to propagate a bugged version, and then prevent the newer, perhaps bugfree version from propagating. *this* could pose a bit of a problem. However, the file is untrusted to start with, in the case of "ports" making the port already has an MD5, and without our MD5 checking the bad file will still stay there until someone fixes the server and uploads clean files. In the case of a black or grey admin, you're still screwed to begin with, because the servers aren't trusted. Hence, SITE MD5 doesn't make anything worse. The situation is already untrusted. Please, someone destroy my argument. Adrian -- Adrian Chadd "Programming is like sex: <adrian@freebsd.org> One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010314210758.A2405>