Repository navigation
Abandoned vincenthz packages #187
Description
Activity
Related: haskell-infra/hackage-trustees#396
Reacted by Jens PetersenThanks for notifying us. SRT will begin working through this. If there are any other specific known issues in these packages, please drop them in comments here.
W.r.t. security,
cryptoniteis suboptimal because of kazu-yamamoto/crypton#22, fixed incrypton.W.r.t. security,
cryptoniteis suboptimal because of kazu-yamamoto/crypton#22, fixed incryptoThis particular issue seems somewhat tenuous. If the entropy from
getRandomBytesis compromised, hashing it doesn't help. I think this comment from the discussion sums it up well: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/_YZ_HcvwAwAJ.There already are strong reasons to move from
cryptonitetocrypton. The number of reasons will grow, and some of those reasons may warrant a security advisory. But this one doesn't.(SRT still needs to work through the other issues raised in this ticket).
I think we should find a way to preventively "flag" packages which have unmatched expectations.
GitHub has a way to indicate that a repo is unmaintained. Perhaps something similar? Formal deprecation seems wrong. And of course, we will issue advisories for any known security problems.
Reacted by Gautier DI FOLCO and Mihai Maruseac@frasertweedale Of the issues linked, which one do you think is the worst? I suppose "severe memory issues" is worse than an infinite loop? Or is the infinite loop better to announce because there is a PR with a proposed fix?
I think we should find a way to preventively "flag" packages which have unmatched expectations.
I'm not sure that's the job of the SRT though.
My impression is that it would be good to stay as neutral as possible and only adhere to the CVE process.
Maintenance status etc are practical information that are important, but they are not relevant to the CVE process on its own (except for contacting the mantainers, but the CVE may proceed in absence of response).
If stackage drops those packages, then that would already be a huge warning sign to the community.
It was also discussed whether the Haskell foundation could help to facilitate a list of "vetted" packages etc, but again, I feel it's out of scope of SRT and crossing that scope might upset some parts of the community.
http-client-tls->crypton,tls->memory->basementhttp-client-tlshas over 300 direct dependents in Hackage and 40+ in Stackage includingpandocandstack.What is the recommended or suggested migration path?
Maybefoundationcan be deprecated now though perhaps, along withcryptonite?
Maybecryptonitecan be deprecated now though perhaps?Yeah
memorywill have to be replaced. That would make one less indirection as well, which is good.Reacted by Jens Petersen
Mandatory information:
memory,foundation,basementLong description:
The packages by Vincent have been abandoned with known issues. Given that these packages are commonly used in networked applications, I think it would be prudent to use official communication channels to note that these packages have serious unpatched issues, some of which may already be triggerable from the network.
For example, here is an infinite loop discovered by GHC devs, which was identified and never addressed. The repo is now archived so the issue will presumably never get fixed: haskell-foundation/foundation#570
Neil Mitchell pointed out another issue: haskell-foundation/foundation#447