Trust Sentry on NuGet: Package Prefix Reservation

As a pillar of the .NET ecosystem, NuGet specifies how .NET packages are created, hosted, and consumed, while also providing the necessary tools to achieve these functions. Despite being relatively new (launched in 2010), all project templates from Microsoft’s Visual Studio have included packages that required NuGet.org for several years.

NuGet Package Ownership & Security

Until recently, anyone could upload a package with any name to NuGet.org. Unfortunately, inconsistent naming conventions created an atmosphere of distrust, as more and more .NET users wanted to know who owned and created NuGet packages. 

Jon Galloway, Executive Direct of .NET Foundation, summed the naming conundrum up nicely:

One thing that bothers me about it is the namespaces. The .NET System namespaces are beautifully organized, but community/open-source code namespaces are an anarchistic babel.Those that originate from a big company usually start with the company name, those that come from larger project usually take the the project’s name.

One-off code snips/hobbyist/micro-projects usually contain a random concatenation of some or all of the following words: monkey, alien, squishy, bug, fuzzy, code, util, works, MyNamespace, namespace, ware, example, contrib, and lib: monkeyCode, fuzzyAlienWare, utilLib, bugware, etc. This is the case I’m talking about.

Most .NET developers are fairly used to the concept of starting their library or application namespace with the company name. This has been a guideline since .NET Framework was introduced back in 2002. In fact, they even have it on their new docs website:

The issue with “guidelines” instead of “requirements” is that people will (and did) take advantage of the credibility that accompanies a name that does not belong to them. In other words, people will upload packages using a prefix that isn’t necessarily owned by them or the company they work for. Unsurprisingly, without a way to reserve package prefixes, people started uploading their own System.* and Microsoft.*.

Fortunately, the NuGet.org team took proactive steps to curb misleading namespaces and instill a sense of security with their October 2017 feature announcement. Enter: package prefix reservation.

Package Prefix Reservation

A package prefix reservation ensures no new (unwarranted) packages are published using a reserved prefix, assuming that the application passes the criteria defined by NuGet.

It’s worth noting that old packages are not affected by this change. Take for example:

You may think to yourself: Hey, these packages both contain the prefix Microsoft. I bet they’re both owned by Microsoft. Not so fast. 

The second package surely belongs to Microsoft. How can we be sure? This blue check mark is a visual indication of the reserved prefix is shown on NuGet.org and Visual Studio.

The first package though, even though prefixed with the namespace Microsoft.*, is actually owned by CamronBute and e-bits. The first release of this package was 1/4/2016, before the reserved ID feature was introduced.

In addition to allowing for quick and easy recognition of the package owner, the visual indicator is especially useful considering that the Author field can actually be defined by anyone. In the example below, you’ll see that I’m the package owner, and that I also add Sentry as owner. Here at Sentry, we publish our NuGet packages with authors: Sentry Team and Contributors, so I’ve added that here as well. 

Of course, there is nothing to stop Joe Smith from also using authors: Sentry Team and Contributors, but the visual indicator, along with another new feature (organizations — more on that later), will differentiate the packages appropriately.

How is the package prefix reserved?

Currently, the process to reserve a package prefix is very simple. First, review the package prefix reservation criteria. Next, send an e-mail to account@nuget.org requesting the prefix. We received a reply in a few hours — the verified indications were live on NuGet.org shortly after.

Once you browse your profile settings, you’ll see something like:

Organizations

More recently (April 2018), NuGet.org introduced the concept of organizations on their blog. While organizations appear the same as users externally, this feature feature gives companies and teams space to collaborate under a single identity. 

We’ve converted the sentry user account, which we use now to publish our own packages, into the sentry organization account. From now on, packages will be published with prefix Sentry, and will display the verified check on NuGet and Visual Studio, like our new .NET SDK.

What’s Next

Next, we’ll be working to sign our packages. Signing is the latest and greatest feature that allows you fully trust a package was created by Sentry and not tampered with when you load it into your app. Stay tuned as we’ll be writing about the process here, on Sentry’s blog.

Questions or feedback about how Sentry works with .NET? You can find me on Sentry’s .NET Gitter channel. On top of that, you can check out our docs for .NET or, if you prefer, post in our forum.