I stumbled across the sigstore project and mostly found information on how it helps avoid tampered npm packages.
Is this also relevant for NuGet packages? Or is the attack vector sigstore addresses with npm not relevant for NuGet?
It is relevant to NuGet packages, since they can be signed. Unfortunately for Nuget.org use case, Microsoft requires signing with public certificate authority that is on their approved list. And Sigstore isn't on that list.
So Nuget.org would require some changes to support Sigstore if Sigstore isn't added to the list. And I haven't seen any issue opened for this on Nuget's issues page.
You can naturally do verifications by yourself if you have your own NuGet repository.
Related
Due to the usage of Babel, that require us to host ourself the package manager on a private repository, we are using Azure Devop as a source of our packages.
But now when we look for any package that is not yet somewhere in the solution, we end up with a "No packages found":
Here we were looking for "roslynator"
If I do this same request in a brand new project. No issues at all, I find the packages.
but we have nuget.org correctly specified in the upstream sources:
And the whole team is listed as contributor. I cannot find any error anywhere when we are fetching the packages. I tried to execute the command Install-package Roslynator. The commands succeed, and then I'm able to see the package in the GUI of visual studio(and in the web console of visual studio).
Seems to be an issue on Visual studio level, but I cannot understand what is causing it?
According to the steps in the Consume NuGet packages in Visual Studio document:
If you're using upstream sources, any packages from upstream sources that haven't been saved to your feed yet (by using them at least once) won't appear in the Package Manager search result. To install those packages:
Copy the Install-Package command from the public registry (NuGet.org).
Select Tools then NuGet Package Manager to open the NuGet package
manager.
Paste the command into the Package Manager Console and select run.
So this is the expected behavior and your steps are correct.
Update:
If you want to find all packages in nuget.org, you need to choose nuget.org as source and search packages instead of using your Azure DevOps sources:
According to this document:The nuget.org upstream source allows you to merge the contents of nuget.org into your feed such that the NuGet client can install packages from both locations without making multiple search queries. Enabling upstream sources also automatically enables saving of packages you use from the upstream source.
If you dislike this behavior (and who wouldn't) you can up-vote this Visual Studio Developer Community issue: Allow search upstream sources on Azure Artifacts
And I can confirm as of 12/28/2022 this is still an issue. :-(
I have a situation where we have multiple C# projects that use similar set of Nuget packages (ex. Newton Json, Microsoft Compilers and CodeDom, Owin, log4net, jQuery, EntityFramework etc.)
I am trying to see how we can have a shared location for all Nuget packages to reduce the footprint of those binaries in Git, having a single repo for them by centralizing them in one place.
One option I found is to use Nuget.config in each project with repositoryPath set to point at the shared location. This works great for adding/upgrading/restoring Nuget packages in the project but it is not very clean when a package gets removed from one project but is still required in a different one. Basically the package will get removed from the shared location and the change is committed to Git, then when the other project requires it, it would get restored and added back to Git. Not a perfect solution in my mind.
I have a two part question:
1. Is there a way to improve the above workflow when packages get removed?
2. What is the industry standard for handling third party libraries delivered via Nuget? Or if there is none, can you share your experience handling Nuget packages across multiple projects.
If the concern lies with the footprint/organization of the Git repository, maybe you can do a .git ignore for the dependencies folders to prevent git from committing them into the repositories. When you need to build the projects from source, just do a dotnet /nuget restore to get the dependencies from the source you configured in the Nuget.config
Not sure if it is the industry standard, but we host our own Nuget server to control the libraries that the different teams can use. Microsoft has an article on Hosting your own NuGet feeds
Hope it helps.
Nuget packages are immutable. All documentation makes this very clear.
I am investigating an issue on my internal Nuget server where prerelease packages can be overwritten. Normally, when trying to upload a package with an existing version, the upload will fail. The Nuget server in question is an Artifactory server.
I immediately assume this to be a bug, but in searching to find other people encountering the same issue, I instead turn up posts from people implying this is normal.
This person asks how to always get the latest version when repeatedly publishing v1.0.0-prerelease.
This person found an Artifactory bug where prerelease packages can't be overwritten if they have a dot in the name.
Another Artifactory bug where STABLE packages can be overwritten because they are incorrectly identified as prerelease
I have yet to find any actual documentation saying prerelease packages can be overwritten on Nuget or Artifactory. I would not expect to, but those posts take it as a fact!
Upon more research and testing, the conclusion is this appears to be an undocumented feature of Artifactory.
The closest they come to documenting this is here:
https://www.jfrog.com/confluence/display/RTF/Managing+Permissions#ManagingPermissions-PreventingOverwritingDeployments
You can prevent a user or group from overwriting a deployed release or
unique snapshot by not granting the Delete permission. Non-unique
snapshots can always be overwritten (provided the Deploy permission is
granted).
That section of the documentation is not specific to any kind of repository. It is never specifically clarified anywhere that Nuget prerelease packages are considered "snapshots", but the terms "prerelease" and "unstable" are not used anywhere in the documentation (for any repository type).
Since this cannot be turned off, my team went with using automatically-generated versioning for prerelease packages to avoid having issues caused by package overwrite.
nuget.org does not allow any overwriting of prerelease packages.
I have turned on TeamCity's NuGet Server and I want to push in common packages (i.e. from public sources such as NuGet.org) because the build server cannot see outside our company, so restoring packages on the build server from NuGet.org is not possible.
I cannot see how to push these packages on to our TeamCity server. I've seen various answers suggesting to use a package build still or some other means of publishing from within a build, but this is not appropriate for my use case.
If I try to publish from a command line it complains that it cannot find an API key (where do I get that from?) and it won't allow me to enter my credentials (I assume my team city login would be it) as it tells me "Cannot prompt for input in non-interactive mode." (I didn't set that mode and I can't see how to turn that off).
So, how do I push/publish an adhoc package that I obtained elsewhere into team city?
I believe that the nuget functionality provided by TeamCity is an API added on top of TeamCity's builtin artifact functionality.
There are a number of consequences of that:
When a build configuration is executed that produces any .nupkg files that are marked as artifacts, they will be available on the Teamcity nuget feed.
As with all other artifacts nupkgs published in TeamCity are subject to Teamcity's general artifact retention rules.
Access rules for nuget packages are the same as access to the TeamCity projects.
There is however as far as I know no implementation in the Teamcity Nuget API for pushing packages to it. The general practice for storing original or generated packages is to use a stand alone nuget server or service like a normal file share, a Nuget.Core based server, proget or myget.org.
Update:
If you end up with many packages of your own I've heard people reporting that Teamcity becomes quite slow when the clients are resolving the packages.
Update 2:
The last years I've adopted the notion of separating build artifact packages into the two categories library package and deployment package. A separate package repository can be used for both types but a repository such as the one available in for instance Octopus deploy should only be used for deployment packages.
Update 3:
Microsoft have a page for a number of nuget server options.
per internal policies I have to setup a local nuget repository that contains only the packages approved by internal committee.
I know how to setup a local nuget server and I also found how to download all packages from Nuget (http://weblogs.asp.net/jgalloway/archive/2011/02/02/downloading-a-local-nuget-repository-with-powershell.aspx), but what I'd need is a way to just download the packages that are approved with their dependencies, save them on my local server and then possibly keep them up do date when a new version comes out and it is "re-approved" internally.
Thank you
This is exactly what ProGet was built for :)
ProGet is a private NuGet repository designed to manage both third-party and in-house libraries used as application dependencies. There's a free version of ProGet available that meets most organizational needs.
There are also other private repositories available, including MyGet, JFrog Artifactory, and Sona Nexus. Make sure to check out Taking NuGet to the Enterprise for other best practices in introducing NuGet in your organization.
(disclaimer: I work for Inedo)