Flurl: Strong Name Assemblies

[carolynvs]

First, I love Flurl, it's awesome and I am excited to use it. Great job! :smile:

I thought I'd throw in my vote to strong name the Flurl assemblies, if it's not a huge headache. Currently, I believe my only workaround is to use StrongNameSigner to sign Flurl assemblies (or build and sign myself) and then ship the signed assemblies with openstack.net. Which I'm willing to do but would prefer to not redistribute my own signed Flurl assemblies.

I am maintaining openstack.net, a .NET client for the OpenStack API and it ends up being deployed/used in enterprise type scenarios where strong naming is sometimes required. At this point, I'm not sure I could stop strong naming openstack.net anyway as it's been out in the wild for a while... Not your problem I realize, just sharing the context behind the request.

If it's not something you're willing to take on, no worries. I just thought it wouldn't hurt to ask first!

[tmenier]

Thanks for the suggestion. It's been requested before and I've weighed the pros and cons and decided against strong naming. Seeing the headaches that others have encountered while going down that path has convinced me that's it's not where I want to go and not in the best interest of the majority of Flurl users. However, I would very much encourage a community member like yourself to create and maintain a strongly-named fork. I know there are others who would be grateful for that effort.

[carolynvs]

Thanks for the quick reply. At the moment I'm hosting a package with strongly named assemblies under a MyGet feed, e.g. if you just released 1.0.7, I would push a signed package with the same id and a version of 1.0.7-signed to MyGet.

Sounds like you would be okay with having this package on NuGet.org, maybe Flurl.Signed and Flurl.Http.Signed? The version numbers would then 100% match, just the id suffix would differ. Hopefully I can get the build server to monitor flurl and automatically publish signed versions whenever a new version of flurl comes out.

[tmenier]

That would be a thing of beauty if you want to do it. I'll be happy to tweet it out, mention it on the web site, etc, etc. Thanks!

[carolynvs]

I'm on it! :smiley:

[carolynvs]

The signed packages are now available!

https://github.com/carolynvs/Flurl.Signed

Flurl.Signed
Flulr.Http.Signed

FYI, I made a goof the first time I published to NuGet and since they don't allow editing a package, I had to dork up the version number to get the fix in. The next time you publish a version, the version numbers will match between the signed and official packages.

Let me know if anything jumps out at you. I tried to make it clear on the package listings that these are not the official packages.

[tmenier]

Awesome! I'm adding those links to the main site. I'd also like to link to you personally for attribution. Do you prefer I link to your Twitter handle? GitHub profile? NuGet profile? Other? (None of the above?)

[carolynvs]

My github profile is just fine, thanks!

[tmenier]

I am re-opening this in hopes that another user can step up and help get these running again. A perfect solution that keeps the signed packages current with the latest version of Flurl automatically is already figured out, we just need a new place to host it, which I believe can be done on MyGet or AppVeyor for free. I'm hoping @carolynvs can answer any questions. Thanks!

[ellenfieldn]

If you still want this, I can try to get it running again.

It doesn't seem to work out-of-the-box with the build tooling I use, so I'll have to make some small changes.

[tmenier]

@ellenfieldn If you have the time, that would be awesome! AFAIK @carolynvs had it completely on auto-pilot so every time there was a Flurl or Flurl.Http release on NuGet, there would automatically be a corresponding Flurl.Signed/Flurl.Http.Signed available within minutes. It was slick. Just need someone who has the time to set it up again.

Hopefully @carolynvs can answer any questions if they come up. I know very little about _how_ it all worked.

Thanks!

[ellenfieldn]

I have a POC working to try to figure out the tooling and all the little changes that are needed.
Updated source is at:
https://github.com/ellenfieldn/Flurl.Signed

The whole thing is orchestrated with a VSTS build that runs every day at 03:00 UTC. (signing key is also stored securely on VSTS) There is a slight chance that a version will get missed if 2 versions of Flurl or Flurl.Http are pushed to the nuget repo on the same day.

Right now, I've just set it to automatically push the packages to the nuget.org integration environment and verified that they were signed correctly using sn.exe:
https://int.nugettest.org/packages/Flurl.Signed.New/
https://int.nugettest.org/packages/Flurl.Http.Signed.New/

Since I got that setup, I decided to generate a new signing key and remove the old one from the repository (don't see a point in signing something if anyone can just steal the private key). Doing that _shouldn't_ break anything, but I wouldn't bet my life on it or anything. Since I can't overwrite packages even on the integration environment, I'll try to come up with a way to double check it that isn't too destructive to the build scripts.

I have a few questions for you @tmenier :

1. Do you have a preferred package repository? Normally, I would prefer Nuget.org since basically everyone already has that configured, but obviously the Flurl.Signed and Flurl.Http.Signed packages are already taken.
2. Since we basically have to start with a fresh package, do you have a naming preference? I tentatively picked Flurl.Signed.New and Flurl.Http.Signed.New since I was testing with Nuget.org and the previous names were already taken. If I push to a different package source, I can of course use the original *.Signed names.

[tmenier]

@ellenfieldn Ideally I'd like it if they were kept on NuGet with the same names. @carolynvs Would you be willing to transfer or share ownership of those packages? Looks like it's just a matter of adding @ellenfieldn as an owner and (optionally) having him remove you.

Just FYI my availability over the next week will be a little spotty so I apologize in advance if you have more questions that I can't get to.

Thanks again.

[ellenfieldn]

Yeah, I wholeheartedly agree!

[carolynvs]

Ill add you to NuGet when I’m at a computer. ❤️👍

[carolynvs]

@ellenfieldn I've added you as a co-owner on nuget for the Flurl.Signed and Flurl.Http.Signed packages. Feel free to email [email protected] if you run into any issues.

Also in case it's helpful, here's the source for the CI job that I was running previously to maintain those packages.

https://github.com/carolynvs/Flurl.Signed/blob/master/build.cmd

[tmenier]

@carolynvs @ellenfieldn Thanks again to both of you. It'll be great to be able provide people a path forward on this! Once it's ready I'll be happy to list it on the main site and credit you both.

[tmenier]

@ellenfieldn

There is a slight chance that a version will get missed if 2 versions of Flurl or Flurl.Http are pushed to the nuget repo on the same day.

If I ever publish twice in the same day, there's a far better than slight chance I don't want people using the first one anyway, so no worries. ;)

[ellenfieldn]

@carolynvs Thanks so much for your help! I totally forked your repository and just made updates to support changes to MSBuild and to nuget.org. (I guess I also popped the signing key out of the repo and generated a new one)

@tmenier I should have a new version of Flurl.Signed and Flurl.Http.Signed published soon. I'll let you know when once it's indexed and I can grab the package to verify it.

[ellenfieldn]

@tmenier Alright everything is good to go!

Github: https://github.com/ellenfieldn/Flurl.Signed
Flurl.Signed Nuget: https://www.nuget.org/packages/Flurl.Signed/
Flurl.Http.Signed Nuget: https://www.nuget.org/packages/Flurl.Http.Signed/

[carolynvs]

Hurray! Thank you for jumping in and getting it up and running again! 💖

[tmenier]

Sweet!! Nice work! @ellenfieldn do you have a Twitter handle? Want to announce this and make sure you both get credited.

[ellenfieldn]

Sure do. Shockingly it's @ellenfieldn

Thanks!

[tmenier]

heh, how did I miss that

[tmenier]

@carolynvs @ellenfieldn I guess I should have asked, do either of you have a preference of whether I link to your Twitter or GitHub page under "Acknowledgments"? Looks like I haven't been consistent about that.

[ellenfieldn]

@tmenier Hmm. Github I guess. I seem to use it more than I use twitter.

[carolynvs]

GitHub is fine 👍 I am carolynvs everywhere really so it's all good.

[tmenier]

Meant to get to that sooner but you're both now credited on the home page. Thanks again :)

[tmenier]

@ellenfieldn It looks like signed packages are not getting created anymore, not automatically anyway. Just wondering if you are aware of that?

cc @kroniak

[ellenfieldn]

Yeah. I'm aware. Since nuget.org did their whole signed package update late last year, you can no longer get away with using a self-signed certificate. They just reject the package if it doesn't chain up to a trusted CA.

Since it looks like some people still want to use this, I guess I'll buy a real one. I know the CAs do some level of identity proofing, but I'm not sure how long it will take.. Hopefully not too long.

I'll update here when I have it fixed.

I also am tracking this with an issue at: https://github.com/ellenfieldn/Flurl.Signed/issues/4

[stogle]

Hi @ellenfieldn any news on this? I created https://github.com/ellenfieldn/Flurl.Signed/issues/6 before I came across this issue.

[ellenfieldn]

@stogle Hey! I responded on the other issue, but since a lot of people come here first, I'll copy it and post it here:

"Hey, I realize that I'm way late in responding to this (Sorry!), but It's unlikely. The requirements for signing the packages and publishing to nuget.org has changed and requires a code-signing certificate, which tend to be kinda pricey.

I could maybe look into publishing them to an alternative package source like MyGet if that would help?"

[stogle]

@ellenfieldn Thanks for replying!

I could maybe look into publishing them to an alternative package source like MyGet if that would help?

I haven't heard of MyGet, but it seems to be a paid service? I think we'd be more likely to fork and apply the strong naming ourselves than go that route.

The requirements for signing the packages and publishing to nuget.org has changed and requires a code-signing certificate, which tend to be kinda pricey.

So the official Flurl and Flurl.Http packages are published with a CA-signed certficiate then? Would @tmenier be willing/able to allow you to use the same certificate for the Flurl.Signed and Flurl.Http.Signed packages?

The reason I would like a strongly-named Flurl is because we need to register one of our DLLs with regasm.exe /codebase so that it can be used via COM. Due to the "viral nature" of strong-naming, that means that every dependent assembly has to be strongly-named. The only dependency we have that isn't strongly-named is Flurl.

[tmenier]

So the official Flurl and Flurl.Http packages are published with a CA-signed certficiate then?

No, they're not signed at all.

[stogle]

So the official Flurl and Flurl.Http packages are published with a CA-signed certficiate then?

No, they're not signed at all.

Then I'm confused why Flurl.Signed and Flurl.Http.Signed would need a CA-signed certificate. I thought that the only difference between the official packages and the signed ones was that the latter had strongly-named assemblies. Strong naming the assemblies shouldn't have anything to do with signing the NuGet package, or CA-signed certificates. It's a fairly simple process.

[ellenfieldn]

So the official Flurl and Flurl.Http packages are published with a CA-signed certficiate then?

No, they're not signed at all.

Then I'm confused why Flurl.Signed and Flurl.Http.Signed would need a CA-signed certificate. I thought that the only difference between the official packages and the signed ones was that the latter had strongly-named assemblies. Strong naming the assemblies shouldn't have anything to do with signing the NuGet package, or CA-signed certificates. It's a fairly simple process.

So. This is a little embarrassing.....

After nuget introduced package signing, when I would try publish the Flurl.Signed packages to nuget, it would return a response "Response status code does not indicate success: 400 (The package was signed. You must register the signing certificate to publish signed packages.).".

I clearly completely misunderstood that error -- I don't sign the packages themselves and only do strong-name signing of the assemblies, so I assumed that was somehow also enforcing a check on the assemblies themselves. Turns out that for packages that are not signed by the author, nuget.org will automatically sign those packages to ensure integrity between nuget.org and the client. When I was packaging the signed version, it was picking up the signature that was magically included with the original flurl packages by nuget.org. One very long wild-goose-chase later and....

Only took me 1.5 years to realize!

I'll get an update out this weekend. I'm really glad you posted on this issue and convinced me to take another look at it again!

[stogle]

I'll get an update out this weekend. I'm really glad you posted on this issue and convinced me to take another look at it again!

Oh wow, if you can do that it'd be amazing. I had started contemplating other avenues and all of them were dark and scary. Now I'm looking forward to Flurl 3.0 (and Flurl.Signed 3.0) again.

[ellenfieldn]

Well, I got it set-up a little quicker than I thought. I have Flurl.Signed 2.8.2 and Flurl.Http.Signed 2.4.2 published. Do you need the prerelease package versions too? If so, I'll track that as part of a new issue on the Flurl.Signed repo.

[stogle]

I see them! Thank you.

Do you need the prerelease package versions too?

I don't personally have a need for those right now, but don't let that stop you.