nuget Discussions Rss Feed

New Post: TFS NuGet tricks that I don't already know about?

aniraf — Fri, 24 May 2013 21:38:48 GMT

If I remember correctly, the fix was simply making sure that the environment variable "EnableNuGetPackageRestore" was properly set as a machine level variable. Beyond that, I followed this article http://blog.nuget.org/20120518/package-restore-and-consent.html.

We also had a problem where we were using a local network share to host the nuget packages, and the build machine didn't have access to them.

As far as the issue with the Embed Interop Types...we actually rebuilt that package so that the DLL no longer had the old COM code which forced .net 4+ to include that feature. I'm not certain that there is a way to flag it during the build process.

Hopefully one of those things answers your question.

New Post: Unable to Upload Package - Access is Denied

shieldst — Fri, 24 May 2013 19:35:36 GMT

PS, this is in regards to the official NuGet feed on Nuget.org.

New Post: Unable to Upload Package - Access is Denied

shieldst — Fri, 24 May 2013 17:05:41 GMT

We have been unable to upload any new Nuget packages to our Nuget feed. When uploading packages using Nuget.exe, I get a 403-Forbidden: Access is Denied error.

I got a new API key from our feed's owner, but that didn't give a different result.

Is there something we are doing wrong? My only theory now is that we have too many previous versions on the feed. I will have the owner remove older versions and see if that does the trick, but could there be something else that's wrong?

Thanks for any help you can give.

New Post: TFS NuGet tricks that I don't already know about?

margarette1980 — Fri, 24 May 2013 13:48:24 GMT

Hello Aniraf... Thanks for your post but still I am having trouble in finding version 2.1.505.0 Please send a reply on whats could be the best way to do it?? I tried so many times using the instructions of the previous posts but nothing is OK.

slow cooker pulled pork

New Post: TFS NuGet tricks that I don't already know about?

smaheshkannan — Fri, 24 May 2013 13:31:54 GMT

Hi Aniraf, i am having the same problem .nuget\nuget.targets(57,5): error : Unable to find version '2.1.505.0' of package. Could you please explain what would you do to resolve this. I have correct target file and NuGet.Config file in the MSBuild user AppData folder.

Thanks in advance!

New Post: NuGet Package Signing

outercurve — Thu, 23 May 2013 18:03:13 GMT

The current method of using hashes isn't great for a few reasons. First it requires me to trust that nuget.org hasn't been compromised. This is a massive point of a failure because if someone gets access to NuGet.org they can poison EVERY package and change the hash appropriately. Literally, 13,000 packages which are used as part of build systems for billions of dollars worth of software are riding on the bet that no one can guess a password to NuGet.org. On top of that, if the package is compromised after it's already on my local machine, or before it's been uploaded to the server, there's no way to know. That means I have to trust NuGet.org's (or any repos) security, the package uploader's security and the security of all of the programs on my build machine. With signing I need to trust one thing: that the packager took care of their key. If by default, we create a one-time key as part of "nuget pack" to sign the newly created package, and we immedidately discard that key, I know that the package has never been tampered with since creation. I don't know anything about who signed the package but I know it hasn't been tampered with.

We can also allow people to choose to reuse the same key multiple times by giving them a pfx file when they run nuget pack , then we not only know it hasn't been modified with but for future versions of the package we know it was signed by the same key. If they choose to use a key from someone like Verisign, we not only know it hasn't been modified with and that for future versions of the package we know it was signed by the same key but we also know that the identity of the person has been verified!

New Post: NuGet Package Signing

dotnetjunky — Thu, 23 May 2013 16:50:47 GMT

The hash is computed automatically by nuget.org when the package is uploaded. You can see it from the feed (https://nuget.org/api/v2/Packages).

When NuGet downloads the package, it recalculates the package hash itself, and compare with the value from the feed. If the hashes don't match, NuGet won't install the package.

New Post: NuGet Package Signing

wwahammy — Thu, 23 May 2013 16:41:06 GMT

@dotnetjunky the hash is added by whom? And what how do we know that the hash hasn't been tampered with? What prevents someone from modifying the contents of the package and creating a new hash? Signing would be a pretty strong guarantee that the user would know the package has been modified because the hash is encrypted by the private key. If someone tries to modify the hash without the original private key, the signature is invalid. For some users, being warned that a package has an invalid signature is okay with them because they may have modified the package or they know who modified the package. For a lot of users, it gives them pause to think "wait a minute, something is wrong here." It's a way to guarantee that we know if a package is in the same condition as the creator made it.

I think a web of trust is a perfectly fine idea. It just shouldn't NEGATE signing. Signing isn't a particularly hard issue for the package creator because tools can be written to make it simpler. Fortunately, we're writing a tool right now to simply difficult problems: NuGet.

New Post: Update in VS Console different than nuget.exe

sasha_london — Thu, 23 May 2013 11:08:58 GMT

Hello,

we have encountered different update behaviour between Package Console Manager in VS and nuget.exe . I was wondering whether somebody could advice whether this is a correct behaviour on both sides or it is a bug. I'm using nuget 2.5.40416.9020

My network share repo contains the following packages

Core.Logging.3.2.0-development-1000.nupkg
Core.Logging.3.2.0-development-1001.nupkg
Core.Logging.3.2.0-development-1002.nupkg
Core.Logging.3.2.0.1000.nupkg
Core.Logging.3.3.0-development-1001.nupkg

packages.config for my project contains the following reference

<package id="Core.Logging" version="3.2.0-development-1000" targetFramework="net20" />

In VS (Package Manager Console Host Version 2.5.40416.9020)
If I run: update-package Core.Logging -safe
Then packages.config will be updated to Core.Logging version 3.2.0.1000
I find this expected behaviour as I do not specify -includePrerelease option and I asked for safe update (keeping major&minor versions the same)

However using nuget.exe (NuGet Version: 2.5.40416.9020)
If I run: nuget update mysolution -Safe -id Core.Logging
Then packages.config will be updated to Core.Logging version 3.3.0-development-1001
Not only the update is not "safe" but also a pre-release version of the package is installed.
Is there a way how to get the same behaviour as in the VS console?

Many thanks for your help,

Sasha

New Post: Hosting Own NuGet Feed, Unable to reach it with NuGet.exe

westhusing — Thu, 23 May 2013 07:53:27 GMT

I have set up a NuGet feed following all of the directions here:
http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

I am able to reach the server on all but one machine, but of course the only machine I HAVE to be able to reach it from, I can't.

I consistently receive a 404 error when I use the feed as directed in the tutorial. When I change the feed to use dataservices/packages.svc, I receive a 503 error.

I thought it would help to debug by installing the NuGet Package Explorer. When I install that on the machine, it can reach the NuGet feed I've set up and download packages without any issues.

I also installed Wireshark on the machine. When using Visual Studio, or the NuGet.exe for command-line utilities, I never see any packets trying to reach the NuGet server I set up. When using the NuGet Package Explorer, I see packets showing up in Wireshark contacting my NuGet server.

I briefly tried using Fiddler, but I never saw anything showing up in there when I was using NuGet.exe. I didn't try to see what it looked like when running the NuGet Package Explorer.

So basically, my question is what can I do to either solve this issue, or further debug it?

Thanks for any assistance that can be offered.

New Post: NuGet Package Signing

fearthecowboy — Wed, 22 May 2013 17:39:17 GMT

dotnetjunky wrote:

And I want to repost the link to Phil's blog about trust in NuGet. This is the NuGet team's stance on the topic of package signing.

http://haacked.com/archive/2013/02/19/trust-and-nuget.aspx

And I significantly disagree with some of Phil's assertions.

http://coapp.org/news/2013-04-04-Trust-And-Identity.html

And, you'd damn well read Kim Cameron's Laws of Identity: http://www.identityblog.com/?p=352

Having worked in the Digital Identity ecosystem (and authored a book on the subject) I can tell you that this isn't a trivial problem.

To Address specific issues:

That said, I see private NuGet servers popping up in enterprises too (mine included), so don't ignore these scenarios where package source identity is probably easier to manage at the server level, and strong naming (spit) doing the grunt work at the package level.

Enterprises should be encouraged to issue individual certificates off of a common CA, with which each developer can sign binaries for use inside the organization with. This actually gives a greater degree of trust, since you can track down the individual who actually compiled the binary, and have an effective audit trail.

I want to point out that NuGet today does validate the package file hash before installation to make sure it hasn't been tampered with. Coupled with the fact that we use HTTPS by default, I think we have that concern covered.

No. You don't. Who generated the hash? This doesn't provide any ability to ensure that a poisoned package hasn't been inserted at all. Nor does it provide the ability to know specifically who created a package .

What process?

One of the fears that keeps getting brought up is that for some reason people view signing as "hard" or "difficult" or "complicated" ... the tools can be built so that this is implicit, and requires zero additional work on the part of the developer, and shouldn't require any significant functionality at the server (since, NuGet packages are very useful even without a server).

Today, nuget.org automatically replaces the Owners field in the nuspec file with the account username of the user who uploads the package. So one way to address this concern is to establish a trust system on the nuget.org website itself

And this is a perfect example of tampering with the package. Not Cool.

David Ebbo and Phil Haack suggested relaying on Twitter or StackOverflow. Once we have that system in place, we don't need to sign packages at all.

OMFG. NO.

Relying on a third-party authentication system significantly weakens trust. What happens when someone's Twitter or SO account is hacked? Worse, what if they go offline? What if they disappear?

This is a direct violation of Law 3 :

JUSTIFIABLE PARTIES -- Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.

Involving an unrelated third party is not acceptable.

New Post: NuGet Package Signing

dotnetjunky — Wed, 22 May 2013 17:16:44 GMT

And I want to repost the link to Phil's blog about trust in NuGet. This is the NuGet team's stance on the topic of package signing.

http://haacked.com/archive/2013/02/19/trust-and-nuget.aspx

New Post: NuGet Package Signing

dotnetjunky — Wed, 22 May 2013 17:15:12 GMT

What process?

This topic is only about trust, not about security.

New Post: NuGet Package Signing

maartenba — Wed, 22 May 2013 17:10:16 GMT

YES!

Sent from my Windows Phone

From: [email removed]
Sent: ‎22/‎05/‎2013 19:01
To: [email removed]
Subject: Re: NuGet Package Signing [nuget:444089]

From: fearthecowboy

And simplify the process.

New Post: NuGet Package Signing

fearthecowboy — Wed, 22 May 2013 17:01:20 GMT

And simplify the process.

New Post: NuGet Package Signing

wwahammy — Wed, 22 May 2013 16:59:09 GMT

I strongly recommend we use signing instead. Getting trust and security right is a brutally difficult problem but in this space it's been solved. I don't understand the reluctance to just use the tools we have available to us.

New Post: PackageServer.PushPackage throws WebException: The underlying connection was closed

mckay — Tue, 21 May 2013 14:50:34 GMT

Same problem here, any solution?

New Post: Errors when opening the NuGet Package Manager Console. I have no Add-ins installed.

jlubea — Tue, 21 May 2013 04:59:01 GMT

The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2977) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2984) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2991) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2998) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3005) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The term 'Get-ExecutionPolicy' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

I'm using VS2012. When I go to "Add-in Manager", the list is empty. NuGet used to work fine. I'm not sure when the problem started happening, as I haven't used NuGet in a while. I've installed Windows 8 since the last time I remember using NuGet.

To try to resolve the issue, I've tried installing all Windows Updates, Visual Studio 2012 Update 2, and the latest updates for NuGet from the VS Update Manager. I tried uninstalling Power Shell 2.0 from Add/Remove Windows Features and reinstalling it. I've rebooted after each step if necessary. I can use the Set-ExecutionPolicy and Get-ExecutionPolicy cmdlets if I run Power Shell standalone.

Does anyone have any ideas as to what's going on?

New Post: PLR

rhiansuarez — Tue, 21 May 2013 02:53:54 GMT

quality plr products (http://dsm-publishing.com/plrwithsam/simply-the-best-quality-plr-products)

New Post: NuGet Package Signing

dotnetjunky — Mon, 20 May 2013 19:29:14 GMT

The only real virtues of the signature are:
•to uniquely identify the package publisher, 
• to validate that the package has not been tampered since the publisher has signed the package.

I want to point out that NuGet today does validate the package file hash before installation to make sure it hasn't been tampered with. Coupled with the fact that we use HTTPS by default, I think we have that concern covered.

That leaves us with the other virtue of signature: identify the package publisher. Today, nuget.org automatically replaces the Owners field in the nuspec file with the account username of the user who uploads the package. So one way to address this concern is to establish a trust system on the nuget.org website itself. We have indeed discussed about doing it a while go, with David Ebbo and Phil Haack suggested relaying on Twitter or StackOverflow. Once we have that system in place, we don't need to sign packages at all.