Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Feature Request - ProGet - Update vulnerability list if a package is not available in any feed
-
If a package is listed with vulnerabilities and the package is removed from all feeds. The vulnerability is still listed.
Suggestion: have a scheduled task that refresh the vulnerability list with packages that are available from ProGet, not those that are unlisted or deleted entirely.
Cases:
We remove internalized chocolatey packages that are older than 10 versions. It doesn't make sense that we have to assess those packages eventhough they are removed. Earlier versions of Firefox (around version ~80 and downwards) have a multitude of vulnerabilities that fills the Vulnerabilities view, they persist even after the packages aren't available on the server.
-
@harald-somnes-hanssen_2204 thanks for the Feature Request, definitely makes sense to me!
Just a couple things to consider / think about, on our end, from an implementation point.
-
How do you remove internalized chocolatey packages? Is this using the Package Retention Rules feature? Maybe it would make sense to add a deletion as part of this process.
-
How many excess/outdated vulnerabilities do you have now? Handful? Dozens? Hundreds?
-
-
How do you remove internalized chocolatey packages? Is this using the Package Retention Rules feature? Maybe it would make sense to add a deletion as part of this process.
Manually by version, where the version is either removed entirely or unlisted .. very ineffective.
Having the option to actually consider unlist or delete as part of the process would be more helpful than the current assessment (which lasts for 90 days ..)How many excess/outdated vulnerabilities do you have now? Handful? Dozens? Hundreds?
Firefox has so many that it's hilarious
This is the currenty view in our Proget Instance:
-
@harald-somnes-hanssen_2204 that's... a lot of vulnerabilities
I did just want to confirm this bit...
Manually by version, where the version is either removed entirely or unlisted .. very ineffective.
Are you referring to deleting/removing vulnerabilities, or the packages themselves? Are you using "retention rules" to clean-up the old chocolatey packages?
Basically the feature idea I'm thinking essentially a checkbox on the Retention Rules, where it deletes the vulnerabilities when the package is deleted, if no other packages are using it. That seems like the easiest and most explicit way to manage going forward
-
@stevedennis said in Feature Request - ProGet - Update vulnerability list if a package is not available in any feed:
I did just want to confirm this bit...
Manually by version, where the version is either removed entirely or unlisted .. very ineffective.
Are you referring to deleting/removing vulnerabilities, or the packages themselves? Are you using "retention rules" to clean-up the old chocolatey packages?
Basically the feature idea I'm thinking essentially a checkbox on the Retention Rules, where it deletes the vulnerabilities when the package is deleted, if no other packages are using it. That seems like the easiest and most explicit way to manage going forwardI'm referring to the deleting/removing vulnerabilities.
Yes, we are using retention rules to remove old chocolatey packages. We currently allow 10 versions of each package, anything older gets deleted.A checkbox sounds like a good idea.
-
Thanks @harald-somnes-hanssen_2204 !
This seems like a low-risk way to handle this going forward. We'll track this via PG-1924; note it's currently planned for the next maintenance release, so hopefully it'll be there soon!
In the meantime, if you've got a ton of vulnerabilities, we could help construct a database query to help with a one-off purge. But it might be easier to just click away, too
-
Hi @harald-somnes-hanssen_2204,
Unfortunately this got pretty complex, pretty quick due to the way these are stored (in ranges, per package type).
In order to clean-up vulnerabilities, we will need to scan all feeds of that type, then it's packages, and then do version comparisons. So it would need to be a separate Vulnerability Cleanup job (as you originally suggested), and not a retention rule.
It's unfortunately not an easy engineering task on our end, especially since it could be quite resource intensive, depending on number of vulnerabilities / packages.
All the mass-clicking seems to be really annoying for sure, but we just need to evaluate the engineering costs/effort of this feature, with the benefits alternatives. For now, we should wait to see if anyone else expresses interest or issues with managing vulnerabilities.
I want to also note that... we do have a project on the horizon for a kind of multi-selecting UI table (where you could do bulk operations on selected items), and perhaps that would help here instead
-
At the very least, a bulk operation would help.
