[20511] in Kerberos_V5_Development
Re: Using std::regex for pkinit on Windows
daemon@ATHENA.MIT.EDU (Ken Hornstein via krbdev)
Sat Nov 23 17:50:50 2024
Message-Id: <202411232250.4ANMoZ6G018466@hedwig.cmf.nrl.navy.mil>
To: "Greg Hudson" <ghudson@mit.edu>
cc: krbdev@mit.edu
In-Reply-To: <e1859217-36d7-4e6e-86d1-fc920944133e@mit.edu>
MIME-Version: 1.0
Date: Sat, 23 Nov 2024 17:50:35 -0500
From: Ken Hornstein via krbdev <krbdev@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>The ideal would be that code using regular expressions would include a
><k5-regex.h> from src/include and use the POSIX APIs. On POSIX
>platforms this header would include <regex.h> and otherwise do nothing;
>on Windows it would #define the POSIX symbols to k5_ symbols implemented
>in libkrb5support.
>
>If it's not possible to express the POSIX API perfectly in terms of
>std::regex, then we can invent a least-common-denominator API with k5_
>names. In that case, k5-regex.h would use macros or inline functions to
>express the common API in terms of the POSIX ones on POSIX platforms,
>and they would be implemented in libkrb5support otherwise.
Okay, that seems relatively straightforward. As far as I can tell
you can implement almost everything that the POSIX APIs do with
std::regex, and I believe that includes everything that Kerberos uses
those APIs for.
The only complication is that the compatibility layer I came up with
requires you to call regfree() on the regex_t structure if regcomp()
fails because there's no way of getting out a useful error otherwise and
it seems like some of the code (specifically stuff in localauth_rules.c)
doesn't do that (PKINIT does). I'm unclear from the description of the
regex POSIX API if you are supposed to do that or not (one document
I saw said that the return value of regex_t from regcomp()/regexec() on
error was undefined, but clearly they expected you to use it as you
can pass it into regerror()). Thinking about it ... that might be
fixable, let me think about it.
>> There is some support for older regular expression libraries that use
>> the functions compile() and re_comp().
>
>It looks like we used to have this for an2ln in 1.11, and I got rid of
>it for 1.12. Nobody has complained about it. So I think we can safely
>assume POSIX regex.h for Unix-like platforms, and expunge any
>compatibility code using older regex APIs.
I still see compatibility calls in:
src/lib/kadm5/srv/svr_iters.c
src/kadmin/dbutil/kdb5_mkey.c
src/kadmin/dbutil/dump.c
But as you note that compatibility layer got removed in other code a while
ago and nobody complained. Sounds like it can be garbage collected at
the same time.
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev