Re: PECL Radius Extension PHP8+ and Maintainership

Hi all,

I'm not sure what the expectation is for reply-all on this list, but
I'll do so until I'm corrected.

I've been going through the original code with some amount of scrutiny
and I have some questions:

1) What was the rationale for implementing RADIUS salt-encryption? As
far as I can tell, this was never adopted as an RFC.
If this is the case, I'm wondering why we have this capability in our
local copy libradius. Is this actually utilized? [1]

2) What was the rationale behind carrying a local copy of
libradius(3)? I see there are some PHP-specific modifications related
to RNG. Is there something I'm missing here that would specifically
require this? The libradius code was pulled from FreeBSD
and modified. My target platform is FreeBSD so naturally I gravitate
to just linking against libradius(3) provided by the host
system. Having a local copy would obviously solve the problem of
supporting other *nix and windows platforms. I have also
explored using a more modern radius client library (radcli [2]), and I
have a working PoC extension for that library too.

Best,
CM


[1] https://datatracker.ietf.org/doc/html/draft-ietf-radius-saltencrypt
[2] https://github.com/radcli/radcli

On Thu, Aug 4, 2022 at 9:09 AM Christoph M. Becker <[email protected]> wrote:
>
> On 03.08.2022 at 23:16, Christian McDonald wrote:
>
> > On Wed, Aug 3, 2022 at 4:39 PM Adam Harvey <[email protected]> wrote:
> >>
> >> On Tue, 2 Aug 2022, at 10:54, Christian McDonald wrote:
> >>
> >>> Can we get the radius extension updated to support PHP8+? I see that
> >>> the extension has several open PRs regarding PHP8 support. It looks
> >>> like the most pressing issue is just refactoring against the latest
> >>> extension skeleton to utilize the arginfo generator. We utilize the
> >>> radius extension here at Netgate and would very much appreciate some
> >>> traction here. If there is no longer an interest in maintaining the
> >>> extension, I would be interested in forking the current code and
> >>> taking over the extension under the same PECL name (radius).
> >>
> >> My apologies — I haven't had a lot of bandwidth of late for non-work
> >> things.
>
> Thanks for the swift reply!
>
> > No worries
> >
> >> I would be happy and grateful if you wanted to take over the extension.
> >> Let me know what you need there.
> >
> > I still have much to learn with regards to the PECL'ing process. So if anyone
> > is willing to provide a bit of mentorship there and provide next-steps, I would
> > be grateful.
> >
> >> Separately, cmb messaged me to suggest transferring the extension into
> >> the PHP GitHub organisation. I'm not sure if those would be mutually
> >> exclusive (my last serious involvement with PECL was before the GitHub
> >> transition), so I'd appreciate advice on the best path forward in
> >> general there.
> >
> > Agreed. That is a sensible place to host it. I wouldn't want it on my personal
> > GH account either.
>
> Right.  As the past has shown, hosting PECL extensions in a PHP repo
> makes it easier if maintainership changes.
>
> Adam, I've invited you to the PHP organization on Github.  After you
> have accepted, you may already be able to transfer the radius repo to
> the PHP organization.  If that doesn't work, we may need to adjust some
> settings.
>
> [1]
> <https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository>
>
> Thanks,
> Christoph