Pre-HFTP: Package security advisory database

Wrt freeze files and transitive deps: the next cabal version will have support for remote freeze files, so constraints that reflect vulnerable package versions could simply be hosted somewhere centrally and managed by hackage trustees or similar.

This wouldn’t really be a substitute for first class hackage support, but tools like dependabot would simply either automatically import said freeze file or inline it into the existing one.

References:

2 Likes

I think that is a really great policy that’s compatible with what I wrote:

  1. bounds do not enforce security

  2. bounds can be adjusted if that’s the only/best/simplest way to make the freeze file change not violate the bounds

I highly support us starting with this strategy. Just bumping freeze files / constraint files is the MVP. Adjusting bounds too so those bumps don’t just fail in the too-new corner case is a feature for the second release.

[In fact, auto sending PRs to try raising bounds and seeing how CI reacts could be beginning of a solution (not the entire solution!!) to the “upper bounds are annoying problem” in general. But I don’t want to derail with that contentious topic.]

Another thing to note about dependabot is that it seems closely tied to semver. This is noticeable in rust as rust has restrictions on top of semver (namely that 0.x → 0.(x+1) is also a breaking change),. Dependabot still considers this to be a minor update. Naive integration with dependabot may mean that it will not consider 2.1 → 2.2 to be a major update for Haskell. If 2.1 is vulnerable and fixes are available in 2.2 and 2.1.1, I think that dependabot would aggressively file a “semver-compatible” update to 2.2.

1 Like

The GitHub employee who we talked to indicated that they’re aware that different languages have different versioning schemes, and it seemed that as long as we provide a clear explanation of PVP, they can make it work. They already have to account for differing incompatible versions and interpretations of SemVer anyway, so I don’t think it will be a huge problem.

1 Like
>= 1.1 && < 1.1.234 || >= 1.1.235 && <= 1.2.8754 || >= 1.2.8755 ... && < 1.4

I’m not concerned about this in that packages already do this to avoid particular known-buggy releases, and having an advisory database does not change this situation in any particular manner. So it seems orthogonal.

I would think that the synchronization to Hackage could be a git pull, and that Hackage could otherwise be set to read our standard file format. Then, it can put links to advisories on each affected package/version page, along with the README, the maintainer, etc.

This is all rather technical architecture stuff here, but are you suggesting hackage runs a “git pull” of the advisory db? I would tend to prefer hackage itself continue to not run any pull based processes, and we instead have another tool (with authorization) that runs the pull and then uploads to hackage in a specified format. Internally, I think hackage should extend its datastructures to maintain a map of “packagename → [advisory]” and then query this on render, to keep the advisory feature as not-intertwingled as possible with existing functionality. I’m partially just sketching this for my own future reference.

I’m not sure that Dependabot would be sending MRs to adjust bounds in the first iteration. It can run in two modes - advisory mode, where it sends a private message to maintainers about potential dependency issues, and PR mode, where it actually sends PRs to adjust dependencies.

An important note, cabal supports “preferences.” I have the following in all my cabal.project files:

preferences:
    aeson          >= 2.0.0,
    bytestring     >= 0.11.3,
    text           >= 2.0.0,

Maybe dependabot could suggest this for “higher” preferences which are post-security-patch?

Interesting, I’ve never heard of that feature. I’m linking it here for others: 8. cabal.project Reference — Cabal 3.6.0.0 User's Guide

However, I’m not sure I understand your suggestion about using that with security bounds. Preferences are not necessarily satisfied by the solver, which seems inappropriate for security bounds. Maybe I misunderstood what you mean with “post-security-patch”?

No - please don’t take my comment as suggesting a specific bit of technology, just that we keep the repository as a central source of information on advisories, and that Hackage and Dependabot and all the other tools get it from there by some automated means.

1 Like

Well, I have mixed feelings about it being done manually today too :). But regardless, if it’s just an occasional practice of some people where there is no other good solution, it is hardly worth worrying about. If it becomes widespread due to the bot, then the practical extent to which such changes are “denormalizing” hackage increases a lot. The bottom line is, the default settings of the bot do send a normative message on what the recommended work flow, and so that deserves some discussion even if it veers on bike-shedding.

All that said, I am happy save further discussion of these details for the HFTP proper :). The basic idea is good enough to me to advance from a pre-HFTP to an HFTP, and that is a better venue for pining down such details.

1 Like

This kind of functionality would be a great addition to the Haskell ecosystem, especially when convincing clients and partners that software written with Haskell can power critical infrastructure.

4 Likes

Taking the community temperature here, it seems like most people are at least cautiously in favor, and some important points have been brought up.

In the interest of achievable goals and quick successes, I plan on writing a proposal that includes the bare minimum needed to get Dependabot alerts working. However, I’ll do so with an eye towards eventual integration into the rest of the Haskell tool ecosystem.

The initial phase will consist of only the following:

  • The advisory repository, including the format for advisories (which will be essentially the one used in Rustsec) and sufficient documentation for tool implementors
  • A specification of where advisory audit tools (such as Dependabot) should look for dependency versions.
  • A plan for governance and maintenance of the repository
  • Written sketches of designs for integration with tooling, written in collaboration with the relevant developers, to validate that the repository and format design do what we need them to do

I’ll post here and elsewhere when a first draft of the proposal is up. Thank you all for your feedback, and please let me know in this thread if anything else comes to mind in the meantime.

8 Likes

Great, because I started to get worried a little that we’re affiliating too strongly with github tooling here.

Apparently dependabot can be run on gitlab too, though: Running Dependabot on GitLab - JDriven Blog

Most developers are using Github today, and Github is concretely interested in improving the experience of Haskellers with these advisories. I’d like to help them help us! This means temporarily prioritizing the generally-useful things that they can use right now, rather than the other generally-useful things that we don’t yet have a collaborator on. I think this is the best way to help out Haskellers as quickly as possible.

But I also think it’s important that the things we develop are broadly useful in many contexts. Thank you for keeping that concern in your mind.

5 Likes

A whole bunch of the community doesn’t ever touch cabal-install and only use stack, so we’d also need to consider how stack would fit into this picture.

2 Likes

In my mind, either we should contribute to advisory audit tools, or generate different formats from our vulnerability descriptions.

I’m in favor of the second option, but it may be too soon to talk about it.

Good point, a bit early to talk about it, maybe providing a library could be a good way to let any tools use it.

1 Like

Also nice to have: Dependency graph adds vulnerability alerting support for Rust | GitHub Changelog

2 Likes

Agree with CVSS. Indeed the “authoritative” scores from CISA and National Vulnerability DB often disagree.
Something else potentially to include, which could help in prioritizing vulns, is checking to see if the vulnerability is in CISA’s Known Exploited Vulnerabilities Catalogue, which lists vulnerabilities that are known to be exploited in the wild (Reducing the Significant Risk of Known Exploited Vulnerabilities)

At long last, I’ve submitted the a more thought-through proposal at https://github.com/haskellfoundation/tech-proposals/pull/37 , which includes a suggested format and governance structure.

6 Likes

I thougt I’d leave this here https://twitter.com/JGamblin/status/1560016175265972224?t=hA543MQ3hU1vClS3x2LrzA&s=19

1 Like