Closed no6v closed 3 months ago
I found that each failing check is caused by the following change: https://github.com/ruby/openssl/commit/6c09fd3ef5422d798f6674094b9f222c3abae660
The simple way to pass a spec is to not specify an exception class.
By the way, is there any plan to drop supporing old versions of ruby? As you may know, even 2.7 is in security maintainance phase, 2.6 and previous versions have reached an EOL.
By the way, is there any plan to drop supporing old versions of ruby? As you may know, even 2.7 is in security maintainance phase, 2.6 and previous versions have reached an EOL.
Yes, plan is to drop support for some older versions of ruby. However there are Long Term Support OSes that have old versions of ruby in them (Ubuntu LTS, Red Hat Enterprise Linux). For examples Ubuntu 18 LTS - Bionic Beaver has ruby 2.5.1). And Ubuntu 14 Trusty Tahr doesn't reach EOL until April 2024.
Need to work out which to support in the next release.
Just checked and Redhat Enterprise Linux 7 comes with Ruby version 2.0.0.648-39.el7_9
.
Amazingly RHEL7 has maintenance support until 30 June 2024 and Extended
Lifecycle Support until 30 June 2026.
Thanks for your informations! I omitted the exception class on the spec.
Would it be possible to add an example key into /spec/fixtures, so that it is possible to test that this works?
I'm sorry, I'm late. I prepared the EC
keys with and without password encrypted, and added the specs for those EC
keys (almostly copied from the specs for RSA
keys :).
Thank you very much for updating this PR to include some tests. Sorry to not merge it for so long.
It is enough to use
OpenSSL::PKey.read
to handle private keys. In the case of key or passphrase is invalid, the exception class and the message are changed. Is this acceptable? Anyway, we should not useFile.open
without#close
(or block) too read a key.