This blog post provides insights into the NuGet team plans for the upcoming quarter (July - Sep 2018). In the March 2018 NuGet Spring 2018 Roadmap, we had outlined Package Signing, Organizations, Cross-platform credential provider support, Repeatable builds for PackageReference based projects, etc. as our immediate priorities. We were able to complete much of this work over the past few months and have made good progress on others. In this blog post, I would like to summarize our progress and share our plans for the next quarter.
Here is a quick summary of various experiences that we enabled over the last quarter.
Package Signing - Signing and publishing signed packages
We enabled authors to sign their packages, publish them to nuget.org and consume them from various NuGet clients. In this quarter, we plan to sign (or counter-sign already author signed) all packages with the NuGet.org repo signature. Once implemented, it will help ensure package integrity for all packages (signed or unsigned by their authors) from the time the package was uploaded to nuget.org to when it is consumed on the developer machine.
In upcoming Visual Studio releases, we will also add the ability to configure environments to enforce various levels of package signing. Note that we only support validation of packages signatures in Visual Studio 2017 Update 6 or later, with older clients ignoring the signature validation step. Support for signature validation for other NuGet clients such as
dotnet.exe will come in the future.
nuget.org now requires either MSA or AAD to sign in and has fully transitioned away from NuGet.org’s home-grown authentication mechanism. We have also enabled, and strongly recommend, using two-factor authentication (2-FA) to sign in to nuget.org.
Organizations allow multiple users to manage the same set of packages. With Administrator and Collaborator roles combined with audit history of which member updated the packages, you now have better control and management of the packages owned by a team or group. Learn more about Organizations on nuget.org
PackageReference migration tool
With Visual Studio Version 15.7, we introduced the ability to migrate existing projects that use the
packages.config format to use
PackageReference. While this functionality will let users quickly migrate to the new package format and leverage its benefits, we plan to make several improvements to address top feedback on
PackageReference over the next quarter.
Cross-platform credential provider support
Status: In progress
If you were to use an authenticated package feed like VS Team Services Package Management with Visual Studio or the NuGet CLI (including dotnet.exe and msbuild.exe), there is no easy way to restore packages on Linux or Mac. Solution such as specifying Personal Access Tokens or API keys in plain text in your
nuget.config file are not good security practices. To address this limitation, we plan to build cross platform support for credential providers similar to the Windows experience.
Improved debugging and symbols support for packages
Status: In progress
With a fast growing .NET ecosystem, we need to streamline the NuGet package debugging experience. Developers should be able to get meaningful debug information when consuming NuGet packages, and for open-source projects, they should even be able to step into the code without the need to clone a repository. We want to enable integrated debugging and source-stepping experiences for all NuGet package consumers.
Improve validation times on package submissions
Status: In progress
In December 2017, we changed the NuGet.org publishing pipeline to introduce a set of validation steps for packages that resulted in longer turnaround times before packages were available for consumption. Our goal is to make packages available with a similar turnaround time as before this change. Over the last quarter, we were able reduce the overall validation time by cutting down the time it takes to index packages by half. We plan to reduce the overall validation time further this quarter.
Enable repeatable builds for PackageReference based projects
Status: In progress
Projects that use PackageReference to manage NuGet dependencies only specify direct package dependencies. The transitive closure for the dependencies happen during restore resulting in potentially different build outputs for consecutive builds (for select corner cases). We plan to address this issue so that repetitive restores (builds) are consistent no matter when and where they happen.
Deprecate external URLs for packages
We want to further improve support for portability and immutability of NuGet packages by allowing authors to embed icons, licenses and documentation within packages. The NuGet clients will also be updated to respect such content. Finally, we will encourage package authors to stop using external content URLs inside NuGet package specifications.
Deprecate vulnerable, legacy packages
As the number of packages grows on nuget.org, packages start getting obsolete either because they are no longer maintained or because there were some issues with them (security, privacy, etc.). Though nuget.org has the ability to hide (unlist) packages, we want to improve this experience by enabling authors to explicitly deprecate packages with specific reasons. We also want to add the ability for package authors to suggest alternatives to consumers.
We want to hear your feedback!
We would love to hear your feedback on these items, or any additional items you think we should be prioritizing. You can reach out to us either by creating a new GitHub issue or by tagging @nuget in your tweets. You can also email me at firstname.lastname@example.org or tag me - @adgrv in your tweets. We will be sure to announce any changes or updates to this plan on our NuGet/Announcements repo.