[Haskell-cafe] Ongoing IHG work to improve Hackage security

[Michael Snoyman]

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 at 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 at googlegroups.com.
> To post to this group, send email to commercialhaskell at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150416/87ffabf9/attachment.html>