Your message dated Sun, 19 Feb 2017 21:11:22 +0100
with message-id <[email protected]>
and subject line Re: Bug#855458: libssl1.0-dev: Development environment is
incomplete w/o openssl tool
has caused the Debian Bug report #855458,
regarding libssl1.0-dev: Development environment is incomplete w/o openssl tool
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
855458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855458
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libssl1.0-dev
Version: 1.0.2k-1
Severity: normal
Dear Maintainer,
When trying to build Pound against libssl1.0, the build fails because
Pound uses the openssl tool to generate C code containing DH parameters
(openssl dhparam -C ...).
The system-wide openssl on Debian testing is from OpenSSL 1.1, and
generates C code which is incompatible with OpenSSL 1.0. As a result it
is impossible to build some software (Pound) against OpenSSL 1.0 in
spite of having installed libssl1.0-dev.
The upstream developers have rejected the idea that the openssl dhparam
command should generate code compatible with multiple OpenSSL releases,
(https://github.com/openssl/openssl/issues/2675), so it seems if Debian
wants to provide a fully functional 1.0.x development environment on a
machine primarily using OpenSSL 1.1, the development package will need
to include its own version of the openssl tool (or pull one in via
depencencies).
An alternate fix would be to patch the OpenSSL 1.1 tool to generate
backwards compatible code (against the wishes of the upstream).
I hope this helps!
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libssl1.0-dev depends on:
ii libssl1.0.2 1.0.2k-1
libssl1.0-dev recommends no packages.
libssl1.0-dev suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On 2017-02-18 22:17:21 [-0000], Bjarni Runar Einarsson wrote:
> Hi Sebastian,
Hi Bjarni,
> My problem was just Pound - I'm just a user when it comes to
> these tools.
okay. #828511 is closed so I am closing this bug. Could you please
verify that pound 2.7-1.3 works as it supposed to work?
> I do not know how widespread this problem is or how common it is
> for projects to use openssl dhparam -C during their build process
> (as opposed to running it once and including the output in their
> a source distribution). I performed a few quick searches and
> found some examples - but not many.
I don't think pound should be doing this. Instead it should create the
dhaparm via 'openssl dhparam -out dhparams.pem 2048' in its postinst
script and read them at runtime via `PEM_read_DHparams()'. This would
ensure that not every Debian installation for an architecture has the
same keys.
> Cheers,
> - Bjarni
Sebastian
--- End Message ---
