Proposal: Changes to the PVP

[Michael Snoyman]

On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <gershomb at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140410/ae2ae9cb/attachment.html>