Merge with jaraco.crypto
jaraco opened this issue · 3 comments
Hi Victor. Like you, I adopted the abandoned ctypescrypto as jaraco/jaraco.crypto. I haven't used the library much lately, so was thinking I would just abandon it, but I looked and found you'd revived ctypescrypto. Shame we couldn't have been working together all this time.
As you can see, the code has since diverged quite a bit, and we've solved many of the same problems. My question to you - would be interested in adopting any of the changes from jaraco.crypto, such as the exposing of evp and cross-platform library discovery?
Let me know your interest or thoughts. I'm primarily interested in setting the code free, so I'm very open to any proposal.
Hi, Jason
I'm very glad that somebody else is interested in working on ctypescrypto rathere than just using it.
Unfortunately I have almost abandoned this project about two years ago and have some unsolved problems i.e. with python3 migration and with test coverate. (cms module has no tests at all and it seems to be a most used).
I've looked breefily at your code and it seems to me that we are going in different directions. You are basing all you objects on ctype.Structure, i.e considering openssl structure as transparent thing with accessible fields. I consider OpenSSL object pointers opaque handlers which can be only passed to libcrypro functions. This more or less in the same line as OpenSSL developers move. In the 1.1 version they make most of structures opaque and provide accessor functions that were missing before.
And support of 1.0 and earlier versions of the OpenSSL is only reason why I use ctype.Structure at all.
I.e. I use top-down approach - design objects so it is easy to perform commonly used tasks with them, That is why I have big omissinns covering an API - I never encountered tasks for which these omitted functions were needed, And this is why I have ec module, which seems to be much more low level than rest of my modules. - I just have one project where I have to compute EC public key from private outside of typical high operations with EVP_PKEY.
Your approach seems to be bottom-up.
Also I've found out that if you want to work in both 32-bit and 64-bit environments, you ought to declare prototype of every function you use using argtypes and restype methods of ctype function objects. It was at least the case 5 years ago when I've started my fork.
From a first glance i cannot see any part of code which is missing or underdeveloped in my version and deserves merging from yours.
In my opinion I miss
- Common ancestor for PEM/DER serializable objects (certificates, requests, CMS messages, private keys) which would transparently handle binary and text data in python3
- Proper absstractiion for message text with same ability to handle str/bytes for CMS message content
- Test coverage for CMS and certificate/request construction.
- X509Req handling, so one can properly implemnet both client and CA side of PKI.
Your approach seems to be bottom-up.
That sounds about right. My approach is usually first to expose the underlying API as genuinely as possible and then to build abstractions on that.
I'm perfectly happy to abandon that approach and redirect users (if any) from that project to this one.
I have lots of experience with packaging and testing cross-platform, so I could help by adding CI support and other modernizations of the packaging tooling. I might even suggest using jaraco/skeleton to adopt a lot of practices wholesale, although I'd also be happy to take it slow and suggest improvements piecemeal.
Would you be interested in adding me as a maintainer, either based on my experience with jaraco.crypto or perhaps after some pull requests? I'm happy to defer to your vision for the project and aid in its maintenance as long as the project is open to it.
I'm unlikely to implement new features, but I would be happy to step in periodically to pair with another contributor to help with an implementation or to address shortcomings.
Problem with using such approach with OpenSSL is that it is too versatile and too underdocumented, not to mention evolving over time.
It is quite hard to tell whether particular function is part of the API which is intended for use by the application developers or some internal function, exposed into the public header by pure chance and ought to disappear in the next major release.
About ten years ago I have written API documentation for Libcrypto, for Russian certification body. The problem was thatt deveiopers of certified software have right to use only documented API of certified library. So, I have at least to mention everything which can be useful. it was quite hard job, even if I have to support only one particular OpenSSL version.
In the ctypescrypto we have to support several versions which can be found in the wild. About a year ago I had to convince PostgreSQL developers, that it is not tiime yet to drop support of OpenSSL 0.9.8, because it is used in the SLES 11, and it is still supported Linux distribution. Since that we in the PostgresPro have dropped support of both SLES 11 and RHEL 6 and I'm wery glad with it. I've even planned to order some pizza into the office to celebrate funeral of RHEL 6, but coronaviruts pandemy and remote work ruined these plans.\
As for my vision of project, I've expressed it in README.md. Yesterday I also wrote blog post to clarify some things which haven't been covered in README.md.
So, you are welcome to the project.