On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <gershomb@gmail.com> wrote:

On 4/9/14, 5:13 PM, Michael Snoyman wrote:

And this is where I think the PVP is doing a disservice with its current wording. Users have this expectation, but it doesn't actually hold up in reality. Reasons why it may fail include:

* Typeclass instance leaking from transitive dependencies.
* Module reexports leaking from transitive dependencies.
* Someone made a mistake in an upload to Hackage (yes, that really does happy, and it's not that uncommon).
* The package you depend on doesn't itself follow the PVP, or so on down the stack.

So my point is: even though the *goal* of the PVP is to provide this guarantee, it *doesn't* provide this guarantee. Since we have a clear alternative that does provide this guarantee (version freezing), I think we should make it clear that the PVP does not solve all problems, and version freezing should be used.

Along the same lines I am concerned about the expectation of security provided by SSL. As the recent Heartbleed bug shows, we have an expectation that we have security, but this may fail in practice. As such, even though the *goal* of SSL is to provide this guarantee, it *doesn't* provide this guarantee, and furthermore it is a pain to comply with, certificates are expensive, etc. Since we have a clear alternative that does provide this guarantee (one-time-pads coupled with dead drops and a system of code phrases), I think we should make it clear that public key encryption does not solve all problems, and other techniques should be used.

That's a flawed analogy, since:

1. I never suggested not using the PVP.

2. The *additional* tool I recommended (version freezing) is going to be cheap to use, since it's included in the tool everyone's already using (cabal).

3. Freezing has additional benefits not covered by the PVP, which we should be encouraging users to take advantage of anyway.

A better analogy would be: Given that SSL has some flaws:

* Possible buggy implementation

* Possible MITM attack

* Possible untrustworthy server

It's best not to send passwords over SSL in plaintext. Therefore, we recommend that when sending passwords, you use a client-side hashing scheme to avoid sending sensitive data to the server. This transport should still occur over SSL.

Michael 

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries