ntp: add patch to support for libressl
PATCH 1/1 ntp: add patch to support for libressl
NTP currently fails to compile against LibreSSL because of checks used to determine the SSL library version.
Upstream-Status: Pending
http://bugs.ntp.org/show_bug.cgi?id=3401#c3
--- package/ntp/0004-libressl-support.patch | 107 ++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 package/ntp/0004-libressl-support.patch
package/ntp/0004-libressl-support.patch new file +107 -0
@@ -0,0 +1,107 @@ +From a3bd714d3028241c7546ded6ae6b93887a17a7fa Mon Sep 17 00:00:00 2001 +From: Adam Duskett <[email protected]> +Date: Wed, 12 Jul 2017 09:14:38 -0400 +Subject: [PATCH] add libressl support + +Fix some preprocessor macros to add libressl support. + +Upstream-Status: Pending +http://bugs.ntp.org/show_bug.cgi?id=3401#c3 + +Signed-off-by: Adam Duskett <[email protected]> +--- + include/libssl_compat.h | 4 +++- + libntp/libssl_compat.c | 2 +- + libntp/ssl_init.c | 2 +- + ports/winnt/include/msvc_ssl_autolib.h | 2 +- + sntp/libevent/test/regress_ssl.c | 4 ++-- + 5 files changed, 8 insertions(+), 6 deletions(-) + +diff --git a/include/libssl_compat.h b/include/libssl_compat.h +index 2a3697c..eede47b 100644 +--- a/include/libssl_compat.h ++++ b/include/libssl_compat.h +@@ -25,8 +25,10 @@ + #include "openssl/rsa.h" + + #ifndef OPENSSL_VERSION_NUMBER ++#ifndef LIBRESSL_VERSION_NUMBER + #define OPENSSL_VERSION_NUMBER SSLEAY_VERSION_NUMBER + #endif ++#endif + + #ifndef OPENSSL_VERSION_TEXT + #define OPENSSL_VERSION_TEXT SSLEAY_VERSION_TEXT +@@ -37,7 +39,7 @@ + #endif + + /* ----------------------------------------------------------------- */ +-#if OPENSSL_VERSION_NUMBER < 0x10100000L ++#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) + /* ----------------------------------------------------------------- */ + + # include <openssl/objects.h> +diff --git a/libntp/libssl_compat.c b/libntp/libssl_compat.c +index afe4d07..dae7017 100644 +--- a/libntp/libssl_compat.c ++++ b/libntp/libssl_compat.c +@@ -26,7 +26,7 @@ + /* ----------------------------------------------------------------- */ + + /* ----------------------------------------------------------------- */ +-#if defined(OPENSSL) && OPENSSL_VERSION_NUMBER < 0x10100000L ++#if defined(OPENSSL) && OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) + /* ----------------------------------------------------------------- */ + + #include "libssl_compat.h" +diff --git a/libntp/ssl_init.c b/libntp/ssl_init.c +index bebf6e1..0a27050 100644 +--- a/libntp/ssl_init.c ++++ b/libntp/ssl_init.c +@@ -21,7 +21,7 @@ + + int ssl_init_done; + +-#if OPENSSL_VERSION_NUMBER < 0x10100000L ++#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) + + static void + atexit_ssl_cleanup(void) +diff --git a/ports/winnt/include/msvc_ssl_autolib.h b/ports/winnt/include/msvc_ssl_autolib.h +index 688b5e2..393e1c9 100644 +--- a/ports/winnt/include/msvc_ssl_autolib.h ++++ b/ports/winnt/include/msvc_ssl_autolib.h +@@ -85,7 +85,7 @@ + * request in the object file, depending on the SSL version and the + * build variant. + */ +-# if OPENSSL_VERSION_NUMBER >= 0x10100000L ++# if OPENSSL_VERSION_NUMBER >= 0x10100000L && ! defined(LIBRESSL_VERSION_NUMBER) + # pragma comment(lib, "libcrypto" LTAG_SIZE LTAG_RTLIB LTAG_DEBUG ".lib") + # else + # pragma comment(lib, "libeay32" LTAG_RTLIB LTAG_DEBUG ".lib") +diff --git a/sntp/libevent/test/regress_ssl.c b/sntp/libevent/test/regress_ssl.c +index 226a2a3..dc761dc 100644 +--- a/sntp/libevent/test/regress_ssl.c ++++ b/sntp/libevent/test/regress_ssl.c +@@ -61,7 +61,7 @@ + + #include <string.h> + +-#if OPENSSL_VERSION_NUMBER < 0x10100000L ++#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) || defined(LIBRESSL_VERSION_NUMBER) + #define OpenSSL_version_num SSLeay + #endif /* OPENSSL_VERSION_NUMBER */ + +@@ -130,7 +130,7 @@ getcert(void) + X509_set_subject_name(x509, name); + X509_set_issuer_name(x509, name); + +-#if OPENSSL_VERSION_NUMBER < 0x10100000L ++#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) + X509_time_adj(X509_get_notBefore(x509), 0, &now); + now += 3600; + X509_time_adj(X509_get_notAfter(x509), 0, &now); +-- +2.13.0 +
Signature · 1 line
2.13.6
PATCH 1/1 ntp: add patch to support for libressl
Hello,
Quoted 7 lines · Adam Duskett
NTP currently fails to compile against LibreSSL because of checks used to determine the SSL library version.
Upstream-Status: Pending
http://bugs.ntp.org/show_bug.cgi?id=3401#c3Signed-off-by Adam Duskett <[email protected]>
Arnout, Peter, Yann, I think we discussed this topic during the Buildroot meeting, and concluded we didn't want patches in Buildroot to enable LibreSSL compatibility with a package. Do we stand on this position, and reject Adam's contribution on ntp?
Quoted 2 lines
+ #ifndef
OPENSSL_VERSION_NUMBER
++#ifndefLIBRESSL_VERSION_NUMBER
In addition, this continue to use the LIBRESSL_VERSION_NUMBER approach, which will fail when libressl gains support for new APIs.
Thanks in advance for giving your feedback on this patch. If nobody complains, I'll merge :-)
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 ntp: add patch to support for libressl
Quoted 9 lines · Thomas Petazzoni
Hello,
Quoted 6 lines · Adam Duskett
NTP currently fails to compile against LibreSSL because of checks used to determine the SSL library version.
Upstream-Status: Pending
http://bugs.ntp.org/show_bug.cgi?id=3401#c3
Quoted 6 lines
Quoted 1 line
Signed-off-by Adam Duskett <[email protected]>Arnout, Peter, Yann, I think we discussed this topic during the Buildroot meeting, and concluded we didn't want patches in Buildroot to enable LibreSSL compatibility with a package. Do we stand on this position, and reject Adam's contribution on ntp?
I don't think the conclusion was that we would reject patches to enable
LibreSSL compatibility outright, only:
Quoted 6 lines
Quoted 3 lines
+ #ifndef
OPENSSL_VERSION_NUMBER
++#ifndefLIBRESSL_VERSION_NUMBERIn addition, this continue to use the
LIBRESSL_VERSION_NUMBERapproach, which will fail when libressl gains support for new APIs.
we would reject this approach because I believe it is not upstreamable.
I think upstreamable patches are acceptable. And maybe even theLIBRESSL_VERSION_NUMBER approach is OK - but then I first want to see a reliable upstream accept it.
Regards,
Arnout
Quoted 8 lines
Thanks in advance for giving your feedback on this patch. If nobody complains, I'll merge :-)
Thanks!
Thomas
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 ntp: add patch to support for libressl
Hello,
Quoted 12 lines · Arnout Vandecappelle
Quoted 4 lines
Arnout, Peter, Yann, I think we discussed this topic during the Buildroot meeting, and concluded we didn't want patches in Buildroot to enable LibreSSL compatibility with a package. Do we stand on this position, and reject Adam's contribution on ntp?
I don't think the conclusion was that we would reject patches to enable
LibreSSL compatibility outright, only:Quoted 4 lines
Quoted 3 lines
+ #ifndef
OPENSSL_VERSION_NUMBER
++#ifndefLIBRESSL_VERSION_NUMBER
Quoted 8 lines
Quoted 2 lines
In addition, this continue to use the
LIBRESSL_VERSION_NUMBERapproach, which will fail when libressl gains support for new APIs.we would reject this approach because I believe it is not upstreamable.
I think upstreamable patches are acceptable. And maybe even the
LIBRESSL_VERSION_NUMBERapproach is OK - but then I first want to see a reliable upstream accept it.
The issue here is that Adam has submitted the patch upstream a while ago (see bugs.ntp.org/show_bug.cgi?id=3401#c3), and upstream has reacted.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 ntp: add patch to support for libressl
Quoted 21 lines · Thomas Petazzoni
Hello,
Quoted 17 lines · Arnout Vandecappelle
Quoted 4 lines
Arnout, Peter, Yann, I think we discussed this topic during the Buildroot meeting, and concluded we didn't want patches in Buildroot to enable LibreSSL compatibility with a package. Do we stand on this position, and reject Adam's contribution on ntp?
I don't think the conclusion was that we would reject patches to enable
LibreSSL compatibility outright, only:Quoted 6 lines
Quoted 3 lines
+ #ifndef
OPENSSL_VERSION_NUMBER
++#ifndefLIBRESSL_VERSION_NUMBERIn addition, this continue to use the
LIBRESSL_VERSION_NUMBERapproach, which will fail when libressl gains support for new APIs.we would reject this approach because I believe it is not upstreamable.
Quoted 7 lines
Quoted 3 lines
I think upstreamable patches are acceptable. And maybe even the
LIBRESSL_VERSION_NUMBERapproach is OK - but then I first want to see a reliable upstream accept it.The issue here is that Adam has submitted the patch upstream a while ago (see bugs.ntp.org/show_bug.cgi?id=3401#c3), and upstream has reacted.
Maybe I missed something, but I don't see the reaction?
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 ntp: add patch to support for libressl
Hello,
Quoted 26 lines · Arnout Vandecappelle
Quoted 25 lines · Thomas Petazzoni
Hello,
Quoted 20 lines · Arnout Vandecappelle
Quoted 4 lines
Arnout, Peter, Yann, I think we discussed this topic during the Buildroot meeting, and concluded we didn't want patches in Buildroot to enable LibreSSL compatibility with a package. Do we stand on this position, and reject Adam's contribution on ntp?
I don't think the conclusion was that we would reject patches to enable
LibreSSL compatibility outright, only:Quoted 6 lines
Quoted 3 lines
+ #ifndef
OPENSSL_VERSION_NUMBER
++#ifndefLIBRESSL_VERSION_NUMBERIn addition, this continue to use the
LIBRESSL_VERSION_NUMBERapproach, which will fail when libressl gains support for new APIs.we would reject this approach because I believe it is not upstreamable.
I think upstreamable patches are acceptable. And maybe even the
LIBRESSL_VERSION_NUMBERapproach is OK - but then I first want to see a reliable upstream accept it.
Quoted 5 lines
Quoted 3 lines
The issue here is that Adam has submitted the patch upstream a while ago (see bugs.ntp.org/show_bug.cgi?id=3401#c3), and upstream has reacted.
Maybe I missed something, but I don't see the reaction?
It was too late when I replied to you. I obviously wanted to say:
"upstream has *not* reacted". I.e, your request to "see a reliable upstream accept it" is hard to achieve, because even if Adam did the effort of submitting the patch upstream, there was no reaction, either positive or negative.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 ntp: add patch to support for libressl
In reply to Thomas PetazzoniThomas, All,
On 2017-11-23 22:51 +0100, Thomas Petazzoni spake thusly:
Quoted 7 lines · Adam Duskett
Quoted 6 lines
NTP currently fails to compile against LibreSSL because of checks used to determine the SSL library version.
Upstream-Status: Pending
http://bugs.ntp.org/show_bug.cgi?id=3401#c3
Quoted 6 lines
Quoted 1 line
Signed-off-by Adam Duskett <[email protected]>Arnout, Peter, Yann, I think we discussed this topic during the Buildroot meeting, and concluded we didn't want patches in Buildroot to enable LibreSSL compatibility with a package. Do we stand on this position, and reject Adam's contribution on ntp?
My position is to avoid feature patches. Adding libresl support in a package is adding a new feature IMHO.
As such, we should not accept it, unless it has *already* been accepted *and* merged upstream.
Regards,
Yann E. MORIN.
Quoted 16 lines
Quoted 2 lines
+ #ifndef
OPENSSL_VERSION_NUMBER
++#ifndefLIBRESSL_VERSION_NUMBERIn addition, this continue to use the
LIBRESSL_VERSION_NUMBERapproach, which will fail when libressl gains support for new APIs.Thanks in advance for giving your feedback on this patch. If nobody complains, I'll merge :-)
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 ntp: add patch to support for libressl
Quoted 12 lines · Yann E. MORIN
Thomas, All,
On 2017-11-23 22:51 +0100, Thomas Petazzoni spake thusly:
Quoted 9 lines · Adam Duskett
Quoted 7 lines
NTP currently fails to compile against LibreSSL because of checks used to determine the SSL library version.
Upstream-Status: Pending
http://bugs.ntp.org/show_bug.cgi?id=3401#c3Signed-off-by Adam Duskett <[email protected]>
Quoted 7 lines
Quoted 4 lines
Arnout, Peter, Yann, I think we discussed this topic during the Buildroot meeting, and concluded we didn't want patches in Buildroot to enable LibreSSL compatibility with a package. Do we stand on this position, and reject Adam's contribution on ntp?
My position is to avoid feature patches. Adding libresl support in a package is adding a new feature IMHO.
Well, it's a bit borderline; it's more like patching a script so that it can
run with busybox ash instead of relying on a bashism. However...
Quoted 2 lines
As such, we should not accept it, unless it has *already* been accepted *and* merged upstream.
... I agree with this one, since there are some doubts (at least in my mind)
that this is the right approach.
Regards,
Arnout
Quoted 21 lines
Regards,
Yann E. MORIN.Quoted 16 lines
Quoted 2 lines
+ #ifndef
OPENSSL_VERSION_NUMBER
++#ifndefLIBRESSL_VERSION_NUMBERIn addition, this continue to use the
LIBRESSL_VERSION_NUMBERapproach, which will fail when libressl gains support for new APIs.Thanks in advance for giving your feedback on this patch. If nobody complains, I'll merge :-)
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF