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

"You need NuGet client 4.1" message on push #4315

Closed
maartenba opened this Issue Jul 3, 2017 · 14 comments

Comments

Projects
None yet
7 participants
@maartenba
Contributor

maartenba commented Jul 3, 2017

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?

@skofman1

This comment has been minimized.

Show comment
Hide comment
@skofman1

skofman1 Jul 5, 2017

Contributor

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.

Contributor

skofman1 commented Jul 5, 2017

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.

@maartenba

This comment has been minimized.

Show comment
Hide comment
@maartenba

maartenba Jul 6, 2017

Contributor

Is there an API design for this? This is blocking some of our customers that are not using nuget.exe but other clients.

Contributor

maartenba commented Jul 6, 2017

Is there an API design for this? This is blocking some of our customers that are not using nuget.exe but other clients.

@anangaur

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Jul 6, 2017

Member

@maartenba lets sync up offline on this one. Can you ping me on anangaur at msft email id?

Member

anangaur commented Jul 6, 2017

@maartenba lets sync up offline on this one. Can you ping me on anangaur at msft email id?

@maartenba

This comment has been minimized.

Show comment
Hide comment
@maartenba

maartenba Jul 7, 2017

Contributor

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?

Contributor

maartenba commented Jul 7, 2017

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?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 7, 2017

Contributor

lets sync up offline

please don't. This is important and we (as paket community) need to know!

Contributor

forki commented Jul 7, 2017

lets sync up offline

please don't. This is important and we (as paket community) need to know!

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 7, 2017

Contributor

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.

Contributor

isaacabraham commented Jul 7, 2017

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.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 7, 2017

Contributor

Linking to #4088

Contributor

isaacabraham commented Jul 7, 2017

Linking to #4088

@anangaur

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Jul 10, 2017

Member

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.

Member

anangaur commented Jul 10, 2017

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.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 10, 2017

Contributor

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.

Contributor

forki commented Jul 10, 2017

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.

@maartenba

This comment has been minimized.

Show comment
Hide comment
@maartenba

maartenba Jul 10, 2017

Contributor

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.

Contributor

maartenba commented Jul 10, 2017

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.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Jul 10, 2017

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

cartermp commented Jul 10, 2017

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 10, 2017

Contributor

@maartenba see that header is excellent push security protocol. Now I need one commit and one release call to behave.

Contributor

forki commented Jul 10, 2017

@maartenba see that header is excellent push security protocol. Now I need one commit and one release call to behave.

@maartenba

This comment has been minimized.

Show comment
Hide comment
@maartenba

maartenba Jul 13, 2017

Contributor

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

Contributor

maartenba commented Jul 13, 2017

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

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Jul 13, 2017

Contributor

@maartenba I filed this exact same issue a little over a month ago -
#4083

With Chocolatey, the pushes are not to NuGet.org so it's unlikely to be affected by this change for quite awhile.

Contributor

ferventcoder commented Jul 13, 2017

@maartenba I filed this exact same issue a little over a month ago -
#4083

With Chocolatey, the pushes are not to NuGet.org so it's unlikely to be affected by this change for quite awhile.

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