New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verified Authors for NuGet.org and packages #1882

Closed
onovotny opened this Issue Jan 5, 2016 · 58 comments

Comments

Projects
None yet
@onovotny
Copy link

onovotny commented Jan 5, 2016

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.

@onovotny onovotny changed the title Verified Authors for NuGet.org Verified Authors for NuGet.org and packages Jan 5, 2016

@SimonCropp

This comment has been minimized.

Copy link

SimonCropp commented Jan 5, 2016

@onovotny

This comment has been minimized.

Copy link

onovotny commented Jan 5, 2016

@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

This comment has been minimized.

Copy link
Member

jasonmalinowski commented Jan 5, 2016

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.

@onovotny

This comment has been minimized.

Copy link

onovotny commented Jan 5, 2016

@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

This comment has been minimized.

Copy link

yishaigalatzer commented Jan 5, 2016

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).

@onovotny

This comment has been minimized.

Copy link

onovotny commented Jan 5, 2016

@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

This comment has been minimized.

Copy link

yishaigalatzer commented Jan 5, 2016

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

@onovotny

This comment has been minimized.

Copy link

onovotny commented Jan 5, 2016

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

This comment has been minimized.

Copy link

yishaigalatzer commented Jan 5, 2016

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

@onovotny

This comment has been minimized.

Copy link

onovotny commented Jan 5, 2016

Thanks!

@Cheesebaron

This comment has been minimized.

Copy link

Cheesebaron commented Jan 5, 2016

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

This comment has been minimized.

Copy link

yishaigalatzer commented Jan 5, 2016

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

This comment has been minimized.

Copy link

yishaigalatzer commented Mar 13, 2016

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.

@yishaigalatzer yishaigalatzer added this to the Discussions milestone Mar 13, 2016

@harikmenon harikmenon modified the milestones: Discussions, Future Apr 19, 2016

@rrelyea rrelyea added the Type:Feature label Jun 9, 2016

@asbjornu

This comment has been minimized.

Copy link

asbjornu commented Sep 12, 2016

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

This comment has been minimized.

Copy link

diverdan92 commented Apr 17, 2017

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: #2577

@NickCraver

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

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

This comment has been minimized.

Copy link

FransBouma commented Apr 17, 2017

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

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

@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

This comment has been minimized.

Copy link

jariq commented Apr 17, 2017

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).

image

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

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

@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

This comment has been minimized.

Copy link

asbjornu commented Apr 17, 2017

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

This comment has been minimized.

Copy link

FransBouma commented Apr 17, 2017

@daveaglick

This comment has been minimized.

Copy link

daveaglick commented Apr 17, 2017

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

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

@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.

@onovotny

This comment has been minimized.

Copy link

onovotny commented Apr 17, 2017

@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

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

@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

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

@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

This comment has been minimized.

Copy link

diverdan92 commented Apr 17, 2017

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

@NickCraver

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

@diverdan92 Do you consider NuGet/NuGetGallery#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...

@onovotny

This comment has been minimized.

Copy link

onovotny commented Apr 17, 2017

@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

This comment has been minimized.

Copy link

diverdan92 commented Apr 17, 2017

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

@skofman1 / @dtivel FYI.

@NickCraver

This comment has been minimized.

Copy link

NickCraver commented Apr 17, 2017

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

@JamesNK

This comment has been minimized.

Copy link

JamesNK commented Apr 17, 2017

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

This comment has been minimized.

Copy link

diverdan92 commented Apr 17, 2017

@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

This comment has been minimized.

Copy link

FransBouma commented Apr 18, 2017

@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

This comment has been minimized.

Copy link

forki commented Apr 18, 2017

@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

This comment has been minimized.

Copy link

FransBouma commented Apr 18, 2017

@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

This comment has been minimized.

Copy link

asbjornu commented Apr 18, 2017

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

This comment has been minimized.

Copy link

abatishchev commented Apr 18, 2017

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

This comment has been minimized.

Copy link

diverdan92 commented Apr 18, 2017

@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

This comment has been minimized.

Copy link

diverdan92 commented Apr 18, 2017

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

@FransBouma

This comment has been minimized.

Copy link

FransBouma commented Apr 18, 2017

@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

This comment has been minimized.

Copy link

forki commented Apr 18, 2017

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

@jariq

This comment has been minimized.

Copy link

jariq commented May 20, 2017

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

This comment has been minimized.

Copy link

diverdan92 commented May 31, 2017

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: #5307

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

@emgarten

This comment has been minimized.

Copy link
Collaborator

emgarten commented Nov 9, 2017

Duplicate of #5307

@emgarten emgarten marked this as a duplicate of #5307 Nov 9, 2017

@emgarten emgarten closed this Nov 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment