Avoiding cryptonite-verse packages in your dependency closure

1

At work, I was upgrading the crypton-x509* packages to avoid the vulnerabilities published in the HSEC advisory. The new versions of these packages released with the fixes now depend on ram instead of memory which was kind of an issue because many packages still use memory over ram.

While I have upgraded / forked all the packages that bring in the cryptonite-verse, it’s still possible that a new cabal plan can still bring them into the closure, so here’s how I am currently outlawing dependencies bringing in cryptonite, memory, asn1-*.

-- file: cabal.project.local
constraints:
  cryptonite < 0,
  memory < 0,
  crypto-pubkey-types < 0,
  asn1-types < 0,
  asn1-encoding < 0,
  asn1-parse < 0,
  hourglass < 0,
  pem < 0

you can also directly import this gist that has the same constraints

-- file: cabal.project.local
import: https://gist.githubusercontent.com/pranaysashank/11fb5bc36b0c71ba7f69e8e2d980340f/raw/no-cryptonite-memory-asn1-universe.project
14 Likes
2

So cryptonite and deps are just sitting on Hackage with vulnerabilities?

Is there a way for Hackage to mark them as bad so cabal won’t plan for them unless the user explicitly overrides it? I know it says it’s deprecated but that doesn’t feel like enough.

Feels like a pretty important feature! Given the maintainer refuses to do any maintenance but also refuses to allow people to contribute in order to fix vulnerabilities.

2 Likes
3

We have the advisory database and the cabal-audit tool that uses it: GitHub - MangoIV/cabal-audit: audit your cabal projects for haskell-specific security-advisories · GitHub

I got that info from this blog post: Overview of Haskell security tooling | The Haskell Programming Language's blog

1 Like
4

I think there are plans to mark a package as vulnerable like how it is done for deprecated packages.

Though this post is not about the vulnerable packages, it’s about avoiding all the packages abandoned in the cryptonite universe

1 Like
5

cabal audit is useful but top-down and opt-in.

i think hackage should be able to flag packages as vulnerable in a bottom-up, opt-out way. for our own safety.

like those constraints @pranaysashank put in that gist should be the default unless the user says “i know what i’m doing”

3 Likes