Menu
▾
▴
perl-ldap-dev
|
From: David B. <d.b...@ma...> - 2001-07-04 00:18:57
|
Of course, the easiest way to do a password compare without having to
worry about the encoding, or UTF, or any other directory specific stuff is
to try doing a bind as that user.
If you can bind, then the password was OK.
Isn't that easier than the other options given?
David.
"Odell, Chauncey (Dyncorp)" <COd...@DT...>
Sent by: per...@li...
07/04/01 05:24 AM
To: "'per...@li...'"
<per...@li...>
cc:
Subject: userpassword
I found in the archives from last August (with slight modification to
protect the fish)
================
to do a compare:
use Net::LDAP::Constant;
$mesg = $ldap->compare($dn,"userpassword",_properly_encoded_password);
if ($mesg->code() == LDAP_COMPARE_TRUE)
{
auth success
}
==================
I assume that '_properly_encoded_password' is the encripted password held
by
the directory server because
the plain text password does not provide LDAP_COMPARE_TRUE.
Is it possible to obtain username / password validation using perl-ldap if
I
have the plain text password.
I can use normal prompt for user / password for the CGI portion of my
program, but I also need to validate the user as part of a daemon request.
My security folks feel that passing the encripted password to the daemon
only proves that I was able to access the directory server and ask for the
encripted password.
Thanks,
chauncey
|
|
From: Chris R. <chr...@me...> - 2001-07-04 08:12:37
|
David Bussenschutt <d.b...@ma...> wrote: > Of course, the easiest way to do a password compare without having to > worry about the encoding, or UTF, or any other directory specific stuff > is to try doing a bind as that user. > If you can bind, then the password was OK. > Isn't that easier than the other options given? Yes and no. When you send a bind to the server, internally it issues a compare operation against the userPassword attribute etc, so bind and compare should basically both work and fail identically when given the same input. The reason you might want to use compare instead of bind is because some servers will close the TCP connection when you unbind, which is a pain if you're trying to have your authentication code embedded in a long lived process, eg mod_perl. Also of course, it might be possible to bind as the manager of the server and then bind as user 'A', but not bind as user 'A' and then bind as user 'B' due to access controls. For a short-lived CGI script you can get away with creating a connection and doing a bind over it, but for a long-lived embedded script you want to keep the connection open as long as possible and therefore should bind once as the manager (or something equivalent) and then issue compare operations on demand. > David. > I assume that '_properly_encoded_password' is the encripted password held > by > the directory server because > the plain text password does not provide LDAP_COMPARE_TRUE. > > Is it possible to obtain username / password validation using perl-ldap > if I > have the plain text password. > I can use normal prompt for user / password for the CGI portion of my > program, but I also need to validate the user as part of a daemon request. > My security folks feel that passing the encripted password to the daemon > only proves that I was able to access the directory server and ask for the > encripted password. That is true, if the hash algorithm used doesn't use any 'salt'. For example a password hashed using SHA-1 or MD5 will always hash to the same value, but a password hashed using the traditional Unix crypt algorithm will hash to different values each time because of the extra randomness stirred in by the algorithm. If the server is storing hashed passwords, you should be binding/comparing with the plain text passwords. Consider using LDAPS or LDAPv3 startTLS if you want to prevent people from sniffing those passwords on your network. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-07-04 08:40:47
|
On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote: > If the server is storing hashed passwords, you should be binding/comparing > with the plain text passwords. Consider using LDAPS or LDAPv3 startTLS if > you want to prevent people from sniffing those passwords on your network. This reminds me. What needs to be done for Net::LDAP to support startTLS ? Graham. |
|
From: Chris R. <chr...@me...> - 2001-07-04 08:58:54
|
Graham Barr <gb...@po...> wrote: > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote: >> If the server is storing hashed passwords, you should be >> binding/comparing with the plain text passwords. Consider using LDAPS or >> LDAPv3 startTLS if you want to prevent people from sniffing those >> passwords on your network. > > This reminds me. What needs to be done for Net::LDAP to support startTLS ? > > Graham. IIRC, IO::Socket::SSL needs to support send() and recv(), which I imagined would mean it (and by extension Net::SSLeay) needed rewriting to use openssl's non-blocking I/O. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-07-04 09:05:32
|
On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote: > >> If the server is storing hashed passwords, you should be > >> binding/comparing with the plain text passwords. Consider using LDAPS or > >> LDAPv3 startTLS if you want to prevent people from sniffing those > >> passwords on your network. > > > > This reminds me. What needs to be done for Net::LDAP to support startTLS ? > > > > Graham. > > IIRC, IO::Socket::SSL needs to support send() and recv(), which I imagined > would mean it (and by extension Net::SSLeay) needed rewriting to use > openssl's non-blocking I/O. Is this because Net::LDAP currently uses send() and recv() ? If so I am planning to change that so that Net::LDAPS does not need its own _sendmesg. I am also going to split the actual connect out out new(), so Net::LDAPS will not need to duplicate that, but just provide a connect sub. Is the Net::LDAPS in CVS upto date ? Graham. |
|
From: Chris R. <chr...@me...> - 2001-07-04 09:27:05
|
Graham Barr <gb...@po...> wrote: > On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote: >> >> If the server is storing hashed passwords, you should be >> >> binding/comparing with the plain text passwords. Consider using LDAPS >> >> or LDAPv3 startTLS if you want to prevent people from sniffing those >> >> passwords on your network. >> > >> > This reminds me. What needs to be done for Net::LDAP to support >> > startTLS ? >> > >> > Graham. >> >> IIRC, IO::Socket::SSL needs to support send() and recv(), which I >> imagined would mean it (and by extension Net::SSLeay) needed rewriting >> to use openssl's non-blocking I/O. > > Is this because Net::LDAP currently uses send() and recv() ? Yes. I thought it was doing that in case we wanted to support CLDAP (a version of LDAP over UDP) at some point. > If so I am planning to change that so that Net::LDAPS does not > need its own _sendmesg. That would be good. > I am also going to split the actual connect out out new(), so Net::LDAPS > will not need to duplicate that, but just provide a connect sub. That sounds sensible. > Is the Net::LDAPS in CVS upto date ? Yes. > Graham. > Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-07-04 09:37:00
|
On Wed, Jul 04, 2001 at 10:26:50AM +0100, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote: > >> Graham Barr <gb...@po...> wrote: > >> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote: > >> IIRC, IO::Socket::SSL needs to support send() and recv(), which I > >> imagined would mean it (and by extension Net::SSLeay) needed rewriting > >> to use openssl's non-blocking I/O. > > > > Is this because Net::LDAP currently uses send() and recv() ? > > Yes. I thought it was doing that in case we wanted to support CLDAP (a > version of LDAP over UDP) at some point. There are always other ways to solve that. And right now I would rather support LDAPS than CLDAP > > Is the Net::LDAPS in CVS upto date ? > > Yes. OK, I will make the changes. Graham. |
|
From: Graham B. <gb...@po...> - 2001-07-04 12:00:51
|
On Wed, Jul 04, 2001 at 10:35:11AM +0100, Graham Barr wrote:
> On Wed, Jul 04, 2001 at 10:26:50AM +0100, Chris Ridd wrote:
> > Graham Barr <gb...@po...> wrote:
> > > On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote:
> > >> Graham Barr <gb...@po...> wrote:
> > >> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
> > >> IIRC, IO::Socket::SSL needs to support send() and recv(), which I
> > >> imagined would mean it (and by extension Net::SSLeay) needed rewriting
> > >> to use openssl's non-blocking I/O.
> > >
> > > Is this because Net::LDAP currently uses send() and recv() ?
> >
> > Yes. I thought it was doing that in case we wanted to support CLDAP (a
> > version of LDAP over UDP) at some point.
>
> There are always other ways to solve that. And right now I would
> rather support LDAPS than CLDAP
>
> > > Is the Net::LDAPS in CVS upto date ?
> >
> > Yes.
>
> OK, I will make the changes.
OK, I have commited the changes to CVS, please check that I have not broken
Net::LDAPS
It seems to ne we can add this to Net::LDAP
sub start_tls {
my $ldap = shift;
require IO::Socket::SSL;
IO::Socket::SSL::startTLS($ldap->socket);
}
yes ?
Graham.
|
|
From: Chris R. <chr...@me...> - 2001-07-05 18:59:55
|
Graham Barr <gb...@po...> wrote:
> On Wed, Jul 04, 2001 at 10:35:11AM +0100, Graham Barr wrote:
>> On Wed, Jul 04, 2001 at 10:26:50AM +0100, Chris Ridd wrote:
>> > Graham Barr <gb...@po...> wrote:
>> > > On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote:
>> > >> Graham Barr <gb...@po...> wrote:
>> > >> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
>> > >> IIRC, IO::Socket::SSL needs to support send() and recv(), which I
>> > >> imagined would mean it (and by extension Net::SSLeay) needed
>> > >> rewriting to use openssl's non-blocking I/O.
>> > >
>> > > Is this because Net::LDAP currently uses send() and recv() ?
>> >
>> > Yes. I thought it was doing that in case we wanted to support CLDAP (a
>> > version of LDAP over UDP) at some point.
>>
>> There are always other ways to solve that. And right now I would
>> rather support LDAPS than CLDAP
>>
>> > > Is the Net::LDAPS in CVS upto date ?
>> >
>> > Yes.
>>
>> OK, I will make the changes.
>
> OK, I have commited the changes to CVS, please check that I have not
> broken Net::LDAPS
Minor damage: you need to create an IO::Socket::SSL instead of an
IO::Socket::INET in the new _connect method in LDAPS.pm :-)
> It seems to ne we can add this to Net::LDAP
>
> sub start_tls {
> my $ldap = shift;
>
> require IO::Socket::SSL;
> IO::Socket::SSL::startTLS($ldap->socket);
> }
>
> yes ?
>
>
> Graham.
Not quite. You need to issue an extended LDAP operation to indicate you're
going to start the TLS handshake, so it needs to be something like this:
sub startTLS {
my $ldap = shift;
my $args = &_options;
if ($ldap->version < 3) {
require Carp;
Carp::croak("StartTLS not supported before LDAPv3");
}
require Net::LDAP::Extension;
my $mesg = Net::LDAP::Extension->new($ldap);
$mesg->encode(
extendedReq => {
requestName => "1.3.6.1.4.1.1466.20037",
}
);
$ldap->_sendmesg($mesg);
$mesg->sync();
if ($mesg->code) {
require Carp;
Carp::croak("LDAP_OPERATIONS_ERROR $@");
}
require IO::Socket::SSL;
IO::Socket::SSL::context_init($args);
IO::Socket::SSL::socketToSSL($ldap->socket);
}
*However* that returns an I/O error when you next try to call _sendmesg on
the socket, even though the socket looks OK:
DB<1> x $ldap->socket
0 IO::Socket::SSL=GLOB(0x866b998)
-> *Symbol::GEN0
FileHandle({*Symbol::GEN0}) => fileno(3)
... same fd as before the socketToSSL, which is good.
The mechanism to select the ciphers and verify mode etc need some
improvement too - perhaps the logic in Net::LDAPS to set this stuff should
go into LDAP.pm
I'm not sure calling context_init() is the right thing to do here either;
it looks awfully 'global' in scope.
We should also override startTLS in LDAPS to prevent someone from calling
it on an LDAPS socket :-)
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-07-05 18:59:18
|
On Thu, Jul 05, 2001 at 12:00:12PM +0100, Chris Ridd wrote:
> > OK, I have commited the changes to CVS, please check that I have not
> > broken Net::LDAPS
>
> Minor damage: you need to create an IO::Socket::SSL instead of an
> IO::Socket::INET in the new _connect method in LDAPS.pm :-)
Whoops :)
> Not quite. You need to issue an extended LDAP operation to indicate you're
> going to start the TLS handshake, so it needs to be something like this:
>
> sub startTLS {
I would rather stick to the same name convention as the rest of the module
and have start_tls
> my $ldap = shift;
> my $args = &_options;
> if ($ldap->version < 3) {
> require Carp;
> Carp::croak("StartTLS not supported before LDAPv3");
> }
> require Net::LDAP::Extension;
> my $mesg = Net::LDAP::Extension->new($ldap);
> $mesg->encode(
> extendedReq => {
> requestName => "1.3.6.1.4.1.1466.20037",
> }
> );
> $ldap->_sendmesg($mesg);
> $mesg->sync();
> if ($mesg->code) {
> require Carp;
> Carp::croak("LDAP_OPERATIONS_ERROR $@");
> }
> require IO::Socket::SSL;
> IO::Socket::SSL::context_init($args);
> IO::Socket::SSL::socketToSSL($ldap->socket);
> }
>
> *However* that returns an I/O error when you next try to call _sendmesg on
> the socket, even though the socket looks OK:
>
> DB<1> x $ldap->socket
> 0 IO::Socket::SSL=GLOB(0x866b998)
> -> *Symbol::GEN0
> FileHandle({*Symbol::GEN0}) => fileno(3)
>
> ... same fd as before the socketToSSL, which is good.
Yes, looking at the code they just re-bless the given socket.
> The mechanism to select the ciphers and verify mode etc need some
> improvement too - perhaps the logic in Net::LDAPS to set this stuff should
> go into LDAP.pm
>
> I'm not sure calling context_init() is the right thing to do here either;
> it looks awfully 'global' in scope.
>
> We should also override startTLS in LDAPS to prevent someone from calling
> it on an LDAPS socket :-)
Right.
Graham.
|
|
From: Graham B. <gb...@po...> - 2001-07-05 21:20:12
|
On Thu, Jul 05, 2001 at 12:12:04PM +0100, Graham Barr wrote:
> > *However* that returns an I/O error when you next try to call _sendmesg on
> > the socket, even though the socket looks OK:
> >
> > DB<1> x $ldap->socket
> > 0 IO::Socket::SSL=GLOB(0x866b998)
> > -> *Symbol::GEN0
> > FileHandle({*Symbol::GEN0}) => fileno(3)
> >
> > ... same fd as before the socketToSSL, which is good.
I have solve it. socketToSSL does not tie the socket to the IO::Socket::SSL package.
Adding that then it works.
I will commit what I have to CVS
Graham.
|
|
From: Chris R. <chr...@me...> - 2001-07-06 09:25:22
|
Graham Barr <gb...@po...> wrote:
> On Thu, Jul 05, 2001 at 12:12:04PM +0100, Graham Barr wrote:
>> > *However* that returns an I/O error when you next try to call
>> > _sendmesg on the socket, even though the socket looks OK:
>> >
>> > DB<1> x $ldap->socket
>> > 0 IO::Socket::SSL=GLOB(0x866b998)
>> > -> *Symbol::GEN0
>> > FileHandle({*Symbol::GEN0}) => fileno(3)
>> >
>> > ... same fd as before the socketToSSL, which is good.
>
> I have solve it. socketToSSL does not tie the socket to the
> IO::Socket::SSL package. Adding that then it works.
Confirmed here. Hurray! Are you going to send that bug fix back to Marko?
> I will commit what I have to CVS
>
> Graham.
I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I just
copied the documentation across because I thought it was still useful to
see directly on the LDAPS page.
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-07-06 10:09:16
|
On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Thu, Jul 05, 2001 at 12:12:04PM +0100, Graham Barr wrote:
> >> > *However* that returns an I/O error when you next try to call
> >> > _sendmesg on the socket, even though the socket looks OK:
> >> >
> >> > DB<1> x $ldap->socket
> >> > 0 IO::Socket::SSL=GLOB(0x866b998)
> >> > -> *Symbol::GEN0
> >> > FileHandle({*Symbol::GEN0}) => fileno(3)
> >> >
> >> > ... same fd as before the socketToSSL, which is good.
> >
> > I have solve it. socketToSSL does not tie the socket to the
> > IO::Socket::SSL package. Adding that then it works.
>
> Confirmed here. Hurray! Are you going to send that bug fix back to Marko?
Yes.
> > I will commit what I have to CVS
> >
> > Graham.
>
> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I just
> copied the documentation across because I thought it was still useful to
> see directly on the LDAPS page.
OK, great.
Graham.
|
|
From: Graham B. <gb...@po...> - 2001-07-06 10:13:11
|
On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I just
> copied the documentation across because I thought it was still useful to
> see directly on the LDAPS page.
I see you have overridded start_tls in LDAPS with a croak.
I want to avoid croaks if we can. We could just return a sucess
as afterall we are already using SSL.
This check really needs to go into Net::LDAP, as what should happen
if start_tls is called twice ?
I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')
Graham.
|
|
From: Chris R. <chr...@me...> - 2001-07-06 11:12:26
|
Graham Barr <gb...@po...> wrote:
> On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
>> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I
>> just copied the documentation across because I thought it was still
>> useful to see directly on the LDAPS page.
>
> I see you have overridded start_tls in LDAPS with a croak.
>
> I want to avoid croaks if we can. We could just return a sucess
> as afterall we are already using SSL.
>
> This check really needs to go into Net::LDAP, as what should happen
> if start_tls is called twice ?
>
> I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')
>
> Graham.
>
That makes more sense. Does the attached patch look any better?
It also changes the default values for cafile and capath to '', which is
required for versions of IO::Socket::SSL since 0.78. I've tested using both
cafile and capath options, and without this change using capath fails.
(We should incidentally require at least this version of IO::Socket::SSL in
Makefile.PL.)
Cheers,
Chris |
|
From: Graham B. <gb...@po...> - 2001-07-06 11:44:11
|
On Fri, Jul 06, 2001 at 12:12:13PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
> >> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I
> >> just copied the documentation across because I thought it was still
> >> useful to see directly on the LDAPS page.
> >
> > I see you have overridded start_tls in LDAPS with a croak.
> >
> > I want to avoid croaks if we can. We could just return a sucess
> > as afterall we are already using SSL.
> >
> > This check really needs to go into Net::LDAP, as what should happen
> > if start_tls is called twice ?
> >
> > I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')
> >
> > Graham.
> >
>
> That makes more sense. Does the attached patch look any better?
Actually I have made it return an error. I checked what openldap did if
you called start_tls twice, it returned an error (which was expected)
Note start_tls returns a message object, from the extension call.
> It also changes the default values for cafile and capath to '', which is
> required for versions of IO::Socket::SSL since 0.78. I've tested using both
> cafile and capath options, and without this change using capath fails.
OK, I will change those.
> (We should incidentally require at least this version of IO::Socket::SSL in
> Makefile.PL.)
We should check, but I am not sure about require.
Graham.
|
|
From: Chris R. <chr...@me...> - 2001-07-06 12:03:32
|
Graham Barr <gb...@po...> wrote:
> On Fri, Jul 06, 2001 at 12:12:13PM +0100, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
>> >> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I
>> >> just copied the documentation across because I thought it was still
>> >> useful to see directly on the LDAPS page.
>> >
>> > I see you have overridded start_tls in LDAPS with a croak.
>> >
>> > I want to avoid croaks if we can. We could just return a sucess
>> > as afterall we are already using SSL.
>> >
>> > This check really needs to go into Net::LDAP, as what should happen
>> > if start_tls is called twice ?
>> >
>> > I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')
>> >
>> > Graham.
>> >
>>
>> That makes more sense. Does the attached patch look any better?
>
> Actually I have made it return an error. I checked what openldap did if
> you called start_tls twice, it returned an error (which was expected)
>
> Note start_tls returns a message object, from the extension call.
>
>> It also changes the default values for cafile and capath to '', which is
>> required for versions of IO::Socket::SSL since 0.78. I've tested using
>> both cafile and capath options, and without this change using capath
>> fails.
>
> OK, I will change those.
>
>> (We should incidentally require at least this version of IO::Socket::SSL
>> in Makefile.PL.)
>
> We should check, but I am not sure about require.
> Graham.
>
The setting of capth/cafile to '' instead of undef is required by 0.78. Hm,
we could make our code check the IO::Socket::SSL version and set the
defaults appropriately...
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-07-06 12:09:58
|
On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote: > The setting of capth/cafile to '' instead of undef is required by 0.78. Hm, > we could make our code check the IO::Socket::SSL version and set the > defaults appropriately... Hm, I have o.78 here and it works fine with undef or '' Graham. |
|
From: Chris R. <chr...@me...> - 2001-07-06 12:36:04
|
Graham Barr <gb...@po...> wrote: > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote: >> The setting of capth/cafile to '' instead of undef is required by 0.78. >> Hm, we could make our code check the IO::Socket::SSL version and set the >> defaults appropriately... > > Hm, I have o.78 here and it works fine with undef or '' > > Graham. You have to actually try verifying a server's cert using capath to see this problem. With verify => require, capath => "/tmp/certs" and cafile defaulting to undef the socket creation fails silently (new returns undef and there's nothing in $@), and strace reveals something attempting to open "certs/my-ca.pem", which is one of IO::Socket::SSL.pm's defaults. With cafile defaulting to '' and everything else the same, the socket gets created OK. (I had my CA cert in /tmp/certs of course.) So I'm fairly sure that undef does not work in 0.78. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-07-06 13:03:59
|
On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote: > >> The setting of capth/cafile to '' instead of undef is required by 0.78. > >> Hm, we could make our code check the IO::Socket::SSL version and set the > >> defaults appropriately... > > > > Hm, I have o.78 here and it works fine with undef or '' > > > > Graham. > > You have to actually try verifying a server's cert using capath to see this > problem. Ah, that would explain it. Graham. |
|
From: Chris R. <chr...@me...> - 2001-07-06 13:17:15
|
Graham Barr <gb...@po...> wrote: > On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote: >> >> The setting of capth/cafile to '' instead of undef is required by >> >> 0.78. Hm, we could make our code check the IO::Socket::SSL version >> >> and set the defaults appropriately... >> > >> > Hm, I have o.78 here and it works fine with undef or '' >> > >> > Graham. >> >> You have to actually try verifying a server's cert using capath to see >> this problem. > > Ah, that would explain it. > > Graham. Would this patch be appropriate? Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-07-06 13:32:15
|
On Fri, Jul 06, 2001 at 02:17:03PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote:
> >> Graham Barr <gb...@po...> wrote:
> >> > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote:
> >> >> The setting of capth/cafile to '' instead of undef is required by
> >> >> 0.78. Hm, we could make our code check the IO::Socket::SSL version
> >> >> and set the defaults appropriately...
> >> >
> >> > Hm, I have o.78 here and it works fine with undef or ''
> >> >
> >> > Graham.
> >>
> >> You have to actually try verifying a server's cert using capath to see
> >> this problem.
> >
> > Ah, that would explain it.
> >
> > Graham.
>
> Would this patch be appropriate?
Yes. But it seems Marcus is going to release a new IO::Socket::SSL with my fix.
So rather than fill with version comparisons, I was thinking of the Makefile.PL
warning if the version was < 0.80
What do you think ?
Graham.
>
> Cheers,
>
> Chris
> Index: lib/Net/LDAPS.pm
> ===================================================================
> RCS file: /cvsroot/perl-ldap/ldap/lib/Net/LDAPS.pm,v
> retrieving revision 1.8
> diff -b -c -r1.8 LDAPS.pm
> *** lib/Net/LDAPS.pm 2001/07/06 11:53:01 1.8
> --- lib/Net/LDAPS.pm 2001/07/06 13:15:35
> ***************
> *** 49,56 ****
>
> (
> SSL_cipher_list => defined $arg->{'ciphers'} ? $arg->{'ciphers'} :
> 'ALL',
> ! SSL_ca_file => exists $arg->{'cafile'} ? $arg->{'cafile'} : '',
> ! SSL_ca_path => exists $arg->{'capath'} ? $arg->{'capath'} : '',
> SSL_key_file => $clientcert ? $clientkey : undef,
> SSL_use_cert => $clientcert ? 1 : 0,
> SSL_cert_file => $clientcert,
> --- 49,58 ----
>
> (
> SSL_cipher_list => defined $arg->{'ciphers'} ? $arg->{'ciphers'} :
> 'ALL',
> ! SSL_ca_file => exists $arg->{'cafile'} ? $arg->{'cafile'} :
> ! ($IO::Socket::SSL::VERSION >= "0.78" ? '' : undef),
> ! SSL_ca_path => exists $arg->{'capath'} ? $arg->{'capath'} :
> ! ($IO::Socket::SSL::VERSION >= "0.78" ? '' : undef),
> SSL_key_file => $clientcert ? $clientkey : undef,
> SSL_use_cert => $clientcert ? 1 : 0,
> SSL_cert_file => $clientcert,
|
|
From: Graham B. <gb...@po...> - 2001-07-06 13:34:04
|
On Fri, Jul 06, 2001 at 02:30:34PM +0100, Graham Barr wrote: > Yes. But it seems Marcus is going to release a new IO::Socket::SSL with my fix. > > So rather than fill with version comparisons, I was thinking of the Makefile.PL > warning if the version was < 0.80 > > What do you think ? That would mean changing Net::LDAPS to have use IO::Socket::SSL 0.80; which would cause it to die id they have a lower version. Graham. |
|
From: Chris R. <chr...@me...> - 2001-07-06 13:40:50
|
Graham Barr <gb...@po...> wrote: > On Fri, Jul 06, 2001 at 02:17:03PM +0100, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote: >> >> Graham Barr <gb...@po...> wrote: >> >> > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote: >> >> >> The setting of capth/cafile to '' instead of undef is required by >> >> >> 0.78. Hm, we could make our code check the IO::Socket::SSL version >> >> >> and set the defaults appropriately... >> >> > >> >> > Hm, I have o.78 here and it works fine with undef or '' >> >> > >> >> > Graham. >> >> >> >> You have to actually try verifying a server's cert using capath to see >> >> this problem. >> > >> > Ah, that would explain it. >> > >> > Graham. >> >> Would this patch be appropriate? > > Yes. But it seems Marcus is going to release a new IO::Socket::SSL with > my fix. > > So rather than fill with version comparisons, I was thinking of the > Makefile.PL warning if the version was < 0.80 > > What do you think ? > > Graham. Yes, I'm happy with that and for adding "use IO::Socket::SSL 0.80". We probably want to wait until he's actually released 0.80 to make sure it works correctly with perl-ldap, in case there are nasty surprises. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-07-06 13:44:33
|
On Fri, Jul 06, 2001 at 02:40:33PM +0100, Chris Ridd wrote: > Yes, I'm happy with that and for adding "use IO::Socket::SSL 0.80". We > probably want to wait until he's actually released 0.80 to make sure it > works correctly with perl-ldap, in case there are nasty surprises. Sure, but I can send you a copy :) Graham. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X