administrators

Ultimately this is going to involve training for your developers. Just like instituting a code review process will be new and uncomfortable at first, a package review process will be the same. Developers will not like it and they will complain.

However, 99% of the time, developers will be fine using the approved feed. 1% of the time (when they want to test a new package or upgrade), then will use the unapproved feed. They'll just need to learn how to switch package sources (it's a drop-down in Visual Studio) and then learn not commit commit these package references.

My advise is to make it incumbent upon developers to not commit code/configuration that depends on unapproved packages. If they do, then it will "break the build" because the packages aren't available. This is an expected behavior - it would be like if a developer decided to upgrade to .NET9-beta.

"Don't break the build" is a common mantra on development teams, and it means developers can't commit code changes that will do that. Just extend that to using unapproved packages.

Hi @rick-kramer_9238,

In all cases, you'll need to configure ProGet to listen to a certain URL; this basically involves editing the ProGet configuration file, which the web page will do for you (or you can edit yourself).

If you're going to do port sharing (i.e. have multiple applications on the server listen/respond
on port 443 for example), the you also need register the URL and certificate with Windows using the netssh commands.

If you're not doing port sharing (i.e. ProGet is only application listening on 443) then no need to use netsh.

Hope that helps,
Alana

Hi @jw ,

We added a compliance property via PG-2658 in the next maintenance release.

It basically shows what's in the database (which is also what the page in the UI does):

writer.WritePropertyName("compliance");
writer.WriteStartObject();
writer.WriteString("result", Domains.PackageAnalysisResults.GetName(package.Result_Code));
if (package.Detail_Text is not null)
    writer.WriteString("detail", package.Detail_Text);
if (package.Analysis_Date.HasValue)
    writer.WriteString("date", package.Analysis_Date.Value);
writer.WriteEndObject();

I think you can rely on result=Inconclusive meaning the package isn't in ProGet. That's all we use the status for now, but in the future it might be used for something else. A result=Error means that our code crashed and you shouldn't ever see that.

We'll definitely considering doing something other than a single result string down the line, but for now this was the easiest :)

Thanks,
Steve

Hi @pbinnell_2355 ,

The normal workflow for a two-feed package approval is to generally have developers use the approved feed but allow them to use the unapproved feed when they need to use a new package or version.

However, this shouldn't be their default development style. If they want to use packages that aren't approved, they can request approval for the package(s) they want to use.

This obviously slows down development, but so does code review. And it's a tradeoff in general.

You can use bulk promotion if you'd like. Go to the PAckages page, then select "Cached" from the type of package, then select the packages you wish to promote.

Hope that helps,
Steve

Hi @pbinnell_2355,

Looks like the example code was incorrect. I've updated it. When a dotnet tool is installed globally, you run it by just running the tool name directly, so pgutil instead of dotnet pgutil

Hope this help!
-Greg

@rick-edwards_9161 that is correct, these will only be developed for ProGet 2024

Hi @pbinnell_2355 ,

It sounds like you've built a kind of package approval process?

https://blog.inedo.com/nuget/package-approval-workflow/

If that's the case, you'll need to promote the packages developers need to feed "B" or ask the developers to not use unapproved packages.

Thanks,
Steve

Hi @rick-edwards_9161 ,

There is a corresponding API, but we haven't documented it yet.

For now, you have to "reverse engineer" the code (ProGetClient.cs):

    public async IAsyncEnumerable<VulnerabilityInfo> AuditPackagesForVulnerabilitiesAsync(IReadOnlyList<PackageVersionIdentifier> packages, [EnumeratorCancellation] CancellationToken cancellationToken = default)
    {
        ArgumentNullException.ThrowIfNull(packages);

        using var response = await this.http.PostAsJsonAsync("api/sca/audit-package-vulns", packages, ProGetApiJsonContext.Default.IReadOnlyListPackageVersionIdentifier, cancellationToken).ConfigureAwait(false);
        await CheckResponseAsync(response, cancellationToken).ConfigureAwait(false);

        using var stream = await response.Content.ReadAsStreamAsync(cancellationToken).ConfigureAwait(false);
        await foreach (var v in JsonSerializer.DeserializeAsyncEnumerable(stream, ProGetApiJsonContext.Default.VulnerabilityInfo, cancellationToken).ConfigureAwait(false))
            yield return v!;
    }

We do plan to document all this in the coming weeks/months.

Thanks,
Steve

Hi @dan-brown_0128 ,

Sorry that we your reply. It must have been closed by mistake on our dashboard or something.

You're correct - this does require a database cleanup. As it so happens, we do have a "duplicates clean-up" script available, but it's intended for ProGet 2024. It's extraordinarily complicated, as you can see:

https://gist.github.com/apxltd/351d328023c1c32852c30c335952fabb

If you're able to send us a copy of your database (we can share a secure link for you in EDO-10419, just let us know), then we can review and think of the best plan to fix it. That will be either running the script in ProGet 2023 or upgrading then running the script.

Let us know your thoughts

Thank you,
Steve

Hi @jw ,

Thanks for the update, that sounds like a decent work-around for the time being. It will likely be a while before we can develop something more generalized.

I'm curious if you looked at any of the audit endpoints/commands in pgutil yet? That's kind of the direction we're thinking it will make sense to go - basically pgutil packages audit --package=myGroup/myPackage --version=1.2.3

I don't know what the HTTP Endpoint is offhand, but that does make sense to add something to PackageInfo, since we have it in the database already pretty easily. We could display a complianceStatus (Compliant, Warn, Noncompliant, Inconclusive, Error) and a complianceDetail string - that's what we have in the database. I think properties are easier to work with than objects... what do you think?

As for Download Package behavior -- we do intend to get the Common Packages API to work with connectors. That involves a lot of refactoring that just didn't make it in ProGet 2024 (only PyPi and Apk were refactored).

Cheers,
Alana