Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Date: 2008-11-24 14:55:17
Message-ID: 492AC055.8090605@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>>> ... The other option is to have
>>>> autoconf substitute our own local version of fnmatch when this happens.
>>>> How would one go about to do that in autoconf asks the autoconf n00b?
>>> I'd try adding a little test program that tries to compile
>>>
>>> #include <fnmatch.h>
>>> ...
>>> n = fnmatch("foo","bar", FNM_CASEFOLD);
>>>
>>> and see if that succeeds.
>>>
>>> For extra credit, incorporate that into a new PGAC_FUNC_FNMATCH macro,
>>> but I think you'd need to get Peter's help on the details --- I'm just
>>> a duffer on autoconf myself.
>>
>> Yeah, likely that someone who knows this will make it happen a lot
>> faster.
>>
>> Peter, got time to help me out with this? Thanks!
>
> Well, FNM_CASEFOLD is not POSIX, and Autoconf thinks it's a GNU
> extension, which has obviously crept into other systems. So you'd need
> to use AC_FUNC_FNMATCH_GNU, but that also requires you to use the GNU
> replacement implementation. (A bit stupid, but then again, if you are
> trying to use GNU features, whose replacement implementation are you
> going to use.)

Meh, I looked at that, and considered having to implement it the GNU way
was bad. Since we can't just import the GNU sourcecode.

> If you google for FNM_CASEFOLD, you will get about a million hits of
> other open-source projects having run into this same issue.
>
> Then again, having looked into the libpq source now, is using fnmatch()
> even appropriate here? The matching rules for https are in RFC 2818:
>
> Matching is performed using the matching rules specified by
> [RFC2459]. If more than one identity of a given type is present in
> the certificate (e.g., more than one dNSName name, a match in any one
> of the set is considered acceptable.) Names may contain the wildcard
> character * which is considered to match any single domain name
> component or component fragment. E.g., *.a.com matches foo.a.com but
> not bar.foo.a.com. f*.com matches foo.com but not bar.com.
>
> Using fnmatch(), however, will also treat ? and [] special and it will
> not follow the "any single domain name component" rule.

Grr. I didn't find that RFC when I was googling around for the rules.
Must've been a bad-google-day for me. And that does *not* match what I
found on a couple of SSL-certificate-selling-websites that told you how
it worked :-(

I guess it's back to the drawingboard. Can probably still base it on the
fnmatch stuff, but it'll need to be ripped apart. Basically, it should
match only with *, and * should not match "." - do you agree that's a
reasonable interpretation?

//Magnus

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2008-11-24 15:11:25 Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Previous Message Peter Eisentraut 2008-11-24 14:40:00 Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-11-24 15:00:42 Re: [PATCHES] Solve a problem of LC_TIME of windows.
Previous Message Magnus Hagander 2008-11-24 14:55:09 Re: [PATCHES] Solve a problem of LC_TIME of windows.