What would you like in the next major version?

[briandfoy]

People have been asking for various things, so lets collect our thoughts on what the next major version might do for us. This way, we can plan changes that make it easy for all the new features rather than bolting on single features in a haphazard way.

If you don't have something for a new comment or a reply, simply leave a reaction to note your interest in the idea.

[briandfoy]

First, there's an issue for selectively ignoring some reports. For example, File::Temp has a long-standing issue.

[guest20]

Personally I'd want --ignore to work exactly like todo skips under Test::More, so folks get reminded to stop ignoring it when it gets fixed:

• When failing, warn "I ignored CVE-2011-4116 for File::Temp even though you rely in a vulnerable version", exit with 0
• When a fix is available, warn "CVE-2011-4116 in File::Temp is being ignored when a fix is available, pls install", exit 1
• When the fix is installed, warn "You're ignoring CVE-2011-4116 for FIle::Temp when you already have a fixed version installed", exit 0

Also:

The issue in question was raised along with 3 others on 04 Nov 2011... the other 3 are resolved by "use File::Temp::tempdir" patches... but the fix to File::Temp _is_safe the researcher submitted was merged, but was reported as not fixing the issue.

[briandfoy]

I'd like to have some flexibility in output formats. Outputting JSON allows middleware to easily make decisions on what to do.

[schelcj]

Looking at this and wondering a few things:

• Would you prefer adding a --json flag to output json or something like a --format json option allowing for different formats?
• When outputing a diffrent format should the --no-color be implied?
• Would the total advisories be included in the alternate output instead of separate print statements?
• Any formats in mind beyond json?

[briandfoy]

• If there's a --format json, then there would be a --json the would be a shortcut for it. But, I don't intend on providing any other formats. If you want something else, you can convert the JSON with whatever tool you like. That doesn't preclude a --format option though.

• Outputting a different format wouldn't use ANSI sequences to color anything. It's not like --no-color is implied, but more like no color is used at all.

• The total advisories would have to handled in some way in the alternate formats. Like a meta keys then an objects array of results.

[briandfoy]

@robrwo suggested an SQLite database to take the place of the Perl module. I've been thinking about that.

[guest20]

Having an writeable database makes good sense when pulling updates after installing the dist. I don't think the hard-coded list can go away because you have to get the initial set from somewhere (as long as the tool still needs to run without an internet connection)

Then there's schema migrations...

Having a scheduled agent to sync via json+http would add quite a lot of software/dependencies the dist too.

At it's heart it feels like doing database replication, in sqlite, from the internet to every dev who runs the tool sounds is the kind of suggestion that would get you banned from stack overflow...

[briandfoy]

Hm, distributing just the patches to the data is an interesting idea. However, it's certainly not something I have time to do in the short term. I think I'd have to devise a way to patch any version to any other version, or maintain all the "patches" from one version to the next version so someone could apply a series of patches to update.

This stuff doesn't necessarily need to be part of this dist. It could even be a separate dist that consumes the JSON data that I'm already producing.

Something to think about.

[robrwo]

I don't think we've updated it with newer data since we started reorganising external vulnerabilities into a separate structure. We should probably get that sorted.

[briandfoy]

I have one task left for this. All the external library data has been cleansed and I have the way to covert it to normal reports. I need to test it though and I haven't had a chance to do this.

[sjn]

Would it be sensible to try jumping through whatever hoops are necessary to have the database exposed through a MetaCPAN API endpoint?

[briandfoy]

Sure, I'd support that feature. I mean, the database is just a file and I need to get it to the point where it's a JSON file for easy consumption. Anything can read database file (even directly from the repo) and do whatever they like with it.

[robrwo]

See metacpan/metacpan-web#2698