Date: Thu, 15 Mar 2001 00:08:23 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Matt Dillon <dillon@earth.backplane.com>, "David O'Brien" <TrimYourCc@NUXI.com>, Brooks Davis <brooks@one-eyed-alien.net>, freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <p0501040ab6d5f1cb0b56@[128.113.24.47]> In-Reply-To: <200103150256.f2F2u1b37896@earth.backplane.com> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> <200103150256.f2F2u1b37896@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:56 PM -0800 3/14/01, Matt Dillon wrote: > Doesn't SITE MD5 introduce a race condition? What if someone > does a SITE MD5 and someone else then renames or modifies the > file before the first person proceeds to download it? And what awful thing will happen then? You can still MD5 the result after you've received it. You will be no worse off than if you simply downloaded the file without doing the MD5. > Also, why bother doing an MD5 on the remote site if 99.9% of > the time you are going to get a match and download the file > anyway? You might as well download it first. If you're going to download it anyway, then there is zero point to doing the MD5. The way I'm reading this option, the ONLY reason to do an MD5 is to try and *-AVOID-* doing a download. That is all I want it for, at least. > Or perhaps simply check the size of the file for a match > (e.g. enhance ports to include the file size to check > against in addition to the MD5), then download it, then > do the MD5 on the local box. I do not agree that SIZE is an adequate check. I have had plenty of times where the size of a file did not change, even though the contents did. Therefore, when a file on a ftp server is the same size as a file I already have, I may still decide to download that file, "just in case it is different". I *have* done that in the past, and there are times when it *was* different, and therefore I keep downloading files. > I just don't see much point in adding a command to FTP that > isn't going to be generally useful and has security holes > in it to boot. The only "security hole" that I see in this is a possible DOS attack (or at least, reduction-in-service), by someone forcing an ftp server to MD5 a massive number of files. I must admit that I am a little uneasy about that. Perhaps implement it so the MD5 calculation is always done at minimum (nice) priority. People seeing this as some kind of security threat misunderstand what it's intent is. I want to know "is the file on the FTP server exactly the same as a file I already have?", and it would be nice to answer that question without having to download the entire file. If it IS exactly what I already have or already know about, then there is no point in me downloading it. If it is NOT, *then* I would want to download it. I would not blindly trust it after downloading it, as that is patently stooopid. I just want to know if it would be a waste of time to download the file before I type up my modem line for a half hour. That is all. Other than the concern about CPU time on the server, I don't see what the problem is. I have trouble believing that it will ever be less load on an ftp server to MD5 a file than it will be for the remote user to download the entire file. Remember, I want this to AVOID doing the download in the first place, and not just as some stupid waste-of-time extra step to do before every download that I intend to do. If I do not already have a file, then I'm going to download it. I am not going to MD5 it. I am puzzled by this thread, but then I also tried to put my shoes on the wrong feet this morning, so maybe I'm just having a bad day. Perhaps we need to use a different name for the option, as some people seem obsessed in thinking that this MD5 digest has something to do with security. I see it as having ABSOLUTELY NOTHING to do with "security". I just want to avoid a download if there is no point in me doing it. Call it: site md5toAvoidDoingADownload filename It seems to me that we could start out doing this as a 'site' command (as long as it isn't me who has to write it...), and see how it goes. If it sucks, then we'll drop it. If it is useful, then, well, it is useful. In a separate message, Terry Lambert wrote: >if everyone is in >love with the SITE MD5 thing, at least make it so it will >prefer the contents of a "site.md5" file in the directory >to doing recomputation, or, even better, will cache MD5, >filename, and timestamp, look at the timestamp for the name, >or if the name doesn't exist, MD5 it, and cache the new value, >and if the timestamp is equal, return the cached value. I like some of these ideas. As I say, my only misgiving about this MD5 idea is the potential for excessive CPU load on the server. Anything which reduces that would be welcome, I think. Er, when he says "prefer a site.md5 file", I assume that the ftp daemon itself would be keeping that md5 file up-to-date. I would not trust a person to do it. Ie, the daemon would basically cache the answers in some filename, instead of in virtual memory... The added benefit of that is some external process could just download that file, and get MD5's for all the files in that directory at one shot. The file might not really be in that directory on the ftp server, but it would look like it is to someone connecting via ftp. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu 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?p0501040ab6d5f1cb0b56>