[asterisk-bugs] [JIRA] (ASTERISK-27908) [patch] crypto.h: Repair ./configure --with-ssl=PATH.

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-27908:
-------------------------------------

    Target Release Version/s: 13.22.0

> [patch] crypto.h: Repair ./configure --with-ssl=PATH.
> -----------------------------------------------------
>
>                 Key: ASTERISK-27908
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27908
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2, Functions/func_aes, PBX/pbx_dundi, Resources/res_crypto
>    Affects Versions: 13.21.0, 15.4.0
>            Reporter: Alexander Traud
>            Assignee: Alexander Traud
>              Labels: patch
>      Target Release: 13.22.0
>
>         Attachments: with-ssl_crypto_C.patch, with-ssl_crypto_D.patch
>
>
> With the upcoming [TLS 1.3|https://tools.ietf.org/html/draft-ietf-tls-tls13] and 3DES being [disabled|https://www.openssl.org/blog/blog/2016/08/24/sweet32/] in OpenSSL 1.1.x, using a custom build OpenSSL library for SIP-over-TLS might be interesting.
> This is sequel 5 of a larger fix, which started in ASTERISK-27865. Commit [606ae34|https://github.com/asterisk/asterisk/commit/606ae3484ab5a4b928ab8e9116d430d6c295b387#diff-c7524f14b5854b2e901b325446991695] (ASTERISK-27390) introduced this issue here in Nov. 2017. When a source file includes a header from an optional package (for example OpenSSL), one has to specify either
> A) {{xyz.o: _ASTCFLAGS+=$(OPENSSL_INCLUDE)}} in its Makefile, or
> B) {{<depend>openssl</depend>}} in its {{MODULEINFO}}, or
> C) {{<use type="external">openssl</use>}} in its {{MODULEINFO}}.
> The latter is for modules which can be used/built without that external library. When OpenSSL was detected by the script {{./configure}}, the build system of Asterisk adds the required include path. Without, the path of {{--with-ssl}} is not honored and those headers are searched within the system only.
> *Steps to Reproduce* (Ubuntu 18.04 LTS)
> {code}sudo apt install build-essential pkg-config libedit-dev libjansson-dev libsqlite3-dev uuid-dev libxslt1-dev
> sudo apt remove libssl-dev
> cd ~/Downloads
> wget www.openssl.org/source/openssl-1.1.1-pre7.tar.gz
> tar -zxf ./openssl-*.tar.gz
> cd ./openssl-*
> ./config shared enable-weak-ssl-ciphers
> make
> export SSL_HOME=$PWD
> cd ~/Downloads
> wget downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz
> tar -zxf ./asterisk-*.tar.gz
> cd ./asterisk-*
> LDFLAGS="-Wl,-rpath $SSL_HOME" ./configure --enable-dev-mode=noisy --with-crypto=$SSL_HOME --with-ssl=$SSL_HOME
> make{code}*Expected Result*
> Should build without any problem.
> *Actual Result*
> {{fatal error: 'openssl/aes.h' file not found}}
> *Workaround*
> Install headers of OpenSSL in the system, for example in Ubuntu via
> {{sudo apt install libssl-dev}}
> *Notes*
> Thanks to the 'noisy' developer mode (see the configure option), the cause was found quite fast.
> Another alternative would be to go for forward declarations in the header {{asterisk/crypto.h}} and then change all occurrences from structs to pointer of structs. Such a patch is attached and Asterisk compiles. However, that does not work, because those structs are copied at least once:
> * channels/chan_iax2.c:iax2_send(.)
> * pbx/pbx_dundi.c:dundi_encrypt(.)
> * funs/func_aes.c:aes_helper(.)
> In all cases, the fix would require the size of the struct, which again would require the OpenSSL header present in that source file. The next approach would be to analyze if those files really need to copy and whether not a simple pointer is sufficient. However, because that struct is used in other structs, more places might copy. This is way above my head because I am just an external contributor. Furthermore, I do not use those modules actually. They are compiled at default. Consequently and because all of them are modules, I went for alternative C.



--
This message was sent by Atlassian JIRA
(v6.2#6252)