Enforcing Licence Policies/Blocking?

johnsen_7555

Hi,

I'm in the process of evaluating ProGet as a solution for improving our software supply chain controls. To that end I've deployed ProGet Enterprise edition, version 2024.8 build 10, to a Kubernetes cluster with a trial licence and am currently trialing it's licence-based download blocking.

A Python feed has been configured as follows in terms of its policies and blocking behaviour:

The global settings are applied to the feed which are to block anything noncompliant:

However, in the box on the policy page it says that downloads are not blocked:

And indeed if I try to download and install a GPLv3 licensed package into a test virtual environment I'm not encountering any issues:

The test user in question has been explicitly only permitted to view and download packages from this one feed:

Can you please point me in the right direction for enforcing the licence/vulnerability blocking?

Many thanks,
Stian

dean-houston

Hi @johnsen_7555 ,

Thanks for sharing all of the configuration details; can you navigate to one of the GPL packages that you're trying to install, and see what it says on the package page within ProGet?

On that page, you can also ReAnalyze the package (using the dropdown button ) and get a log of which policies/rules were applied.

-- Dean

johnsen_7555

Hi Dean,
Thanks for the quick response. Here's an example called abydos where I even set the status to always block downloads:

Not even the download of this package is blocked.

Here's another example, the one whose download is shown above, plover-consol-ui, which again as expected shows it as noncompliant:

dean-houston

Hi @johnsen_7555 ,

Thanks for sharing the additional details; I was able to reproduce this, and its a regression/bug.

We fixed this via PG-2723 (FIX: Noncompliant Pypi packages can be downloaded when blocking is enabled on trial licenses), which is going to be shipped in the next maintenance release.

However, in the mean time, you can try a patch/prerelease version that contains the fix; since you mentioned Docker, the tag to pull would be 24.0.9-ci.1.

Hopefully that will solve the issue!

-- Dean

johnsen_7555

Thanks, Dean. This new build does indeed resolve the issue:

Have a good weekend.