From owner-freebsd-arch Wed Mar 14 20:39:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id CD2E537B718 for ; Wed, 14 Mar 2001 20:39:12 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id VAA43732; Wed, 14 Mar 2001 21:38:57 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdePffUa; Wed Mar 14 21:38:56 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA01217; Wed, 14 Mar 2001 21:39:09 -0700 (MST) From: Terry Lambert Message-Id: <200103150439.VAA01217@usr05.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: brooks@one-eyed-alien.net (Brooks Davis) Date: Thu, 15 Mar 2001 04:39:09 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), roam@orbitel.bg (Peter Pentchev), freebsd-arch@FreeBSD.ORG In-Reply-To: <20010314161555.A4984@Odin.AC.HMC.Edu> from "Brooks Davis" at Mar 14, 2001 04:15:55 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is a reasionable objection to the implemention in question, but not > to the concept as a whole. If you just cache the MD5 and the mtime at > the time of the MD5 you only pay for files that have never been MD5ed > or have changed since you last MD5ed them. You could easily cache them > either in files the ftp server ignores like .md5. or in a > shared cache file. Neither would be all that difficult to implement. > The VFS option someone else mentioned could work the same way except > being more efficent. I suggested both of these (see other posts). > I'm frankly, completly mystified by the various comments about this not > being a security feature. Of course it's not. That's blindly obvious. I've always taken it as a security feature. I have to override the enforcement for a number of ports, and the only ill effects I have seen is that ...I have to override the enforcement for a number of ports. I always took it for granted that getting /usr/ports from a known source meant that I had the MD5s -- cryptographic hashes -- that would vet "known good" code from a random source as being the unadulterated version of the code. I really haven't thought about it from a "validation" persepective before this thread, since bad code in one spot is going to be mirrored everywhere, and so is a version number change with a deletion of the old version. In my personal experience, the code that fails the MD5 isn't grabbed from a different server in hopes of getting a copy that doesn't fail the MD5, so I'm just as screwed as if it weren't there. > As for the problem that many distfiles are distributed via HTTP, you > could trivialy build an apache module to add a non-standard HTTP header > so you could do a "HEAD /file/I/want/to/check HTTP/1.1" and get the MD5 > from that. Obviously you wouldn't always want it on and it wouldn't > work very well on dynamicaly generated content, but there doesn't seem > to be any problem with using it on distfile directories. The comments > above on caching the results apply here as well. Better to archive the file as an archive + an MD5 of the archive part, and abort the transfer after getting the MD5 part, if it's the wrong part. If you don't want to get as complicated as a MIME multipart, you could return an MD5 in an XML hunk, and a redirect. The whole idea of HTTP protection like this is pretty inane, since we've all already agreed, I think, that it's really only useful for mirroring, or for offloading an MD5 calculation from my 800MHz Pentium III laptop onto a big, ballsy 66MHz 486 FTP server. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message