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,