* [Buildroot] [PATCH] libcurl: drop polarssl support
@ 2014-04-15 13:59 Gustavo Zacarias
2014-04-15 16:10 ` Thomas Petazzoni
2014-04-15 19:55 ` Thomas Petazzoni
0 siblings, 2 replies; 6+ messages in thread
From: Gustavo Zacarias @ 2014-04-15 13:59 UTC (permalink / raw)
To: buildroot
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 <gustavo@zacarias.com.ar>
---
package/libcurl/libcurl.mk | 3 ---
1 file changed, 3 deletions(-)
diff --git a/package/libcurl/libcurl.mk b/package/libcurl/libcurl.mk
index ab558fb..2907303 100644
--- a/package/libcurl/libcurl.mk
+++ b/package/libcurl/libcurl.mk
@@ -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`"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [Buildroot] [PATCH] libcurl: drop polarssl support
2014-04-15 13:59 [Buildroot] [PATCH] libcurl: drop polarssl support Gustavo Zacarias
@ 2014-04-15 16:10 ` Thomas Petazzoni
2014-04-15 16:22 ` Gustavo Zacarias
2014-04-15 19:55 ` Thomas Petazzoni
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2014-04-15 16:10 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Tue, 15 Apr 2014 10:59:06 -0300, Gustavo Zacarias wrote:
> 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [PATCH] libcurl: drop polarssl support
2014-04-15 16:10 ` Thomas Petazzoni
@ 2014-04-15 16:22 ` Gustavo Zacarias
2014-04-15 16:31 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Gustavo Zacarias @ 2014-04-15 16:22 UTC (permalink / raw)
To: buildroot
On 04/15/2014 01:10 PM, Thomas Petazzoni wrote:
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [PATCH] libcurl: drop polarssl support
2014-04-15 16:22 ` Gustavo Zacarias
@ 2014-04-15 16:31 ` Thomas Petazzoni
2014-04-15 17:18 ` Gustavo Zacarias
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2014-04-15 16:31 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Tue, 15 Apr 2014 13:22:08 -0300, Gustavo Zacarias wrote:
> 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.
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [PATCH] libcurl: drop polarssl support
2014-04-15 16:31 ` Thomas Petazzoni
@ 2014-04-15 17:18 ` Gustavo Zacarias
0 siblings, 0 replies; 6+ messages in thread
From: Gustavo Zacarias @ 2014-04-15 17:18 UTC (permalink / raw)
To: buildroot
On 04/15/2014 01:31 PM, Thomas Petazzoni wrote:
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [PATCH] libcurl: drop polarssl support
2014-04-15 13:59 [Buildroot] [PATCH] libcurl: drop polarssl support Gustavo Zacarias
2014-04-15 16:10 ` Thomas Petazzoni
@ 2014-04-15 19:55 ` Thomas Petazzoni
1 sibling, 0 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2014-04-15 19:55 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Tue, 15 Apr 2014 10:59:06 -0300, Gustavo Zacarias wrote:
> 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 <gustavo@zacarias.com.ar>
> ---
> package/libcurl/libcurl.mk | 3 ---
> 1 file changed, 3 deletions(-)
Applied, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-15 19:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-15 13:59 [Buildroot] [PATCH] libcurl: drop polarssl support Gustavo Zacarias
2014-04-15 16:10 ` Thomas Petazzoni
2014-04-15 16:22 ` Gustavo Zacarias
2014-04-15 16:31 ` Thomas Petazzoni
2014-04-15 17:18 ` Gustavo Zacarias
2014-04-15 19:55 ` Thomas Petazzoni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox