Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).

In this case, the package is actually websocket_client, not websocket-client.

See: https://pypi.org/project/websocket_client/

When you search for websocket_client in ProGet, it shows up, as expected.

In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.

That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)

As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.

I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.

Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.

You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.

Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

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

Thanks @daniel-pardo_5658 , I was able to reproduce it.

It seems to work when you have additional metadata fields. Anyway we'll get it fixed via PG-2935 in the next maintenance release. AS a work-around, you can just download the package, edit the upack.json, and reupload it.

Cheers,
Alana

Hi @parthu-reddy ,

This hasn't changed; to "Set Package Status", you need to first Pull the Package to the feed. From there, you can a compliance rule override of Always Block or Always Allow Downloads.

Thanks,
Alana

Hi @scusson_9923 ,

Thanks for clarifying. You're right, the result is not available as a variable. Instead, the Operation will fail, which means you'd want to handle this via a try/catch.

try
{
    InedoCore::Exec
    (
        FileName: pwsh,
        WorkingDirectory: C:\,
        Arguments: test.ps1,
        ErrorOutputLogLevel: Error,
        OutputLogLevel: Information,
        SuccessExitCode: == 0
    );

    ... operations for success...
}
catch
{
    ... operations upon failure ...
}

Hope that helps,
Alana

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

Hi @scusson_9923 ,

Can you clarify what update you're looking for?

Are you looking for help on how to capture a failure and test on it?

Thanks,
Alana

Hi @daniel-pardo_5658 ,

Unfortunately I'm not able to reproduce the error; I think it has something to do with your upack.json file. Can you share that?

Thanks,
Alana

Hi @pratik-kumar_8939 ,

Unfortunately Nexus has a very limited API, which is why the so the import isn't working (404 error - not found). Basically, it doesn't implement the "catalog API" that allows all artifacts/packages to be listed.

However, you can use a file-system / drop-path import after you extract the files from Nexus

Thanks,
Alana

Hi @infrastrcture_6303 ,

We've had one other user report this, and unfortunately it's a bit complicated behind the scenes. ProGet 6 allowed npm packages to be uploaded without a @ in the scope, which meant that if you used a non-npm client (your own script, etc), you could have "bad data" in the database.

We did not anticipate this data when doing the ProGet 2023 datamigration, so the bad data was brought over.

We don't have a means of fixing it, and it would take a nontrivial amount of time to do that - so as a free user we can't really put in that time. We do plan on a cleanup task ina few months that will take care of this automatically.

If you're comfortable with SQL, you may be able to fix it yourself (that's what the other user did), and it invovles a figuring out some queries around the PackageNameIds table.

Another alternative is to setup a new instance of ProGet 2024 and then just import the packages from disk.

Thanks,
Alana

Hi @rel_0477 ,

I just want to confirm... is the error that you're not able to view the files on the View Files tab in the UI? The file uploaded fine otherwise?

Are you able to download/pull packages through the connector to Shippyard?

Thanks,
Alana