Proposal: Changes to the PVP

[Carter Schonwald]

that analogue has a flaw,  CAs :), the MITM to rule them all, one time pads
are still needed to resolve that.

-2


On Thu, Apr 10, 2014 at 12:33 AM, Michael Snoyman <michael at snoyman.com>wrote:

>
>
>
> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140410/00998614/attachment.html>