Hackage is flooded with old package versions reuploads

[David Feuer]

It would be best to be sure to make the maintainer (if there is one) aware
of such changes. That said, not every package has a responsive maintainer,
and *someone* has to do this work, and do it promptly. A signed hash
failure does not introduce a security hole, unless you count a sort of
semi-manual, avoidable denial of service. If you don't trust Herbert and
Austin, you probably shouldn't bother trying to use Haskell anyway.
On Jan 18, 2015 6:05 PM, "Vincent Hanquez" <tab at snarc.org> wrote:

>
> On 18/01/2015 09:56, kyra wrote:
>
>> Hi, guys,
>>
>> It looks old (and even ancient) versions of many packages gets uploaded
>> to hackage over and over again in ever increasing amounts. The username of
>> uploader for vast majority of these uploads is HerbertValerioRiedel.
>>
>> While this is harmless I wonder what idea stands behind this?
>>
> This is not harmless. This is a security issue by itself, as now packages
> get changes transparently given a url, you might have a different package
> one day, which trigger hash check failure. or signed tag verification
> failure.
>
> This has also the effect of not changing the bounds in the repository, so
> for example, next time you upload a tweak'ed packages, you effectively
> revert the change done on hackage only.
>
> This is also done without the consent of the maintainer of a given
> package, nor that the maintainer is actually notified when that happens, or
> allow to prevent it happening. This is pretty big start from the other
> similar policy for taking over packages, that insist on a very long period
> of repeated communication with the author and then the community.
>
> The whole thing is at best ill advised,
> --
> Vincent
> _______________________________________________
> 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/20150118/0a1bc585/attachment.html>