Checking TLS-Cert-* and and accept/reject based on them

Axel Thimm Axel.Thimm at ATrpms.net
Thu Aug 29 17:40:42 CEST 2013


On Thu, Aug 29, 2013 at 02:49:17PM +0000, stefan.paetow at diamond.ac.uk wrote:
> > Agreed on the support contract thing. If something is apparently
> > "unsupported" when it's broken, just run the "supported" version on a
> > test system, reproduce the problem, and go from there. If you know the
> > problem is to do with the newer features, forget the paid support and
> > ask here like you just did.
> > 
> > If the support is worth anything, of course, then I'm sure they'll be
> > delighted to build later packages for you that include the patch. :-)

I'm discussing this within Red Hat already. They are not that
upgrade-shy (if it doesn't change the API/ABI), but it takes longer to
get approvals from all people involved.

> RedHat does follow this list, so perhaps it is worth contacting them
> to point out that this patch would really be appreciated, even if it
> ends up in an EPEL package (which should still be acceptable).

freeradius belongs to the core group of technologies in Red Hat, so
it's unlikely to allow a replacing package in EPEL (unless it is
called freeradius3 or freeradius221 or similar).

> That said, I commiserate with the original poster that yes, when the
> policy is that you're only allowed to use vendor packages, you're
> limited in what you can and cannot do.

Thanks!
-- 
Axel.Thimm at ATrpms.net


More information about the Freeradius-Users mailing list