libcurl: drop polarssl support
PATCH 1/1 libcurl: drop polarssl support
As of curl 7.36.0 it doesn't support polarssl < 1.3 any longer. Fixes:
http://autobuild.buildroot.net/results/d82/d82c3618e9dde3da7e36ba2b58545a9a8de5e442/
--- package/libcurl/libcurl.mk | 3 --- 1 file changed, 3 deletions(-)
package/libcurl/libcurl.mk +0 -3
@@ -36,9 +36,6 @@ LIBCURL_CONF_OPT += --with-ssl=$(STAGING_DIR)/usr \ else ifeq ($(BR2_PACKAGE_GNUTLS),y) LIBCURL_CONF_OPT += --with-gnutls=$(STAGING_DIR)/usr LIBCURL_DEPENDENCIES += gnutls -else ifeq ($(BR2_PACKAGE_POLARSSL),y) -LIBCURL_CONF_OPT += --with-polarssl=$(STAGING_DIR)/usr -LIBCURL_DEPENDENCIES += polarssl else ifeq ($(BR2_PACKAGE_LIBNSS),y) LIBCURL_CONF_OPT += --with-nss=$(STAGING_DIR)/usr LIBCURL_CONF_ENV += CPPFLAGS="$(TARGET_CPPFLAGS) `$(PKG_CONFIG_HOST_BINARY) nspr nss --cflags`"
Signature · 1 line
1.8.3.2
PATCH 1/1 libcurl: drop polarssl support
Dear Gustavo Zacarias,
Quoted 2 lines · Gustavo Zacarias
As of curl 7.36.0 it doesn't support polarssl < 1.3 any longer. Fixes:
http://autobuild.buildroot.net/results/d82/d82c3618e9dde3da7e36ba2b58545a9a8de5e442/
It seems odd to drop a feature because we have a too old version of a dependency, no? Shouldn't we package polarssl 1.3, even if as a separate polarssl13 package?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 libcurl: drop polarssl support
Quoted 3 lines · Thomas Petazzoni
It seems odd to drop a feature because we have a too old version of a dependency, no? Shouldn't we package polarssl 1.3, even if as a separate polarssl13 package?
The problem is that they aren't made to live together in a friendly way and some packages don't take path arguments for it.
It would require quite some package patching since we'd need each polarssl to live outside the default include/library PATHs. We aren't dropping a feature itself, just a feature based on one of the possible candidates that enables it, with gnutls, nss and openssl being the other candidates for the job.
The big culprit here AFAIK is just openvpn, it's the only mofo that won't do with polarssl 1.3. There are patches in the master branch upstream for it, but that's to become openvpn 2.4 or so. Maybe they're not hard to backport, i don't know, but it would require more testing than just "it builds".
Or we can kill polarssl support in openvpn, not great either since the other alternative is openssl.
Regards.
PATCH 1/1 libcurl: drop polarssl support
Dear Gustavo Zacarias,
Quoted 6 lines · Gustavo Zacarias
The problem is that they aren't made to live together in a friendly way and some packages don't take path arguments for it.
It would require quite some package patching since we'd need each polarssl to live outside the defaultinclude/libraryPATHs. We aren't dropping a feature itself, just a feature based on one of the possible candidates that enables it, with gnutls, nss and openssl being
Quoted 8 lines
the other candidates for the job.
The big culprit here AFAIK is just openvpn, it's the only mofo that won't do with polarssl 1.3. There are patches in the master branch upstream for it, but that's to become openvpn 2.4 or so. Maybe they're not hard to backport, i don't know, but it would require more testing than just "it builds".
Or we can kill polarssl support in openvpn, not great either since the other alternative is openssl.
Ok. I guess we can wait for openvpn 2.4 to be released. If that takes too long, I'd say we should kill polarssl support in openvpn, because it's the one lagging behind. It seems more logical to me to kill that one (the one lagging behind) instead of the one being up-to-date (i.e, libcurl).
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 libcurl: drop polarssl support
Quoted 5 lines · Thomas Petazzoni
Ok. I guess we can wait for openvpn 2.4 to be released. If that takes too long, I'd say we should kill polarssl support in openvpn, because it's the one lagging behind. It seems more logical to me to kill that one (the one lagging behind) instead of the one being up-to-date (i.e, libcurl).
That's debatable, if you don't like openssl support for libcurl (paranoia, security, friends & family, whatever) you still got other options, if you do that to openvpn you're stuck since it's the only other option.
That being said a 2.4 release is quite off IMHO and the polarssl backend isn't feature-complete compared to openssl, though the paranoia point is still valid given the heartbleed fallout.
Regards.
Thomas Petazzoni
AppliedPATCH 1/1 libcurl: drop polarssl support
In reply to Gustavo ZacariasDear Gustavo Zacarias,
Quoted 7 lines · Gustavo Zacarias
As of curl 7.36.0 it doesn't support polarssl < 1.3 any longer. Fixes:
http://autobuild.buildroot.net/results/d82/d82c3618e9dde3da7e36ba2b58545a9a8de5e442/Signed-off-by Gustavo Zacarias <[email protected]>--- package/libcurl/libcurl.mk | 3 --- 1 file changed, 3 deletions(-)
Applied, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com