mech_eap build with --enable-acceptor=no fails

Bug #1752520 reported by Alejandro Perez on 2018-03-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Project Moonshot
Undecided
Unassigned

Bug Description

Trying to build mech_eap with the --enable-acceptor=no configuration option fails, because using that option removes libradsec header files from the source files, but init_sec_context.c still tries to use the PW_GSS_ACCEPTOR_* definitions for the channel bindings code.

In my opinion, not using libradsec when acceptor code is disabled is the right thing to do. What I think is wrong is using libradsec RADIUS attribute definitions from the initiator code.

Since the initiator code makes use of libeap RADIUS functions for creating the channel bindings (though the gssEapRadiusAddAttr() function), it makes more sense to add the GSS_ACCEPTOR_* definitions in libeap/src/radius/radius.h, and then use those definitions from init_sec_context.c instead of the libradsec ones.

Since these definitions are already standard defined in section 7.4 of RFC 7055, I think this addition should be taken upstream so this would be a temporary patch to our local clone of libeap.

You can find a proposed patch in my Github repository (allow_inititor_only branch).
https://github.com/alejandro-perez/mech_eap/compare/master...allow_initiator_only

LGTM.

Sent from my iPhone

> On 1 Mar 2018, at 19:43, Alejandro Perez <email address hidden> wrote:
>
> Public bug reported:
>
> Trying to build mech_eap with the --enable-acceptor=no configuration
> option fails, because using that option removes libradsec header files
> from the source files, but init_sec_context.c still tries to use the
> PW_GSS_ACCEPTOR_* definitions for the channel bindings code.
>
> In my opinion, not using libradsec when acceptor code is disabled is the
> right thing to do. What I think is wrong is using libradsec RADIUS
> attribute definitions from the initiator code.
>
> Since the initiator code makes use of libeap RADIUS functions for
> creating the channel bindings (though the gssEapRadiusAddAttr()
> function), it makes more sense to add the GSS_ACCEPTOR_* definitions in
> libeap/src/radius/radius.h, and then use those definitions from
> init_sec_context.c instead of the libradsec ones.
>
> Since these definitions are already standard defined in section 7.4 of
> RFC 7055, I think this addition should be taken upstream so this would
> be a temporary patch to our local clone of libeap.
>
> You can find a proposed patch in my Github repository (allow_inititor_only branch).
> https://github.com/alejandro-perez/mech_eap/compare/master...allow_initiator_only
>
> ** Affects: moonshot
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of Moonshot
> Drivers, which is subscribed to Project Moonshot.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/1752520
>
> Title:
> mech_eap build with --enable-acceptor=no fails
>
> Status in Project Moonshot:
> New
>
> Bug description:
> Trying to build mech_eap with the --enable-acceptor=no configuration
> option fails, because using that option removes libradsec header files
> from the source files, but init_sec_context.c still tries to use the
> PW_GSS_ACCEPTOR_* definitions for the channel bindings code.
>
> In my opinion, not using libradsec when acceptor code is disabled is
> the right thing to do. What I think is wrong is using libradsec RADIUS
> attribute definitions from the initiator code.
>
> Since the initiator code makes use of libeap RADIUS functions for
> creating the channel bindings (though the gssEapRadiusAddAttr()
> function), it makes more sense to add the GSS_ACCEPTOR_* definitions
> in libeap/src/radius/radius.h, and then use those definitions from
> init_sec_context.c instead of the libradsec ones.
>
> Since these definitions are already standard defined in section 7.4 of
> RFC 7055, I think this addition should be taken upstream so this would
> be a temporary patch to our local clone of libeap.
>
> You can find a proposed patch in my Github repository (allow_inititor_only branch).
> https://github.com/alejandro-perez/mech_eap/compare/master...allow_initiator_only
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/moonshot/+bug/1752520/+subscriptions

My patch was accepted by hostap upstream, meaning that as soon as we merge into our repository, we no longer require libradsec for the initiator part.

https://w1.fi/cgit/hostap/commit/?id=2ff9696d3bb6ed744318f8d5d135a99dcac4de2b

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers