Maven Policy not blocking Noncompliant packages

[parthu.reddy]

Hi Team

We created a License WTGBL so that it blocks few log4j-core versions from being downloaded. But when we do that it's not stopping the package from being downloaded for the first time. After that it's blocked.

Proget version: 2024.13

Thanks

[atripp]

Hi @parthu-reddy,

I'm not sure about the specifics of how you've configured this, but in general, the "first download not blocked behavior" is to be expected with certain types of license checking.

Depending on how the author configured the license, ProGet cannot detect a license without the package file... so until the package has been added to the feed in ProGet, (via caching) happens it's considered "Undetected". In your Policy, you have that as "Warn", so it won't be blocked.

It's not technically feasible to handle this any other way, as ProGet streams the file it's downloading from a remote source to the user while also adding it to the feed for caching.

Thanks,
Alana

[parthu.reddy]

Hi @atripp

Actually we created a license WTGBL and assigned it to a package that doesn't have any license. and the packages that have this license should be noncompliant.

So when we try to download it shouldn't we stop it without downloading even for first time.

And our team suggested that if some license type are only known after downloading full package, it would be possible to discard those without saving. Is this possible to do from your end?

Why this is needed:
Our security team told that there are few files on the machine that doesn't meet security standards. And few versions of this package shouldn't be available on the machine itself.

Thanks
Parthu

[atripp]

Hi @parthu-reddy ,

If you can provide my with some step-by-step instructions (reproduction case), then I can see if if there's a bug in ProGet. However we can't really change the "license file is embedded in the package file" technical requirement.

That said... using custom licenses for blocking package is definitely inappropriate. Please do not do that. It will cause you headaches and probably business disruptions later. There are already tools to prevent users from downloading packages from ProGet, this is not how you want to do it.

The easiest solution here is to align the security team's understanding/expectations align with reality. You don't want to try to configure ProGet in unrealistic ways that will lead to actual problems/risks.

I suspect the security team is conflating "vulnerable packages" with "malware and viruses", so it'd be best to take this opportunity to educate them on how packages / ProGet works.

1. ProGet can prevent users from downloading certain packages, but vulnerable packages are freely available on the internet for download.
2. A vulnerable package is NOT some a "virus in a lab that can escape" and infect a system
3. A package is just a library and cannot run on its own
4. If a user has a copy of vulnerable package, they can't use it to "hack" a system with it nor will it cause any harm
5. Vulnerable packages simply shouldn't be used as building blocks in your own applications

Thanks,
Alana