Repository navigation
Abandoned vincenthz packages #187
Description
Mandatory information:
- Package : I think the most notable are
memory,foundation,basement - cvss: 8
- affected versions: Latest, and given that the packages are abandoned, no new release will ever happen.
Long 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
Reacted by Maxim Ivanov and Mihai Maruseac
Reacted by hasufell, Gautier DI FOLCO and Mihai Maruseac
Activity
Kleidukos commentedon Apr 8, 2024
Related: haskell-infra/hackage-trustees#396
frasertweedale commentedon Apr 10, 2024
Thanks 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.
Bodigrim commentedon Apr 12, 2024
W.r.t. security,
cryptoniteis suboptimal because of kazu-yamamoto/crypton#22, fixed incrypton.frasertweedale commentedon Apr 14, 2024
This 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).
blackheaven commentedon Jun 10, 2024
I think we should find a way to preventively "flag" packages which have unmatched expectations.
frasertweedale commentedon Jun 10, 2024
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.
ysangkok commentedon Jun 12, 2024
@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?
hasufell commentedon Jun 12, 2024
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.
juhp commentedon Jun 14, 2024
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?Maybe
cryptonitecan be deprecated now though perhaps?Kleidukos commentedon Jun 14, 2024
Yeah
memorywill have to be replaced. That would make one less indirection as well, which is good.