SSL build and runtime requirements are misaligned

Question

SSL build and runtime requirements are misaligned

drf opened this issue 6 years ago · comments

Currently, the images install libssl1.0.2 as a runtimeDeps whereas libssl-dev is installed as a buildDeps. In fact, this means that Erlang is built with libssl1.1 (default in stretch, libssl-dev resolves to libssl1.1-dev https://packages.debian.org/stretch/libssl-dev).

This is quite misleading, and moreover the 1.0.2 dependency is totally useless.

Kyle A Anderson · Answer 1 · Tue Apr 24 2018 01:40:51 GMT+0800 (China Standard Time)

Our elixir apps will no longer run on the latest official elixir images, and I believe this issue is the cause.

2018-04-23 17:39:52 Unable to load crypto library. Failed with error:~n"~p, ~s"~nOpenSSL might not be installed on this system.~n
	load_failed
	"Failed to load NIF library /usr/local/lib/erlang/erts-9.3/../lib/crypto-4.2.1/priv/lib/crypto: 'libcrypto.so.1.1: cannot open shared object file: No such file or directory'"

Dario Freddi · Answer 2 · Tue Apr 24 2018 07:13:54 GMT+0800 (China Standard Time)

@kyleaa yes. either you wait for this to be fixed or you install libssl1.1 in your image. I'll send a PR tomorrow.

c0b · Answer 3 · Tue Apr 24 2018 07:41:12 GMT+0800 (China Standard Time)

Sorry with that, the issue may be coming from f3ce594 (committed on Mar 21) which upgraded base OS from debian:jessie to debian:stretch I believe at the moment of Mar 21 the libssl in debian:stretch was still libssl1.0.2 as latest, on that date the the reproducing steps in #122 (comment) was still able to run, and then on Mar 29 debian:stretch updated to libssl1.1 ; Due to debian packaging limitation, the libssl1.1 and libssl1.0.2 are two different package names not with their packaging version yet, and there's no such package name as libssl to point to latest version; so I am not sure if there's better to prevent it happen again in future other than monitoring upstream libssl changes, or rely on all you guys filing issues here

see more in Debian ChangeLog

$ docker run -it --rm -h debian-stretch.local debian:stretch
root@debian-stretch:/# 
root@debian-stretch:/# 
root@debian-stretch:/# apt update
Ign:1 http://deb.debian.org/debian stretch InRelease
Get:2 http://security.debian.org stretch/updates InRelease [94.3 kB]
Get:3 http://deb.debian.org/debian stretch-updates InRelease [91.0 kB]
Get:4 http://deb.debian.org/debian stretch Release [118 kB]         
Get:5 http://deb.debian.org/debian stretch Release.gpg [2434 B]
Get:6 http://security.debian.org stretch/updates/main amd64 Packages [468 kB]
Get:7 http://deb.debian.org/debian stretch-updates/main amd64 Packages [12.1 kB]
Get:8 http://deb.debian.org/debian stretch/main amd64 Packages [9530 kB]
Fetched 10.3 MB in 2s (4706 kB/s)   
Reading package lists... Done
Building dependency tree       
Reading state information... Done
4 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@debian-stretch:/# apt search libssl
Sorting... Done
Full Text Search... Done
libssl-dev/stable 1.1.0f-3+deb9u2 amd64
  Secure Sockets Layer toolkit - development files

libssl-doc/stable 1.1.0f-3+deb9u2 all
  Secure Sockets Layer toolkit - development documentation

libssl-ocaml/stable 0.5.2-2 amd64
  OCaml bindings for OpenSSL (runtime)

libssl-ocaml-dev/stable 0.5.2-2 amd64
  OCaml bindings for OpenSSL

libssl1.0-dev/stable 1.0.2l-2+deb9u3 amd64
  Secure Sockets Layer toolkit - development files

libssl1.0.2/stable 1.0.2l-2+deb9u3 amd64
  Secure Sockets Layer toolkit - shared libraries

libssl1.1/stable 1.1.0f-3+deb9u2 amd64
  Secure Sockets Layer toolkit - shared libraries

root@debian-stretch:/# apt search libssl-dev
Sorting... Done
Full Text Search... Done
libssl-dev/stable 1.1.0f-3+deb9u2 amd64
  Secure Sockets Layer toolkit - development files

Dario Freddi · Answer 4 · Tue Apr 24 2018 22:07:38 GMT+0800 (China Standard Time)

@c0b a clever approach could be matching what golang does (https://hub.docker.com/_/golang/), where they tag Debian's version together with golang's release. I think this is a good solution in the mid term.

In the meanwhile, just changing libssl1.0.2 to libssl1.1 will do, especially given Debian's stable won't change for a while

c0b · Answer 5 · Tue Apr 24 2018 23:34:19 GMT+0800 (China Standard Time)

Golang's image difference is their latest is aliased to version tag 1.10.1 and 1.10.1-stretch or 1.10.1-windows... depends on linux or windows it uses different image; so that special alias tag -stretch makes sense
For this Erlang image, I don't think will support windows in the near or mid-term future;
The other difference is Golang has its own https://golang.org/pkg/crypto/tls/ implementation, not linked with libssl at all;

yes; the Debian stable is really stable and conservative on upgrading software, so libssl1.1 will be probably in a long time (some years), this kind of fix won't be too often.

c0b · Answer 6 · Fri Apr 27 2018 03:24:23 GMT+0800 (China Standard Time)

it should be fixed after yesterday docker hub rebuild erlang slim images

$ docker run -h erlang-20-slim.local -it --rm erlang:20-slim erl -s crypto -s inets -s ssl
Erlang/OTP 20 [erts-9.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V9.3  (abort with ^G)
1> httpc:request("https://nghttp2.org/httpbin/get").
{ok,{{"HTTP/1.1",200,"OK"},
     [{"connection","close"},
      {"date","Thu, 26 Apr 2018 19:17:39 GMT"},
      {"via","1.1 nghttpx"},
      {"server","nghttpx"},
      {"content-length","201"},
      {"content-type","application/json"},
      {"access-control-allow-origin","*"},
      {"access-control-allow-credentials","true"},
      {"x-backend-header-rtt","0.002335"},
      {"strict-transport-security","max-age=31536000"},
      {"x-frame-options","SAMEORIGIN"},
      {"x-xss-protection","1; mode=block"},
      {"x-content-type-options","nosniff"}],
     "{\n  \"args\": {},\n  \"headers\": {\n    \"Content-Length\": \"0\",\n    \"Host\": \"nghttp2.org\",\n    \"Te\": \"\",\n    \"Via\": \"1.1 nghttpx\"\n  },\n  \"origin\": \"xx.xx.xx.xx\",\n  \"url\": \"https://nghttp2.org/httpbin/get\"\n}\n"}}
2> 
User switch command
 --> q

Or with Elixir:

$ docker run -it --rm elixir:slim iex --app crypto --app inets --app ssl
Erlang/OTP 20 [erts-9.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false]

Interactive Elixir (1.6.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> :httpc.request 'https://nghttp2.org/httpbin/get'
{:ok,
 {{'HTTP/1.1', 200, 'OK'},
  [
    {'connection', 'close'},
    {'date', 'Thu, 26 Apr 2018 19:18:55 GMT'},
    {'via', '1.1 nghttpx'},
    {'server', 'nghttpx'},
    {'content-length', '201'},
    {'content-type', 'application/json'},
    {'access-control-allow-origin', '*'},
    {'access-control-allow-credentials', 'true'},
    {'x-backend-header-rtt', '0.002376'},
    {'strict-transport-security', 'max-age=31536000'},
    {'x-frame-options', 'SAMEORIGIN'},
    {'x-xss-protection', '1; mode=block'},
    {'x-content-type-options', 'nosniff'}
  ],
  '{\n  "args": {},\n  "headers": {\n    "Content-Length": "0",\n    "Host": "nghttp2.org",\n    "Te": "",\n    "Via": "1.1 nghttpx"\n  },\n  "origin": "xx.xx.xx.xx",\n  "url": "https://nghttp2.org/httpbin/get"\n}\n'}}
iex(2)> 
User switch command
 --> q