Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Mar 2001 11:50:45 -0700 (MST)
From:      Nate Williams <nate@yogotech.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        brooks@one-eyed-alien.net (Brooks Davis), roam@orbitel.bg (Peter Pentchev), freebsd-arch@FreeBSD.ORG
Subject:   Re: [PATCH] add a SITE MD5 command to ftpd
Message-ID:  <15025.3845.13790.411778@nomad.yogotech.com>
In-Reply-To: <200103150439.VAA01217@usr05.primenet.com>
References:  <20010314161555.A4984@Odin.AC.HMC.Edu> <200103150439.VAA01217@usr05.primenet.com>

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.

The client MD5 matching *is* a security features.  SITE-MD5 on an
ftp/http server is not, because the client is doing the security for
us.  At the remote site, it's an 'optimization' to avoid having to
download a file that isn't going to match anyway.



Nate

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?15025.3845.13790.411778>