[Haskell-cafe] Improvements to package hosting and security

[Bardur Arantsson]

On 17-04-2015 05:34, Michael Snoyman wrote:
> AFAIK, neither of these proposals as they stand have anything to do with
> security against a malicious server. In both cases, we need to simply trust
> the server to be sending the right data. Using some kind of signing
> mechanism is a mitigation against that, such as the GPG signatures I added
> to all-cabal-files. HTTPS from Hackage would help prevent MITM attacks, and
> having the 00-index file be cryptographically signed would be another
> (though I don't know what Duncan has planned here).

Well, TUF (at at least if fully implemented) can certainly limit the
amount of damage that a malicious (read: compromised) server can do.
Obviously it can't magically make a malicious server behave like a
non-malicious one, but it does prevent e.g. the "serve stale data" trick
or Slowloris-for-clients*.

(*) By clients knowing up-front, in a secure manner, how much data there
is to download.

>> [--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.
>>>
>>
> 
> All of that said: the discussion here is about efficient incremental
> downloads, not package signing. For some reason those two points are
> getting conflated here.

I think you might not have been very clear about stating that you were
limiting your comments in this subthread to apply only to said
mechanism. (Or at least I didn't notice any such statement, but then I
might well have missed it.)

Another point is: It's often not very useful to talk about things in
complete isolation when discussion security systems since there may be
non-trivial interplay between the parts -- though TUF tries to limit the
amount of interplay (to limit complexity/understandability). Not
necessary a major concern in this particular subsystem, but see (*)

Regards,