I've read the blog post, and am still trying to understand the implications of TUF. However, it's incredibly difficult to give solid review of a system which is stated to be "based on TUF," without knowing what the delta implied by that is. For now, I can only ask simple questions:
1. Is there any timeline for the changes needed to Hackage and cabal-install?
2. Is there any idea of how much extra code will need to be maintained going forward for this? This is an important point, given that both Hackage and Cabal are having trouble keeping up with demand already.
3. Is there any mitigation of eavesdropping attacks on the authorization headers sent to Hackage by uploaders for digest authentication?
4. Is there any mitigation against a compromise of the Hackage server itself, either the code base or the system?
Overall, I'm quite wary of a solution stated as "experts devised this, it's good, we'll implement it, everyone stop worrying." I take your point about crypto-humility, but I'm not confident that an approach based on TUF addresses that concern since it involves a new implementation (or copy-pasted implementation) of crypto primitives together with unspecified changes to TUF.
Note: wary is *not* a code word for opposed, but I strongly believe that anything we do here warrants far more discussion, and that can't happen until more details are explained.
On Thu, Apr 16, 2015 at 12:33 PM Duncan Coutts <
duncan@well-typed.com> wrote:
All,
The IHG members identified Hackage security as an important issue some
time ago and myself and my colleague Austin have been working on a
design and implementation.
The details are in this blog post:
http://www.well-typed.com/blog/2015/04/improving-hackage-security
We should have made more noise earlier about the fact that we're working
on this. We saw that it was important to finally write this up now
because other similar ideas are under active discussion and we don't
want to cause too much unnecessary duplication.
The summary is this:
We're implementing a system to significantly improve Hackage security.
It's based on a sensible design (The Update Framework) by proper crypto
experts. The basic system is fully automatic and covers all packages on
Hackage. A proposed extension would give further security improvements
for individual packages at the cost of a modest effort from package
authors.
http://theupdateframework.com/
It will also allow the secure use of untrusted public Hackage mirrors,
which is the simplest route to better Hackage reliability. As a bonus
we're including incremental index downloads to reduce `cabal update`
wait times. And it's all fully backwards compatible.
I should also note that our IHG funding covers the first phase of the
design, and for the second phase we would very much welcome others to
get involved with the detailed design and implementation (or join the
IHG and contribute further funding).
--
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
--
You received this message because you are subscribed to the Google Groups "Commercial Haskell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commercialhaskell+unsubscribe@googlegroups.com.
To post to this group, send email to commercialhaskell@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/1429176835.25663.30.camel%40dunky.localdomain.
For more options, visit https://groups.google.com/d/optout.