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'
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
>>
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
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
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
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
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
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
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
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
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
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
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
"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
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
17 matches
Mail list logo
