wpa-supplicant & EAP-TLS

wpa-supplicant & EAP-TLS

[Gary Thomas]

Does anyone know why the recipe for wpa_supplicant is using gnutls
and not the default OpenSSH for TLS services?  It seems that gnutls
is somehow broken and EAP-TLS does not work with this configuration.
Changing wpa_supplicant to use the OpenSSH libraries makes EAP-TLS
work fine.

Would a patch to make this change be entertained?  or should I just
keep it in my own layer?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: wpa-supplicant & EAP-TLS

[Phil Blundell]

On Tue, 2012-08-14 at 05:44 -0600, Gary Thomas wrote:
> Does anyone know why the recipe for wpa_supplicant is using gnutls
> and not the default OpenSSH for TLS services?  It seems that gnutls
> is somehow broken and EAP-TLS does not work with this configuration.
> Changing wpa_supplicant to use the OpenSSH libraries makes EAP-TLS
> work fine.
> 
> Would a patch to make this change be entertained?  or should I just
> keep it in my own layer?

I don't think a patch to just flip the default would be a good idea.  A
patch to make it be a DISTRO_FEATURE, on the other hand, would be
excellent.

p.

Re: wpa-supplicant & EAP-TLS

[Saul Wold]

On 08/14/2012 02:46 PM, Phil Blundell wrote:
> On Tue, 2012-08-14 at 05:44 -0600, Gary Thomas wrote:
>> Does anyone know why the recipe for wpa_supplicant is using gnutls
>> and not the default OpenSSH for TLS services?  It seems that gnutls
>> is somehow broken and EAP-TLS does not work with this configuration.
>> Changing wpa_supplicant to use the OpenSSH libraries makes EAP-TLS
>> work fine.
>>
>> Would a patch to make this change be entertained?  or should I just
>> keep it in my own layer?
>
> I don't think a patch to just flip the default would be a good idea.  A
> patch to make it be a DISTRO_FEATURE, on the other hand, would be
> excellent.
>
+1

Sau!

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>

Re: wpa-supplicant & EAP-TLS

[Gary Thomas]

On 2012-08-14 05:46, Phil Blundell wrote:
> On Tue, 2012-08-14 at 05:44 -0600, Gary Thomas wrote:
>> Does anyone know why the recipe for wpa_supplicant is using gnutls
>> and not the default OpenSSH for TLS services?  It seems that gnutls
>> is somehow broken and EAP-TLS does not work with this configuration.
>> Changing wpa_supplicant to use the OpenSSH libraries makes EAP-TLS
>> work fine.
>>
>> Would a patch to make this change be entertained?  or should I just
>> keep it in my own layer?
>
> I don't think a patch to just flip the default would be a good idea.  A
> patch to make it be a DISTRO_FEATURE, on the other hand, would be
> excellent.

Thanks, I'll see about working one up.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: wpa-supplicant & EAP-TLS

[Henning Heinold]

On Tue, Aug 14, 2012 at 05:52:32AM -0600, Gary Thomas wrote:
> On 2012-08-14 05:46, Phil Blundell wrote:
> >On Tue, 2012-08-14 at 05:44 -0600, Gary Thomas wrote:
> >>Does anyone know why the recipe for wpa_supplicant is using gnutls
> >>and not the default OpenSSH for TLS services?  It seems that gnutls
> >>is somehow broken and EAP-TLS does not work with this configuration.
> >>Changing wpa_supplicant to use the OpenSSH libraries makes EAP-TLS
> >>work fine.
> >>
> >>Would a patch to make this change be entertained?  or should I just
> >>keep it in my own layer?
> >
> >I don't think a patch to just flip the default would be a good idea.  A
> >patch to make it be a DISTRO_FEATURE, on the other hand, would be
> >excellent.
> 
> Thanks, I'll see about working one up.

Btw. You mean openssl not openssh, which uses openssl too.

And a problem with using openssl for wpa_supplicant was license incompatibilities.

Mabyee it is fixed meanwhile.

Bye Henning

Re: wpa-supplicant & EAP-TLS

[Koen Kooi]

Op 14 aug. 2012, om 15:59 heeft Henning Heinold <heinold@inf.fu-berlin.de> het volgende geschreven:

> On Tue, Aug 14, 2012 at 05:52:32AM -0600, Gary Thomas wrote:
>> On 2012-08-14 05:46, Phil Blundell wrote:
>>> On Tue, 2012-08-14 at 05:44 -0600, Gary Thomas wrote:
>>>> Does anyone know why the recipe for wpa_supplicant is using gnutls
>>>> and not the default OpenSSH for TLS services?  It seems that gnutls
>>>> is somehow broken and EAP-TLS does not work with this configuration.
>>>> Changing wpa_supplicant to use the OpenSSH libraries makes EAP-TLS
>>>> work fine.
>>>> 
>>>> Would a patch to make this change be entertained?  or should I just
>>>> keep it in my own layer?
>>> 
>>> I don't think a patch to just flip the default would be a good idea.  A
>>> patch to make it be a DISTRO_FEATURE, on the other hand, would be
>>> excellent.
>> 
>> Thanks, I'll see about working one up.
> 
> Btw. You mean openssl not openssh, which uses openssl too.
> 
> And a problem with using openssl for wpa_supplicant was license incompatibilities.

I think wpa_supplicant has the openssl exception in its license nowadays, but it's best to double check

Re: wpa-supplicant & EAP-TLS

[Gary Thomas]

On 2012-08-14 08:13, Koen Kooi wrote:
>
> Op 14 aug. 2012, om 15:59 heeft Henning Heinold <heinold@inf.fu-berlin.de> het volgende geschreven:
>
>> On Tue, Aug 14, 2012 at 05:52:32AM -0600, Gary Thomas wrote:
>>> On 2012-08-14 05:46, Phil Blundell wrote:
>>>> On Tue, 2012-08-14 at 05:44 -0600, Gary Thomas wrote:
>>>>> Does anyone know why the recipe for wpa_supplicant is using gnutls
>>>>> and not the default OpenSSH for TLS services?  It seems that gnutls
>>>>> is somehow broken and EAP-TLS does not work with this configuration.
>>>>> Changing wpa_supplicant to use the OpenSSH libraries makes EAP-TLS
>>>>> work fine.
>>>>>
>>>>> Would a patch to make this change be entertained?  or should I just
>>>>> keep it in my own layer?
>>>>
>>>> I don't think a patch to just flip the default would be a good idea.  A
>>>> patch to make it be a DISTRO_FEATURE, on the other hand, would be
>>>> excellent.
>>>
>>> Thanks, I'll see about working one up.
>>
>> Btw. You mean openssl not openssh, which uses openssl too.
>>
>> And a problem with using openssl for wpa_supplicant was license incompatibilities.
>
> I think wpa_supplicant has the openssl exception in its license nowadays, but it's best to double check

I don't see anything explicit on this topic.  That said, the latest version
(1.0) is dual licensed GPL and BSD and the OpenSSL license is BSD compatible
from what I can tell.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: wpa-supplicant & EAP-TLS

[Phil Blundell]

On Tue, 2012-08-14 at 08:47 -0600, Gary Thomas wrote:
> I don't see anything explicit on this topic.  That said, the latest version
> (1.0) is dual licensed GPL and BSD and the OpenSSL license is BSD compatible
> from what I can tell.

Yes, wpa-supplicant itself has been OK in this respect for some time.
(The dual-licensing option has actually been removed for the very latest
versions of wpa-supplicant and it's now under the BSD license only, but
this is fine for OpenSSL compatibility purposes.)  However, there are
quite a lot of other SSL-using programs which are only licensed under
GPL terms and linking these with OpenSSL is problematic for some people.
In an ideal world the oe-core license machinery would be able to detect
and warn about that conflict, but I don't think we are quite there yet.

As a general rule, we don't want to build and ship multiple SSL
implementations when one will suffice.  GnuTLS seems to be the most
compatible (in license terms) which is why it is generally the default.
However, DISTROs which don't need to worry about the OpenSSL-GPL
conflict for whatever reason might legitimately want to use OpenSSL
globally, and DISTROs which aren't too bothered about potentially
shipping both might legitimately want to use OpenSSL for specific
packages like wpa-supplicant even if they have GnuTLS elsewhere.

p.

Re: wpa-supplicant & EAP-TLS

[Gary Thomas]

On 2012-08-14 14:30, Phil Blundell wrote:
> On Tue, 2012-08-14 at 08:47 -0600, Gary Thomas wrote:
>> I don't see anything explicit on this topic.  That said, the latest version
>> (1.0) is dual licensed GPL and BSD and the OpenSSL license is BSD compatible
>> from what I can tell.
>
> Yes, wpa-supplicant itself has been OK in this respect for some time.
> (The dual-licensing option has actually been removed for the very latest
> versions of wpa-supplicant and it's now under the BSD license only, but
> this is fine for OpenSSL compatibility purposes.)  However, there are
> quite a lot of other SSL-using programs which are only licensed under
> GPL terms and linking these with OpenSSL is problematic for some people.
> In an ideal world the oe-core license machinery would be able to detect
> and warn about that conflict, but I don't think we are quite there yet.
>
> As a general rule, we don't want to build and ship multiple SSL
> implementations when one will suffice.  GnuTLS seems to be the most
> compatible (in license terms) which is why it is generally the default.
> However, DISTROs which don't need to worry about the OpenSSL-GPL
> conflict for whatever reason might legitimately want to use OpenSSL
> globally, and DISTROs which aren't too bothered about potentially
> shipping both might legitimately want to use OpenSSL for specific
> packages like wpa-supplicant even if they have GnuTLS elsewhere.

I looked a bit into this and found that OE-core is already rather
schizo on this topic, so I'm not quite sure what needs to be done
here (i.e. should there be a DISTRO_FEATURES switch that chooses only
one?)  It would seem that all systems (at least those with wpa-supplicant
included) will already have both SSL libraries installed.

opsnssl is used in these packages:
   midori
   socat
   curl-native
   openvpn
   bind
   telepathy-idle
   dhcp
   xserver-kdrive
   tcf-agent
   python
   rpm
   git
   task-core-basic
   mailx
   libzypp (=> sat-solver, zypper)
   wget

gnutls is used by these packages:
   cups
   wpa-supplicant
   neon
   curl

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: wpa-supplicant & EAP-TLS

[Phil Blundell]

On Wed, 2012-08-15 at 04:47 -0600, Gary Thomas wrote:
> I looked a bit into this and found that OE-core is already rather
> schizo on this topic, so I'm not quite sure what needs to be done
> here (i.e. should there be a DISTRO_FEATURES switch that chooses only
> one?)  It would seem that all systems (at least those with wpa-supplicant
> included) will already have both SSL libraries installed.

"All systems" is probably a bit strong.  I certainly have multiple
configurations which don't install anything from the openssl list below.

Anyway, it looks like the best way forward in the short term is to make
the choice of SSL library be a PACKAGECONFIG option for wpa-supplicant
and any other recipes that you feel like changing.  I think it would
also make sense to have some sort of DISTRO_FEATURE to set a global
preference for this although perhaps the exact form of that setting
needs a bit of further thought.

> opsnssl is used in these packages:
>    midori
>    socat
>    curl-native
>    openvpn
>    bind
>    telepathy-idle
>    dhcp
>    xserver-kdrive
>    tcf-agent
>    python
>    rpm
>    git
>    task-core-basic
>    mailx
>    libzypp (=> sat-solver, zypper)
>    wget
> 
> gnutls is used by these packages:
>    cups
>    wpa-supplicant
>    neon
>    curl

p.