Closed maartenba closed 7 years ago
We are enforcing a security policy on owners of Microsoft packages and and co-owners of those package. The security policy requires pushing packages with nuget client 4.1 and above. If any of your users experience this issue they can reach out to support for assistance.
Is there an API design for this? This is blocking some of our customers that are not using nuget.exe but other clients.
@maartenba lets sync up offline on this one. Can you ping me on anangaur at msft email id?
Seems this message originates from accounts with RequireMinClientVersionForPushPolicy.cs enabled.
From reading the code: if I specify the following header, will push work when someone has this policy enabled on their account?
X-NuGet-Client-Version: 4.1.0
Or are there any other requirements?
lets sync up offline
please don't. This is important and we (as paket community) need to know!
Please don't take this offline. This is exactly what I meant in my other issue on the Nuget repo. If your want NuGet to be a public API then start treating it as such without more of these surprises.
Linking to #4088
Let me start by saying that only NuGet.org accounts owned by Microsoft employees are affected by this policy change. In the rare event that your account co-owned a package with another Microsoft account, you will be impacted. If you were impacted by this policy enforcement, please reach out to us on support@nuget.org so we can assist you further.
Details:
Newer NuGet clients (4.1.0 and above) are more secure compared to older clients due to the new push protocol they implement (to push to NuGet.org only). Since the protocol is still evolving, we wanted to dog food the protocol on Microsoft package authors first using nuget.exe before mandating the protocol for other authors and clients.
As next steps as the protocol evolves, we are planning to reach out to the various NuGet clients to incorporate these changes (hence my request for you to reach out to me offline so we can work on assessing the impact, and the next steps we need to take). We will be sure to document any changes we mandate on all NuGet clients at a later point in time as well, once we have finished talking to a number of you and devised on the final protocol.
Thanks for the feedback, and sorry about all the inconvenience caused to you.
Just for clarification: if you are a co-owner of any package that is also Microsoft package then you can only push with nuget? We currently shared a package between f# software foundation and Microsoft and this could become an issue.
Also what do we need to do in paket? Please keep this here in the open. Nuget wants to be an OSS project so we should really discuss any changes and it's impact here.
Just for clarification: does this mean there is a second push protocol which is not part of the (public) NuGet codebase? I have been looking through both client and server code and all I could find is this one specific header that would be required. There are some other policies but those seem to relate to symbols instead.
I will reach out via e-mail, but since there are many third party products out there, public discussion would be preferred for the sake of the NuGet ecosystem.
@anangaur Steffen raises an excellent point:
Just for clarification: if you are a co-owner of any package that is also Microsoft package then you can only push with nuget? We currently shared a package between f# software foundation and Microsoft and this could become an issue.
The F# Core Library is currently under joint ownership with the F# Software Foundation and Microsoft. We arrived at this after much discussion, working out issues on both sides, and balancing out what the greater F# community wants to use with Microsoft-specific needs. We'd like to make sure that we can continue to successfully make that the go-to package for the F# Core Library so that both NuGet and Paket clients can push to it.
@maartenba see that header is excellent push security protocol. Now I need one commit and one release call to behave.
So after looking into the source code of client and server, it seems right now there is no new push protocol. The only thing that is there seems to be an experiment of applying a policy to a user account on the server (see above).
I asked NuGet support for my account to be enrolled in all policies there currently are (thanks, support!), to test the above assumption. And yes, it seems that if you get the error from #4083 (400 (Your account requires client version '4.1.0' or higher to be able to push packages
), all that is needed is adding one simple header to push operations for users that are enrolled in such policy:
X-NuGet-Client-Version: 4.1.0
From observation, this header can be sent for all users, whether enrolled in this security policy or not.
While I assume this will probably change in the future (and I hope it can be communicated before the fact, not after - #4088), I'm guessing all in the NuGet ecosystem that do pushes to NuGet.org and want to support the users enrolled in this policy should add this header when uploading packages.
Off the top of my head:
And probably some of the others listed here :-)
@maartenba I filed this exact same issue a little over a month ago - https://github.com/NuGet/NuGetGallery/issues/4083
With Chocolatey, the pushes are not to NuGet.org so it's unlikely to be affected by this change for quite awhile.
Some of our users are reporting a similar error as in #4083. Has something changed to push that nobody but the NuGet team is aware of?