mech_eap build with --enable-acceptor=no fails
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Project Moonshot |
New
|
Undecided
|
Unassigned |
Bug Description
Trying to build mech_eap with the --enable-
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 gssEapRadiusAdd
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_
https:/
LGTM.
Sent from my iPhone
> On 1 Mar 2018, at 19:43, Alejandro Perez <email address hidden> wrote: acceptor= no configuration Attr() src/radius/ radius. h, and then use those definitions from inititor_ only branch). /github. com/alejandro- perez/mech_ eap/compare/ master. ..allow_ initiator_ only /bugs.launchpad .net/bugs/ 1752520 acceptor= no fails acceptor= no configuration Attr() src/radius/ radius. h, and then use those definitions from inititor_ only branch). /github. com/alejandro- perez/mech_ eap/compare/ master. ..allow_ initiator_ only /bugs.launchpad .net/moonshot/ +bug/1752520/ +subscriptions
>
> Public bug reported:
>
> Trying to build mech_eap with the --enable-
> 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 gssEapRadiusAdd
> function), it makes more sense to add the GSS_ACCEPTOR_* definitions in
> libeap/
> 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_
> https:/
>
> ** 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:/
>
> Title:
> mech_eap build with --enable-
>
> Status in Project Moonshot:
> New
>
> Bug description:
> Trying to build mech_eap with the --enable-
> 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 gssEapRadiusAdd
> function), it makes more sense to add the GSS_ACCEPTOR_* definitions
> in libeap/
> 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_
> https:/
>
> To manage notifications about this bug go to:
> https:/