[asterisk-bugs] [JIRA] (ASTERISK-27914) [patch] tests/test_utils: Repair ./configure --with-ssl=PATH.

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243820#comment-243820 ] 

Asterisk Team commented on ASTERISK-27914:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> [patch] tests/test_utils: Repair ./configure --with-ssl=PATH.
> -------------------------------------------------------------
>
>                 Key: ASTERISK-27914
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27914
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Tests/General
>    Affects Versions: 13.21.1, 15.4.1
>            Reporter: Alexander Traud
>            Severity: Minor
>
> 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 6 (the last one) of a larger fix, which started in ASTERISK-27865. Commit [832d129|https://github.com/asterisk/asterisk/commit/832d1296c61477eb5c5848b64cf48b36e636bfb0#diff-641acafb670816a3fb642db1e7b6aad3] (ASTERISK-16216) introduced this issue here in Nov. 2010. 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 menuselect.makeopts
> ./menuselect/menuselect --enable TEST_FRAMEWORK --enable test_utils
> 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.
> This bug is marked minor because the affected module is built only optionally. Actually, the affected source code does not need anything from OpenSSL. However, the header {{asterisk/crypto.h}} is included, which includes the header {{openssl/aes.h}}. Because of that, while building, the search path must include the path of OpenSSL. Here in this case, the correct solution would be to fix {{asterisk/crypto.h}}. However, I went for approach C from above. Please, see the note section in ASTERISK-27908 why.



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