Managing Python Proxy Repo's

Hi, We have been dipping our toe into Nexus 3. We have two Pypi proxy repos so that we can place new packages from Pypi into the “staging” repo, and then when they have been assessed for vulnerabilities & license issues (from the built in tooling). Then the plan would be to promote that package to the “production” repo which is the one that everyone uses.

Now, im trying to find the best way to make this work. As we keep the “production” repo blocked from accessing Pypi. We unblock it when we need to add a new package (after staging) and then re-block it again.

Now the issue here is that during that window, a normal user could inadvertently pull in an un-planned package, bypassing the staging process.

Now, im wondering if there is anyway to handle this better. Originally I though we could add a password to the production repo, then un-block it, pull in the new package, re-block and then remove the user/pass. However it appears this is not an option.

Is there a way to use the API to promote directly from staging to production? Would it still require the outbound access or is it an internal promotion?

How else do you guys do it?

I work in an industry whereby just allowing packages through from Pypi is not really an option.

Any thoughts/advice would be greatly appreciated

Thanks

I imagine you could do something where you remove it from the group then add what you want, that said builds that expect the proxy to be present in the group will fail during that period.

We also offer a product called Nexus Firewall that is capable of quarantining packages based on policies (like license, or security) and preventing them from being downloaded in proxies.

Hey, that sounds like it would work. They would rather people not be able to pull packages, than to pull in potentially harmful ones. Plus after the initial burst, I don’t think this will be a daily activity.

My intention is to move to Repository Pro and Firewall, but we need to prove the benefit first and raise a case for it. The business is pretty well regulated, and additional operational costs are always a bit tricky.

Thanks for the response :slight_smile: