Critical Bug in Net::LDAP v0.35

I have discovered a critical bug in Net::LDAP 0.35 and submitted the
following ticket:
http://rt.cpan.org/Ticket/Display.html?id=34878

In 0.35, the Net::Ldap::Util::ldap_error_name subroutine is broken which
means that all functions such as Net::LDAP->code() that return a message
as a constant are broken.

Instead of returning the correct message, Password Policy (PP) constants
are being returned instead.

The most crucial example is that a successful bind or search is
returning LDAP_PP_PASSWORD_EXPIRED (0) instead of LDAP_SUCCESS (0). You
can code around this failure by using resultCode() instead to get the
integer form of the result code, however all current perl modules that
determine results by using the constant names will function unexpectedly.

Please advise me *quickly* if you think for any reason that I have the 
wrong end of the stick here, but having passed it by a few colleagues 
I'm pretty damn sure this is a bug and a critical one.
-- 
Kind Regards,

__________________________________________________

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com
__________________________________________________

0
mike
4/11/2008 3:03:12 PM
perl.ldap 1268 articles. 0 followers. Follow

5 Replies
641 Views

Similar Articles

[PageSpeed] 44
Get it on Google Play
Get it on Apple App Store

--Boundary-00=_32iBIIdqQhG3blX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Mike,

On Friday, 11. April 2008, Mike Peachey wrote:
> I have discovered a critical bug in Net::LDAP 0.35 and submitted the
> following ticket:
> http://rt.cpan.org/Ticket/Display.html?id=34878
>
> In 0.35, the Net::Ldap::Util::ldap_error_name subroutine is broken which
> means that all functions such as Net::LDAP->code() that return a message
> as a constant are broken.
>
> Instead of returning the correct message, Password Policy (PP) constants
> are being returned instead.
>
> The most crucial example is that a successful bind or search is
> returning LDAP_PP_PASSWORD_EXPIRED (0) instead of LDAP_SUCCESS (0). You
> can code around this failure by using resultCode() instead to get the
> integer form of the result code, however all current perl modules that
> determine results by using the constant names will function unexpectedly.
>
> Please advise me *quickly* if you think for any reason that I have the
> wrong end of the stick here, but having passed it by a few colleagues
> I'm pretty damn sure this is a bug and a critical one.

You are right, this is a bug.

I committed a patch to perl-ldap-SVN to fix it.
For you convenience I also append it to this posting.

Please test and report back.

CU
PEter

-- 
Peter Marschall
peter@adpm.de

--Boundary-00=_32iBIIdqQhG3blX
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="Net-LDAP-Constant.pm.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Net-LDAP-Constant.pm.patch"

--- Constant.pm	(revision 549)
+++ Constant.pm	(working copy)
@@ -135,60 +135,32 @@
 
 Operation completed without error
 
-=item LDAP_PP_PASSWORD_EXPIRED (0)
-
-The account's password has expired.
-
 =item LDAP_OPERATIONS_ERROR (1)
 
 Server encountered an internal error
 
-=item LDAP_PP_ACCOUNT_LOCKED (1)
-
-The account is locked.
-
 =item LDAP_PROTOCOL_ERROR (2)
 
 Unrecognized version number or incorrect PDU structure
 
-=item LDAP_PP_CHANGE_AFTER_RESET (2)
-
-The account's password has been reset and now must be changed.
-
 =item LDAP_TIMELIMIT_EXCEEDED (3)
 
 The time limit on a search operation has been exceeded
 
-=item LDAP_PP_PASSWORD_MOD_NOT_ALLOWED (3)
-
-The account's password may not be modified.
-
 =item LDAP_SIZELIMIT_EXCEEDED (4)
 
 The maximum number of search results to return has been exceeded.
 
-=item LDAP_PP_MUST_SUPPLY_OLD_PASSWORD (4)
-
-The old password must also be supplied when setting a new password.
-
 =item LDAP_COMPARE_FALSE (5)
 
 This code is returned when a compare request completes and the attribute value
 given is not in the entry specified
 
-=item LDAP_PP_INSUFFICIENT_PASSWORD_QUALITY (5)
-
-The new password was not of sufficient quality.
-
 =item LDAP_COMPARE_TRUE (6)
 
 This code is returned when a compare request completes and the attribute value
 given is in the entry specified
 
-=item LDAP_PP_PASSWORD_TOO_SHORT (6)
-
-The new password was too short.
-
 =item LDAP_AUTH_METHOD_NOT_SUPPORTED (7)
 
 Unrecognized SASL mechanism name
@@ -197,18 +169,10 @@
 
 Unrecognized SASL mechanism name
 
-=item LDAP_PP_PASSWORD_TOO_YOUNG (7)
-
-The previous password was changed too recently.
-
 =item LDAP_STRONG_AUTH_REQUIRED (8)
 
 The server requires authentication be performed with a SASL mechanism
 
-=item LDAP_PP_PASSWORD_IN_HISTORY (8)
-
-The new password was used too recently.
-
 =item LDAP_PARTIAL_RESULTS (9)
 
 Returned to version 2 clients when a referral is returned. The response
@@ -513,6 +477,48 @@
 
 =back
 
+=head2 Control constants
+
+=over 4
+
+=item LDAP_PP_PASSWORD_EXPIRED (0) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The account's password has expired.
+
+=item LDAP_PP_ACCOUNT_LOCKED (1) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The account is locked.
+
+=item LDAP_PP_CHANGE_AFTER_RESET (2) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The account's password has been reset and now must be changed.
+
+=item LDAP_PP_PASSWORD_MOD_NOT_ALLOWED (3) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The account's password may not be modified.
+
+=item LDAP_PP_MUST_SUPPLY_OLD_PASSWORD (4) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The old password must also be supplied when setting a new password.
+
+=item LDAP_PP_INSUFFICIENT_PASSWORD_QUALITY (5) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The new password was not of sufficient quality.
+
+=item LDAP_PP_PASSWORD_TOO_SHORT (6) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The new password was too short.
+
+=item LDAP_PP_PASSWORD_TOO_YOUNG (7) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The previous password was changed too recently.
+
+=item LDAP_PP_PASSWORD_IN_HISTORY (8) [LDAP_CONTROL_PASSWORDPOLICY]
+
+The new password was used too recently.
+
+=back
+
 =head2 Extension OIDs
 
 B<Net::LDAP::Constant> exports constant subroutines for the following LDAP

--Boundary-00=_32iBIIdqQhG3blX--
0
peter
4/16/2008 4:47:51 PM
Peter Marschall wrote:
> Hi Mike,
> 
> On Friday, 11. April 2008, Mike Peachey wrote:
>> I have discovered a critical bug in Net::LDAP 0.35 and submitted the
>> following ticket:
>> http://rt.cpan.org/Ticket/Display.html?id=34878
>>
> 
> You are right, this is a bug.
> 
> I committed a patch to perl-ldap-SVN to fix it.
> For you convenience I also append it to this posting.
> 
> Please test and report back.

I have tested the patch with a test perl script and it resolves the 
problem (obviously, given the way the array is built).

While the patch works and I heartily thank you for it, my primary 
concern is getting the fix out to the Net::LDAP distribution on CPAN.

For my own purposes I have remained on 0.34 but I maintain an LDAP and 
DBI external authentication extension for RT from BestPractical and for 
those who are just taking up the extension and coming with up to date 
perl installs the extension is broken.

I'm not familiar with the development hierarchy and roll-out process for 
Net::LDAP, do you think it may be put to a release soon, or should I 
code a new version of my extension using integer result codes and 
release it?

Thanks for your help.
--
Kind Regards,

__________________________________________________

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com
__________________________________________________
0
mike
4/16/2008 8:39:12 PM
On 16 Apr 2008, at 21:39, Mike Peachey wrote:

> Peter Marschall wrote:
>> Hi Mike,
>> On Friday, 11. April 2008, Mike Peachey wrote:
>>> I have discovered a critical bug in Net::LDAP 0.35 and submitted the
>>> following ticket:
>>> http://rt.cpan.org/Ticket/Display.html?id=34878
>>>
>> You are right, this is a bug.
>> I committed a patch to perl-ldap-SVN to fix it.
>> For you convenience I also append it to this posting.
>> Please test and report back.
>
> I have tested the patch with a test perl script and it resolves the  
> problem (obviously, given the way the array is built).
>
> While the patch works and I heartily thank you for it, my primary  
> concern is getting the fix out to the Net::LDAP distribution on CPAN.
>
> For my own purposes I have remained on 0.34 but I maintain an LDAP  
> and DBI external authentication extension for RT from BestPractical  
> and for those who are just taking up the extension and coming with  
> up to date perl installs the extension is broken.
>
> I'm not familiar with the development hierarchy and roll-out process  
> for Net::LDAP, do you think it may be put to a release soon, or  
> should I code a new version of my extension using integer result  
> codes and release it?

I think we should release a new version ASAP. Graham does all the  
release engineering...

Cheers,

Chris
0
chrisridd
4/17/2008 5:51:39 PM
On Apr 17, 2008, at 12:51 PM, Chris Ridd wrote:
> I think we should release a new version ASAP. Graham does all the  
> release engineering...

I will do a release this weekend (or before if I get time) and also a  
new release of Authen::SASL

Graham.

0
gbarr
4/17/2008 6:14:12 PM
Graham Barr wrote:
> On Apr 17, 2008, at 12:51 PM, Chris Ridd wrote:
>> I think we should release a new version ASAP. Graham does all the 
>> release engineering...
> 
> I will do a release this weekend (or before if I get time) and also a 
> new release of Authen::SASL
> 
> Graham.
> 

Much appreciated. Thanks for the quick responses everyone. I'll get back 
to coding my latest feature request :)
--
Kind Regards,

__________________________________________________

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com
__________________________________________________
0
mike
4/17/2008 7:20:13 PM
Reply:

Similar Artilces:

Net::LDAP v0.28, bug in Net::LDAP::Constant, :all not supported
Net::LDAP::Constant no longer supports the :all tag in the export list due to the switch from Exporter to a manual export routine. So, while the following: perl -MNet::LDAP::Constant=:all -e 1 worked fine in 0.2701, it now dies with the error: ":all" is not exported by the Net::LDAP::Constant module at -e line 0 Can't continue after import errors at -e line 0 BEGIN failed--compilation aborted, <DATA> line 197. The documentation for Net::LDAP::Constant still documents the ':all' tag. I am not subscribed to the list, so if some...

Bug in Net::LDAP::LDIF v0.15
------------B210F881E6F0EB7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit It is not blocking, but rather anoying. Try the script and you'll see: Attempt to use reference as lvalue in substr at /usr/share/perl5/Net/LDAP/LDIF.pm line 348 [or 346, I don't remember] It is due that at this line $_[0] could be something like 'do bless ....'. Code, in other words. That means that if you try to 'print $_[0]' you won't see the code, bu substr while complain. Just 'use Data::Dumper' then 'print Dumper($_[0])' and y...

$ldap->search triggers Bug in ASN1 and utf8 Net::LDAP code
Dear perl programmers, I think I found bug in Net::LDAP in the part which is doing something with ASN.1 (Convert::ASN1). I'm writing small program for selecting and exporting part of oracle (with DBD::Oracle) doing nasty things with output, selecting from OpenLDAP server matching and non-matching entries and comparing them attribute by attribute, making ldif diff file from that, or producing new entries if $mesg->entries is 0. I'm not a professional programmer, but I *must* finish this application. :-( Output from oracle is in UTF-8, and it has many names with nati...

make Net::LDAP::LDIF more similar to Net::LDAP
Hi Graham, hi Chris, hi list, I would like to rework Net::LDAP::LDIF a bit so that its API resembles that of Net::LDAP a bit more while still keeping the traditional API. The reason for this is that in application I often need to distinguish between Net::LDAP and Net::LDAP::LDIF because some methods are only implemented on one side. I\'d like to start with a code() method that tries to mimic the Net::LDAP one and I\'d like to extend the Net::LDAP::Entry->update() method so that it takes a Net::LDAP::LDIF object as an argument. The latter one requires a...

[Fwd: make Net::LDAP::LDIF more similar to Net::LDAP]
--------------95D5815B06BDC2BD1A0ABFEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------95D5815B06BDC2BD1A0ABFEB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <40C7B13E.8864E5A0@cs.adelaide.edu.au> Date: Thu, 10 Jun 2004 10:54:22 +1000 From: Sion Camilleri <sion@cs.adelaide.edu.au> Reply-To: sion@cs.adelaide.edu.au X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Graham Barr <gbarr@pobox.com>...

Net::LDAP and Net:LDAP::LDIF read & add problems
I'm trying to read in a simple LDIF file to add an entry to my LDAP server. Here is the basic routine (extraneous details omitted for brevity and security): $ldif = Net::LDAP::LDIF->new($tmp,"r",onerror => 'warn'); $entry = $ldif->ready_entry(); $ldap = Net::LDAP->new($LDAPSERVER); $result=$ldap->bind("$binddn",password=>"$bindpass",version=>"3"); $result=$ldap->add($entry); Now, everything seems to work until I get to the $ldap->add method. From that I get various versions of the following: object...

Fw: Re: make Net::LDAP::LDIF more similar to Net::LDAP
Am 08.06.2004 um 18:29 Uhr haben Sie geschrieben: > On 8 Jun 2004, at 16:56, peter@adpm.de wrote: > > I\'d like to start with a code() method that tries to mimic the >> Net::LDAP one and >I assume you mean better error handling ? My first goal is having a code() method in Net::LDAP::LDIF. > > I\'d like to extend the > > Net::LDAP::Entry->update() method so that it takes a > > Net::LDAP::LDIF object as an argument. The latter one > > requires a bit of work in Net::LDAP::LDIF to make it > > correct. > Not su...

superreview cancelled: [Bug 116692] Define official Mozilla LDAP schema extension : [Attachment 165899] Mozilla LDAP schema V0.6.3
Roland Felnhofer <roland.felnhofer@chello.at> has cancelled Roland Felnhofer <roland.felnhofer@chello.at>'s request for superreview: Bug 116692: Define official Mozilla LDAP schema extension https://bugzilla.mozilla.org/show_bug.cgi?id=116692 Attachment 165899: Mozilla LDAP schema V0.6.3 https://bugzilla.mozilla.org/attachment.cgi?id=165899&action=edit ...

superreview requested: [Bug 116692] Define official Mozilla LDAP schema extension : [Attachment 165899] Mozilla LDAP schema V0.6.3
Roland Felnhofer <roland.felnhofer@chello.at> has asked Seth Spitzer (not reading bugmail) <sspitzer@mozilla.org> for superreview: Bug 116692: Define official Mozilla LDAP schema extension https://bugzilla.mozilla.org/show_bug.cgi?id=116692 Attachment 165899: Mozilla LDAP schema V0.6.3 https://bugzilla.mozilla.org/attachment.cgi?id=165899&action=edit ...

superreview cancelled: [Bug 116692] Define official Mozilla LDAP schema extension : [Attachment 142856] Mozilla LDAP schema V0.6.1
Roland Felnhofer <roland.felnhofer@chello.at> has cancelled Roland Felnhofer <roland.felnhofer@chello.at>'s request for superreview: Bug 116692: Define official Mozilla LDAP schema extension http://bugzilla.mozilla.org/show_bug.cgi?id=116692 Attachment 142856: Mozilla LDAP schema V0.6.1 http://bugzilla.mozilla.org/attachment.cgi?id=142856&action=edit ...

superreview cancelled: [Bug 116692] Define official Mozilla LDAP schema extension : [Attachment 157124] Mozilla LDAP schema V0.6.2
Roland Felnhofer <roland.felnhofer@chello.at> has cancelled Roland Felnhofer <roland.felnhofer@chello.at>'s request for superreview: Bug 116692: Define official Mozilla LDAP schema extension https://bugzilla.mozilla.org/show_bug.cgi?id=116692 Attachment 157124: Mozilla LDAP schema V0.6.2 https://bugzilla.mozilla.org/attachment.cgi?id=157124&action=edit ...

superreview requested: [Bug 116692] Define official Mozilla LDAP schema extension : [Attachment 142856] Mozilla LDAP schema V0.6.1
Roland Felnhofer <roland.felnhofer@chello.at> has asked Seth Spitzer <sspitzer@mozilla.org> for superreview: Bug 116692: Define official Mozilla LDAP schema extension http://bugzilla.mozilla.org/show_bug.cgi?id=116692 Attachment 142856: Mozilla LDAP schema V0.6.1 http://bugzilla.mozilla.org/attachment.cgi?id=142856&action=edit ...

superreview requested: [Bug 116692] Define official Mozilla LDAP schema extension : [Attachment 157124] Mozilla LDAP schema V0.6.2
Roland Felnhofer <roland.felnhofer@chello.at> has asked Seth Spitzer (not reading bugmail) <sspitzer@mozilla.org> for superreview: Bug 116692: Define official Mozilla LDAP schema extension http://bugzilla.mozilla.org/show_bug.cgi?id=116692 Attachment 157124: Mozilla LDAP schema V0.6.2 http://bugzilla.mozilla.org/attachment.cgi?id=157124&action=edit ...

Fw: Re: make Net::LDAP::LDIF more similar to Net::LDAP #2
Hi, Am 09.06.2004 um 01:44 Uhr haben Sie geschrieben: > Extending Net::LDAP::Entry to update against LDIF and LDAP objects > could allow the changetype modifications to be to produced. > > This would be really useful to produce changetypes for entry objects by > updating against an LDIF object to produce the changetype LDIF required > up to synchronise entry objects. as Graham posted you can to that already now. Simply create your Net::LDAP::Entry object with the changes option set to TRUE. Having created the ::LDIF object that way you autom...

Web resources about - Critical Bug in Net::LDAP v0.35 - perl.ldap

Resources last updated: 12/27/2015 11:34:09 AM