Hi @sneh-patel_0294 ,

That error message is coming from the operating system; it doesn't necessarily mean a permissions issue.

Does it happen every time for every package, consistently?

If that's the case, then it's certainly some kind of permission configuration. The user running the ProGet Web Service (or IIS App pool) may not have the appropriate permissions to the folder.... or it could be something related to network access? I don't really know.

The operating system is opaque with the error message, and you might have to use a tool like procmon to see exactly what's going on. That will show you what programs/processes request file handles.

If this is sporadic, then it means the file is locked. It's possible for ProGet to lock the file, but it's unlikely and would require basically two processes trying to write to the same file at the same time. We've only seen that with misconfigured build servers that publish same build twice.

More likely the file locking is coming from like backup, index scanning, or malware that's masquerading as "security software". Procmon will also advise this, if you can catch it.

-- Dean

Hi @forbzie22_0253 ,

Tags are a field in the nuspec file, which is embedded within the NuGet package:
https://learn.microsoft.com/en-us/nuget/reference/nuspec#tags

As such, we do not recommend using tags in NuGet, because they are "permanent" and you can't "untag" packages. It makes it hard to think of a tagging system that will be useful for the long-term: https://blog.inedo.com/nuget/best-practices-internal-nuget-packages/

-- Dean

Hi @arkady-karasin_6391 ,

A 403 error means Not Authorized; since those are publicly-available repositories, my guess is that you have a Proxy or Content Filter that's blocking that URL, and the ProGet Server is getting a 403 response from that intermediate server.

-- Dean

@joel-shuman_8427 thanks for the heads up!

I just updated it
https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md

HI @parthu-reddy ,

Thanks for the feedback; I update the docs to mention that the feeds/permissiosn would also need to be updated as well.

We hope to handle an in-place migration in a future version, but didn't want to delay shipping the feed. Please let us know if you have any issues/feedback.

Note we are adding several improvements to the Maven (New) feeds in ProGet 2024.15:

• PG-2798 Add Direct Download (Artifact Import) Support for Maven (New) Feeds
• PG-2797 Add OSS Metadata Caching Support to Maven (New) Feeds
• PG-2796 Improve MavenIndex Download Visibility for New Feed Connectors
• PG-2792 Feed Management API Returns Empty Type on Maven2 and new feeds
• PG-2794 Add Simulated Directory Browsing to Maven (New) Feeds

-- Dean

Hi @parthu-reddy ,

I'm afraid we don't have enough information to help with this; it appears to be an error the tool you're using (packet), and there's not enough information in the screenshot to see what error packet is encountering. It just says "Packaged failed with could not download..."

We aren't familiar enough with packet to know how to follow their Stack Trace.

If you can't find a clear error message, I would use an HTTP Proxy tool like Fiddler Classic to inspect the traffic that packet is making, and see if you can spot an issue there.

I would also try downgrading packet , as it's very possible there's a regression in the tool.

-- Dean

Hi @kichikawa_2913,

We see multiple connectors pretty often, and it rarely presents a problem.

The main downside comes in the overhead of aggregation; for some queries like "list all package versions", each connector will need to be queried and have the results aggregated. So it could cause performance issues for for very high-traffic feeds - at least that's what we see on the support side of things.

However, if you plan on using a package-approval workflow, then it won't be a problem, as your approved-npm feed wouldn't have any connectors.

Hope that gives some insight,

Dean

Hi @stuart-houston_1512,

ProGet will download nightly updates of the vulnerability database from an inedo.com server.

If you're running in a totally air-gapped environment, then you obviously won't get these updates. However, each version of ProGet includes an up-to-date database, so upgrading will get you the updates.

--Dean

Hi @steviecoaster ,

The Native API can be a little finicky, especially since you can invoke with JSON, forum-encoded values, querystring, and I think even XML. But it sounds like you're on the right track.

Let me share the C# code that ProGet uses to set the password:

    using (var rfc2898 = new Rfc2898DeriveBytes(password ?? string.Empty, 10, 10000, HashAlgorithmName.SHA1))
    {
        var bytes = rfc2898.GetBytes(20);
        DB.Users_SetPassword(userName, bytes, rfc2898.Salt);
    }

... it looks a little different than the code you're using, so hopefully that will help!

-- Dean

Hi @russell_8876,

Thanks for all the additional details!

Actually, this is definitely a bug in pgutil, since it's sending a negative offset to ProGet, and then ProGet is responding with a 400 error ("Missing or invalid "offset" parameter.)

Asset uploaf capability is just a few weeks old, and I'm not sure if we tested with such a large file. Anyway, we'll get it looked at and let you know once fixed; just a small tweak needed here I think:

https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L240

-- Dean

Hi @noam-linux-2022_8869 ,

Here is documentation on how to enable HTTPS in our products on Windows and Linux:

• https://docs.inedo.com/docs/installation/installing-on-iis/installation-windows-https-support
• https://docs.inedo.com/docs/installation/linux/https-support

-- Dean

Hi @steviecoaster,

The Native API isn't hacky, just harder to used. Here is the documentation on the Native API:
https://docs.inedo.com/docs/proget/reference-api/proget-api-http#native-api-endpoints

We don't have any articles/guidance on how to call the Native API beyond what's there.

The Users_* procs have not changed in years and are very safe to use. There are a few forums posts here and there with "hints" on work with the User_ procs, like this:
https://forums.inedo.com/topic/4198/reset-proget-admin-password-via-api/2

-- Dean

Hi @steviecoaster ,

I agree it'd be nice, but it's also not trivial as you noticed. I believe it's possible to configure security with the Native API, but obviously not as easy. So I would explore that, it's probably close to what you wnat.

A first-class Built-in Users/Groups API has been requested over the years (and is now something that makes sense with pgutil) - however if we made it, the API would be paid-editions only. We haven't had any interest from paid users in such a feature, as they generally use LDAP or don't mind non-API configuration.

-- Dean

@steviecoaster great, thanks for sharing!

I added this to our documentation (https://github.com/Inedo/inedo-docs/pull/253), but apparently I don't have ability to merge PRs in that repo so it'll go live sometime later I'm sure

@steviecoaster glad you were able to figure it out :)

Easy typo and we should consider a validator on that "Update SSL Certificate" page as well to save a headache like this!

Hi @v-makkenze_6348 ,

If you download (i.e. cache) the package, then you shouldn't see the compliance issue anymore. The reason is that ProGet does not have information about the package unless it's cached/local, or if you're viewing it on the package overview page.

When ProGet runs a build analysis (first screenshot), it only uses local/cached package data. This is for performance reasons, as users will have 100's of builds with 1000's of packages in each build, and that much traffic to each connector is problematic.

However, we are working on building a "remote metadata cache" that will fetch this data in a more performant manner.

-- Dean

Hi @steviecoaster ,

Sorry about giving the bad advice there -- I did not realize that the offline installer does not include the hub.exe program. It looks like the Offline Installer Creation Process must strip that from the offline installer we provide.

As you discovered, the advice from before wouldn't really work. Without doing a deep dive in the code, I don't know how to make it work. This isn't a use case we designed for, and I'd hate to send you down a wild goose chase.

How about just using our standard silent installation approach, which I shared before:

# create working directories
mkdir C:\InedoHub
cd C:\InedoHub

# download and extract file to working directory
Invoke-WebRequest "https://proget.inedo.com/upack/Products/download/InedoReleases/DesktopHub?contentOnly=zip&latest" -OutFile C:\InedoHub\InedoHub.zip
Expand-Archive -Path InedoHub.zip -DestinationPath C:\InedoHub

# perform silent installation
hub.exe install ProGet:5.2.3 --ConnectionString="Data Source=localhost; Integrated Security=True;"

This will basically install the desired version and it's likely "good enough" for the time being.

-- Dean

@MY_9476 I'm afraid not; what you're seeing is a diff of the OtterScript, which is what's stored in the database. The issue is that the "serialization to code" order must have changed between major versions.

We try to not have that happen, but fortunately this only happens the first time you edit such a script. Next time, only your changes will be preserved.

Hi @jw,

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.

However, the compliance analysis scheduled job will reassociate them. This runs nightly, or you can manually run it. Also, if you visit the package page or download the package, it should associate with the new license.

We'll definitely reconsider the design/approach if there's more demand, but we need to really make sure there's a value to the user -- there's a relatively high cost to change things and then there's a chance of regression/bugs, which is really frustrating to users.

-- Dean

Hi @jw ,

[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

[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

FYI, the URLs that we have in our database for LGPL-3.0-only are: as follows

gnu.org/licenses/lgpl+gpl-3.0.txt
gnu.org/licenses/lgpl-3.0-standalone.html
opensource.org/licenses/LGPL-3.0

I'm guessing you have the www from an older version

-- Dean