search

ponylang / crypto

Library of common cryptographic algorithms and functions for Pony
https://ponylang.io
BSD 2-Clause "Simplified" License
11 stars 8 forks source link

Deprecate openssl 0.9.8 #30

Closed SeanTAllen closed 4 years ago

SeanTAllen commented 4 years ago

Deprecation would mean we continue to not test on it (we test with Libressl that shares the same API) and we rename the openssl_0.9.0 compile flag to libressl_3.0.0.

@ponylang/committer can I get some input on this?

This would be a breaking change and grounds for a switch to version 2.0.0 of this library. If we aren't comfortable with deprecating 0.9.8 of openssl (which the project itself has deprecated), we should continue with the 1.x series of this library but introduce a libressl_3.0.0 flag as well.

mfelsche commented 4 years ago

I would say we should support as much openssl/libressl versions as possible/reasonable. I would determine this by what is the default openssl api version on main platforms we support. We can drop openssl 0.9.0 if all major platforms we support moved to 1.1.x or newer.

I think it makes most sense to support openssl/libressl as this is installed nearly everywhere and we do not have a good story around providing custom C libraries alongside pony libraries and building them during the compilation process with corral. Also i think pony needs support for linking against such a specific custom-built library over one provided by the system. If this was possible, we could provide an crypto library to compile and link against and only need to support this one. We could even support: https://hacl-star.github.io/ But all this seems to be a whole different story.

The same applies to the https://github.com/ponylang/net_ssl library.

damon-kwok commented 4 years ago

I think this idea is great, 0.9.x is notorious, it's hard to find in the popular linux.

SeanTAllen commented 4 years ago

@mfelsche openssl 0.9.8 has been deprecated by the project. It's not supported on any recent LTS for anything like Ubuntu, even Ubuntu 16.04 (3 LTS ago) is openssl 1.1.x series.

If this was possible, we could provide an crypto library to compile and link against and only need to support this one

We do that already with this library. It provides a standard interface over OpenSSL and LibreSSL. The issue is linking, we still need to link against the underlying crypto library. Unless you are suggesting we create our own crypto library.

Another possibility is that we decide that this "abstract over libressl and openssl" is a fool's errand (I wouldn't argue against that) and split this library into libraries to support libressl and openssl and if someone wants to try to maintain a common interface, they can.

That makes for an easier maintenance burden, but certainly surfaces the problem of non-standard crypto libraries in Linux back to the user. Given however, that people could request additional crypto libraries be added to this package, well, that seems like a losing proposition. We aren't in the position to keep adding more and more libraries to this. When OpenSSL 3 comes out with its new API, that will already be kind of painful as is. And the problem will get worse in the future most likely as new version of the API for the divergent projects come out.

mfelsche commented 4 years ago

If this was possible, we could provide an crypto library to compile and link against and only need to support this one

What i meant was is providing e.g. openssl sources in the source tree of this library and compile them before actually compiling the pony sources, and automatically link them against this provided and compiled library.

I would never go and write my own crypto library. never!

SeanTAllen commented 4 years ago

Interesting idea, however on a glibc based distro, that might cause issues if other libraries that link against the shared library version are also used.

damon-kwok commented 4 years ago

Interesting idea, however on a glibc based distro, that might cause issues if other libraries that link against the shared library version are also used.

If we implement Rename Robot, it can be prefixed with "pony_" before all functions. Perhaps this problem can be avoided.

damon-kwok commented 4 years ago

We can start this work after https://github.com/ponylang/crypto/issues/36 is finished. At that time, the work of code modification will be easier.

SeanTAllen commented 4 years ago

I'm "deprecating" openssl 0.9.8 in the sense that we do not have any PR tests against it and as such might break it. Libressl uses the same API at the moment as 0.9.8 did.