Abandoned vincenthz packages

[ysangkok]

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

[Kleidukos]

Related: haskell-infra/hackage-trustees#396

[frasertweedale]

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]

W.r.t. security, cryptonite is suboptimal because of kazu-yamamoto/crypton#22, fixed in crypton.

[frasertweedale]

W.r.t. security, cryptonite is suboptimal because of kazu-yamamoto/crypton#22, fixed in crypto

This particular issue seems somewhat tenuous. If the entropy from getRandomBytes is 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 cryptonite to crypton. 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]

I think we should find a way to preventively "flag" packages which have unmatched expectations.

[frasertweedale]

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]

@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]

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.

[juhp]

http-client-tls -> crypton, tls -> memory -> basement

http-client-tls has over 300 direct dependents in Hackage and 40+ in Stackage including pandoc and stack.

What is the recommended or suggested migration path?

Maybe foundation can be deprecated now though perhaps, along with cryptonite?
Maybe cryptonite can be deprecated now though perhaps?

[Kleidukos]

Yeah memory will have to be replaced. That would make one less indirection as well, which is good.