Warning: run-time library vs. compile-time heade

diederick76 · 2018-09-18 06:55:00

Hi,

Since last sysupdate, I get this message every few minutes in my logs:

postfix/smtpd[38495]: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.1.1 may not be compatible with OpenSSL 1.1.0

Was postfix compiles against the wrong version of OpenSSL and do I have to wait until this is solved by its maintainer or is there something I can do?

Thanks for any help!

brebs · 2018-09-18 08:07:34

I suggest you report it on bugzilla, to get postfix recompiled.

diederick76 · 2018-09-18 09:10:14

Thanks. I'll do that when I get home.

Allan · 2018-09-18 09:31:12

It is already there a couple of times. No need for another report.

brebs · 2018-09-18 09:44:52

I see bug report, closed as "not a bug".

I would be confused as to why the bug report was closed

diederick76 · 2018-09-18 10:07:07

I have made a request to re-open it.

diederick76 · 2018-09-18 13:38:45

And it was closed again:

Reason for denial:
Warnings are not errors due to the fact that they are warnings. Ask upstream not to add silly warnings, we're not recompiling @world for every package bump of any sort.

I personally don't feel that bugs are defined as something that is logged as error (often bugs aren't logged at all), and I don't think warning against using a different OpenSSL than what it is compiled against is silly (Or is it? Perhaps I'm wrong here?)

Anyway I guess the fact that these warnings are basically flooding my logs (once every connection) is not enough reason for the maintainer to recompile the package and make the update internally consistent

brebs · 2018-09-18 13:59:36

Well, both sides have a point

Postfix shouldn't be spamming its logs with that (seems ancient).

I suggest creating a patch, to to disable the headers check and logspam.

Edit: The patch already exists, see Ubuntu patches: 10_openssl_version_check.diff

Last edited by brebs (2018-09-18 14:01:45)

diederick76 · 2018-09-18 14:20:17

brebs wrote:

Well, both sides have a point
Postfix shouldn't be spamming its logs with that (seems ancient).

Agreed

brebs · 2018-09-18 14:40:48

I'd suggest: Check that the patch works, then request to re-open that bug (again), including the patch.

I am surprised that the Arch bug was closed/rejected so quickly.

eschwartz · 2018-09-18 15:02:46

WE WILL NOT ADD DOWNSTREAM PATCHES TO DISABLE THIS CHECK.

As I already said: "Ask upstream not to add silly warnings, we're not recompiling @world for every package bump of any sort."

eschwartz · 2018-09-18 15:14:35

diederick76 wrote:

I personally don't feel that bugs are defined as something that is logged as error (often bugs aren't logged at all), and I don't think warning against using a different OpenSSL than what it is compiled against is silly (Or is it? Perhaps I'm wrong here?)

If something is incorrectly logged as a warning when it is an error, then that is a bug.

If something is incorrectly not logged at all when it is an error, then that is a bug.

If something is logged as a warning, then the fact that it is logged, is not in and of itself any sort of proof that there is a bug. I dispute your notion that *this* warning is real, and therefore I do not see a valid reason to recompile anything.

Anyway I guess the fact that these warnings are basically flooding my logs (once every connection) is not enough reason for the maintainer to recompile the package and make the update internally consistent

With this logic, we will have to rebuild our entire distribution from scratch every time openssl is updated. That's thousands of packages.
EDIT: "with this logic" ==> "the natural end result of this logic if both we and upstream developers of various software begin to consider this a reasonable approach"

If the warnings are flooding your logs and its messy, complain to upstream. The *minimum* requirement for us applying a patch to disable this version check, is for that patch to be accepted upstream.

Last edited by eschwartz (2018-09-18 15:28:27)

Allan · 2018-09-18 15:16:43

Eschwartz wrote:

With this logic, we will have to rebuild our entire distribution from scratch every time openssl is updated. That's thousands of packages.

Or the one package that is giving excess warnings...

diederick76 · 2018-09-19 06:24:00

Eschwartz wrote:

With this logic, we will have to rebuild our entire distribution from scratch every time openssl is updated. That's thousands of packages.
EDIT: "with this logic" ==> "the natural end result of this logic if both we and upstream developers of various software begin to consider this a reasonable approach"

Fair enough.

Trilby · 2018-09-19 13:48:07

This isn't the justice system, one ruling does not set a precedent that must forever be followed. So while this really should be addressed upstream (the warning seems prudent, spamming the warning is ridiculous), it can be addressed here by recompiling one package (not all of them) to silence the silliness of upstream until they get their heads on strait(er).

And while it might be nice if the maintainer did that and put it in the repos, anyone who is unhappy with the log spam can just as easily use the ABS to rebuild it themselves and solve the problem with much less time and effort than has been put into this thread.

Last edited by Trilby (2018-09-19 13:49:17)

seth · 2018-09-19 14:45:49

While most of the time nothing happens, openssl doesn't guarantee 100% ABI compatibility even w/ "micro" releases, see https://abi-laboratory.pro/?view=timeline&l=openssl
So, strictly spoken, the postfix check is correct (though it certainly should not spam the log), the debian patch (of course) bogus and yes, you got to recompile the system w/ every minor openssl bump :-P

src/tls/tls_misc.c

…
void    tls_check_version(void)
{
    static bool previously_logged = false;
    if (previously_logged)
        return; // don't spam
    previously_logged = true;
…

brebs · 2018-09-19 14:56:50

Eschwartz wrote:

The *minimum* requirement for us applying a patch to disable this version check, is for that patch to be accepted upstream.

Where does this requirement come from?

For example, taking a patch at random, I don't see xserver-autobind-hotplug.patch in xorg-server git.

phw · 2018-09-19 21:34:18

brebs wrote:

Eschwartz wrote:
The *minimum* requirement for us applying a patch to disable this version check, is for that patch to be accepted upstream.
Where does this requirement come from?

AFAIK there is no such requirement, only the general consensus that the practice of applying non-upstream patches should be limited to a minimum. But I let the package maintainers decide if this case warrants an exception

Last edited by phw (2018-09-19 21:36:23)

Arch Linux

#1 2018-09-18 06:55:00

Warning: run-time library vs. compile-time heade

#2 2018-09-18 08:07:34

Re: Warning: run-time library vs. compile-time heade

#3 2018-09-18 09:10:14

Re: Warning: run-time library vs. compile-time heade

#4 2018-09-18 09:31:12

Re: Warning: run-time library vs. compile-time heade

#5 2018-09-18 09:44:52

Re: Warning: run-time library vs. compile-time heade

#6 2018-09-18 10:07:07

Re: Warning: run-time library vs. compile-time heade

#7 2018-09-18 13:38:45

Re: Warning: run-time library vs. compile-time heade

#8 2018-09-18 13:59:36

Re: Warning: run-time library vs. compile-time heade

#9 2018-09-18 14:20:17

Re: Warning: run-time library vs. compile-time heade

#10 2018-09-18 14:40:48

Re: Warning: run-time library vs. compile-time heade

#11 2018-09-18 15:02:46

Re: Warning: run-time library vs. compile-time heade

#12 2018-09-18 15:14:35

Re: Warning: run-time library vs. compile-time heade

#13 2018-09-18 15:16:43

Re: Warning: run-time library vs. compile-time heade

#14 2018-09-19 06:24:00

Re: Warning: run-time library vs. compile-time heade

#15 2018-09-19 13:48:07

Re: Warning: run-time library vs. compile-time heade

#16 2018-09-19 14:45:49

Re: Warning: run-time library vs. compile-time heade

#17 2018-09-19 14:56:50

Re: Warning: run-time library vs. compile-time heade

#18 2018-09-19 21:34:18

Re: Warning: run-time library vs. compile-time heade

Board footer