Which way would you like to refresh the advisory data for CPAN::Audit?

[briandfoy]

At the moment, CPAN::Audit updates the data it uses by releasing a new version of itself. Even if the code has not changed, the versions of the module and tools change. That gives the appearance of change where there is none.

Because CPAN::Audit has done this from the start, I don't want to change this suddenly. And, perhaps change it in a way that makes multiple methods of data update available. At least for awhile, I'll keep doing what we are doing and phase in another way.

There are not necessarily exclusive:

• Option 1 is to do nothing new.
• Option 2 is the break out CPAN::Audit::DB into another module that you can update separately.
• Option 3 is to get the data as a JSON file (perhaps loaded from the command-line with a switch)

No matter which way you get the file, it will be signed with the same GPG key. Additionally, the release on GitHub will be verifiable through GitHub Attestations .

[renderorange]

I thought about it again after submitting, but it won’t let me change my answer. Breaking it out into a DB package is a better choice. Final answer.

[schelcj]

I'd actually prefer both options 2 and 3. Initial install via separate DB module but a switch to download new definitions for use in CI jobs.

[guest20]

It seems like the best option here would be to make one change, and that is adding a cpan-audit --update-database so it's easier to change how the database is distributed/loaded in the future

Putting the update mechanism into the tool (in a pluggable way, ideally) means that users don't have to choose between installing via cpan / carton / curl / etc when they set up the audits

Edited I did a bad job of explaining myself the first time.

[briandfoy]

Yeah, updating like that should be a feature. However, one of the big decisions in CPAN::Audit was its usability in air-gapped systems. That doesn't mean we can't have auto-updates, but we should think carefully about how we trust what we get.

I've just finished converting all the reports to v2, and the stuff on the cpan-security-advisory can now output JSON. The dev version of cpan-audit can read a local json file. Now the trick is figuring out how to distribute that JSON in a way that allows people to verify its authenticity. The database is already GPG-signed, and we can use GitHub Attestations, so that's mostly solved.

This would take a local file that you can check on your own in separate steps:

cpan-audit --json /local/path/to/cpan-security-advisory.json

But the lower risk environments might fetch that directly, perhaps from a local resource that everything on the private network shares, or maybe just the internet:

cpan-audit --json-network https://...
cpan-audit --json-network @latest 

Or something close to that, I think.