@joshuagilman_1054 this is currently planned for 5.3.27 as PG-1934 (April 17) - we'll let you know if plans change!
stevedennis
@stevedennis
Best posts made by stevedennis
-
RE: How to set content type of asset with API?
-
RE: Proget: delete all versions of a package via API
Hi @mcascone ,
We don't have a single API method that can be used to delete all package versions from the API, but the
foreach
loop will do the trick!I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted
I don't know the specifics/details of your use-case, but based on what I read, I'd recommend these guidelines:
- assuming: one GitHub repository, one project, one package you want to release
- use the same package name/group for all packages you create for this project, regardless of branch or development status
- create your "dev" packages using a prerelease version number, that has a sort of
-ci.##
version (assuming you use CI to build packages) - embed the commit id and branch in your upack metadata file, for traceability
- if you want to see which branch the packages was created from using the version number alone, add a
+branch
metadata label to the version number for branches (don't do this formaster
) - use repackaging and promotion to take your
-ci
packages to-rc
to stable (and the desired feed) - let retention policies automatically cleanup up the
-ci
packages
-
RE: No option for NuGet package path under Advanced Settings
Hi @kichikawa_2913 ,
I think it's this way for "historic reasons" - mostly all the other feed types came later, and it seems no one ever changes these paths or noticed.
Easy enough to make it configurable, but can you share your use case? Why do you want to use something other than a single root path with all of your packages?
Anyway I added a feature for this, and we should be able to get it in the next maintenance release PG-2006
Cheers,
Steve
-
RE: Marking packages as deprecated
No problem "resurrecting" topics! We definitely want to hear from users about feedback/feature requests.
We still haven't had anyone else ask for deprecation since this request, but I wonder if there's a better solution to solving your challenges than this feature. It sounds like you want to increase governance of your NuGet Packages, potentially with some sort of compliance in mind.
The
dotnet list package --vulnerable
is probably not what you want for your organization; NuGet's Built-in Vulnerability Scanning is really limited, in part because it only reports on a fraction of known package vulnerabilities (164 as of today). It also won't block packages that you deem problematic, unlike ProGet's feature.The same is true with
dotnet list package --outdated
-- it's probably not what you want, because it relies on developers to have to know (1) to run the command, and (2) know what to do if there's an outdated dependency.There are better ways to manage third-party packages (see How to Create a Package Approval Workflow for NuGet), and you'd better served knowing who's consuming outdated packages (see Use Package Consumers to Track Dependencies
Just some thoughts; like I said, we haven't had any demand for this feature, but these are proven solutions for improving governance of packages as organizations grow/expand their NuGet usage like you are.
Cheers,
Steve -
RE: Permissions only work when set for specific user, not a group (LDAP)
Hi @kichikawa_2913 ,
The NuGet client's behavior is based on NuGet.org, where no authentication is ever required to view/download packages. As such, it doesn't pass the API key when doing those queries; instead, you can use a username of
api
and the password of your api key.Based on the issue though, it sounds like ProGet is unable resolve the groups; I would use the "test privileges" function on the Tasks page to verify this. Thatw ill show you if the username can download packages or not.
The most common reason that groups aren't resolving is that the member is not directly in the group (i.e. they're in a group which is a member of the group), and you don't have recursive groups enabled; do note that this is really slow on some domains.
Cheers,
Steve -
RE: upack repack doesn't use complete version string from CLI
Hi @mcascone ,
Just looking at the code real quick, I suspect we have a bug where it writes out the wrong files name for the new package:
https://github.com/Inedo/upack/blob/master/src/upack/Repack.cs#L120That's probably an easy fix, which we can do as part of this Q&A item. I'll wait to hear back about this one.
As for the error, "The underlying connection was closed: An unexpected error occurred on a send.", that sounds like it's HTTPS related. Could you attach Fiddler, or something like that, to find out what's happening under the hood? We may be able to error message to better report it if so.
Cheers,
Steve -
RE: Mixing ProGet Instances
Hi @cimen-eray1_6870 ,
Great questions; there's no problem having a second instance with ProGet Free Edition.
The relevant restriction is that you can't use a Connector in ProGet Free Edition to connect to another instance of ProGet (either another Free Edition or your paid edition).
Hopefully you can use your Maven feed as a proof of concept for implementing it in the main instance. Good luck!
Cheers,
Steve -
RE: Proget - Can't use the native API even with an API Key with Native API access
Hi @m-webster_0049 ,
The first thing I would try is to troubleshoot this is to switch to a very basic API key like
hello
. That just eliminates any typos, spacing, etc.Next, I would try specifying the API Key via
X-ApiKey
header (see docs) - just to see if you get a different error. It's possible there is a regression somewhere.Best,
Steve
Latest posts made by stevedennis
-
RE: NPM Package name case sensitivity
hi @dan-brown_0128,
ProGet simply does not support case-sensitive npm package names. This is a 10+ year old design decision (back from ProGet v3), which we made because npm package were always supposed to be lower-cased: https://docs.npmjs.com/creating-a-package-json-file#required-name-and-version-fields
JSONPath
is an invalid package that entered the public registry due to an npmjs.org bug. It's an old package -- latest version version 0.1.2, is 8+ years old -- and according to the package page says that it's "moved tojsonpath-plus
to avoid npm problems in dealing with upper-case packages."ProGet permits these packages, but there are just going to be quirks if you have them in your feed. For example, if you have both
jsonpath-1.1.1
andJSONPath-0.1.2
in your feed, then they will generally show up asjsonpath
, but in some API queries you may seeJSONPath
.We understand this is different than how the npmjs.org registry behaves, but as I mentioned, this was a "day 1" choice that we can't change today. No one's mentioned this as an issue until now.
If npm audit is crashing because sometimes
JSONPath
is returned in results, that sounds like a bug in npm audit to me? We obviously can't add support for case-sensitive npm packages nor change how ProGet returns data in npm API calls just to work-around an npm audit bug like this.The easiest solution is to stop using
JSONPath
and remove from your feed, which it sounds like you already have. It's a really old package, and there are only a handful like this on the public registry.Best,
Steve -
RE: NPM Vulnerability with Exception
@dan-brown_0128 I understand
So you'd either have to upgrade (where we fixed the code) or reassess it to Low so npm audit won't crash. I suppose you could also patch npm audit so it doesn't crash.
-
RE: NPM Vulnerability with Exception
Hi @dan-brown_0128 ,
Thanks for the detailed analysis; we'll get this fixed via PG-2636 in 2024.1 (due later today).
You should be able to assess it as "Low" to work-around it in the meantime. FYI, here is the code that is used to map a vulnerability to an npm vulnerability:
//assessed if (vuln.Severity_Code != null) { return vuln.Severity_Code switch { Domains.AssessmentSeverityCodes.Error => npmAuditSeverity.critical, Domains.AssessmentSeverityCodes.Warning => npmAuditSeverity.high, Domains.AssessmentSeverityCodes.NotApplicable => npmAuditSeverity.info, Domains.AssessmentSeverityCodes.Custom => npmAuditSeverity.info, _ => npmAuditSeverity.info }; } // unassessed and has a Severity Score else if (!string.IsNullOrWhiteSpace(vuln.ScoreSeverity_Text)) { return vuln.ScoreSeverity_Text switch { nameof(CVSSRange.Low) => npmAuditSeverity.low, nameof(CVSSRange.Medium) => npmAuditSeverity.moderate, nameof(CVSSRange.High) => npmAuditSeverity.high, nameof(CVSSRange.Critical) => npmAuditSeverity.critical, _ => npmAuditSeverity.info, }; } return npmAuditSeverity.none;
Thank you,
Steve -
RE: NPM Package name case sensitivity
Hi @dan-brown_0128,
I understand that npm is currently case insensitive, but there was a brief period that it wasn't. This led to several duplicate packages being published:
I don't believe this is possible anymore? Either way, ProGet is case insensitive for npm packages, which means that
JSONPath
andjsonpath
are considered the same package.IfIn either case, the package name should be returned in results asJSONPath
came first, then that's what the package name is I guess?jsonpath
It doesn't seem to cause any issues, except with
npm audit
?This is a rare case, so I would just not worry about it. We don't recommend
npm audit
and you should usepgutil audit
anyway. More comprehensive, covers licenses, all that.. -
RE: Support for CocoaPods
Thanks for the inquiry; I've updated our Other feed types docs with a link to this thread.
On a first glance, it looks like a CocoaPod itself is just a basic text file that acts as a "pointer" to a GitHub repository. The pod client uses the git client to "download" files and tags for versioning. In other words, there is no package file.
A CocoaPod repository is a Git repository, and the pod client seems to just use git client to commit/push files to the repo. In other words, there is no API for ProGet to implement.
Here is what a CocoPod repo looks like (note how it's just a bunch of files in a Git repo):
https://github.com/CocoaPods/Specs/tree/master/SpecsTo make a "private repo", you basically just create a Git repository:
https://guides.cocoapods.org/making/private-cocoapodsThis means that ultimately to implement a CocoPods repository, your only option is to create a private Git repository? That's my inital assessment at least.
And of course, we have no plans to add Git source code hosting to ProGet :)
From here, I recommend to ask the developers to research this a bit more, and maybe contribute their thoughts? It just doesn't seem like the iOS devs uses packages - it's all very open-source and just GitHub repositories.
Steve
-
RE: GPG error updating Debian repositories
@daniel-scati we'll also get this fixed via PG-2635 in an upcoming maintenance release (hopefully 2024.2), which is targeted for next Friday.
-
RE: Date in Debian feed release file malformed
Hi @daniel-scati , thanks for the analysis!
We'll get this fixed via PG-2635 in an upcoming maintenance release (hopefully 2024.2), which is targeted for next Friday.
-
RE: Proget as registry proxy
ProGet works as a "Private Docker Registry" which seems to be different than a "Docker Hub Mirror".
Last time we researched Docker Hub Mirrors, they seemed to be primarily intended to provide image to certain geographic regions (like China) where Docker Hub content would otherwise be restricted. They could also be used to set up a "local mirror" of Docker Hub, but in all cases, it seemed to basically just redirect traffic from the default docker.io URL (or whatever) - so it wasn't intended to be used as "Private Docker Registries".
In any case, Mirrors don't seem to be a good fit for ProGet; instead, if you wish to use
nginx
, we would advise to "privatizing" and "lock" images using sematic tag, so that you can be assured thatcorp.local/images/nginx
is a tested/safe image with tags you control.Best,
Steve -
RE: What is the general design philosophy regarding permissions and visibility in ProGet?
@jw excellent, thanks for the finds! I also added this to our "final touches" for ProGet 2024 to address all these-- all pretty easy fixes I think
-
RE: ProGet feature request: Dedicated permission for marking packages as deprecated
Hi @jw ,
I'm afraid this is a bit too granular for us now, but it's something we can consider re-evaluating down the line, especially as we will likely want to add specialize permissions for projects, policies, etc. We expect that will happen later in the year, after ProGet 2024's new features get more adoption. We'll see if anyone else requests package-level permissions, etc.
As for the Advanced, I put a note in ProGet 2024's final touches to address that. Honestly I thought those were only on Debug builds only, but clearly not... thanks for reporting!
Cheers,
Steve