* [PATCH] imap-send: Fix compilation without deprecated OpenSSL APIs
@ 2018-12-27 2:35 Rosen Penev
2018-12-27 6:32 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Rosen Penev @ 2018-12-27 2:35 UTC (permalink / raw)
To: git
Initialization in OpenSSL has been deprecated in version 1.1. This makes
compilation fail when deprecated APIs for OpenSSL are compile-time
disabled.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
imap-send.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/imap-send.c b/imap-send.c
index b4eb886e2..21f741c8c 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
int ret;
X509 *cert;
+#if (OPENSSL_VERSION_NUMBER < 0x10000000L)
SSL_library_init();
SSL_load_error_strings();
+#endif
meth = SSLv23_method();
if (!meth) {
--
2.20.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] imap-send: Fix compilation without deprecated OpenSSL APIs
2018-12-27 2:35 [PATCH] imap-send: Fix compilation without deprecated OpenSSL APIs Rosen Penev
@ 2018-12-27 6:32 ` Junio C Hamano
2018-12-27 17:55 ` Rosen Penev
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2018-12-27 6:32 UTC (permalink / raw)
To: Rosen Penev; +Cc: git
Rosen Penev <rosenp@gmail.com> writes:
> Initialization in OpenSSL has been deprecated in version 1.1.
https://www.openssl.org/docs/man1.0.2/ssl/SSL_library_init.html says
SSL_library_init() must be called before any other action takes
place.
https://www.openssl.org/docs/man1.1.0/ssl/SSL_library_init.html says
the same.
Which makes it necessary for us to defend the following claim
> This makes
> compilation fail when deprecated APIs for OpenSSL are compile-time
> disabled.
as a valid problem description more rigorously. To me, the cursory
web-serfing I did above makes me suspect that an OpenSSL
implementation with such a compile-time disabling _is_ buggy, as it
forbids the API users to call an API function they are told to call
before doing anything else.
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> imap-send.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/imap-send.c b/imap-send.c
> index b4eb886e2..21f741c8c 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
> int ret;
> X509 *cert;
>
> +#if (OPENSSL_VERSION_NUMBER < 0x10000000L)
https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.html
says that OPENSSL_VERSION_NUMBER is of form 0xMNNFFPPS where M is
major, NN is minor, FF is fix, PP is patch and S is status, and
gives an example that 0x00906023 stands for 0.9.6.b beta 3 (M=0,
NN=09, FF=06, PP=02 and S=3). So "< 0x10000000L" means "anything
with M smaller than 1". IOW, we would no longer call _init() for
e.g. "version 1.0.0 beta 0". That contradicts with the first claim
of the proposed log message ("deprecated in 1.1" implying that it is
not yet deprecated in say 1.0.2).
> SSL_library_init();
> SSL_load_error_strings();
> +#endif
>
> meth = SSLv23_method();
> if (!meth) {
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] imap-send: Fix compilation without deprecated OpenSSL APIs
2018-12-27 6:32 ` Junio C Hamano
@ 2018-12-27 17:55 ` Rosen Penev
2018-12-28 19:20 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Rosen Penev @ 2018-12-27 17:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Dec 26, 2018 at 10:32 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Rosen Penev <rosenp@gmail.com> writes:
>
> > Initialization in OpenSSL has been deprecated in version 1.1.
>
> https://www.openssl.org/docs/man1.0.2/ssl/SSL_library_init.html says
>
> SSL_library_init() must be called before any other action takes
> place.
>
> https://www.openssl.org/docs/man1.1.0/ssl/SSL_library_init.html says
> the same.
Later on in the document it mentions that it is deprecated.
>
> Which makes it necessary for us to defend the following claim
>
> > This makes
> > compilation fail when deprecated APIs for OpenSSL are compile-time
> > disabled.
>
> as a valid problem description more rigorously. To me, the cursory
> web-serfing I did above makes me suspect that an OpenSSL
> implementation with such a compile-time disabling _is_ buggy, as it
> forbids the API users to call an API function they are told to call
> before doing anything else.
I agree the man page is misleading. The changelog for 1.1.0 is very
clear though:
Added support for auto-initialisation and de-initialisation of the library.
OpenSSL no longer requires explicit init or deinit routines to be called,
except in certain circumstances. See the OPENSSL_init_crypto() and
OPENSSL_init_ssl() man pages for further information.
[Matt Caswell]
https://www.openssl.org/news/changelog.html#x12
>
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > imap-send.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/imap-send.c b/imap-send.c
> > index b4eb886e2..21f741c8c 100644
> > --- a/imap-send.c
> > +++ b/imap-send.c
> > @@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
> > int ret;
> > X509 *cert;
> >
> > +#if (OPENSSL_VERSION_NUMBER < 0x10000000L)
>
> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.html
>
> says that OPENSSL_VERSION_NUMBER is of form 0xMNNFFPPS where M is
> major, NN is minor, FF is fix, PP is patch and S is status, and
> gives an example that 0x00906023 stands for 0.9.6.b beta 3 (M=0,
> NN=09, FF=06, PP=02 and S=3). So "< 0x10000000L" means "anything
> with M smaller than 1". IOW, we would no longer call _init() for
> e.g. "version 1.0.0 beta 0". That contradicts with the first claim
> of the proposed log message ("deprecated in 1.1" implying that it is
> not yet deprecated in say 1.0.2).
This is a mistake. I will send a v2 to fix.
Oh I see what I did wrong. I mistakenly copied the above
OPENSSL_VERSION_NUMBER check without looking carefully at the number.
>
>
>
> > SSL_library_init();
> > SSL_load_error_strings();
> > +#endif
> >
> > meth = SSLv23_method();
> > if (!meth) {
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] imap-send: Fix compilation without deprecated OpenSSL APIs
2018-12-27 17:55 ` Rosen Penev
@ 2018-12-28 19:20 ` Junio C Hamano
0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2018-12-28 19:20 UTC (permalink / raw)
To: Rosen Penev; +Cc: git
Rosen Penev <rosenp@gmail.com> writes:
> On Wed, Dec 26, 2018 at 10:32 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Rosen Penev <rosenp@gmail.com> writes:
>>
>> > Initialization in OpenSSL has been deprecated in version 1.1.
>>
>> https://www.openssl.org/docs/man1.0.2/ssl/SSL_library_init.html says
>>
>> SSL_library_init() must be called before any other action takes
>> place.
>>
>> https://www.openssl.org/docs/man1.1.0/ssl/SSL_library_init.html says
>> the same.
> Later on in the document it mentions that it is deprecated.
>>
>> Which makes it necessary for us to defend the following claim
>>
>> > This makes
>> > compilation fail when deprecated APIs for OpenSSL are compile-time
>> > disabled.
>>
>> as a valid problem description more rigorously. To me, the cursory
>> web-serfing I did above makes me suspect that an OpenSSL
>> implementation with such a compile-time disabling _is_ buggy, as it
>> forbids the API users to call an API function they are told to call
>> before doing anything else.
> I agree the man page is misleading. The changelog for 1.1.0 is very
> clear though:
>
> Added support for auto-initialisation and de-initialisation of the library.
> OpenSSL no longer requires explicit init or deinit routines to be called,
> except in certain circumstances. See the OPENSSL_init_crypto() and
> OPENSSL_init_ssl() man pages for further information.
> [Matt Caswell]
All it says is explicit calls to SSL_library_init() is now optional.
It does not say it is a compile-time-error worthy offense to make
explicit init/deinit calls. Which still means that an OpenSSL
implementation with such a compile-time disabling _is_ buggy, as it
forbids the API users to call an API function they are told to call
before doing anything else.
>> > diff --git a/imap-send.c b/imap-send.c
>> > index b4eb886e2..21f741c8c 100644
>> > --- a/imap-send.c
>> > +++ b/imap-send.c
>> > @@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
>> > int ret;
>> > X509 *cert;
>> >
>> > +#if (OPENSSL_VERSION_NUMBER < 0x10000000L)
>>
>> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.html
>>
>> says that OPENSSL_VERSION_NUMBER is of form 0xMNNFFPPS where M is
>> major, NN is minor, FF is fix, PP is patch and S is status, and
>> gives an example that 0x00906023 stands for 0.9.6.b beta 3 (M=0,
>> NN=09, FF=06, PP=02 and S=3). So "< 0x10000000L" means "anything
>> with M smaller than 1". IOW, we would no longer call _init() for
>> e.g. "version 1.0.0 beta 0". That contradicts with the first claim
>> of the proposed log message ("deprecated in 1.1" implying that it is
>> not yet deprecated in say 1.0.2).
> This is a mistake. I will send a v2 to fix.
>
> Oh I see what I did wrong. I mistakenly copied the above
> OPENSSL_VERSION_NUMBER check without looking carefully at the number.
Yup, please be careful next time.
>>
>>
>>
>> > SSL_library_init();
>> > SSL_load_error_strings();
>> > +#endif
>> >
>> > meth = SSLv23_method();
>> > if (!meth) {
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-12-28 20:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-27 2:35 [PATCH] imap-send: Fix compilation without deprecated OpenSSL APIs Rosen Penev
2018-12-27 6:32 ` Junio C Hamano
2018-12-27 17:55 ` Rosen Penev
2018-12-28 19:20 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).