cabal-audit: add support for outputing as json using osv

[MangoIV]

This adds support for outputting found advisories as json by pairing a package name with a version and a list of advisories in osv format.

It also fixes some minor issues with printing etc

depends on #148

---

hsec-tools

• Previous advisories are still valid

[MangoIV]

{
  "base": {
    "advisories": [
      {
        "affected": [
          {
            "package": {
              "ecosystem": "Hackage",
              "name": "base"
            },
            "ranges": [
              {
                "events": [
                  {
                    "introduced": "3.0.3.1"
                  }
                ],
                "type": "ECOSYSTEM"
              }
            ],
            "severity": [
              {
                "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                "type": "CVSS_V3"
              }
            ]
          },
          {
            "package": {
              "ecosystem": "Hackage",
              "name": "toml-reader"
            },
            "ranges": [
              {
                "events": [
                  {
                    "introduced": "0.1.0.0"
                  },
                  {
                    "fixed": "0.2.0.0"
                  }
                ],
                "type": "ECOSYSTEM"
              }
            ],
            "severity": [
              {
                "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                "type": "CVSS_V3"
              }
            ]
          }
        ],
        "details": "# `readFloat`: memory exhaustion with large exponent\n\n`Numeric.readFloat` takes time and memory linear in the size of the\nnumber _denoted_ by the input string.  In particular, processing a\nnumber expressed in scientific notation with a very large exponent\ncould cause a denial of service.  The slowdown is observable on a\nmodern machine running GHC 9.4.4:\n\n```\nghci> import qualified Numeric\nghci> Numeric.readFloat \"1e1000000\"    -- near instantaneous\n[(Infinity,\"\")]\nghci> Numeric.readFloat \"1e10000000\"   -- perceptible pause\n[(Infinity,\"\")]\nghci> Numeric.readFloat \"1e100000000\"  -- ~ 3 seconds\n[(Infinity,\"\")]\nghci> Numeric.readFloat \"1e1000000000\" -- ~ 35 seconds\n[(Infinity,\"\")]\n```\n\n## In *base*\n\n`Numeric.readFloat` is defined for all `RealFrac a => a`:\n\n```haskell\nreadFloat :: RealFrac a => ReadS a\n```\n\nThe `RealFrac` type class does not express any bounds on the size of\nvalues representable in the types for which instances exist, so\nbounds checking is not possible (in this *generic* function).\n`readFloat` uses to `Text.Read.Lex.numberToRational` which, among\nother things, calculates `10 ^ exponent`, which seems to take linear\ntime and memory.\n\n**Mitigation:** use `read`.  The `Read` instances for `Float` and\n`Double` perform bounds checks on the exponent, via\n`Text.Read.Lex.numberToRangedRational`.\n\n\n## In *toml-reader*\n\nThe issue was detected in *toml-reader* version 0.1.0.0, and\nmitigated in version 0.2.0.0 by immediately returning `Infinity`\nwhen the exponent is large enough that there's no reason to process\nit.\n",
        "id": "HSEC-2023-0007",
        "modified": "2023-07-22T02:29:32Z",
        "published": "2023-07-22T02:29:32Z",
        "references": [
          {
            "type": "REPORT",
            "url": "https://gitlab.haskell.org/ghc/ghc/-/issues/23538"
          },
          {
            "type": "REPORT",
            "url": "https://github.com/brandonchinn178/toml-reader/issues/8"
          },
          {
            "type": "FIX",
            "url": "https://github.com/brandonchinn178/toml-reader/pull/9"
          }
        ],
        "schema_version": "1.5.0",
        "summary": "readFloat: memory exhaustion with large exponent"
      }
    ],
    "version": "4.17.2.1"
  },
  "toml-reader": {
    "advisories": [
      {
        "affected": [
          {
            "package": {
              "ecosystem": "Hackage",
              "name": "base"
            },
            "ranges": [
              {
                "events": [
                  {
                    "introduced": "3.0.3.1"
                  }
                ],
                "type": "ECOSYSTEM"
              }
            ],
            "severity": [
              {
                "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                "type": "CVSS_V3"
              }
            ]
          },
          {
            "package": {
              "ecosystem": "Hackage",
              "name": "toml-reader"
            },
            "ranges": [
              {
                "events": [
                  {
                    "introduced": "0.1.0.0"
                  },
                  {
                    "fixed": "0.2.0.0"
                  }
                ],
                "type": "ECOSYSTEM"
              }
            ],
            "severity": [
              {
                "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                "type": "CVSS_V3"
              }
            ]
          }
        ],
        "details": "# `readFloat`: memory exhaustion with large exponent\n\n`Numeric.readFloat` takes time and memory linear in the size of the\nnumber _denoted_ by the input string.  In particular, processing a\nnumber expressed in scientific notation with a very large exponent\ncould cause a denial of service.  The slowdown is observable on a\nmodern machine running GHC 9.4.4:\n\n```\nghci> import qualified Numeric\nghci> Numeric.readFloat \"1e1000000\"    -- near instantaneous\n[(Infinity,\"\")]\nghci> Numeric.readFloat \"1e10000000\"   -- perceptible pause\n[(Infinity,\"\")]\nghci> Numeric.readFloat \"1e100000000\"  -- ~ 3 seconds\n[(Infinity,\"\")]\nghci> Numeric.readFloat \"1e1000000000\" -- ~ 35 seconds\n[(Infinity,\"\")]\n```\n\n## In *base*\n\n`Numeric.readFloat` is defined for all `RealFrac a => a`:\n\n```haskell\nreadFloat :: RealFrac a => ReadS a\n```\n\nThe `RealFrac` type class does not express any bounds on the size of\nvalues representable in the types for which instances exist, so\nbounds checking is not possible (in this *generic* function).\n`readFloat` uses to `Text.Read.Lex.numberToRational` which, among\nother things, calculates `10 ^ exponent`, which seems to take linear\ntime and memory.\n\n**Mitigation:** use `read`.  The `Read` instances for `Float` and\n`Double` perform bounds checks on the exponent, via\n`Text.Read.Lex.numberToRangedRational`.\n\n\n## In *toml-reader*\n\nThe issue was detected in *toml-reader* version 0.1.0.0, and\nmitigated in version 0.2.0.0 by immediately returning `Infinity`\nwhen the exponent is large enough that there's no reason to process\nit.\n",
        "id": "HSEC-2023-0007",
        "modified": "2023-07-22T02:29:32Z",
        "published": "2023-07-22T02:29:32Z",
        "references": [
          {
            "type": "REPORT",
            "url": "https://gitlab.haskell.org/ghc/ghc/-/issues/23538"
          },
          {
            "type": "REPORT",
            "url": "https://github.com/brandonchinn178/toml-reader/issues/8"
          },
          {
            "type": "FIX",
            "url": "https://github.com/brandonchinn178/toml-reader/pull/9"
          }
        ],
        "schema_version": "1.5.0",
        "summary": "readFloat: memory exhaustion with large exponent"
      }
    ],
    "version": "0.1.0.0"
  }
}

[hasufell]

I suggest to build a proper URI parser. E.g. GHCup uses uri-bytestring:

• https://github.com/haskell/ghcup-hs/blob/be4a1bdf7a78f6783cba04de425b652d336192c3/lib-opt/GHCup/OptParse/Common.hs#L216-L217
• https://hackage.haskell.org/package/uri-bytestring-0.3.3.1/docs/URI-ByteString.html#v:parseURI

But network-uri probably does the job too:

• https://hackage.haskell.org/package/network-uri-2.6.4.2/docs/Network-URI.html#v:parseURI

[MangoIV]

what would be the immediate advantage of that? I don't want to pass in my files as file:// etc.

[hasufell]

what would be the immediate advantage of that? I don't want to pass in my files as file:// etc.

I'm not talking about filepath, but the URI options (for the git repo). Users passing malformed URIs will get errors once your code tries to git clone instead of directly.

[MangoIV]

yeah, this assumes that you will pass a proper git cloneeable URI, I don't know if the advantage of proper parsing and writing a bunch of handlers outweigh the advantage of the simplicity of this, for now? I can add this as future work to the tracking issue, though, if that's okay with you?

[hasufell]

cabal-audit --help prints this:

Welcome to cabal audit

Usage: cabal-audit [(-p|--file-path FILEPATH) | (-r|--repository REPOSITORY)]
                   [--verbosity ARG] [-o|--osv FILEPATH]

  audit your cabal projects for vulnerabilities

Available options:
  -h,--help                Show this help text
  -p,--file-path FILEPATH  the path to the repository containing an advisories
                           directory
  -r,--repository REPOSITORY
                           the url to the repository containing an advisories
                           directory
  -o,--osv FILEPATH        whether to print to a file of osv, mapping package
                           name and version to an osv
cabal-audit failed:
ExitSuccess

cabal-audit failed: ExitSuccess is a bit confusing, innit?

[MangoIV]

@hasufell this is fixed on the branch you're reviewing. I should backport to the other branch though, you're right.

[MangoIV]

(that's because optparse-applicative uses exitSuccess and exitFailure on its own.

[MangoIV]

@hasufell thank you for the review, btw, much appreciated <3

[blackheaven]

Hello Mango,

Sorry for the delay, we had a meeting last Wednesday and it seems there is a miscommunication regarding our response.

The thing is, we have discussed about your pull request and we would like to start a discussion with you about it.

We think that your contribution may be more suited in it's own repository (either under your GitHub handle, or @haskell), there are few reasons for that:

• The HSRT (group of people managing this repository) was create to handle security breaches in the Haskell ecosystem, along the way we have started to collaborate with maintainers to prevent vulnerabilities, eventually providing a basic tool-set. Currently we have not decided whether we will broaden our mission statement.
• We are concerned about the contributions barrier is would create hosting cabal-audit in this repository.
• We expect/hope that this tool would be merge "soon", to make cabal secure by default.

WDYT?

[MangoIV]

Yeah sure, that’s possible. I thought it would be suited for this repo as it was part of the stated longer term plan of the security working group but thats totally fine. I’ll publish this tool separately then. I will put it into my own git until it finds a final place after some adoption. Thank you for the kind review and time spent on this, all of you ❤️

[MangoIV]

This PR was rejected because it is currently out of scope for the security-avisories team. Please find the work at github.com/mangoiv/cabal-audit