Misc #13771: Digest, Ruby OpenSSL, OpenSSL v1.1.0

• Status: Closed
• Assignee: hsbt (Hiroshi SHIBATA)

[MSP-Greg (Greg L)]

A thanks to everyone involved in 'gemifying' ruby.

As I've mentioned before, I'm a windows user, and not a c type.

Where I noticed potential issues is that std-lib openssl is a gem, but std-lib digest is not. Hence, thru system updates, the two std-libs could be using different versions of OpenSSL...

Would 'gemifying' digest help with this?

Note - in 2.4 stable, both libraries can be built with 1.1.0. 2.3 stable cannot, but will install a current openssl gem, and the system package library (MSYS2/MinGW) could have been updated to 1.1.0. I ask this mostly because 2.3 might have an extended life...

[shevegen (Robert A. Heiler)]

I can not answer your questions, the ruby core team will have to decide on the content + gemifying.

As for one other part of your comment though:

A thanks to everyone involved in 'gemifying' ruby.

I believe the majority of the work in regards to gemifying stdlib of ruby has been done
by hsbt (Hiroshi Shibata https://github.com/hsbt), after a much older discussion and the
go-ahead by matz in favour of it. The old discussion, or at the least the major discussion,
can be seen here at https://bugs.ruby-lang.org/issues/5481 started by nahi and hsbt is
listed as the Assignee. (I assume that the ruby core team has some way to distribute
work among its members, you can often see some core team members focusing on individual
parts more than more general parts, except for nobu perhaps who seems to work at just
about every part of ruby :))

Anyway, if you look at the link there, the:

https://bugs.ruby-lang.org/issues/5481

My suggestion is to also link in your proposal here (or perhaps someone else that). Even
if it may not be accepted (and I do not know whether it will be accept or not), there may
be a reason given as to why not. On the other hand, it may also be accepted, and this
may help formalizing the process.

Usually an initial .gemspec file has to be created, describing the content of the sub-gem
itsel ("sub-gem" in this context means a part of the ruby distribution itsel, an internal
gem that gets distributed and also built when you compile ruby from source, I think - at
the least I think that this was related to some minor bug about a wrongful path assumption
in some of the recent bug entries, which was a duplicate of someone else already reporting
that days before).

You can have a look at the extensions of ruby at:

https://github.com/ruby/ruby/tree/trunk/ext

Openssl has a .gemspec file already:

https://github.com/ruby/ruby/blob/trunk/ext/openssl/openssl.gemspec

Digest does not yet have one:

https://github.com/ruby/ruby/tree/trunk/ext/digest

It looks a bit more complicated than openssl because it has four
subdirectories (md5, rmd160, sha1, sha2), so I would not know if
these are then all part of digest too and the digest gem? But I
think that given how central openssl is to many functionality of
ruby itself (gem for example but also now that more and more
websites are transitioning to https), I am quite confident that
the ruby core team will have a look at issues related to the
larger ecosystem, including digest.

Note - in 2.4 stable, both libraries can be built with 1.1.0.
2.3 stable cannot, but will install a current openssl gem,

That reminds me of some other suggestion I have made, to automatically
specify somewhere which versions are officially supported. I
would not know how to easily obtain that information presently,
that is, which ruby versions can support which particular other,
external version. My suggestion was to also specify this into
.gemspec but I guess that would first require a change in gem
itself to also allow such "meta" information.

I ask this mostly because 2.3 might have an extended life...

Completely understandable. By the way, since you are on winows,
and although this may not be of help, but since Win10, and the
"Bash subsystem on Windows / *nix subsystem", you can use ubuntu
or opensuse and thus also ruby. I tested it and it works very
well, in fact - it works even better than the ruby one click
installer. :)

Perhaps you may use an older version of windows so that may not be
applicable to your case, but if you have the time, I recommend to
you to give it a try. All my ruby scripts work very fine, the
hdd on win10 is by default available under /mnt/c and commandline
stuff works perfectly well. Even xorg may work if you use xming or
some simulation to start xorg apps and I suspect that rails may also
work perhaps... or in the future. I have not tried the latter part
yet, was mostly just experimenting with win10. But it is pretty nice
to use ruby on win10 in a semi-real linux environment (it's not a full
system of course... no linux kernel. But bash works and compiling
stuff from source also works, as does apt-get, rpm etc...)

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to hsbt (Hiroshi SHIBATA)

[hsbt (Hiroshi SHIBATA)]

• Related to Feature #5481: Gemifying Ruby standard library added

[nobu (Nobuyoshi Nakada)]

MSP-Greg (Greg L) wrote:

Where I noticed potential issues is that std-lib openssl is a gem, but std-lib digest is not. Hence, thru system updates, the two std-libs could be using different versions of OpenSSL...

Would 'gemifying' digest help with this?

I think that it can happen even if both are installed as gems.

[MSP-Greg (Greg L)]

nobu (Nobuyoshi Nakada) wrote:

I think that it can happen even if both are installed as gems.

True. But if digest is a gem, one can uninstall then (re)install to change to the newer OpenSSL version. As 'base' code, that can't easily be changed.

How to convey the issues to people unfamiliar with OpenSSL is also a concern.

I haven't looked to see how similar OpenSSL::Digest is to Digest, nor do I know if one could be aliased to the other...

Again, thanks for your work.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Assigned to Closed

Applied in changeset trunk|r59607.

---

Added gemspec of digest library.

standalone repository is https://github.com/ruby/digest
[Misc #13771][ruby-core:82179]