Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

integration for cabal #145

Open
3 of 8 tasks
MangoIV opened this issue Feb 4, 2024 · 5 comments
Open
3 of 8 tasks

integration for cabal #145

MangoIV opened this issue Feb 4, 2024 · 5 comments

Comments

@MangoIV
Copy link
Contributor

MangoIV commented Feb 4, 2024

Summary

It would be nice to have a cabal integration, like cabal audit that can build a report for a cabal package, now that you can write plugins for cabal.

  • printing human readable
  • printing to json
  • instead of running in IO, use more fine grained stack to allow some nice changes in a clean way, e.g. outputting without colouring, cf. https://no-color.org/
  • querying for newer packages on hackage
  • Add option —dont-solve that compares against the parsed version range in the stanza instead of solving the project. This would be useful for e.g. libraries
  • pass through arguments from cabal and show cabal help text
  • both for URI parsing (for git clone and filepath parsing, be clever about creating directories and showing errors
  • not planned offer API to request security advisories #166
@frasertweedale
Copy link
Collaborator

This ticket can be a bag-of-holding for any and all work we need to do in the advisory-db and associated libs/tools, to support such features in cabal-install.

@MangoIV
Copy link
Contributor Author

MangoIV commented Mar 31, 2024

Now that I think about it; what kinda machine readable format would be best suited to output vulnerabilities for some project? Perhaps there’s already something pre-made I can output instead of coming up with my own serialisation format. Any ideas?

@frasertweedale
Copy link
Collaborator

@MangoIV it depends. If you want compatibility with a wide range of tooling, a bundle of OSV objects would be a good option. But some information may be lost, or the usefulness of the info may be degraded, in that transformation (e.g. some fields would be "database specific" and not understood by generic OSV tooling).

On the other hand, if you are mainly concerned about Haskell-specific tooling, whatever our archive/distribution format ends up being (#170) would seem to be a good option, assuming you can slim it to the subset of advisories you are interested in.

@MangoIV
Copy link
Contributor Author

MangoIV commented Apr 1, 2024

@frasertweedale see my follow up PR for what I’ve decided to do, perhaps you have some input?

@MangoIV
Copy link
Contributor Author

MangoIV commented Apr 1, 2024

Also perhaps if we could get the first PR merged, would be easier to review the second 😅 (don’t wanna pressure though)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants