We use autoconf for configure. I like the idea of using the thread-safe
crypt if available, though it does confuse things because it makes
thread-safeness contingent of SSL being installed. I question whether
it is just easier to say it isn't thread-safe because I am not sure how
someone is goi
This has been saved for the 7.3 release:
http://candle.pha.pa.us/cgi-bin/pgpatches2
---
Federico Di Gregorio wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Il ven, 2002-01-18
This has been saved for the 7.3 release:
http://candle.pha.pa.us/cgi-bin/pgpatches2
---
Mario Lorenz wrote:
> Tom,
>
> I originally worked with Federico to get the garbled passwords issue
> resolved which hit us
Tom,
I originally worked with Federico to get the garbled passwords issue
resolved which hit us (we use Psycopg, and Zope at work).
Federico's suggestion to use the crypt from libssl is incomplete,
and slightly wrong. The replacement function to use is des_fcrypt()
and it takes an additional ar
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, have we decided we don't want to ever bother making crypt
> > thread-safe? Is it a TODO item?
>
> I can't get excited about it. However, if Federico or someone else
> wants to do the work ...
OK, it gets on the TODO:
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> That is entirely the wrong place to put it. There is a section
> >> specifically about libpq's reentrancy or lack of it; mention the
> >> issue there.
>
> > Uh, I put it in this section:
>
> Um ... duh ... I ca
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, have we decided we don't want to ever bother making crypt
> thread-safe? Is it a TODO item?
I can't get excited about it. However, if Federico or someone else
wants to do the work ...
regards, tom lane
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> That is entirely the wrong place to put it. There is a section
> >> specifically about libpq's reentrancy or lack of it; mention the
> >> issue there.
>
> > Uh, I put it in this section:
>
> Um ... duh ... I ca
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That is entirely the wrong place to put it. There is a section
>> specifically about libpq's reentrancy or lack of it; mention the
>> issue there.
> Uh, I put it in this section:
Um ... duh ... I can only plead momentary brain fade.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, new text for docs.
>
> That is entirely the wrong place to put it. There is a section
> specifically about libpq's reentrancy or lack of it; mention the
> issue there.
Uh, I put it in this section:
Thr
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > As of 7.2 we are only going to recommend crypt for backward
> > compatibility with older releases. I will add a mention in libpq docs
> > that crypt authentication is not thread-safe. Even when crypt did work
> ^^
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > As of 7.2 we are only going to recommend crypt for backward
> > compatibility with older releases. I will add a mention in libpq docs
> > that crypt authentication is not thread-safe. Even when crypt did work
> ^^
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, new text for docs.
That is entirely the wrong place to put it. There is a section
specifically about libpq's reentrancy or lack of it; mention the
issue there.
regards, tom lane
---(end of broadcast
Bruce Momjian writes:
> As of 7.2 we are only going to recommend crypt for backward
> compatibility with older releases. I will add a mention in libpq docs
> that crypt authentication is not thread-safe. Even when crypt did work
^^
"may not be"
> it wasn't alway
Tom Lane writes:
> Well, the lack of any man page for crypt_r on Linux doesn't give me a
> warm feeling about its level of supportedness there.
Tom, the man pages on Linux are completely worthless. If you want to get
authorative information about what a function does and how it behaves, you
nee
Il ven, 2002-01-18 alle 18:23, Tom Lane ha scritto:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As of 7.2 we are only going to recommend crypt for backward
> > compatibility with older releases. I will add a mention in libpq docs
> > that crypt authentication is not thread-safe. Even when cr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As of 7.2 we are only going to recommend crypt for backward
> compatibility with older releases. I will add a mention in libpq docs
> that crypt authentication is not thread-safe. Even when crypt did work
> it wasn't always portable between OS's. Is t
> So right off the bat, configure is going to have a task guessing
> the correct type of the third argument to crypt_r. (Who knows what
> it is on other Unixen...)
>
> Given that as of 7.2, MD5 is the preferred password encryption method
> and crypt() is deprecated, I'm not inclined to spend a l
Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> so the right library is already detected. the function is called
> des_crypt and is completely compatible with std. i think that a
> AC_SEARCH_LIBS(crypto, des_crypt)
> in configure.in will suffice. then:
> #ifdef HAVE_DES_CRYPT
> #defin
Il ven, 2002-01-18 alle 16:35, Tom Lane ha scritto:
> Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> >> Given that as of 7.2, MD5 is the preferred password encryption method
> >> and crypt() is deprecated, I'm not inclined to spend a lot of work
> >> trying to develop a bulletproof autoconf pr
Federico Di Gregorio <[EMAIL PROTECTED]> writes:
>> Given that as of 7.2, MD5 is the preferred password encryption method
>> and crypt() is deprecated, I'm not inclined to spend a lot of work
>> trying to develop a bulletproof autoconf procedure for making crypt
>> re-entrant. I'm strongly inclin
Il ven, 2002-01-18 alle 16:21, Tom Lane ha scritto:
> So right off the bat, configure is going to have a task guessing
> the correct type of the third argument to crypt_r. (Who knows what
> it is on other Unixen...)
very bad, indeed. i think i'll solve that (on my side) by adding a
configure opt
Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> i can see ./configure trying to find a reentrant crypt and revert to a
> not-reentrant one only as a last resort.
Well, the lack of any man page for crypt_r on Linux doesn't give me a
warm feeling about its level of supportedness there. crypt_r(
Il ven, 2002-01-18 alle 15:59, Tom Lane ha scritto:
> Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> > libpq claims to be reentrant; to put it shortly it isn't. the problem
> > arise when using crypt authentication. on the Linux/glibc2 arch, the
> > call to crypt() is not reentrant and crypt_r
Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> libpq claims to be reentrant; to put it shortly it isn't. the problem
> arise when using crypt authentication. on the Linux/glibc2 arch, the
> call to crypt() is not reentrant and crypt_r or DES/libcrypto crypt
> should be used instead.
Hmm. Goo
hi,
this is my first post here and i don't know if there is a specific way
to report a postgresql bug apart from a 'plain' meil to this list.
anyway, here it is.
libpq claims to be reentrant; to put it shortly it isn't. the problem
arise when using crypt authentication. on the Linux/glibc2 arch,
26 matches
Mail list logo
