- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 15 Sep 2014 15:20:30 -0400
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "Buzonas, Steve" <sbuzonas@carnegielearning.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Ideally, the patch format would carry something to do that. If not, we’d need some external means of verifying it (such as one of the various hash / signature mechanisms under discussion); the trick is to make sure what the hash/sig is applied to is clear. The other thing to think about when creating a patch format, btw, is whether the patch can manipulate stored HTTP headers; it might be worth coming up with some generic way to do that too (tho it’d be a bit ugly, I suspect, if it’s carried in headers). Cheers, On 12 Sep 2014, at 10:41 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > In message <CABkgnnWgA+cTwUcxF_kt1SQsmEz5X4=82G=do+3Vxtg24NaxZw@mail.gmail.com> > , Martin Thomson writes: >> On 11 September 2014 22:51, Buzonas, Steve >> <sbuzonas@carnegielearning.com> wrote: >>> Passing an MD5 sum won't really cut it either. Each hop could replace the value with whatever it decides to tack on. >> >> I think that the concern is accident here, not malice. > > That's my concern: How does the client know it got the right post-patch > result ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Mark Nottingham http://www.mnot.net/
Received on Monday, 15 September 2014 19:20:56 UTC