Verified Authors for NuGet.org and packages #1882
Comments
clairernovotny
changed the title
|
some history http://blog.nuget.org/20150203/package-signing.html |
|
@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. |
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. |
|
@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. |
|
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). |
|
@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. |
|
@onovotny that is where the Owner feature comes from. The owner determines which organization shipped the package. Author is just not enough. |
|
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 :) |
|
I'll chat internally about the security and legal implications (one thing we can't do on github) and reply here |
|
Thanks! |
|
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... |
|
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. |
|
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. |
|
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. |
|
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 |
|
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) |
|
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. |
|
@FransBouma I don't think this is correct:
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! |
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. |
|
@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 ...or am I way off base here? |
|
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 <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
|
|
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". |
|
@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. |
|
@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. |
|
@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. |
|
@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. |
|
@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. |
|
@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... |
|
@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. |
|
@NickCraver - woops, sorry about that. We were currently planning on this before 2FA, but we'll consider this additional feedback. |
|
@diverdan92 ...I'm guessing that's a private repo? |
|
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.
What does this mean? Will verified accounts log in with their NuGet password again? |
|
@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. |
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. |
|
@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. |
|
@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. |
|
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. |
|
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. |
|
@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. |
|
@asbjornu I'll have our team take a look at Keybase. Thanks for the suggestion! |
|
@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. |
|
@FransBouma maybe Microsoft feels that you "are positive contributors to the .NET Community" - so just stay positive. |
|
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. |
|
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
added
the
Resolution:Duplicate
|
Duplicate of #5307 |
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.
The text was updated successfully, but these errors were encountered: