Posts made by jw

Thank you for the feedback.

I will observe for a while and reserve yelling at people to close their browsers for later. ;)

Hi @stevedennis

I'm not quite sure what to do with this information. Unfortunately the log message contains no information from whom or which IP this exception is triggered.

One question is what is the relation to the package that is mentioned in the Referrer. What could the notification be about?

Another potentially related issue is browser cache busting, which does not seem to work reliably. I have noticed this in the past and also with the upgrade to the 2025 version, that changes in the UI are only reflected after manually cleaning the browser cache or force reloading with Ctrl+F5.

From what I can see in the browser dev tools, some of the css files have a version query parameters, which I assume is meant for cache busting, but others (e.g. proget.css) do not.

Could this be related to the issue, that after the upgrade to 2025, some people are still seeing old versions of the UI and triggering this exception?

After upgrading to 2025.6 from 2024.36 we occasionally have the following exception in logs. It is not quite clear what exactly triggers it.

An error occurred in the web application: Could not load file or assembly 'ProGet.WebApplication, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

URL: https://xxxxxx.local/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications
Referrer: https://xxxxxx.local/feeds/xxxxxxxx-nuget-proxy-telerik/Telerik.UI.for.AspNet.Core/2025.2.702
User: (unknown)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Stack trace:    at System.Reflection.RuntimeAssembly.<InternalLoad>g____PInvoke|49_0(NativeAssemblyNameParts* __pAssemblyNameParts_native, ObjectHandleOnStack __requestingAssembly_native, StackCrawlMarkHandle __stackMark_native, Int32 __throwOnFileNotFound_native, ObjectHandleOnStack __assemblyLoadContext_native, ObjectHandleOnStack __retAssembly_native)
   at System.Reflection.RuntimeAssembly.InternalLoad(AssemblyName assemblyName, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext, RuntimeAssembly requestingAssembly, Boolean throwOnFileNotFound)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
   at Inedo.Web.Handlers.DynamicDelegateHandler.GetHttpHandler(GetHandlerParams args)
   at Inedo.Web.Handlers.DynamicHttpHandling.GetHandler(AhHttpContext context, String requestType, String url, String pathTranslated)
   at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

::Web Error on 31.07.2025 17:06:40::

When opening https://xxxxxx.local/feeds/xxxxxxxx-nuget-proxy-telerik/Telerik.UI.for.AspNet.Core/2025.2.702 the package site is shown and also the package can be downloaded without any problem or exception.
Deleting the package from the cache and repopulating the cache did not help either.

Opening https://xxxxxx.local/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications in a browser returns the following page:

For every reload of this page, a new entry of the same exception shows up in the logs.

Hi @stevedennis

Thanks for the quick response and fix.

The Usage & Statistics page (feeds/some-feed/System.CodeDom/8.0.0/usage) suggests that this package version is part of the scanned project.

When navigating to the package list of that linked "Latest Version" the project it shows what version of said package is actually contained in the project.

In the current state the Usage & Statistics page is not very informative or helpful as it gives users the impression that a particular version is used in the project which in reality is not. Yes, the right information is obtainable by following the version link, but that does not really solve the issue with the page itself.

It would be good if the tables both on feeds/some-feed/System.CodeDom/8.0.0/usage and also on feeds/some-feed/System.CodeDom/versions/usage could be changed to show the concrete version of the package that is used in the project version that is currently listed.

Is this something that could be changed?

Hi @atripp,

We haven't updated the production instance to the version that introduced this feature yet, so nobody breathing down my neck. ;)

I'll wait for the official release, but thanks for the offer.

Have a nice weekend!

First of all thanks for adding the ability to list all packages for a given license on the package usage overview page (PG-2783), very helpful feature.

There seems to be an issue with listing packages that are matched to custom licenses. We have added a number of custom licenses to ProGet, to deal with proprietary packages that do not have OSS SPDX identifiers.

When clicking on the link to list the packages on such a custom license there is a 500 error on the next page:

Stack trace from error log page:

Stack trace: at Inedo.ProGet.WebApplication.Pages.Licenses.ListLicensePackagesPage.CreateChildControls()
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync()
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

Ahh, took me a while to get it, but this is the dialog I was looking for.

It wasn't quite clear that the orange "Package Status is Deprecated" is actually a policy violation dialog, which is overriding this one here.

Thanks again.

Hello @atripp

Thanks for the feedback.

Just to double check: When the box shows "Package Status is Deprecated" it should also contain the custom deprecation reason, right?

Right now the box looks like in my screenshot above and I could not find any place where one could read the custom reason.

Or am I just looking in the wrong place?

Hi @rhessinger

Works like a charm, thanks.

Have a nice weekend.

ProGet Version 2024.15

1. Deprecation reason not visible

The custom deprecation reason does not seem to be visible anywhere anymore. If I recall correctly it was visible both in the ProGet UI and also Visual Studio.

VS package manager:

Any chance something got broken when that field was changed from a dropdown to a textbox?

2. License policy violation overrides deprecation status/reason

When a package is marked as deprecated and it also violates a license policy, the deprecation reason are not visible in the info box, instead only the license message is shown.

It would be good if the deprecation state and reason would always be visible regardless of policy compliance.

Inedo.ProGet was never updated on nuget.org since the initial deployment compared to pgutil. It looks like there have been a number of interesting additions looking at the source.

Any chance this package can be updated?

Always releasing it together with pgutil would also be appreciated.

Thanks for adding it to the roadmap.

From what I can see so far, there haven't been that many changes in the spec. For us mainly the author field changed.

Right now there is no immediate need. It might arise in the future if improvements or fixes are only being made available in the CycloneDX 4.x tooling.

@rhessinger

CycloneDX .NET Runner 4.0.0 was just released and produces spec version 1.6 by default.

Do you guys already have plans for supporting this?

Hi Alana,

the API would have been my next option, thanks for the pointers to the scripts.

My colleagues want to use the deprecation feature in connection with SCA to better communicate package states.

When packages are being deprecated it is usually more than one package that is affected.

Could this bulk edit feature be implemented in the UI?

Is there any way to apply the unlisted/deprecation status to multiple packages at once?

In case no, is this something that could be added as a bulk edit option on the package/versions/all page?

Thanks

Hi @stevedennis

Let's continue this thread here: EDO-10681

Hi Steve,

I tried restarting via Manage Service, restarted both Windows services manually and rebooted the whole VM.

The issue does not seem to go away.

Version 2024.11 (Build 10)

A new exception is created navigating on the web UI or just pressing F5.

An error occurred in the web application: Nullable object must have a value.

URL: https://192.168.x.x/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications
Referrer: https://192.168.x.x/administration/logs
User: xxxxxxxxxx
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Stack trace: at System.Nullable`1.get_Value()
at Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar.GetNotificationsInternal(AhHttpContext context)
at Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar.GetNotifications(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

@v-makkenze_6348

See this topic for additional information on the subject:
https://forums.inedo.com/topic/4152/proget-sca-2024-preview-feedback-package-detection-still-hit-or-miss

Thanks for the feedback and the fix.

Have a nice weekend.

Thanks for the quick fix.

We didn't have that many packages assigned to the licenses in question, so the workaround of disconnecting all packages from a license and then deleting that license did the trick.

We are encountering the following exceptions, when pushing to the ProGet Docker registry:

Error scanning blob 487afa63fba9 (id=1793): The archive entry was compressed using an unsupported compression method.

System.IO.InvalidDataException: The archive entry was compressed using an unsupported compression method.
at System.IO.Compression.Inflater.Inflate(FlushCode flushCode)
at System.IO.Compression.Inflater.ReadInflateOutput(Byte* bufPtr, Int32 length, FlushCode flushCode, Int32& bytesRead)
at System.IO.Compression.Inflater.InflateVerified(Byte* bufPtr, Int32 length)
at System.IO.Compression.DeflateStream.ReadCore(Span`1 buffer)
at ICSharpCode.SharpZipLib.Tar.TarBuffer.ReadRecordAsync(CancellationToken ct, Boolean isAsync)
at ICSharpCode.SharpZipLib.Tar.TarBuffer.ReadBlockIntAsync(Byte[] buffer, CancellationToken ct, Boolean isAsync)
at ICSharpCode.SharpZipLib.Tar.TarInputStream.GetNextEntryAsync(CancellationToken ct, Boolean isAsync)
at Inedo.ProGet.Feeds.Docker.BlobScanner.DockerBlobScanner.ScanBlobAsync(DockerBlobs blobData, Stream blobStream, ILogSink log)

It appears that the exception is coming from blobs that are just docker manifests in JSON format which are not compressed.

The manifests are created and pushed with the docker manifest command.
https://docs.docker.com/reference/cli/docker/manifest/

There's no problem deleting the deprecated licenses and adding their SPDX identifiers to the new licenses. When you delete a license, it will remove the association with packages.

Trying that results in the following exception:

(500) Server Error
547`16`0`Licenses_DeleteLicense`12`The DELETE statement conflicted with the REFERENCE constraint "FK__LicensePackageNameIds__Licenses". The conflict occurred in database "ProGet", table "dbo.LicensePackageNameIds", column 'License_Id'.

[1] is somewhat expected behavior, as some older versions of ProGet allowed non-normalized URLs to be added; newer versions should not allow this. We do not plan to "clean-up" the data at this time, but if you're "brave" you could could like do it with some API/DB calls

I'm actually hoping that the normalizing the URLs design decision would be revisited at some point. Modifying the URLs has a number of unwanted and unneeded side effects as I described further above.

[2] This is probably some quirk related to older data, but you can probably just cut the items to clipboard, save the license, the edit again, and it should work-around the quirk

I did some more digging:

A number of SPDX identifiers got deprecated and replaced, see bottom of the page here https://spdx.org/licenses/

New ProGet installations only ship the new identifiers, this means there is no conflict, but mapping packages to those deprecated license identifiers, like LGPL-3.0 will probably not work, unless there already is special code for it..?

Existing ProGet installations still have deprecated license identifiers like LGPL-3.0 in their databases and the URLs of those are now in conflict with those of the new identifiers like LGPL-3.0-only.

In my case I could solve it by deleting the deprecated licenses and adding their SPDX identifiers to the new licenses.

That said, I could only delete the deprecated licenses after no packages were referencing them anymore. In my case I was lucky since only a few packages were affected, other customers might have a harder time with that.

Not fully sure that is the proper solution though, so feedback is welcomed.

Related: https://docs.debricked.com/product/license-risk-management/proxying-non-standard-license-identifiers

Two related issues came up (Version 2024.9):

1. There is currently a mixture between URLs with www. and without prefix in the database. Saving a license entry causes existing URLs to be modified in the database. So even if one just wants to add another URL to the list, existing entries are modified.
   Storing license URLs without modification and applying additional logic, like ignoring www. subdomains, during comparison still seems like the sensible solution here.

2. LGPL licenses (and possibly others) cannot be saved at all, due to an URL collision.
   

I found another 403 error on the /vulnerabilities page in 2024.9. This should probably not show up during production (this is from my test system), but I thought I'd still report it.

Hitting the button without permissions, results in a 403 popup. I'm not quite sure if non-admins should be able to view this message at all..?

Our leading system, when it comes to deciding what state a build is in, is our build server. So, it does not really make sense for us to maintain this state in another system.

Also, similar to you guys, we are a product-based business, so we need to assume that all our stables releases are in production somewhere at any time.

In ProGet we just want to see how issues with our dependencies (license, vulnerabilities) are changing over time. To keep down the "CI beta build spam", we will either use the archiving feature or maybe even clean out old beta builds since it makes no sense to keep tracking those.

Sounds like a plan. :)

Thank you, once more.

In this case, allow me to sneak in my feedback instead. ;)

At the moment we are not planning to use the "build pipelines" feature at all. So from our point of view, it would be good if there was a way to opt-out of it.

For this page that would basically mean the previous behavior: When one clicks on a project and the "build pipelines" feature is disabled, it would directly navigate to the "all builds" page like before.

@stevedennis

Was the 3rd point addressed yet? I tried clearing the browser cache, but it still looks like this for me in 2024.7:

It's unlikely we will want to add/change this; what you're describing isn't a supported use case, and adding a "second URL" type field that would be empty on nearly every license would be confusing.

Makes sense.

Though, I don't quite understand why the URLs are modified in the first place. Ignoring protocols and subdomains during comparisons is something that could be done in code. A small hint in the UI that there is no need to add all URL permutations should do the trick. This would cover both uses cases and no information is lost.

Our general recommendation for dealing with non-OSS licenses has been to create a code like DEVEXPRESS or ASPOSE, and treat them as all the others.

Not sure what you mean by "code". The CylconeDX Spec says for licence Ids only valid SPDX license IDs must be used same goes for SPDX License Expressions, they list the valid values in the spec.

That is why for proprietary licenses we chose "Option 2" of specifying a name + url instead.

If there's more user demand for the particular use case we'll definitely reconsider. For now the licenses are confusing enough :)

Alright, let's see if there are more users with similar use cases. Right now it looks like we jumped on the SBOM/SCA bandwagon a bit too early. ;)
I'll try to find a workaround.

With version 2024.7 the bulk edit button is once again visible on the packages page, even though users do not have delete or promote permissions in any branch.

From the changelog:
PG-2711 2024.7 FIX: Bulk edit button hidden unless user as Admin_Configure [PG-2651 Regression ]

It gives users without permissions the impression that they could delete packages. Then when they actually click it, nothing happens and they contact Admins with support requests about a "broken ProGet". This is very time consuming and annoying.

Could you please fix this properly? As it stands right now it is back to the original behavior with bad usability.

Hello @atripp

Is this something that could be added?

We could really use this functionality to deal with proprietary licenses that do not have OSS SPDX identifiers.

Currently we add a custom license to the ProGet license database, then map either via license URL or via PUrls and then we modify the incomplete SBOM to to add a proper license name and URL to the component.

The only issue right now is that we cannot get the original unmodified license URL back out of ProGet.

Maybe a field could be added to the General tab that optionally holds an unmodified license URL for a license?

{
    "External_Id": "Custom-DevExpress-EULA",
    "License_Id": 628,
    "Title_Text": "DevExpress EULA"
    "Official_License_Url": "https://www.devexpress.com/Support/EULAs"
},

When saving a license URL to the license database in ProGet, both the protocol scheme and the "www" subdomain gets dropped.

As a consequence it is impossible to get the original URL, e.g. when reading the license definition back out via API. It is impossible to tell if the scheme was http or https or if www. was present in the original URL or not.

While URLs might currently be considered deprecated in NuGet (actually just the field in the nuspec spec is deprecated, but there is no replacement yet), in context of SBOM it continues to be a valid way of specifying license information. CycloneDX Spec

Is there any way I can configure ProGet to not manipulate URLs when they are saved to the database?

Example:

/api/json/Licenses_GetAllLicenseData response:

{
    "License_Id": 635,
    "License_Url": "testing.com/EULA"
}

Inconclusive Analysis

A build package (and thus a build as a whole) can be have an "inconclusive" compliance status. This will occur when two conditions are met:

1. A rule would cause the build package to be Noncompliant, such as Undetected Licenses = Noncompliant or Deprecated = Noncompliant
2. The package is not cached or otherwise pulled to ProGet, which means ProGet doesn't have enough information about the package to perform an analysis because the package is

Not sure I fully understand condition 1. Even if not such rule is configured, compliance could not be established because licensing information is not available, due to the package being not cached. Am I missing something?

The analysis message is incorrect however, it should be "Package is Warn because of Package Status is unknown, No license detected."

Should the string really say "Warn" when the package state is Inconclusive? Aren't Warn (Policies failing, Vulnerabilities detected, etc.) and Inconclusive (Package not found) two mutually exclusive states..?

I haven't investigated this yet, but I assume that the results are the same in the UI? That's all just pulling data from the database, so I would presume so.

Yes, the UI shows the same.

Could you find the relavent parts of the analysis logs? That helps us debug much easier.

It was actually not that easy to find the AutoMapper package in the logs, since the name does not appear anywhere. I made a custom SBOM with just the AutoMapper package and this is what the log looks like:

Analyzing compliance...
Beginning license rule analysis...
Default rules: undectableLicense=Warn, unspecifiedLicense=Compliant
The package is not cached or local to any feed; without package metadata, license detection is limited.
No licenses detected on package; applying undectableLicense rule (Warn)
License rule analysis complete.
The package is not cached or local to any feed; cannot determine if Deprecated.
No policies define a deprecation rule, so default Warn will be used.
The package is not cached or local to any feed; cannot determine if Unlisted.
No policies define an unlisted rule, so default Warn will be used.
Package is Warn because of Package Status is Unlisted, Package Status is Deprecated, No license detected.

[1] Based on the stack trace, I think the issue is that one of the SBOM documents you uploaded has a Component with a null/missing Purl field. Obviously this should error, but that's what the error must be looking at the code. If you can confirm it, that'd be great.

Yes, we are adding components with type Application that represent parts of our product into the SBOM via CycloneDX libraries. As these do not come from a package manager, they do not have a purl.

According to the spec that should be ok.
https://cyclonedx.org/docs/1.5/json/#components_items_purl

[2] ProGet is considered the "source of truth", so a new SBOM document will be generated based on the build packages. That SBOM will then be augmented with some information in the original SBOM(s), such as component "Pedigree", "Description ", etc.

Good to know, thank you.

Stumbled across two issues during SCA testing and a question related to SBOM export:

1. SBOM export does not work

Clicking on "Export SBOM" and choosing either JSON or XML both leads to a popup with the following error message:

The webpage at https://x.x.x.x/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Pages.Projects.Builds.ExportSbomPage/ExportSbom?projectId=5&buildNumber=3.0.0-beta.2024-03-04.9999&format=xml might be temporarily down or it may have moved permanently to a new web address.

Exception in the Diagostics Center:

An error occurred in the web application: Value cannot be null. (Parameter 'key')

URL: https://x.x.x.x/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Pages.Projects.Builds.ExportSbomPage/ExportSbom?projectId=5&buildNumber=3.0.0&format=json
Referrer: https://x.x.x.x/projects/builds/export-sbom?projectBuildId=6
User: xxxxxxxxx
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Stack trace: at System.Collections.Generic.Dictionary`2.FindValue(TKey key)
at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
at Inedo.ProGet.Projects.BomUtil.Munge(Bom bom, IEnumerable`1 originalBoms)
at Inedo.ProGet.Projects.BomUtil.ExportBuild(Int32 projectId, String buildNumber)
at Inedo.ProGet.Projects.BomUtil.ExportBuildJsonAsync(Int32 projectId, String buildNumber, Stream output)
at Inedo.ProGet.Projects.BomUtil.ExportAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

2. Question about SBOM export

When uploading a SBOM as JSON and then using the "Export SBOM" functionality and selecting JSON again, what happens during export?

Is the uploaded JSON returned exactly (identical file hash) like it was uploaded, or is there some "processing" in-between, e.g. it is run through CycloneDX Models/APIs and the exported SBOM is a new output which might have different package orders, etc.?

3. Build version numbers are cut off on the projects page

Thanks for adding the properties to 2024.3.

During testing I encountered unexpected behavior regarding the values:

To trigger the "Inconclusive" state I used the "Delete Cached Package" menu option on the package site and then re-ran the analysis on a build.

My expectation was that the package would be reported as inconclusive, since it is no longer available in cache and thus can't be fully scanned.

Instead I get the following results:

        {
            "purl": "pkg:nuget/AutoMapper@10.1.1",
            "licenses": [
                "MIT"
            ],
            "compliance": {
                "result": "Warn",
                "detail": " because of Package Status is Unlisted, Package Status is Deprecated, No license detected.",
                "date": "2024-05-13T09:55:04.467Z"
            },
            "vulnerabilities": []
        },

The warnings in the detail string do not make sense, since the package is neither unlisted, nor deprecated and the license is also correctly detected as MIT.

Thank you!

Cheers

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 haven't yet, but thanks for the pointer, I will have a look.

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?

From what I understood from the docs, PackageInfo is part of ReleaseInfo (now probably called BuildInfo after the release=>build rename?) and used in the /api/sca/builds?project= endpoint.

Adding complianceStatus (Compliant, Warn, Noncompliant, Inconclusive, Error) to PackageInfo already makes a lot of sense, though it needs be very precisely defined what each status means, especially "Inconclusive" and "Error".

Right now, I'm specifically caring about the state when a package could not be fully scanned because it was not found in cache, not sure if "Inconclusive" means exactly that or if there are other triggers for that state.

As for the detail string, you are probably referring to what is currently shown in the tooltip when hovering warn on the /projects2/packages?buildId=5 page?

Generally, I believe the type of compliance violation is an important piece of information and should be stored as atomic values. At the moment it appears to be a concatenated string of violations?

On the API I would like to see something like an array of enum strings (like my code example above) or a dedicated object within PackageInfo, something like ComplianceViolationInfo with boolean properties for each violation type would also be fine.

In the UI it could look something like this:

This would be much more user-friendly than having to hover each warning and read a long string, or alternatively having to sift through all the generated issues.

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).

Glad to hear that this is already on the roadmap

Cheers

I already reported a number of these here and most of them are fixed, so thank you for that.

Occurs in: 2024.2 (Build 2)

Again using this permission set:

1. Bulk edit on /packages page
   This one was probably just overlooked from my previous report, on the container page it seems already to be fixed.
   The bulk edit menu is always visible, clicking on it shows a menu with delete or promote option. Selecting Delete selected results in no action at all, which is misleading.
   => The "bulk edit" link should be hidden for users that do not have delete or promote permissions in any feed.

2. Notifiers Configure on /sca page
   The "Configure Notifiers" link leads to 403 page.
   => The whole panel should probably be hidden when a user has no notifier permissions

3. Menu on /projects page
   
   All three menu points are not clickable.
   => Whole menu should probably be hidden

4. "manage license types & rules" link on /licenses page
   Link just does nothing
   => Hide

5. Clicking on a license name on /licenses page
   Leads to 403 popup
   => Right now there is only a "Manage" permissions for licenses, but I see no reason why people without editing permissions should not be able to view licenses details. So a read-only version of the edit popup would be helpful.

6. Menu on project page /projects/project?projectId=5
   "Create Build" and "Import SBOM" lead to 403 popups.
   => Hide

7. Project build page /projects2/builds/build?buildId=5
   Promote, analyze, add comment, edit build all lead to 403
   => Hide

8. Project issues page /projects/issues?buildId=5
   Bulk edit -> Delete leads to 403.
   => Hide from bulk edit

I'm pretty sure I overlooked some of them, since these issues are everywhere.

It would be really great if this check could be added to the test suite, especially for new UIs. They are very easy to spot, basically just be authenticated with a user that does not have any major permissions and then click every link on given page.

At some point I need to start thinking about charging a tester fee.

Thanks for the insights.

I think a good option could be to configure the marked library to use a nested baseUrl using marked-base-url, something like https://host/feeds/feedname/packagename/markdown/README.assets/image-20220120113554562.png and then filter error logging URLs beyond the markdown/* URL segment.

Personally, I always try to keep the Diagnostic Center clean and empty, so when new issues show up I can easily spot and address them. Sifting through messages that are basically spam, without being able to filter or ignore them costs me more of my time that I would like to invest for monitoring.

Makes sense, thanks for the quick fix.

Cheers

I don't think there is a standard for that, it probably depends on the markdown editor where it puts its assets.

The README.md had a link like that:
![image-20220120113554562](README.assets/image-20220120113554562.png)

The reason I reported it is, every time some clicks on such a "broken" package, the Diagnostic Center is spammed with these pointless exceptions.

When those packages are coming from a 3rd party feed, then there is no real way to fix it other than praying a new version of that package is released.

Occurs in: 2024.2 (Build 2)

On the /licenses/types page when using the add license type button, the modal dialog says a new license with SPDX identifier could be added.

But after adding the license the SPDX ID is empty.
Additionally the License code: field is shown twice in the UI.

Maybe it would make sense to use the Edit License Definiton UI also for adding new licenses? That would save the user adding only partial information and then having to search the added license again to complete the input. Just a thought..

I managed to implement the workaround for the uncached packages.

Right now I am doing the following:

1. API call to $"api/sca/builds?project={projectName}&version={version}"
   • Parse the build Id out of the ViewBuildUrl property
2. API call to native API $"api/json/Projects_GetBuildInfo?ProjectBuild_Id={projectBuildId}"
   • Cross reference ProjectBuildPackagesFeeds with ProjectBuildPackagesExtended to find out which packages could not be mapped to feeds
3. Call to the download button URL $"nuget/{feedName}/package/{packageName}/{packageVersion}" for each package that could not be mapped to any feed
4. API call to ($"api/sca/analyze-build?project={projectName}&version={version}" to update the build

While it does work, I'm not fully happy with the implementation and would like to ask for some improvements to the regular API.

Compliance information in PackageInfo

Right now the PackageInfo object does not contain any information about compliance violations. Would it be possible to extend it with the warnings that are shown in the compliance column of the /projects2/packages page?

Ideally, it would be some sort of enum, that has atomic values for all the known violations and can be filtered easily. This would help to to avoid the call to the native API in step 2, which as far as I understand you don't recommend using anyways.

{
  "purl": "pkg:myGroup/myPackage@1.2.3",
  "vulnerabilities": [],
  "licenses": ["MIT", "Apache-2.0"],
  "compilanceWarnings": [
     "PackageNotFound",
     "NoLicenseDetected",
     "Deprecated"
  ]
}

What would also be nice to have is atomic values for the package name and version, so one doesn't have to parse it out of the purl.

Download Package API behavior
Right now the /api/packages/MyNugetFeed/download?purl=pkg:nuget/MyNugetPackage@1.0.0 API returns 404 when trying to download a package that is not cached yet.

As a workaround I am using the URL of the download button used in the UI, but I would prefer to use a proper API endpoint that has more chances to be stable in the future.

I think it would be good if the download API could be changed to also trigger package downloading and caching from connectors, so basically the same behavior as the endpoint behind the download button.

Occurs in: 2024.2 (Build 2)

The following exception shows up in the Diagnostic Center every time when viewing a NuGet package which contains a README.md which in turn links to images that were not included in the package:

An error occurred in the web application: image-20220120113554562.png not found.

URL: https://xxxxxxxxx/feeds/xxxxxxxx/xxxxxxxxxx/README.assets/image-20220120113554562.png
Referrer: https://xxxxxxxxx/feeds/xxxxxxxxx/xxxxxxxxx/3.0.0
User: xxxxxxxxxxxxxxxxxxx
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Stack trace: at Inedo.ProGet.WebApplication.Pages.Packages.PackagePageBase.CreateChildControlsAsync()
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync()
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

So this is a strongly subjective thing, but I was wondering why the default font size was changed from 14px to 16px.

I've been looking around other UIs (GitLab, TeamCity, Google, this forum, etc.) and the default text size seems always to be around 14px.

Maybe I'm off here, but 16px somehow it looks "wrong" to me.

Would love to hear other opinions about this, so feel free to jump in.

**edit
Forgot to mention, the new Karla font itself is perfectly fine, just talking about the size.