I think this my first CPAN contribution. I added the Gemini wiki Phoebe.
Based on the recommendations of @wim_v12e and @e1e0 I tried to set it all up using Dist::Milla but in the end, the approach based on How to upload a script to CPAN by David Farrell (2016) just worked, without befuddling me with magic that I did not comprehend. OK, to be honest, I also forgot to include the tests in my first release which means that the tests results were “unknown” or “not available” – no wonder, right. But some of the things I didn’t understand about Dist::Milla: it reportedly couldn’t extract the license from the lib and there was no documentation of how it worked. Well, I finally discovered that it was using Software::LicenseUtils by reading the source, and even then knowing that I couldn’t get it to recognise the license unless I put “afford g” in the file. And when one of the tests failed with “milla test” I couldn’t reproduce it. Even if I entered the latest build directory itself and reran the tests, it worked. Too much magic under the hood.
How to upload a script to CPAN
#Perl #Phoebe
(Please contact me if you want to remove your comment.)
⁂
Hm. Something is still wrong. Version 1.1 is considered to be the latest one, and 1.1.1 and 1.1.2 are considered to be lower somehow? I’m going to schedule 1.1 for deletion and then we’ll see whether 1.1.2 ends up being the “current” version.
– 2020-11-14 12:20 UTC
---
Apparently I made a beginner’s mistake: “That’s obvious, but wrong; version specifiers aren’t numbers. To work correctly, you must quote them …”
– 2020-11-14 20:49 UTC
---
Here we go, 1.20 is released! 😅
– 2020-11-14 21:18 UTC
---
And the “CPAN Testers matrix” reports a ton of errors because I didn’t declare File::Slurper in Makefile.PL. Oh well, here goes 1.21!
– 2020-11-14 22:47 UTC
---
I wonder how one would determine the actual minimum versions of dependencies except through bitter experience...
– 2020-11-15 11:11 UTC
---
Sadly, on some platforms the SSL certificate generation is now the point where tests are failing:
Generating a 2048 bit EC private key writing new private key to 't/key.pem' ----- Could not finalize SSL connection with client handle (SSL accept attempt failed error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher) Cannot construct client socket: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure at ./t/test.pl line 114.
I guess the problem is that I need to specify that a certain openssl version must be around, but only when testing?
– 2020-11-15 12:04 UTC
---
OK, apparently “some platforms” means RHEL7. It uses OpenSSL 1.0 and thus has no access to TLSv1.3. I’m not sure this is the real culprit, though. IO::Socket::IO seems to share at least some of the ciphers! The OpenSSL wiki makes me think that perhaps there is something else at work. I’ve added more debugging info to release 1.22 and will try again.
Elliptic Curve Cryptography on the OpenSSL wiki
– 2020-11-15 19:28 UTC
---
Yeah, SSL is complicated. But it’s no good to make broad and sweeping statements about complexity. The problem of encryption and certificates on a high level is easy to understand; it’s when you get down to the complexities of the openssl command line, the protocol details (deprecation of some versions), the vague definitions of common name and alternative subjects…
All of this, from a distance, is unnecessary complexity. It’s uncalled for weight explained by history, legacy, and so on.
It’s not an inherent complexity that necessarily needs to crop up somewhere.
Or perhaps that just goes to show that cryptography is a field with an inherent dynamic that I don’t fully understand which necessaril leads to this bewieldering complexity.
And that’s not even talking about the various implementation details. People say that the Python part is tricky, I don’t know. But the framework I was using in my Perl code had a bug but only when handling client certificates which forced me to delve into the Perl framework, the OpenSSL bindings, the OpenSSL documentation, and by the end of it I was ready to burn it all down.
---
At last! The automatic testing done by Slaven Rezić is all green. Now I can rest. 🙂
Clicking through to the actual test results, however, it seems that as luck would have it, no RHEL7 was included...
– 2020-11-16 08:33 UTC
---
Ah, RHEL7 results are showing up... and the output produced confirms the verdict on the OpenSSL wiki:
If you use a key or certificate without without the OPENSSL_EC_NAMED_CURVE flag (i.e., one that looks like the image on the right), then the SSL connection will fail with the following symptoms: … Server … 140339533272744:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353:
For reference, what I’m seeing is:
1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
I think what I’ll do is I’ll either skip the tests if the OpenSSL version is too old, or not use elliptic curves.
– 2020-11-16 18:02 UTC
