openssl
openssl copied to clipboard
ruby
Safe to link against gem extension?
Is there any way for one C extension to safely link against another?
Looking at the external symbols in openssl.so, I see the following:
$ nm tmp/x86_64-linux/openssl/3.0.2/openssl.so |
ruby -nae 'g=ARGF.grep(/ T /).map{_1.split[2]}.group_by{_1[/(\A(o|I)|_to)/]}.values.sort_by{-_1.size};
g[0].size.times{|i|puts ("%28s"*4)%g.map{_1[i]}}'
ossl_asn1_get_asn1type Init_openssl DupPKeyPtr asn1integer_to_num
ossl_bin2hex Init_ossl_asn1 DupX509CertPtr asn1str_to_str
ossl_bn_ctx_free Init_ossl_bn DupX509RevokedPtr asn1time_to_time
ossl_bn_ctx_get Init_ossl_cipher GetConfig num_to_asn1integer
ossl_bn_new Init_ossl_config GetPKeyPtr
ossl_bn_value_ptr Init_ossl_dh GetPrivPKeyPtr
ossl_buf2str Init_ossl_digest GetX509AttrPtr
ossl_cipher_new Init_ossl_dsa GetX509CertPtr
ossl_clear_error Init_ossl_ec GetX509CRLPtr
ossl_digest_new Init_ossl_engine GetX509ExtPtr
ossl_digest_update Init_ossl_hmac GetX509NamePtr
ossl_evp_get_cipherbyname Init_ossl_kdf GetX509ReqPtr
ossl_evp_get_digestbyname Init_ossl_ns_spki GetX509StorePtr
ossl_get_errors Init_ossl_ocsp
ossl_make_error Init_ossl_pkcs12
ossl_membio2str Init_ossl_pkcs7
ossl_obj2bio Init_ossl_pkey
ossl_pem_passwd_cb Init_ossl_rand
ossl_pem_passwd_value Init_ossl_rsa
ossl_pkey_check_public_key Init_ossl_ssl
ossl_pkey_export_spki Init_ossl_ssl_session
ossl_pkey_export_traditional Init_ossl_ts
ossl_pkey_new Init_ossl_x509
ossl_pkey_read_generic Init_ossl_x509attr
ossl_protect_x509_ary2sk Init_ossl_x509cert
ossl_raise Init_ossl_x509crl
ossl_str_new Init_ossl_x509ext
ossl_time_split Init_ossl_x509name
ossl_to_der Init_ossl_x509req
ossl_to_der_if_possible Init_ossl_x509revoked
ossl_verify_cb_call Init_ossl_x509store
ossl_x509_ary2sk
ossl_x509_ary2sk0
ossl_x509attr_new
ossl_x509crl_new
ossl_x509crl_sk2ary
ossl_x509ext_new
ossl_x509name_new
ossl_x509name_sk2ary
ossl_x509_new
ossl_x509revoked_new
ossl_x509_sk2ary
ossl_x509_time_adjust
If there's a safe way to do so, I'd like to use a couple of those... and maybe submit a PR with a few more.
I know of at least two gems with their own extensions linking against openssl (puma and eventmachine). It seems to me they would be able to use this gem's implementation with only a few additions to the API, if they could link against the C extension API. In particular, if there were a simple wrapper around the BIO struct, BIO_* functions, and SSL_set_bio, then those gems could be rewritten to use that.
For ease of maintenance and maximum eyeballs on such critical security infrastructure, I'd rather not have a new implementation in every gem with a C extension that needs access to openssl. (n.b. there has been at least three CVEs for gems which depend on eventmachine, all of which probably would've been avoided if eventmachine could've simply used stdlib's openssl)
I don't think there is a good way currently.
RubyGems doesn't support the situation of dependencies between C extensions. There is no standard directory where a gem can install the header files for its C API.
The digest library, which provides some C API for implementing additional digest algorithms, faced this problem during the recent work to gemify the library (https://github.com/ruby/digest/issues/14 and [Feature #17760]). The current workaround is just to skip installing the header files; it's not resolved yet.
@rhenium thanks a lot for the response! Because this is already a scenario that needs to be resolved with the digest gem, I'm hopeful there will be a usable solution in some combination of rubygems and bundler and mkmf soon!
Assuming this issue is resolved and we have a supportable approach for C extension dependencies, would you even want everything currently listed in the ext/ossl_*.h files to be part of this gem's C API? Would it make sense to expose a subset via a public header file?
While I'm waiting for all of that to be resolved, I might try and move forward just to test out the approach. I'm hoping it's not too tricky to create a custom mkmf script that matches the openssl gem directory that would be loaded (including bundler constraints) with a find_header. However although openssl header files are included when installed as a gem, it looks like they are not when it's only installed as a default gem.
╭╼ <nick@anarres> ~ [Thu Nov 18]-(11:39:13) 3.0.2
╰──╼ $ find ~/.rbenv/versions/3.0.2 -name 'ossl_*.h'
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_pkcs12.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_cipher.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_hmac.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_ts.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_ocsp.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_digest.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_asn1.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_bn.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_ns_spki.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_bio.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_engine.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_config.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_pkcs7.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_pkey.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_ssl.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_kdf.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_rand.h
/home/nick/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/openssl-2.2.1/ext/openssl/ossl_x509.h
╭╼ <nick@anarres> ~ [Thu Nov 18]-(11:39:19) 3.0.2
╰──╼ $ find ~/.rbenv/versions/3.0.2 -name 'ruby.h'
/home/nick/.rbenv/versions/3.0.2/include/ruby-3.0.0/ruby.h
/home/nick/.rbenv/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h
/home/nick/.rbenv/versions/3.0.2/include/ruby-3.0.0/ruby/internal/intern/ruby.h
Would it be possible to update the default gem import so that openssl headers are included in both circumstances? I think I could add a dependency on a version of openssl that is newer than any default version in any existing release, but then when new versions of ruby are released, they could come with ossl header files included?
I'll also copy in the two bits of Feature #17760 I found most relevant:
From knu (Akinori MUSHA):
It is (technically) possible for RubyGems to specify where to install header files by passing HDRDIR=destination to make install for example, and to expose the installed header files of activated gems to a newly built gem by passing CPPFLAGS to extconf.rb that lists the header directories.
From byroot (Jean Boussier):
Maybe for digest it would work as realistically it won't change much in the future. But if Rubygems introduce this header file management, other gems will start using it, and I can foresee tons of problems.
While I acknowledge that ABI compatibility issues could potentially be huge, IMO the security issues from gems re-implementing basic openssl functionality are also huge. What are your thoughts?
See also https://github.com/ruby/ruby/commit/5cdf99f64e344b8e4638824d55f5caf33be682ca ?
Haha, I literally just now hit that exact digest bug for the first time as I was upgrading one of my apps from using a local net/smtp monkeypatch to use the net-smtp gem. 😉
Landing here, as I'd also be interested in accessing ruby-openssl's C API, particularly the openssl digest subsystem. I agree with OP that using the convenience of the ruby-openssl C API to implement common functionallity in C in the critical could be useful.
What's the particular blocker in rubygems? Lack of specified "C extension headers path" in Gem::Specification?
