Comments (40)
@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.
from flurl.
Ill add you to NuGet when Iām at a computer. ā¤ļøš
from flurl.
Meant to get to that sooner but you're both now credited on the home page. Thanks again :)
from flurl.
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.
from flurl.
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.
from flurl.
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.
from flurl.
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!
from flurl.
I'm on it! š
from flurl.
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.
from flurl.
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?)
from flurl.
My github profile is just fine, thanks!
from flurl.
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!
from flurl.
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.
from flurl.
@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!
from flurl.
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 :
- 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.
- 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.
from flurl.
@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.
from flurl.
Yeah, I wholeheartedly agree!
from flurl.
@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
from flurl.
@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.
from flurl.
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. ;)
from flurl.
@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/
from flurl.
Hurray! Thank you for jumping in and getting it up and running again! š
from flurl.
Sweet!! Nice work! @ellenfieldn do you have a Twitter handle? Want to announce this and make sure you both get credited.
from flurl.
Sure do. Shockingly it's @ellenfieldn
Thanks!
from flurl.
heh, how did I miss that
from flurl.
@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.
from flurl.
@tmenier Hmm. Github I guess. I seem to use it more than I use twitter.
from flurl.
GitHub is fine š I am carolynvs everywhere really so it's all good.
from flurl.
@ellenfieldn It looks like signed packages are not getting created anymore, not automatically anyway. Just wondering if you are aware of that?
cc @kroniak
from flurl.
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: ellenfieldn/Flurl.Signed#4
from flurl.
Hi @ellenfieldn any news on this? I created ellenfieldn/Flurl.Signed#6 before I came across this issue.
from flurl.
@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?"
from flurl.
@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.
from flurl.
So the official Flurl and Flurl.Http packages are published with a CA-signed certficiate then?
No, they're not signed at all.
from flurl.
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.
from flurl.
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
andFlurl.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!
from flurl.
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.
from flurl.
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.
from flurl.
Hi @ellenfieldn I've been using Flurl.Http.Signed 3.0.0 for a while now and it's great, but I have a need for a couple of the bug fixes in Flurl 3.0.1 and Flurl.Http 3.0.1. Would it be possible to get a signed version of these releases?
from flurl.
Closing, as it looks like issues specific to the signed packages are tracked here.
from flurl.
Related Issues (20)
- Deadlock (or something weird) when calling `GetStringAsync` HOT 2
- 4.0.0 HOT 2
- System.EntryPointNotFoundException on PostJsonAsync HOT 1
- Add support for CancellationToken in IFlurlResponse asynchronous methods HOT 1
- Add option to disable conversion of plus signs to spaces for query parameters HOT 3
- According to RFC-7578 the Content-Disposition filename* parameter in multipart MUST NOT be used
- IFlurlClientBuilder.AddMiddleware cuts the chain of delegating handlers HOT 1
- Encode Issue HOT 2
- .net 8 blazor wasm PlatformNotSupportedException HOT 7
- GetJsonAsync<T> is not working after upgrading the Flurl Http to version 4 >= HOT 5
- The response ended prematurely HOT 2
- Trimming unused code causes the exception - Response could not be deserialized to JSON HOT 4
- Not able to configure Delegating handler in Flurl clientless DI configuration HOT 2
- Collection was modified; enumeration operation may not execute. HOT 1
- DownloadFileAsync => GetFileNameFromPath does not respect redirects HOT 1
- `OnRedirect` does not work with custom `HttpClient` HOT 4
- Serialization based on response status code HOT 1
- Support for Setting HttpRequestMessage.HttpVersionPolicy in FlurlHttpSettings
- SetQueryParam() parameters with the same name will be overwritten, either not overwritten or optionally overwritten HOT 3
- [feature request] support GetJsonAsync with body HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flurl.