Library not compliant DNX (like HttpWebRequest/Response instead of HttpClient)

[ebekker]

Library not compliant DNX (like HttpWebRequest/Response instead of HttpClient)

[lennybacon]

I wouldn't say legacy . It's a lower abstraction layer. If you look at HttpClient internals (HttpClientHandler.SendAsync) you'll see that it uses a HttpWebRequest.

But you are right that the code is not portable to e.g. Linux and Mac. But wasn't there already a ACME client? So what's your point in having the code running on DNX/CoreClr?

[ebekker]

So, secretly, I've always wanted to be able to port the code eventually to .NET Core and make it cross-platform if possible, but my initial concern was just getting to 1.0.

So when I eventually try to attack the xp issue, I'll pby have to refactor some things in a few places, but along the way I've tried to put abstractions in certain places to help that out eventually, for example, refactoring the CertManager interface and using OpenSSL as one of the providers should help that out down the road.

And in AcmeClient, I tried to isolate all the actual HTTP calls as much as possible to a couple methods, but you're saying that wasn't enough -- that it's still not workable? Now, the code is not necessarily the best candidate for async code, but then again, this is the type of code that doesn't have to be especially performance-sensitive, and so if there are places where the code blocks a bit, it's not that bad, at least that my take on it. Would you agree?

Then there's the other side of the coin, it would also be nice if the library was as accomodating as possible to the largest base of existing environments, such as older .NET 4.0 and perhaps even (gasp!) 3.5. Again, that's something I'll look into after getting a reasonable 1.0 released.

[ebekker]

This issue is actually covered by #11, except that the original intent of that ticket was better backward compatibility, but we can just use that to mean better backward and forward support.

[tebeco]

Where and why am i doing that ?
i'm trying to move the Acme client into a aspnet5 middleware
So far I was working with Lone-Coder code base since there's a really clean separation between acme client, certification, installation. (even plugin etc ...)
After few bad attempt I've finally decided to start from the root (to have lot less error and dependencies)
I'm now working on a "buildable" version of ManagedOpenSsl that is Dnx compilant. I would say that I have about 30-40% done
But still there's place for little refactoring after that
For example Encoding.ASCII is now Encoding.GetEncoding("ASCII") and that could be reused
I'll keep you in touch soon about that and acme client

[ebekker]

Do you think that your refactored version would be backward compatible with 4.x or that it itself will be hard-wired for .NET Core? If the former, then you can refactor it and and submit a PR to pull it back into the official code base. If the latter, you could try to throw it into some abstraction layer, say in the Util namespace for example, and then it can at least be isolated to a single or few classes that can be swapped out or even "#if" guarded so that it could be built for different platforms.

[tebeco]

I'm not sure for now.
The project check & build only if the compiler is ok for .NEt Framwork 4.5.1 & .Net Plateform 5.4
So I "think" it will be compliant with both of it (I'll have to test it once it build)

I'll try to find a way to give you an access to my repo (i'm unsing VSO, I can't use Github everywhere I want because of proxy that can't make ssh/https work for github)
Just few hours ago when I thought I was done with almost all error I discovered that the pattern "BeginX/EndX" was almost completly removed so i have to rewrite the class as Async classes

Can you open the "Issues" page on "ebekker/openssl-net" ?
That way i'll ask specific question there (if you're ok with that) I'm almost ouf of subject here.

[ebekker]

The reason I don't have issues on my openssl-net repo is because it's not my repo, I only have a fork of the original project which is here, so you should log any issues there. I forked it because I wanted to package it up as a nuget package so that I could reference it in this project cleanly. But other than the nuget stuff, I wasn't planning on making any changes or enhancements to it.

So if you have any issues that you run into related to OpenSSL, just open a ticket in the original repo. If the main author doesn't respond, I'm also watching it so I might be able to pitch in.

[tebeco]

Ok, so i've migrated ManagedOpenSsl to something called "OpenSslDnx"
I still have some UnitTest that crash (one about ALPN that drive me mad)
I'll go blind and convert this client and Lone-Coder lib too

[tebeco]

Hi there, I'm having trouble with AcmeSharp since there's A LOT of PInvoke
Even moving it to Azure could be challenging.
My idea is to make it run inside a MiddleWare inside MVC6 code so it would handle PFX generation & Renewal all bundled in the published release without requiring a "third part computer"

Just a quick example of my trouble :
So we have :

• an unsecured String that we convert to a SecuringString
• then to a SecureStringPointer (Using Marshal.SecureStringToCoTaskMemUnicode)
• then we use it to export PFX ( NativeMethods.PFXExportCertStoreEx)

I've took a look at msdn about Crypt32 and PFXExportCertStoreEx function and its the password parameter :
In LPCWSTR szPassword,
szPassword [in]
String password used to encrypt and verify the PFX packet. When you have finished using the password, clear the password from memory by calling the SecureZeroMemory function. For more information about protecting passwords, see Handling Passwords.

So i'm curious about the SecureString pointer. I do get that you're using it for memory security etc ... but what would happen if we pass a pointer to a simple "System.String" instead ?
I think i'll have to "get rid" of secure algorithm,

For example :
Marshal.SecureStringToCoTaskMemUnicode is not existing at all, there's workarounds but it requires recoding A LOTS of core function manually

So I'm wondering if I have to rewrite everything from scratch, what is optional etc ...

[tebeco]

And since i'm completly stupid, I forgot to specify something important :D

So far my concern was to make it compliant it the following Framework in the project.json :
"frameworks": {
"dnx46": { },
"dotnet5.4": { }
}

So Maybe i'll remove the "dotnet5.4" until I got something working ^^
The issue is that it will be as difficult as now when i'll try to Add it again so it's only a temporary solution

[kedare]

Any update on the DotNet Core compatibility ?

[ebekker]

I've made a little progress on the .NET Core version (or I should say .NET Standard to be more precise), but I'm actually trying to finish up and round out the .NET Framework version since there are still a lot of folks that depend on it. It will also give me a better base to migrate to .NET Standard.

However, there is now a new purely-managed code base for the PKI functions based on Bouncy Castle, so I've demoted the OpenSSL (lib and cli) providers. They'll still be there for a little while, but if all goes well and no one runs into any problems, the BC version will pby become the only version fully supported going forward. And it should be fully compatible with .NET Core/Standard going forward.

[tebeco]

Nice ;)