Date: Thu, 15 Mar 2001 04:39:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brooks@one-eyed-alien.net (Brooks Davis) Cc: tlambert@primenet.com (Terry Lambert), roam@orbitel.bg (Peter Pentchev), freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <200103150439.VAA01217@usr05.primenet.com> In-Reply-To: <20010314161555.A4984@Odin.AC.HMC.Edu> from "Brooks Davis" at Mar 14, 2001 04:15:55 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.<filename> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103150439.VAA01217>