The following bug has been logged online:
Bug reference: 4363
Logged by: Dan Boeriu
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Redhat Linux
Description:ts_query bug
Details:
In 8.3.3
select to_tsquery('') is null returns false
and
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Actually, I had missed that the OP was looking at 7.3 rather than 8.3.
> There was a "verify_peer()" in 7.3 but it was #ifdef'd out. The
> question remains whether there's a reason to have it. It would be good
> if the discussion were based on a non-obsol
Dan Kaminsky <[EMAIL PROTECTED]> writes:
> My question has been: When you attempt to create an SSL connection to
> database.backend.com, do you actually validate that:
> 1) The subject name of the certificate you're connecting to is
> database.backend.com, and
> 2) At least the basic checks (ex
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Actually, I had missed that the OP was looking at 7.3 rather than 8.3.
There was a "verify_peer()" in 7.3 but it was #ifdef'd out. The
question remains whether there's a reason to have it. It would be good
if the discussion were
Tom Lane wrote:
Dan Kaminsky <[EMAIL PROTECTED]> writes:
My question has been: When you attempt to create an SSL connection to
database.backend.com, do you actually validate that:
1) The subject name of the certificate you're connecting to is
database.backend.com, and
2) At leas
Dan Kaminsky wrote:
>
>
> Tom Lane wrote:
>> Dan Kaminsky <[EMAIL PROTECTED]> writes:
>>
>>> My question has been: When you attempt to create an SSL connection
>>> to database.backend.com, do you actually validate that:
>>>
>>
>>
>>> 1) The subject name of the certificate you're connect
The following bug has been logged online:
Bug reference: 4364
Logged by: Alexander Kirpa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: FreeBSD 7.0
Description:type of "new.id" does not match that when preparing the
plan
Details:
After
Magnus Hagander <[EMAIL PROTECTED]> writes:
> (I don't believe OpenSSL does this verification either, because AFAICS
> OpenSSL only ever sees the IP address of the server, and not the FQDN)
In common usages libpq doesn't have the FQDN of the server either.
To impose such a requirement, we'd have t
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> (I don't believe OpenSSL does this verification either, because AFAICS
>> OpenSSL only ever sees the IP address of the server, and not the FQDN)
>
> In common usages libpq doesn't have the FQDN of the server either.
> To impose such
Dan Kaminsky wrote:
>
>
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>
>>> (I don't believe OpenSSL does this verification either, because AFAICS
>>> OpenSSL only ever sees the IP address of the server, and not the FQDN)
>>>
>>
>> In common usages libpq doesn't have th
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
(I don't believe OpenSSL does this verification either, because AFAICS
OpenSSL only ever sees the IP address of the server, and not the FQDN)
In common usages libpq doesn't have the FQDN of the server either.
To impose such
Dan Kaminsky wrote:
>
>>> Well, right now, SSL does nothing for you, so you have to do
>>> something. It's OK, SSL isn't doing a lot for a lot of people, but
>>> this is the
>>> beginning of us calling people out on that.
>>>
>>
>> Do feel free to explain how it "does nothing" for you with pr
Well, right now, SSL does nothing for you, so you have to do something.
It's OK, SSL isn't doing a lot for a lot of people, but this is the
beginning of us calling people out on that.
Do feel free to explain how it "does nothing" for you with properly set
up certificates (see my previous
On Tue, Aug 19, 2008 at 02:57:55PM -0400, Tom Lane wrote:
> To impose such a requirement, we'd have to forbid naming the server
> by IP address or via a domain-search-path abbreviation.
If you ask me, the second idea at least is a good one anyway. In an
SSL context, search paths are a terrible id
Good, then we're in agreement that far.
Cool!
(FWIW, I don't think I've ever seen a PostgreSQL server with a
certificate off a global root. I've seen plenty off a corporate root
though, which could in theory have similar issues - but at least you're
in control of your own problem in that c
Dan Kaminsky wrote:
>
>> Good, then we're in agreement that far.
>>
>>
> Cool!
>> (FWIW, I don't think I've ever seen a PostgreSQL server with a
>> certificate off a global root. I've seen plenty off a corporate root
>> though, which could in theory have similar issues - but at least you're
>>
1) No roots (but still works for some unknown reason)
2) Explicitly configured corporate roots
3) Explicitly configured corporate roots, AND global roots
4) Global roots (but still works for some unknown reason)
Keep in mind that at least Debian distributes a ca-certificates package,
and I can'
17 matches
Mail list logo
