Many thanks for that proposal, Steve! The warning label in conjunction with dumping of the package cache sounds like it is worth exploring. I shall discuss it with my security and governance collaborators :-)

Thanks for the reply, Steve.
The main problem with the conventional approvals workflow you linked to is the lack of sufficient approver capacity. Hence, the plan is run a setup that allows packages through unchallenged if their licences are acceptable and there are no recorded vulnerabilities. I'm aware of the typo squatter and malicious insider, etc. risks that this does not address.

At any rate, the idea above was that if a package fails that first filter, it can be automatically quarantined and flagged for review. Upon review, if approved, that same package can then via the "manual" promotion mechanic that you reference be inserted into the general feed, and found and consumed by its users via their standard index URL. To achieve this ProGet would need to notify a service that orchestrates this process, that in turn inserts the package into the quarantine feed and notifies the approvers.

Many thanks for the explanation and the link, Steve!

One key objective of this exercise is to arrive at a mostly automated workflow. One way I can still see this being achievable despite the lack of the special metadata API in the ProGet feed is to set up a second quarantine feed that only contains packages blocked by a first, main feed that connects directly to pypi.org but with very restrictive compliance settings.

Could the following webhook provide those events to drive this quarantine workflow:

Hi Steve

Thanks!
No, the python-accessible feed is not directly connected to Pypi, instead it uses passthrough-test-python as its upstream source, that in turn is connected 3rd party feeds including pypi.
Only the python-accessible has blocking policies configured, while passthrough-test-python is configured to pass through non-compliant packages.

If I try to list packages in the python-accessible feed I get:

However, I can successfully retrieve packages from the internal usptream feed when entering the exact package name, as instructed:

Digging into the package, and clicking on the latest version I arrive at:

After downloading the package, by clicking on "Pull to ProGet", I get:

which is wrong, but the licence is then correctly displayed as the (compliant) 0BSD licence:

in the overview.

Hi Steve,
Thanks for the quick response. Good shout on using curl; it looks like this is indeed either another trial licence issue or its a problem with the licence policy failing to detect a permissible licence (which it sucessfully does if accessing the open feed directly):

Hi,
We may have hit another snag with using a trial-licensed copy of ProGet (see also Enforcing Licence Policies/Blocking?):

We're in the process of evaluating ProGet as part of larger solution for software supply chain control that relies heavily on automated, API-based interaction with the package manager.

Part of this workflow is a triage process for unapproved packages with the option of an explicit approval. To that end I've configured two linked Python feeds in ProGet: python-accessible and passthrough-test-python, with the former being configured for explicit whitelisting and the latter being fully open. The python-accessible feed permits anonymous pulls and is configured with a connector to pull packages from the open feed, and the underlying idea is that packages that are blocked in the restricted feed can be seen in the open feed and run through a triage process with the option of granting security approval for their use.
Unfortunately, the setting up of this configuration seems to be failing at the first hurdle. While upstream packages in the open feed are visible in the restricted feed, in the UI:

Installing packages does not seem to be possible and failing with a status 400:

Permissions do not appear to matter, since the same thing happens when using the Admin accocunt.

The deployment is running 2024.9 Build 1, and is deployed to a Kubernetes cluster.

Many thanks!

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

Have a good weekend.

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:

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