Home: Verified Authors for NuGet.org and packages

[clairernovotny]

Much like the concept of Verified Twitter accounts, NuGet.org should be able to verify that packages come from a known author. This mechanism would be optional and opt-in.

There have been incidents of copycat packages uploaded and it can be hard to know which is the right/official package.

Here's a multi-pronged starting point for discussion:

Verified authors. Package author name should be tied to a code signing certificate(s) and identity. Let the existing PKI system deal with verifying identities.

Ability to sign/timestamp NuGet packages and have the NuGet clients validate signatures.

Profile indicator on NuGet.org that an author is verified. Verified accounts would be required to provide the public key from the code sign certs they use. Verified accounts should require that all packages they upload be signed.

The NuGet UI should have some visual indicator that the author is verified and display the verified CN/attributes.

This would help prevent fake/duplicate/misleading packages from being confused with real ones. Even if the account is verified, the author won't match. I.e., no one else will have a Microsoft verified account.

This also helps establish a chain of trust/custody for tracing incidents should any arise. Packages can contain executable code, like ps1 scripts, targets files, or even moduleinit's in dlls. An extra layer of tracability can help mitigate risks.

Bonus: with signed nupkgs, the API key is no longer needed to upload packages; the upload mechanism could just verify the signature of the package and match it to the right account. Or perhaps keep the api key and validate anyway.

This issue was brought up a few days ago in another forum by @raffaeler. I've expanded on it and posted it here for broader discussion.

[SimonCropp]

some history http://blog.nuget.org/20150203/package-signing.html

[clairernovotny]

@SimonCropp Great context. I should add this is a current issue due to some recent packages pretending to be "real" Open source projects forked and rebuilt and posted on NuGet.org with a very similar package name.

Who knows if there's malware in the package and the casual observer has to figure out which is the right one.

While the original/linked specs weren't intended to verify identity, This proposal is just that. I believe it's complementary to the other proposals that would enable signing of packages without a "real" code sign cert. Those authors simply could not be verified.

This crux of this request is a way to display verified information about packages and their authors.

[jasonmalinowski]

Bonus: with signed nupkgs, the API key is no longer needed to upload packages; the upload mechanism could just verify the signature of the package and match it to the right account. Or perhaps keep the api key and validate anyway.

This is dangerous: just because I can obtain a signed package from another team (say, something they provided privately for final testing and sign-offs) doesn't mean I have the right to upload that package to nuget.org.

[clairernovotny]

@jasonmalinowski fair enough, but at the same time I'd think that non-signed packages or packages signed with a cert that's not one of the ones tied to the identity should be rejected too.

[yishaigalatzer]

We do not plan to tie Author to signing of packages. An author many a times will grant redistribution rights to the code (e.g. Apache license), a package owner is not the author of the underlying code necessarily. So this approach is not something we plan to support.

What we do plan on supporting is a mechanism that will allow users to sign packages, and allow consumers to trust specific signatures, and thus protect from hijaacking packages. But not necessarily from picking up the right package.

When it comes to copycat packages - We plan to (very shortly) block packages that appear to be the same (by spoofing the description to look like another package id).

[clairernovotny]

@yishaigalatzer I do agree that having a way to signing packages is useful and would be a building block of this, but I still think there's value in knowing that a particular author is who they say they are.

Even if there's redistribution rights, that's fine. The person can upload their version of the package (re-signed/repacked) with their own author. They don't even really need to sign their package either.

This whole idea is to make it opt-in for certain authors/organizations who want to provide their consumers with an extra level of assurance that the packages come from them.

[yishaigalatzer]

@onovotny that is where the Owner feature comes from. The owner determines which organization shipped the package. Author is just not enough.

[clairernovotny]

I can buy using "Verified Owners" instead of "authors". Part of the issue today is that the owner name is a username and not a "Real Name".

So what about having an option to have verified owners where the display name is tied to an external PKI certificate. That way Microsoft doesn't have to be in the business of validating documents. Leave that to the CA's to do.

Then search results and package displays can highlight verified owners, etc.

Picking on MvvmCross for a moment, how is anyone supposed to know who @cheesebaron or @slodge are?

Or how about https://www.nuget.org/packages/Microsoft.Dnx.Watcher/1.0.0-rc1-final/. The owner is aspnet, not Microsoft. And who's to say that someone doesn't register an account with a username Adobe who's not adobe? That's what I'm trying to help solve :)

[yishaigalatzer]

I'll chat internally about the security and legal implications (one thing we can't do on github) and reply here

[clairernovotny]

Thanks!

[Cheesebaron]

Such mechanism would be very nice to have. Currently MvvmCross has 2 or 3 other developers who have released their own packages which are a fork MvvmCross, all using the MvvmCross name somewhere. This means when searching for MvvmCross in the NuGet package manager they also appear. This can be problematic if the packages are mixed.

The name MvvmCross is not trademarked and the code is licensed under MS-PL, so what they are doing is totally legal. However, I agree with @onovotny that some mechanism to filter unofficial packages is needed.

Last time I tried the Report Abuse thingie on the NuGet webpage, I never got any answer back, so that does not seem to work...

[yishaigalatzer]

Since it is completely valid, there is not much in a way of abuse.

Sorry we missed your report (gets to the same people working on this github repo) but I don't see what should we do about, unless someone claimed fraudulently that his package is the official one.

[yishaigalatzer]

We made a fix in nuget.org where a package title cannot be the id of another package and hence confuse the customers. This doesn't deal with fraud, but it makes sure that you will have to be intentionally malicious and try to fake a name to match another package.

[asbjornu]

I would love to see NuGet build more verification into the platform, in as many layers and vectors of it as possible. Verification of accounts can be done by integrating Keybase, for example.

[diverdan92]

Use this issue to track comments on nuget.org package owner verification, as described in this blog post: http://blog.nuget.org/20170417/Package-identity-and-trust.html

Use this issue to track package signing as a feature: https://github.com/NuGet/Home/issues/2577

[NickCraver]

How will this work for multiple authors, e.g. how would I verify MiniProfiler, yet allow a few of us to push? Would I have to register a foundation to secure the MiniProfiler.* prefix for users as intended? (I realize this crosses issues, but this is a prereq so...commenting here)

[FransBouma]

I don't get why verification is tied to these limiting rules, one of them is a popularity contest. It shouldn't matter how many users a package has to get the author verified. It's actually rather crucial to get everyone verified who is who s/he say they are, simply because it will allow them to register a prefix: you can't register a prefix without being verified.

So to get SD.LLBLGen.* registered for my company, I have to get verified. But I won't get verified as my packages aren't downloaded by the millions. This is a bit silly, as my users now don't know whether an SD.LLBLGen.* package is from a valid owner or not.

Why the limitations? Sounds like MS doesn't want to spent a lot of time vetting package owners, but they have to, as NuGet is more and more positioned as the central hub for .NET programming and where to obtain assemblies from.

(edit) phrasing.

[NickCraver]

@FransBouma I don't think this is correct:

simply because it will allow them to register a prefix

My understanding is relatively few prefixes will be reserved overall, not that the intent it to reserve many. I'd bet most packages aren't namespaces at all, they're single element names with no dot in them. At least, that's my experience. Given that few reservations will actually exist, what's then the driver for everyone to be verified?

There's also the reality that there's no way they can verify everyone, they don't have the resources to do so (and neither does any other platform to date), but understanding need here is critical, since that drives what areas/authors they should focus on.

As for download counts (one of many factors - blog post was just updated to reflect this), I wouldn't think millions is the bar, but maybe. I'd imagine it'll roughly go top down simply because downloads + dependencies is a decent measure of impact that they're talking about. But I have no insider knowledge here...could be way off!

[jariq]

Use this issue to track comments on nuget.org package owner verification, as described in this blog post: http://blog.nuget.org/20170417/Package-identity-and-trust.html

I have already been verified by Certification Authority that have passed Microsoft Trusted Root Certificate Program Requirements and issued a code signing certificate for me. During the process they have verified my e-mail address, my identity (with eID card) and also my bank account. Every single assembly I publish via nuget.org is codesigned with this certificate and the signature can be verified by right-clicking the assembly in explorer (see picture below).

And now you are telling me that I need to get verified again. OK whatever. But you are also telling me that I will most likely not meet the criteria for account verification because me and/or my packages are not popular enough. That is not OK at all.

Instead of presenting assembly signature details to the package consumer in a convenient way you are going to setup manual and tedious account verification process which will not protect assembly integrity in any way.

Please reconsider this decision and embrace code signing of individual assemblies which is a proven platform independent technique for a trusted software distribution and is already used in many Microsoft products.

[NickCraver]

@jariq Just so I understand here - isn't it possible for me to take your DLLs, put them in my package with a confusing name, and put a malicious .targets file in there? I agree these things are very related, I'm not in agreement that the DLLs inside the package (which are re-packageable) serve the same purpose in the container system we have. The package itself can execute more code and carry a large payload than just the assemblies themselves.

...or am I way off base here?

[asbjornu]

I have to echo the concerns of @jariq and ask why you can't use regular code signing, which is a process that will benefit all users of NuGet (such as Octopus Deploy) and guarantee package integrity, none of which will be achieved by the proposed account verification.

Perhaps these are two orthogonal problems, but the way you're describing it, I feel you think you're solving both, when you're in fact "solving" a problem few people have while making it harder to solve the package integrity problem. Can you please reconsider?

[FransBouma]

@FransBouma https://github.com/FransBouma I don't think this is correct:

simply because it will allow them to register a prefix

My understanding is relatively few prefixes will be reserved overall, not that the intent it to
reserve many. I'd bet most packages aren't namespaces at all, they're single element names with no dot
in them. At least, that's my experience. Given that few reservations will actually exist, what's then
the driver for everyone to be verified?

That's a good point, and indeed if they are going for very few reserved reservations, the requirement to get verified for that is then gone. I have the feeling they wanted this reservation system primarily for their own assemblies and to avoid questions from others like "Oh I want that too!" they put up the requirements. 

I still think it would be a good thing if one could register a prefix which is tied to an organisation to avoid name squatters who would upload packages which look like they're tied to the main (and registered) name but aren't.

There's also the reality that there's no way they can verify everyone, they don't have the resources
to do so (and neither does any other platform to date), but understanding need here is critical, since
that drives what areas/authors they should focus on.

Mwah. To be blunt, I don't really care if the largest software company on earth tells me they don't have the resources to verify a limited pool of developers, as that's simply bull: they have enough resources to do so. They likely don't have the will to do so, as it's a tedious process, I'm sure. (and what criteria to use?). 

For package users it can be a big plus if they consume packages from approved contributors/publishers: dependencies through nuget are getting more and more important, so limiting it to a small pool of contributors/publishers gives genuine, non-verified developers who own what they publish a disadvantage over the ones who do get verified: organisations might demand in the (near) future dependencies can only be taken on packages from verified authors. 

I fully understand that right off the bat we can't demand to be verified, that's OK. What I'd like to know from MS is what their roadmap is for verification of contributors/publishers of packages, as for users of packages in general it's a good thing if they can rely on the trustworthyness of the author owning the package they take a dependency on. 

How it looks like now is that small(er) publishers like myself will never be verified and that puts us at a disadvantage over publishers who do get verified. For a central resource like NuGet where everyone looks at to obtain their packages from, it's an unfair disadvantage. 

But we'll see how it plays out :) Indeed, we don't know the inner details so I too can (and likely am!) be way off :)

    FB

[daveaglick]

I had some very long thoughts on this topic that I sent to the team, but I'll summarize here so they're public.

As a practical matter there has to be some sort of "bar" if verification is to be a manual review (obviously self-service verification processes like certificates or signing are different). Given that, download counts as a measure of popularity seems as reasonable as any metric given that you can assume verifying a more-downloaded package may have the largest positive impact sine there are by-definition more package consumers for that package.

That said, what bothers me a little is the idea that this "bar" is somehow absolute. In an ideal world all the package authors that could be verified, would be verified. There's no technical or intrinsic reason why verifying a package author with 100,000 downloads is better than one with 100. As a package consumer I don't care that this or that package is more popular or has more downloads. I ideally select the package that's the best fit and I want to know that the author publishing the package with 100 downloads is the "real" daveaglick just as much as I want to know that for the author of the much more popular package.

There seems to be an underlying analogy here to social media verification (though entirely possible I'm misreading too). I think using that as an analogy for package verification sets the wrong expectation. In social media verification there's absolutely a reason to limit verification to "popular" accounts and it's not all about bandwidth. Verifying an account implies a certain amount of "celebrity": "Hey, here's someone you should follow!" In the package world, and particularly OSS, no position should be taken on "celebrity" status of a package or author. The key, at least IMO, is to ask "do we have the appropriate resources to evaluate this verification request given our other requests" and not "is this package worthy of verification in absolute terms".

[NickCraver]

There's no technical or intrinsic reason why verifying a package author with 100,000 downloads is better than one with 100

I get the sentiment, but I have to strongly disagree there. I'm also a sysadmin, and compromising a package (including fooling people into using yours) that runs on 1,000 build servers is obviously more dangerous than 1 that runs on 10. There's inherent value in scale of impact all around here (both install time and runtime), piggy backing on a larger name is also a larger target if you weave your search tags correctly.

Related: I also personally think all verified accounts must have 2-factor auth here (not mentioned in the post that I recall). Verification of who did own an account isn't worth a whole lot to anyone once not-that-person can do what they want under a verified name.

[jariq]

The package itself can execute more code and carry a large payload than just the assemblies themselves.

@NickCraver that is correct and that's exactly the reason why NuGet also needs package level signing (more than account verification IMO). Important thing to note however is that package level signature will most likely be verified only when the package is added as a reference by the developer. On the contrary assembly level signature can be verified in the runtime (where nupkg does not exist anymore) or manually by the end-user. We simply need both signature types and ideally both based on the same technology.

[NickCraver]

@jariq Sure; that's totally valid to argue for that - I'm not seeing how it argues against verification though. IMO, you're arguing we should do verification: another way. That's totally legit, but also lost in your first comment I think. I'd restate it from that angle.

Of course we have to note that puts onus and infrastructure on each developer rather than anywhere centralized, which flips the bits as to who can do this (and there's cost and ownership issues there). It's a totally valid argument, but with another set of drawbacks at the same time. I see them as orthogonal solutions to the same problem overall.

Perhaps someone from the NuGet team can comment on the signing front. I don't know what is/isn't public there.

[daveaglick]

@NickCraver

that runs on 1,000 build servers is obviously more dangerous than 1 that runs on 10

Is it? What if those 10 build servers are powering Critical Internet Infrastructure (TM) and the 1,000 are all behind the firewall utilities or something. My point was that if you have to down-select what to verify then, yes, obviously impact as measured by download counts is one of, if not the, best way to do it. However, there's no reason why that package author with a package running on 10 build servers shouldn't be verified if not for the limits of human resources. Nothing about that package is intrinsically less-verifiable other than the external factor of download counts. If we start thinking there is, then we'll miss the opportunity to do the most good by verifying smaller packages when resources allow.

I also personally think all verified accounts must have 2-factor auth

:+1: totally agree.

[diverdan92]

Great feedback everyone! Please keep it coming :)

@NickCraver - being a package owner on a package where one or more the other owners was previously verified is one of the criteria that may expedite your verification. In other words, if other verified owners trust you enough to be a co-owner on their packages, that is a good indicator of you as an owner. This will help us drive confidence for packages with multiple owners. That said, all owners will go through a similar verification process, and it is not guaranteed they will be accepted, but it will certainly help.

@FransBouma - @NickCraver is correct in that few prefixes will be reserved. Package namespace prefix reservation will require more scrutiny than verified package owners. We really want to make sure it provides a meaningful identity for the packages submitted by the owner who reserves the prefix.

@jariq @asbjornu - Great feedback. We evaluated package signing (or assembly signing within the packages) as a first possible solution for this problem. We do consider it another solution on top of what we have proposed, but we think it solves a slightly different problem (which is still a very real problem). We are tracking this and will try to find the right approach for it: https://github.com/NuGet/Home/issues/2577. Some problems we considered with this as the first approach is that there are other barriers to being verified by a Certification Authority, as well as the possibility for someone to repackage your signed assemblies (as @NickCraver pointed out). We would need signing at a package level in addition to assembly level (as @jariq correctly pointed out) which would require additional infrastructure either on nuget.org to become a CA, or for the package producers to ensure all of their packages are signed. We recognize the value in a feature like this and will continue to think about the best way to address package/assembly signing in NuGet packages.

Another way to phrase these features (owner verification versus package/assembly signing) is in the problems they address. We are trying to solve an owner identity problem first and foremost. Package signing can help with that, but repackaging previously signed assemblies is a way around this. That said, package signing does help us with the code integrity problem - which we think is a separate problem. With the feature being proposed, we are empowering package consumers with more concrete information about the origin of their package - whether or not they choose to trust that set of owners is up to them, but at least they have confidence that the owner(s) are who they say they are. Package signing adds an additional level of confidence that, not only is the package published by the owner they think it is, but that the code is authored and signed by that publisher, and the code or package hasn't been modified at all. There is so much we can do here, but we have to start somewhere.

[Edit - fixing typos]

[clairernovotny]

Adding my thoughts here that I also sent to the team, I agree with the overall sentiment that it's hard to have a manual verification system that doesn't immediately put in a two-tier system like social. The concept of verification is too engrained there.

I'm also not a fan of re-inventing the wheel. Certificate Authorities already have the infrastructure and auditing requirements and are setup to do just this. What you pay them for isn't the certificate itself (that's a few kb of data). You're paying for the people, time and resources it takes them to verify the paperwork and maintain the appropriate audit trail.

I've said from the beginning that I believe some form of package level signing from a trusted CA should be the foundation of a verification system of owners. The UI can display key information off of the x509 certificate, like the Subject Name, in the UI. Accounts could then restrict or have policies that require all of their packages to be signed with one of several specified public keys.

Basically it boils down to this -- why should Microsoft have to do validation of anything beyond what the CA already does for the info on the x509 cert? NuGet should be mapping certificates to accounts.

The whole prefix this is a separate issue and I'm ok with the current proposal.

[JamesNK]

@jariq @asbjornu -

Bad actor: "Hello NuGet, here is my code signing certificate. As you can see I am trusted by them so I should be verified. I hereby reserve Google.* on NuGet"

NuGet: "A code signing certificate? Why of course sir. No one shall have Google.* packages but you"

Google: "wtf"

[clairernovotny]

@jamesnk I don't think any one is suggesting that prefixes be automatic to anyone. They would be manually vetted regardless so that doesn't happen.

[diverdan92]

@JamesNK @onovotny - correct, no prefix reservations will happen without a manual vetting process against some of the criteria described in the blog post: http://blog.nuget.org/20170417/Package-identity-and-trust.html

[JamesNK]

I agree. I'm pointing out the problem of automatically relying on someone else for trust with no manual verification.

[NickCraver]

@onovotny What's the mapping of certificates to packages? Certificates to domains is covered (what most of the systems you describe are setup for), but how do we map certs to packages they should be related to? I think that's a critical, blurry link we need to solve the signing route. I'm not disagreeing there's some avenue there, but it's not so clear cut. It also only verifies the package, not where it came from - 2 different phases to address overall.

[clairernovotny]

@NickCraver That would be a manual step the account owner has to do -- go to NuGet.org and upload your public code signing key. Or sign a dummy package and upload that. The system will then map that public key to your account.

[NickCraver]

@onovotny but that just says the package came from my account...that's already not in question. The question is whether my account is the one the user intended to get it from.

[clairernovotny]

@NickCraver If the UI only listed the subject name for signed packages instead of the account owner, does it really matter? Keep in mind, we're talking about a signed package as a whole, not a DLL. The "Microsoft Corporation" on the x509 certificate is the only account/owner that really matters then.

[NickCraver]

@diverdan92 Is there any plan for forced 2-factor auth on verified accounts here? If we don't have strong assurances that the uploader is the verified entity NuGet claims it to be, the entire system isn't something we can put much trust in. This is a must have for me to have any faith in any setup proposed here.

[NickCraver]

@onovotny I disagree, any package that executes code on my servers matters to me - I'm the one responsible when malicious code hits the CPU. It depends in the NuGet team aims to solve that problem with this particular approach (which isn't clear to me).

Also bear in mind there are hundreds of variations of the Microsoft name (subsidiaries, countries, dupe company names, etc.), and I could register a cert with Microsoft in it that looks legit. Info in certs isn't as strong as most people give it credit for, we've hit issues with this many times. It's the foundation of how a lot of malware works and gets by admins just looking for "Microsoft" somewhere in there.

[diverdan92]

@NickCraver we plan to enforce scoped API keys for all packages submitted by verified package owners. When we are able to do 2FA (https://github.com/NuGet/NuGetGallery/issues/3252) we would also enforce this for verified package owners.

[NickCraver]

@diverdan92 Do you consider https://github.com/NuGet/NuGetGallery/issues/3252 a pre-req then, or just a nice-to-have later? The former: awesome. The latter is rife with problem, including de-verifying accounts until they have 2-factor enabled or similar down the road.

IMO, 2FA must be in place before verification is, or else you're verifying something fundamentally weak. The scoped API keys aren't any stronger than the single-factor authentication used to create them. Currently the issue you linked contains only an link to a spec which is a 404...so I'm not exactly registering it as high priority over here...

[clairernovotny]

@NickCraver Fair point and that's fine. I would still posit that the basis of any owner information/verification be tied to externally audited data like what a CA does. NuGet can tie that to an account and they can look to verify/group all of the various Microsoft CS subject names into a single account so a user doesn't need to.

Either way, CA's should be the underpinnings.

[diverdan92]

@NickCraver - woops, sorry about that. We were currently planning on this before 2FA, but we'll consider this additional feedback.

@skofman1 / @dtivel FYI.

[NickCraver]

@diverdan92 ...I'm guessing that's a private repo?

[JamesNK]

A while back I was asked to disable logging in via my nuget.org account and rely on my Microsoft account because Microsoft accounts could be protected with 2FA.

This feature will be exclusive to accounts registered with nuget.org.

What does this mean? Will verified accounts log in with their NuGet password again?

[diverdan92]

@NickCraver woops, yes you are correct. That post was created before my time. I'll see if we can get it migrated to a public repo.

@JamesNK - sorry for the ambiguity - that line should just mean that packages coming from nuget.org can have verified owners. It won't automatically appear for other NuGet feeds. Any way you sign into nuget.org should be supported; the verification will be based on account metadata after you are accepted.

[FransBouma]

@diverdan92

Another way to phrase these features (owner verification versus package/assembly signing) is in the problems they address. We are trying to solve an owner identity problem first and foremost.

Then why are there strict rules with e.g. amount of downloads as the criteria? That doesn't make sense, sorry. If you want to solve owner identity problems, you have to vet the owners, one by one, so the rightfully owners are verified, and the ones who don't get verified are apparently not genuine or not who they say they are.

What else does 'verified' mean on NuGet if only a handful of accounts get verified anyway? Please address my concern regarding a possible future where companies dictate developers to take dependencies only on packages from verified authors: if you verify only a handful of accounts, you effectively split the NuGet package repository and it's hard to get into the 'verified' pool if MS won't verify but a handful of accounts.

[forki]

@FransBouma keep calm. It's just yet another enterprisey feature that doesn't really get to the core of issues people have. It's more like a feature Microsoft needs to implement in order to stay in control. See it as that and all the anger goes away.

[FransBouma]

@forki I'm not angry, I just have a couple of questions I'd like to see addressed: now is the chance to give them the feedback and I know it likely is futile and they'll do whatever they think they must, but doing nothing now is no option.

[asbjornu]

Just to kick another idea into the account verification pen, I feel that Keybase has solved this in a very scalable and trust-worthy way (imho; I'm not a cryptographer). Perhaps something similar can be considered for account verification, or perhaps Keybase can be used directly?

To the uninformed, Keybase is a website on which you upload your public keys and verify your account by posting strings of privately signed stuff on social media. Keybase then reads your tweets etc. containing these strings and verifies them against the hosted signatures.

It avoids using a CA and with what we've seen from Symantec and the likes lately, I trust Keybase's verification more than many CA's.

[abatishchev]

What if I wrote a plugin, extension or helper for a package with reserved prefix? How should I name it? I wrote one for Entity Framework and named it accordingly. Any other name would mean it would be never ever found, downloaded and used.
What if I want to create a package for an extension in the Microsoft.Extensions namespace? Is it reserved only for Microsoft itself and its trademarks? Fair enough.
But what about other OSS projects? Is the Newton id prefix reserved to Mr. Newton-King so no other fan of Sir Isaac Newton or owner of golden retriever called Newton can have a package there? Why? Because James published his package earlier? Or because his package has millions of downloads? Both, neither? Doesn't sound fair to me.
I think expanding id prefix monopoly from Microsoft​ trademarks to OSS projects/packages is a bad (unfair, unbalanced) idea.

[diverdan92]

@FransBouma - We _would_ like to verify owners who we feel are positive contributors to the .NET Community. The listed criteria are a practicality to start with. In order for the verification indicator to have any meaning, we (the NuGet team in collaboration with .NET Foundation) must have a thorough review of each applicant (view existing packages, functionality, package metadata, etc...). That's hard to do for every single owner in the immediate future, so we will prioritize based on the criteria listed with the initial goal being to have as much positive impact for package consumers as quickly as possible. As time progresses and as we are able to continue to invest in package identity and trust, we would continuously re-evaluate our progress and see how we can support the positive .NET contributors out there. We really do appreciate this feedback though. When we get to a more detailed specification for this, I will make sure we start considering longer-term roadmaps for some of these features.

@abatishchev - Owners with reserved package ID prefixes will be able to arbitrate subsets of the package ID prefix to other contributors. It is up to you to work with the owner of the package ID prefix to get permission to contribute under a subset of the prefix. For example, if you wanted to work with EntityFramework to be able to submit packages matching the glob pattern "EntityFramework.Testing.*", there would be a process in place for you to do so. Regarding some of the other comments - package ID prefix reservation will be pretty restricted to start with. First and foremost, the package ID prefix must be a strong identifier of the package owner. Additionally, we will not allow common names or words to be reserved.

[diverdan92]

@asbjornu I'll have our team take a look at Keybase. Thanks for the suggestion!

[FransBouma]

@diverdan92 That sounds like you have 2 interns on call to do the vetting for the next year, with a massive book of rules so they can verify at most 1 per day.

At no point have you addressed the concerns where you effectively create two groups of packages: the haves and the have-nots. I'm not kidding here: with .net core, NuGet has become the central place to obtain assemblies to take a dependency on. For enterprises it's crucial these dependencies are trustful. With your criteria and vague wording, us package owners with < 10K downloads can forget being verified in the near future if at all, and thus can forget being part of the group of haves which are verified and trusted and thus first choice for enterprises.

Sorry, but that's simply unacceptable.

(edit) Please do realize what 'verified' means: the identity of account X which represents person X is indeed owned by person X. What more is there? Isn't that very simple to verify? If a person 'X' has access to the account 'X', you can only conclude the person stating being 'X' is 'X' on the website 'NuGet'.

I welcome your thoughts regarding Keybase as it's IMHO exactly what's needed.

[forki]

@FransBouma maybe Microsoft feels that you "are positive contributors to the .NET Community" - so just stay positive. </sarcasm>

[jariq]

Out of curiosity I've created prototype tool for package signing. Digital signature protects both integrity and origin/authenticity of NuGet package. If interested see #5260 for more details.

[diverdan92]

Just wanted to provide an update. We will scope back a bit and start with package ID prefix reservation as a first step. More details here: https://github.com/NuGet/Home/wiki/NuGet-Package-Identity-Verification

Please use this new GitHub issue for discussions regarding prefix reservation as described in the wiki: https://github.com/NuGet/Home/issues/5307

That said, we will continue to use this issue to track owner verification when we get closer to implementing that at scale.

[emgarten]

Duplicate of https://github.com/NuGet/Home/issues/5307