[Haskell-cafe] Improvements to package hosting and security

[Bardur Arantsson]

On 16-04-2015 14:18, Michael Snoyman wrote:
[--snip--]
> I never claimed nor intended to imply that range requests are non-standard.
> In fact, I'm quite familiar with them, given that I implemented that
> feature of Warp myself! What I *am* claiming as non-standard is using range
> requests to implement an incremental update protocol of a tar file. Is
> there any prior art to this working correctly? Do you know that web servers
> will do what you need and server the byte offsets from the uncompressed tar
> file instead of the compressed tar.gz?

Why would HTTP servers serve anything other than the raw contents of the
file? You usually need special configuration for that sort of thing,
e.g. mapping based on requested content type. (Which the client should
always supply correctly, regardless.)

"Dumb" HTTP servers certainly don't do anything weird here.

[--snip--]
> On the security front: it seems that we have two options here:
> 
> 1. Use a widely used piece of software (Git), likely already in use by the
> vast majority of people reading this mailing list, relied on by countless
> companies and individuals, holding source code for the kernel of likely
> every mail server between my fingertips and the people reading this email,
> to distribute incremental updates. And as an aside: that software has built
> in support for securely signing commits and verifying those signatures.
> 

I think the point that was being made was that it might not have been
hardened sufficiently against mailicious servers (being much more
complicated than a HTTP client, for good reasons). I honestly don't know
how much such hardening it has received, but I doubt that it's anywhere
close to HTTP clients in general. (As to the HTTP client Cabal uses, I
wouldn't know.)

[--snip--]
> I get that you've been working on this TUF-based system in private for a
> while, and are probably heavily invested already in the solutions you came
> up with in private. But I'm finding it very difficult to see the reasoning
> to reinventing wheels that need to reinventing.
> 

That's pretty... uncharitable. Especially given that you also have a
horse in this race.

(Especially, also considering that your proposal *doesn't* address some
of the vulnerabilities mitigated by the TUF work.)

Regards,