openwrt/package/libs/openssl/Makefile

226 lines
6.1 KiB
Makefile
Raw Normal View History

#
openssl: update to 1.0.2g (8 CVEs) CVE-2016-0704 s2_srvr.c overwrite the wrong bytes in the master-key when applying Bleichenbacher protection for export cipher suites. This provides a Bleichenbacher oracle, and could potentially allow more efficient variants of the DROWN attack. CVE-2016-0703 s2_srvr.c did not enforce that clear-key-length is 0 for non-export ciphers. If clear-key bytes are present for these ciphers, they *displace* encrypted-key bytes. This leads to an efficient divide-and-conquer key recovery attack: if an eavesdropper has intercepted an SSLv2 handshake, they can use the server as an oracle to determine the SSLv2 master-key, using only 16 connections to the server and negligible computation. More importantly, this leads to a more efficient version of DROWN that is effective against non-export ciphersuites, and requires no significant computation. CVE-2016-0702 A side-channel attack was found which makes use of cache-bank conflicts on the Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA keys. The ability to exploit this issue is limited as it relies on an attacker who has control of code in a thread running on the same hyper- threaded core as the victim thread which is performing decryptions. CVE-2016-0799 The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0797 In the BN_hex2bn function the number of hex digits is calculated using an int value |i|. Later |bn_expand| is called with a value of |i * 4|. For large values of |i| this can result in |bn_expand| not allocating any memory because |i * 4| is negative. This can leave the internal BIGNUM data field as NULL leading to a subsequent NULL ptr deref. For very large values of |i|, the calculation |i * 4| could be a positive value smaller than |i|. In this case memory is allocated to the internal BIGNUM data field, but it is insufficiently sized leading to heap corruption. A similar issue exists in BN_dec2bn. This could have security consequences if BN_hex2bn/BN_dec2bn is ever called by user applications with very large untrusted hex/dec data. This is anticipated to be a rare occurrence. All OpenSSL internal usage of these functions use data that is not expected to be untrusted, e.g. config file data or application command line arguments. If user developed applications generate config file data based on untrusted data then it is possible that this could also lead to security consequences. This is also anticipated to be rare. CVE-2016-0798 The SRP user database lookup method SRP_VBASE_get_by_user had confusing memory management semantics; the returned pointer was sometimes newly allocated, and sometimes owned by the callee. The calling code has no way of distinguishing these two cases. Specifically, SRP servers that configure a secret seed to hide valid login information are vulnerable to a memory leak: an attacker connecting with an invalid username can cause a memory leak of around 300 bytes per connection. Servers that do not configure SRP, or configure SRP but do not configure a seed are not vulnerable. In Apache, the seed directive is known as SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user is now disabled even if the user has configured a seed. Applications are advised to migrate to SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong guarantees about the indistinguishability of valid and invalid logins. In particular, computations are currently not carried out in constant time. CVE-2016-0705 A double free bug was discovered when OpenSSL parses malformed DSA private keys and could lead to a DoS attack or memory corruption for applications that receive DSA private keys from untrusted sources. This scenario is considered rare. CVE-2016-0800 A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non- vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800). Recovering one session key requires the attacker to perform approximately 2^50 computation, as well as thousands of connections to the affected server. A more efficient variant of the DROWN attack exists against unpatched OpenSSL servers using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on 19/Mar/2015 (see CVE-2016-0703 below). Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers, if they've not done so already. Disabling all SSLv2 ciphers is also sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol, and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2 ciphers are nominally disabled, because malicious clients can force the use of SSLv2 with EXPORT ciphers. OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN: SSLv2 is now by default disabled at build-time. Builds that are not configured with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of: SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); or SSL_clear_options(ssl, SSL_OP_NO_SSLv2); as appropriate. Even if either of those is used, or the application explicitly uses the version-specific SSLv2_method() or its client or server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available. In addition, weak ciphers in SSLv3 and up are now disabled in default builds of OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers. Signed-off-by: Jo-Philipp Wich <jow@openwrt.org> SVN-Revision: 48868
2016-03-01 14:31:08 +00:00
# Copyright (C) 2006-2016 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
2006-06-11 00:41:05 +00:00
include $(TOPDIR)/rules.mk
PKG_NAME:=openssl
PKG_BASE:=1.0.2
openssl: update to 1.0.2g (8 CVEs) CVE-2016-0704 s2_srvr.c overwrite the wrong bytes in the master-key when applying Bleichenbacher protection for export cipher suites. This provides a Bleichenbacher oracle, and could potentially allow more efficient variants of the DROWN attack. CVE-2016-0703 s2_srvr.c did not enforce that clear-key-length is 0 for non-export ciphers. If clear-key bytes are present for these ciphers, they *displace* encrypted-key bytes. This leads to an efficient divide-and-conquer key recovery attack: if an eavesdropper has intercepted an SSLv2 handshake, they can use the server as an oracle to determine the SSLv2 master-key, using only 16 connections to the server and negligible computation. More importantly, this leads to a more efficient version of DROWN that is effective against non-export ciphersuites, and requires no significant computation. CVE-2016-0702 A side-channel attack was found which makes use of cache-bank conflicts on the Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA keys. The ability to exploit this issue is limited as it relies on an attacker who has control of code in a thread running on the same hyper- threaded core as the victim thread which is performing decryptions. CVE-2016-0799 The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0797 In the BN_hex2bn function the number of hex digits is calculated using an int value |i|. Later |bn_expand| is called with a value of |i * 4|. For large values of |i| this can result in |bn_expand| not allocating any memory because |i * 4| is negative. This can leave the internal BIGNUM data field as NULL leading to a subsequent NULL ptr deref. For very large values of |i|, the calculation |i * 4| could be a positive value smaller than |i|. In this case memory is allocated to the internal BIGNUM data field, but it is insufficiently sized leading to heap corruption. A similar issue exists in BN_dec2bn. This could have security consequences if BN_hex2bn/BN_dec2bn is ever called by user applications with very large untrusted hex/dec data. This is anticipated to be a rare occurrence. All OpenSSL internal usage of these functions use data that is not expected to be untrusted, e.g. config file data or application command line arguments. If user developed applications generate config file data based on untrusted data then it is possible that this could also lead to security consequences. This is also anticipated to be rare. CVE-2016-0798 The SRP user database lookup method SRP_VBASE_get_by_user had confusing memory management semantics; the returned pointer was sometimes newly allocated, and sometimes owned by the callee. The calling code has no way of distinguishing these two cases. Specifically, SRP servers that configure a secret seed to hide valid login information are vulnerable to a memory leak: an attacker connecting with an invalid username can cause a memory leak of around 300 bytes per connection. Servers that do not configure SRP, or configure SRP but do not configure a seed are not vulnerable. In Apache, the seed directive is known as SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user is now disabled even if the user has configured a seed. Applications are advised to migrate to SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong guarantees about the indistinguishability of valid and invalid logins. In particular, computations are currently not carried out in constant time. CVE-2016-0705 A double free bug was discovered when OpenSSL parses malformed DSA private keys and could lead to a DoS attack or memory corruption for applications that receive DSA private keys from untrusted sources. This scenario is considered rare. CVE-2016-0800 A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non- vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800). Recovering one session key requires the attacker to perform approximately 2^50 computation, as well as thousands of connections to the affected server. A more efficient variant of the DROWN attack exists against unpatched OpenSSL servers using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on 19/Mar/2015 (see CVE-2016-0703 below). Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers, if they've not done so already. Disabling all SSLv2 ciphers is also sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol, and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2 ciphers are nominally disabled, because malicious clients can force the use of SSLv2 with EXPORT ciphers. OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN: SSLv2 is now by default disabled at build-time. Builds that are not configured with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of: SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); or SSL_clear_options(ssl, SSL_OP_NO_SSLv2); as appropriate. Even if either of those is used, or the application explicitly uses the version-specific SSLv2_method() or its client or server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available. In addition, weak ciphers in SSLv3 and up are now disabled in default builds of OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers. Signed-off-by: Jo-Philipp Wich <jow@openwrt.org> SVN-Revision: 48868
2016-03-01 14:31:08 +00:00
PKG_BUGFIX:=g
PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
PKG_RELEASE:=1
PKG_USE_MIPS16:=0
2006-06-11 00:41:05 +00:00
PKG_BUILD_PARALLEL:=0
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
2006-06-11 00:41:05 +00:00
PKG_SOURCE_URL:=http://www.openssl.org/source/ \
ftp://ftp.openssl.org/source/ \
http://www.openssl.org/source/old/$(PKG_BASE)/ \
ftp://ftp.funet.fi/pub/crypt/mirrors/ftp.openssl.org/source \
2006-06-11 00:41:05 +00:00
ftp://ftp.sunet.se/pub/security/tools/net/openssl/source/
openssl: update to 1.0.2g (8 CVEs) CVE-2016-0704 s2_srvr.c overwrite the wrong bytes in the master-key when applying Bleichenbacher protection for export cipher suites. This provides a Bleichenbacher oracle, and could potentially allow more efficient variants of the DROWN attack. CVE-2016-0703 s2_srvr.c did not enforce that clear-key-length is 0 for non-export ciphers. If clear-key bytes are present for these ciphers, they *displace* encrypted-key bytes. This leads to an efficient divide-and-conquer key recovery attack: if an eavesdropper has intercepted an SSLv2 handshake, they can use the server as an oracle to determine the SSLv2 master-key, using only 16 connections to the server and negligible computation. More importantly, this leads to a more efficient version of DROWN that is effective against non-export ciphersuites, and requires no significant computation. CVE-2016-0702 A side-channel attack was found which makes use of cache-bank conflicts on the Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA keys. The ability to exploit this issue is limited as it relies on an attacker who has control of code in a thread running on the same hyper- threaded core as the victim thread which is performing decryptions. CVE-2016-0799 The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0797 In the BN_hex2bn function the number of hex digits is calculated using an int value |i|. Later |bn_expand| is called with a value of |i * 4|. For large values of |i| this can result in |bn_expand| not allocating any memory because |i * 4| is negative. This can leave the internal BIGNUM data field as NULL leading to a subsequent NULL ptr deref. For very large values of |i|, the calculation |i * 4| could be a positive value smaller than |i|. In this case memory is allocated to the internal BIGNUM data field, but it is insufficiently sized leading to heap corruption. A similar issue exists in BN_dec2bn. This could have security consequences if BN_hex2bn/BN_dec2bn is ever called by user applications with very large untrusted hex/dec data. This is anticipated to be a rare occurrence. All OpenSSL internal usage of these functions use data that is not expected to be untrusted, e.g. config file data or application command line arguments. If user developed applications generate config file data based on untrusted data then it is possible that this could also lead to security consequences. This is also anticipated to be rare. CVE-2016-0798 The SRP user database lookup method SRP_VBASE_get_by_user had confusing memory management semantics; the returned pointer was sometimes newly allocated, and sometimes owned by the callee. The calling code has no way of distinguishing these two cases. Specifically, SRP servers that configure a secret seed to hide valid login information are vulnerable to a memory leak: an attacker connecting with an invalid username can cause a memory leak of around 300 bytes per connection. Servers that do not configure SRP, or configure SRP but do not configure a seed are not vulnerable. In Apache, the seed directive is known as SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user is now disabled even if the user has configured a seed. Applications are advised to migrate to SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong guarantees about the indistinguishability of valid and invalid logins. In particular, computations are currently not carried out in constant time. CVE-2016-0705 A double free bug was discovered when OpenSSL parses malformed DSA private keys and could lead to a DoS attack or memory corruption for applications that receive DSA private keys from untrusted sources. This scenario is considered rare. CVE-2016-0800 A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non- vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800). Recovering one session key requires the attacker to perform approximately 2^50 computation, as well as thousands of connections to the affected server. A more efficient variant of the DROWN attack exists against unpatched OpenSSL servers using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on 19/Mar/2015 (see CVE-2016-0703 below). Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers, if they've not done so already. Disabling all SSLv2 ciphers is also sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol, and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2 ciphers are nominally disabled, because malicious clients can force the use of SSLv2 with EXPORT ciphers. OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN: SSLv2 is now by default disabled at build-time. Builds that are not configured with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of: SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); or SSL_clear_options(ssl, SSL_OP_NO_SSLv2); as appropriate. Even if either of those is used, or the application explicitly uses the version-specific SSLv2_method() or its client or server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available. In addition, weak ciphers in SSLv3 and up are now disabled in default builds of OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers. Signed-off-by: Jo-Philipp Wich <jow@openwrt.org> SVN-Revision: 48868
2016-03-01 14:31:08 +00:00
PKG_MD5SUM:=b784b1b3907ce39abf4098702dade6365522a253ad1552e267a9a0e89594aa33
2006-06-11 00:41:05 +00:00
PKG_LICENSE:=OpenSSL
PKG_LICENSE_FILES:=LICENSE
PKG_BUILD_DEPENDS:=ocf-crypto-headers
PKG_CONFIG_DEPENDS:= \
CONFIG_OPENSSL_ENGINE_CRYPTO \
CONFIG_OPENSSL_ENGINE_DIGEST \
CONFIG_OPENSSL_WITH_EC \
CONFIG_OPENSSL_WITH_EC2M \
CONFIG_OPENSSL_WITH_SSL3 \
CONFIG_OPENSSL_HARDWARE_SUPPORT
include $(INCLUDE_DIR)/package.mk
2006-06-11 00:41:05 +00:00
ifneq ($(CONFIG_CCACHE),)
HOSTCC=$(HOSTCC_NOCACHE)
HOSTCXX=$(HOSTCXX_NOCACHE)
endif
define Package/openssl/Default
TITLE:=Open source SSL toolkit
URL:=http://www.openssl.org/
endef
define Package/libopenssl/config
source "$(SOURCE)/Config.in"
endef
define Package/openssl/Default/description
The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, full-featured, and Open Source toolkit implementing the Secure
Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well
as a full-strength general purpose cryptography library.
endef
define Package/libopenssl
$(call Package/openssl/Default)
SECTION:=libs
SUBMENU:=SSL
CATEGORY:=Libraries
DEPENDS:=+zlib
TITLE+= (libraries)
ABI_VERSION:=$(PKG_VERSION)
MENU:=1
endef
define Package/libopenssl/description
$(call Package/openssl/Default/description)
This package contains the OpenSSL shared libraries, needed by other programs.
endef
define Package/openssl-util
$(call Package/openssl/Default)
SECTION:=utils
CATEGORY:=Utilities
DEPENDS:=+libopenssl
TITLE+= (utility)
endef
define Package/openssl-util/conffiles
/etc/ssl/openssl.cnf
endef
define Package/openssl-util/description
$(call Package/openssl/Default/description)
This package contains the OpenSSL command-line utility.
endef
OPENSSL_NO_CIPHERS:= no-idea no-md2 no-mdc2 no-rc5 no-sha0 no-camellia no-krb5
OPENSSL_OPTIONS:= shared no-err zlib-dynamic no-sse2 no-ssl2
ifdef CONFIG_OPENSSL_ENGINE_CRYPTO
OPENSSL_OPTIONS += -DHAVE_CRYPTODEV
ifdef CONFIG_OPENSSL_ENGINE_DIGEST
OPENSSL_OPTIONS += -DUSE_CRYPTODEV_DIGESTS
endif
else
OPENSSL_OPTIONS += no-engines
endif
ifndef CONFIG_OPENSSL_WITH_EC
OPENSSL_OPTIONS += no-ec
endif
ifndef CONFIG_OPENSSL_WITH_EC2M
OPENSSL_OPTIONS += no-ec2m
endif
ifndef CONFIG_OPENSSL_WITH_SSL3
OPENSSL_OPTIONS += no-ssl3
endif
ifndef CONFIG_OPENSSL_HARDWARE_SUPPORT
OPENSSL_OPTIONS += no-hw
endif
ifeq ($(CONFIG_x86_64),y)
OPENSSL_TARGET:=linux-x86_64-openwrt
OPENSSL_MAKEFLAGS += LIBDIR=lib
else
OPENSSL_OPTIONS+=no-sse2
ifeq ($(CONFIG_mips)$(CONFIG_mipsel),y)
OPENSSL_TARGET:=linux-mips-openwrt
# else ifeq ($(CONFIG_arm)$(CONFIG_armeb),y)
# OPENSSL_TARGET:=linux-armv4-openwrt
else
OPENSSL_TARGET:=linux-generic-openwrt
OPENSSL_OPTIONS+=no-perlasm
endif
endif
STAMP_CONFIGURED := $(STAMP_CONFIGURED)_$(subst $(space),_,$(OPENSSL_OPTIONS))
2006-06-11 00:41:05 +00:00
define Build/Configure
[ -f $(STAMP_CONFIGURED) ] || { \
rm -f $(PKG_BUILD_DIR)/*.so.* $(PKG_BUILD_DIR)/*.a; \
find $(PKG_BUILD_DIR) -name \*.o | xargs rm -f; \
}
2006-06-11 00:41:05 +00:00
(cd $(PKG_BUILD_DIR); \
./Configure $(OPENSSL_TARGET) \
--prefix=/usr \
--openssldir=/etc/ssl \
$(TARGET_CPPFLAGS) \
$(TARGET_LDFLAGS) -ldl \
-DOPENSSL_SMALL_FOOTPRINT \
$(OPENSSL_NO_CIPHERS) \
$(OPENSSL_OPTIONS) \
2006-06-11 00:41:05 +00:00
)
# XXX: OpenSSL "make depend" will look for installed headers before its own,
# so remove installed stuff first
-$(SUBMAKE) -j1 clean-staging
+$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
2006-08-31 21:18:29 +00:00
MAKEDEPPROG="$(TARGET_CROSS)gcc" \
OPENWRT_OPTIMIZATION_FLAGS="$(TARGET_CFLAGS)" \
$(OPENSSL_MAKEFLAGS) \
2006-06-11 00:41:05 +00:00
depend
endef
TARGET_CFLAGS += $(FPIC)
define Build/Compile
+$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
CC="$(TARGET_CC)" \
ASFLAGS="$(TARGET_ASFLAGS) -I$(PKG_BUILD_DIR)/crypto -c" \
AR="$(TARGET_CROSS)ar r" \
RANLIB="$(TARGET_CROSS)ranlib" \
OPENWRT_OPTIMIZATION_FLAGS="$(TARGET_CFLAGS)" \
$(OPENSSL_MAKEFLAGS) \
all
+$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
2006-06-11 00:41:05 +00:00
CC="$(TARGET_CC)" \
ASFLAGS="$(TARGET_ASFLAGS) -I$(PKG_BUILD_DIR)/crypto -c" \
2006-06-11 00:41:05 +00:00
AR="$(TARGET_CROSS)ar r" \
RANLIB="$(TARGET_CROSS)ranlib" \
OPENWRT_OPTIMIZATION_FLAGS="$(TARGET_CFLAGS)" \
$(OPENSSL_MAKEFLAGS) \
build-shared
2006-06-11 00:41:05 +00:00
# Work around openssl build bug to link libssl.so with libcrypto.so.
-rm $(PKG_BUILD_DIR)/libssl.so.*.*.*
+$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
CC="$(TARGET_CC)" \
OPENWRT_OPTIMIZATION_FLAGS="$(TARGET_CFLAGS)" \
$(OPENSSL_MAKEFLAGS) \
2006-06-11 00:41:05 +00:00
do_linux-shared
$(MAKE) -C $(PKG_BUILD_DIR) \
CC="$(TARGET_CC)" \
2006-06-11 00:41:05 +00:00
INSTALL_PREFIX="$(PKG_INSTALL_DIR)" \
$(OPENSSL_MAKEFLAGS) \
2006-06-11 00:41:05 +00:00
install
endef
define Build/InstallDev
$(INSTALL_DIR) $(1)/usr/include
$(CP) $(PKG_INSTALL_DIR)/usr/include/openssl $(1)/usr/include/
$(INSTALL_DIR) $(1)/usr/lib/
$(CP) $(PKG_INSTALL_DIR)/usr/lib/lib{crypto,ssl}.{a,so*} $(1)/usr/lib/
$(INSTALL_DIR) $(1)/usr/lib/pkgconfig
$(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/{openssl,libcrypto,libssl}.pc $(1)/usr/lib/pkgconfig/
[ -n "$(TARGET_LDFLAGS)" ] && $(SED) 's#$(TARGET_LDFLAGS)##g' $(1)/usr/lib/pkgconfig/{openssl,libcrypto,libssl}.pc || true
2006-06-11 00:41:05 +00:00
endef
2006-06-11 00:41:05 +00:00
define Package/libopenssl/install
$(INSTALL_DIR) $(1)/usr/lib
$(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/lib/libcrypto.so.* $(1)/usr/lib/
$(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/lib/libssl.so.* $(1)/usr/lib/
2006-06-11 00:41:05 +00:00
endef
define Package/openssl-util/install
$(INSTALL_DIR) $(1)/etc/ssl
2006-06-11 00:41:05 +00:00
$(CP) $(PKG_INSTALL_DIR)/etc/ssl/openssl.cnf $(1)/etc/ssl/
$(INSTALL_DIR) $(1)/etc/ssl/certs
$(INSTALL_DIR) $(1)/etc/ssl/private
2006-06-11 00:41:05 +00:00
chmod 0700 $(1)/etc/ssl/private
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/openssl $(1)/usr/bin/
2006-06-11 00:41:05 +00:00
endef
$(eval $(call BuildPackage,libopenssl))
$(eval $(call BuildPackage,openssl-util))