$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 national
characters in them.

On one part (only one) I must mangle some national chars to produce
valid UNIX uids (for example: �ime �evap > scevap).

like this:
    $tmpname = substr ($n_final_ime , 0, 1);
    $tmpname =~ tr/\x{010C}\x{0106}\x{017D}\x{0160}\x{0110}/cczsd/;
    $tmpname =~ tr/\x{010D}\x{0107}\x{017E}\x{0161}\x{0111}/cczsd/;

    etc ...

For some reason tr/// with utf8 is *only* working if I include this in
program:

use encoding 'utf8';

But when I include encoding 'utf8' I get my tr/// to do job corectly,
*but* ... $ldap->search will die with this error:

(mvz){lav}[o2l]$ perl o2l.pl 
Bad ASN PDU at /usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm
line 178, <RAZLIKA> line 1.

However! If I put "attrs => ['someValidLDAPAttr']" in $ldap->search I
don't get this ASN PDU error message! But I cannot do that because I
need entire LDAP entry out of LDAP. "attrs => ['*']" or "attrs => ['ALL']"
doesn't help, first one is triggering ASN.1 bug like when there is no
attrs, and second one is returning only "dn" - because of this
behaviour I think this is Net::LDAP bug, not a Convert::ASN1 bug.

I have extracted part of the code from my program to reproduce the bug
(see below).

Can somebody help me? Is there some workaround? I'm not very good with
perl. :-(

Here is sample script that will trigger the bug. If you comment out
use encoding 'utf8' it will work. I have tried with "no encoding
'utf8'" after tr/// lines, but it doesn't help.


This is extracted script for triggering bug, part of program that must
use tr/// with utf8 chars in "else" statement in the same function
(sub ldapcmp() ...):
-----------------------------------------------------------------------
use strict;
use Net::LDAP;

my $static_part_of_filter = "(&(objectclass=hrHacPerson)(hrHacPersonWorkKey=";
my $filt;
my $diff_file = "./ora.dump";

my $ldap_server = 'hijena.hac';
my $ldap_pass = "veryverysecret";
my $bind_dn = 'cn=ldapadm,dc=hac,dc=hr';
my $search_base = 'ou=Accounts,dc=hac,dc=hr';
my $mesg;

my ($n_final_ime, $n_final_prezime);

my ($n_datprad, $n_datkrad,
    $n_jmbg, $n_radnik, $n_suborgcjekadr, $n_orgcje_kadr,
    $n_final_naziv, $n_final_ulica, $n_final_naziv2,
    $n_vrrada, $n_rmnaziv);

my $ldap = Net::LDAP->new($ldap_server) or die "Cannot connect: $!";

    $ldap->bind ($bind_dn, password => $ldap_pass, version => 3);

    open(RAZLIKA, "$diff_file") or die "$diff_file: cannot open: $!";


    while(<RAZLIKA>)
    {
	   ($n_final_ime, $n_final_prezime, $n_datprad, $n_datkrad,
	    $n_jmbg, $n_radnik, $n_suborgcjekadr, $n_orgcje_kadr,
	    $n_final_naziv, $n_final_ulica, $n_final_naziv2,
	    $n_vrrada, $n_rmnaziv) = split(/[|\n]/, $_, 9999);

    $filt = ($static_part_of_filter . $n_radnik . "))");

    # this doesn't help:
    no encoding 'utf8';

    $mesg = ($ldap->search (base => $search_base, scope => 'sub',filter => "$filt"));
    $mesg->error if $mesg->code;

	   use encoding 'utf8';

           # $tmpname comes from oracle dump
	   my $tmpname = "ČĆŽŠĐčćžšđ";
	   $tmpname =~ tr/\x{010C}\x{0106}\x{017D}\x{0160}\x{0110}/cczsd/;
	   $tmpname =~ tr/\x{010D}\x{0107}\x{017E}\x{0161}\x{0111}/cczsd/;

	   print "$tmpname\n"
	   # the rest is very long and boring ...

	 }
-----------------------------------------------------------------------

this is input file ora.dump:
-----------------------------------------------------------------------
Drago|Visinski|12042001|:|3104347391214|361|5|501040004|Kutina|A.Mihanovieva 112|Kutina|1|:|
Foo|ČĆŽŠĐčćžšđ|12042001|:|1101974390028|99997|6|601050001|:|:|Oroslavje|1|:|
-----------------------------------------------------------------------


P. S.
Please include `Cc: <mvz@hac.hr>' if you replay to that mail on list.

P. P. S.
Please help! ... I want to go on my summer vacation(1) :-)


-- 
		The Network is the Filesystem

0
mvz
7/7/2003 2:23:50 PM
perl.ldap 1268 articles. 0 followers. Follow

5 Replies
1157 Views

Similar Articles

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

On 7/7/03 3:23 pm, Miroslav Zubcic <mvz@hac.hr> wrote:

> Dear perl programmers,
> 
> I think I found bug in Net::LDAP in the part which is doing something
> with ASN.1 (Convert::ASN1).

The current version of Convert::ASN1 (0.19) has some bug fixes for utf8
support in perl >= 5.8. Either upgrade to that, or try setting your LANG
environment variable so it doesn't include 'utf8'. (On Red Hat you can do
this for all users in /etc/sysconfig/i18n.)


> P. S.
> Please include `Cc: <mvz@hac.hr>' if you replay to that mail on list.
> 
> P. P. S.
> Please help! ... I want to go on my summer vacation(1) :-)
> 

Cheers,

Chris

0
chrisridd
7/8/2003 7:40:10 AM
Thanks for your response Chris;

Chris Ridd <chrisridd@mac.com> writes:

> On 7/7/03 3:23 pm, Miroslav Zubcic <mvz@hac.hr> wrote:

>> I think I found bug in Net::LDAP in the part which is doing something
>> with ASN.1 (Convert::ASN1).

> The current version of Convert::ASN1 (0.19) has some bug fixes for utf8

Where I can find Convert::ASN1 0.19? On CPAN I see only 0.17, and on
google I cannot find 0.19 ... looks like the latest version is 0.17. :-\

> support in perl >= 5.8. Either upgrade to that, or try setting your LANG
> environment variable so it doesn't include 'utf8'. (On Red Hat you can do
> this for all users in /etc/sysconfig/i18n.)

It's not Red Hat but SunOS 5.9 (but this is probably not important in
this case) and in my initial mail I have said that I *must*
convert/mangle (some, but some not) utf8 strings to ascii, and that
tr/// is not working without "use encoding 'utf8'". But _with_ utf8 I
get "Bad ASN PDU" from

/usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm

So I'm stuck here.

Question: is it safe to just comment out this sanity check in IO.pm?

    elsif (!$len && !$tch) {
      die "Bad ASN PDU" unless $depth;
      unless (--$depth) {
        last;
      }
    }

.... or somebody must fix bug in $ldap->search in Net::LDAP?


I have used little older versions of Convert::ASN1 and Net::LDAP, but
after upgrade from CPAN to latest versions of both things are the same.


-- 
		The Network is the Filesystem

0
mvz
7/9/2003 3:11:01 PM
On Wednesday, Jul 9, 2003, at 08:11 US/Pacific, Miroslav Zubcic wrote:

> Thanks for your response Chris;
>
> Chris Ridd <chrisridd@mac.com> writes:
>
>> On 7/7/03 3:23 pm, Miroslav Zubcic <mvz@hac.hr> wrote:
>
>>> I think I found bug in Net::LDAP in the part which is doing something
>>> with ASN.1 (Convert::ASN1).
>
>> The current version of Convert::ASN1 (0.19) has some bug fixes for 
>> utf8
>
> Where I can find Convert::ASN1 0.19? On CPAN I see only 0.17, and on
> google I cannot find 0.19 ... looks like the latest version is 0.17. 
> :-\

Chris has been staring into his crystal ball again, 0.17 is the latest.


>
>> support in perl >= 5.8. Either upgrade to that, or try setting your 
>> LANG
>> environment variable so it doesn't include 'utf8'. (On Red Hat you 
>> can do
>> this for all users in /etc/sysconfig/i18n.)
>
> It's not Red Hat but SunOS 5.9 (but this is probably not important in
> this case) and in my initial mail I have said that I *must*
> convert/mangle (some, but some not) utf8 strings to ascii, and that
> tr/// is not working without "use encoding 'utf8'". But _with_ utf8 I
> get "Bad ASN PDU" from
>
> /usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm
>
> So I'm stuck here.
>
> Question: is it safe to just comment out this sanity check in IO.pm?
>
>     elsif (!$len && !$tch) {
>       die "Bad ASN PDU" unless $depth;
>       unless (--$depth) {
>         last;
>       }
>     }
>
> ... or somebody must fix bug in $ldap->search in Net::LDAP?

That looks like it is in the code reading a packet from the network, 
which is
a different problem to the one Chris is refering to.

Can you turn on debug with Net::LDAP by passing debug=>15 and post what 
it reports
that it read just before the error

Graham.

0
gbarr
7/9/2003 4:16:01 PM
Hi Graham, thanks for your response.

Graham Barr <gbarr@pobox.com> writes:

> Chris has been staring into his crystal ball again, 0.17 is the latest.

Ah ... OK. :-)

>> It's not Red Hat but SunOS 5.9 (but this is probably not important in
>> this case) and in my initial mail I have said that I *must*
>> convert/mangle (some, but some not) utf8 strings to ascii, and that
>> tr/// is not working without "use encoding 'utf8'". But _with_ utf8 I
>> get "Bad ASN PDU" from
>>
>> /usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm
>>
>> So I'm stuck here.
>>
>> Question: is it safe to just comment out this sanity check in IO.pm?
>>
>>     elsif (!$len && !$tch) {
>>       die "Bad ASN PDU" unless $depth;
>>       unless (--$depth) {
>>         last;
>>       }
>>     }
>>
>> ... or somebody must fix bug in $ldap->search in Net::LDAP?

> That looks like it is in the code reading a packet from the network,
> which is a different problem to the one Chris is refering to.

> Can you turn on debug with Net::LDAP by passing debug=>15 and post
> what it reports that it read just before the error

Nothing - absolutly nothing. I tried with my main program and example
script which I posted in my initial mail on list.

(mvz){lav}[o2l]$ perl -w bug.pl 
Use of uninitialized value in ord at /usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm line 161, <RAZLIKA> line 1.
Bad ASN PDU at /usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm line 178, <RAZLIKA> line 1.

# This is test with commented out "use encoding 'utf8'"
(mvz){lav}[o2l]$ perl -w bug.pl
ČĆŽŠĐčćžšđ
ČĆŽŠĐčćžšđ

.... as you see, I don't get an error, but utf8 strings ar *not* tr///'ed
into cczsd like it should be when I use utf8 encoding.

(bug.pl is an example script from my first post).

I have put debug like this:

  $mesg = ($ldap->search
  (base => $search_base, debug => 15, scope => 'sub', filter => "$filt"));

Am I doing something stupid? Did you mean to put "debug => 15" exactly
where I put it? Please be patient - I'm a perl newbee. :-\

truss -t open perl -w bug.pl
Last file open()ed by perl is Filter.pm according to truss(1).
open64("/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Net/LDAP/Filter.pm", O_RDONLY) Err#2 ENOENT
open64("/usr/local/lib/perl5/site_perl/5.8.0/Net/LDAP/Filter.pm", O_RDONLY) = 8
Use of uninitialized value in ord at /usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm line 161, <RAZLIKA> line 1.
Bad ASN PDU at /usr/local/lib/perl5/site_perl/5.8.0/Convert/ASN1/IO.pm line 178, <RAZLIKA> line 1.

Last thing that perl see is this:
read(4, " 0\f", 2)                              = 2
read(4, "020101 a07\n01\004\004\0", 12)         = 12
write(4, " 0 i020102 c d0418 o u =".., 107)     = 107
read(4, " 082", 2)                              = 2
llseek(4, 0, SEEK_CUR)                          Err#29 ESPIPE
close(4)

For some reason $len and $tch in Convert/ASN1/IO.pm are 0 (tried with
print($len $tch\n)) if I not put attrs => ['<some_valid_existent_attribute>'] in
$ldap->search.

Hope this helps, I don't know what else to try and how to debug, but I
will be happy if you or anybody can help me.


-- 
		The Network is the Filesystem

0
mvz
7/9/2003 5:07:43 PM
On 9/7/03 5:16 pm, Graham Barr <gbarr@pobox.com> wrote:
> On Wednesday, Jul 9, 2003, at 08:11 US/Pacific, Miroslav Zubcic wrote:
>> Where I can find Convert::ASN1 0.19? On CPAN I see only 0.17, and on
>> google I cannot find 0.19 ... looks like the latest version is 0.17.
>> :-\
> 
> Chris has been staring into his crystal ball again, 0.17 is the latest.
> 

I've got no idea where I got the idea 0.19 existed! Sorry for the confusion,
Miroslav.

Cheers,

Chris

0
chrisridd
7/9/2003 7:14:40 PM
Reply:

Similar Artilces:

superreview granted: [Bug 206018] ldap connections not close properly, LDAP/SSL triggers internal failure error message. : [Attachment 206568] fix ab quick search ldap leak
Scott MacGregor (out of town December 10th-17th) <mscott@mozilla.org> has granted David Bienvenu <bienvenu@nventure.com>'s request for superreview: Bug 206018: ldap connections not close properly, LDAP/SSL triggers internal failure error message. https://bugzilla.mozilla.org/show_bug.cgi?id=206018 Attachment 206568: fix ab quick search ldap leak https://bugzilla.mozilla.org/attachment.cgi?id=206568&action=edit ...

superreview requested: [Bug 206018] ldap connections not close properly, LDAP/SSL triggers internal failure error message. : [Attachment 206568] fix ab quick search ldap leak
David Bienvenu <bienvenu@nventure.com> has asked Scott MacGregor (out of town December 10th-17th) <mscott@mozilla.org> for superreview: Bug 206018: ldap connections not close properly, LDAP/SSL triggers internal failure error message. https://bugzilla.mozilla.org/show_bug.cgi?id=206018 Attachment 206568: fix ab quick search ldap leak https://bugzilla.mozilla.org/attachment.cgi?id=206568&action=edit ------- Additional Comments from David Bienvenu <bienvenu@nventure.com> we had a reference cycle between the listener and the ldapdirectoryquery - since the ldapd...

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...

superreview granted: [Bug 332483] LDAP userCertificate requests fail for ldap servers that require auth : [Attachment 219790] support login and password for cert certificate ldap searching
David Bienvenu <bienvenu@nventure.com> has granted Scott MacGregor <mscott@mozilla.org>'s request for superreview: Bug 332483: LDAP userCertificate requests fail for ldap servers that require auth https://bugzilla.mozilla.org/show_bug.cgi?id=332483 Attachment 219790: support login and password for cert certificate ldap searching https://bugzilla.mozilla.org/attachment.cgi?id=219790&action=edit ...

superreview requested: [Bug 332483] LDAP userCertificate requests fail for ldap servers that require auth : [Attachment 219790] support login and password for cert certificate ldap searching
Scott MacGregor <mscott@mozilla.org> has asked David Bienvenu <bienvenu@nventure.com> for superreview: Bug 332483: LDAP userCertificate requests fail for ldap servers that require auth https://bugzilla.mozilla.org/show_bug.cgi?id=332483 Attachment 219790: support login and password for cert certificate ldap searching https://bugzilla.mozilla.org/attachment.cgi?id=219790&action=edit ------- Additional Comments from Scott MacGregor <mscott@mozilla.org> trying david. ...

LDAP driver ldap-search
hi, I installed a driver LDAP to SUSE Linux Enterprise Server 11 SP1 (x86_64) - Kernel \ r (\ l), IDM 3.6.1. When I start the driver for the first time I expected synchronization objects dall'LDAP source. I waited for the first round-LDAP search, the second-cycle LDAP search. Only after the third cycle users have been imported within IDV. The start of the driver did not give any errors or warnings. This is normal behavior or is there some fault of the driver and the driver must be configured differently? What would be the optimal configuration for an LDAP Driver / ldap-search?...

Net::LDAP->root_dse() not returning an error (when LDAP server does)
Hello, I'm experimenting with "start_tls()" in Net::LDAP. The manual suggests to check the RootDSE for LDAPv3 and TLS extension. Somhow I managed that creating the LDAP object (i.e. connect) suceeds, but $ldap->root_dse() returns undef. Interesting to say that you cannot get much information out of an undef: May code fragment is this: sub start_TLS($$) { my ($ldap, $q) = @_; my $dse = $ldap->root_dse(); if ($dse && $dse->supported_version(3) && $dse->supported_extension(LDAP_EXTENSION_START_TLS)) { ...

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>...

Secure LDAP (ldaps)
hi I have implemented ldap authentication in our application using the sample given in "LDAP using EAServer and Powerbuilder" document. It is succefully implemented. But the network people has asked me to connect on secure port (ldaps) now. My problem is i don't know what i kind of setting i should do now on EAServer box and what i should do on the clients. I assume there is nothing to be done on the client because the call to ldap check is initiated from the EAServer Server to LDAP server using EJB (calling JNDI API). We are runnig EAServer on JDK 1.3. Can someone g...

<ldap-err ldap-rc="68" ldap-rc-name="LDAP_ALREADY_EXISTS">
Hi, i've create, from two virutal machines of Utopia SIM, two phisical machine. The provisioning to Active directory don't work (SAP emulator, Telco, Lotus Notes work fine). When i create the users (with Enhanced provisioning Workflow") or when i try to syncronize eDir with AD i receve this error (for the new user): <ldap-err ldap-rc="68" ldap-rc-name="LDAP_ALREADY_EXISTS"> I've already seen TID 10091618. I think that the problem is in the AD. I've created it manually (without ntbackup) but with the same structure: OU=Utopia __...

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...

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...

superreview granted: [Bug 223560] clean up the ldap server migration code : [Attachment 134250] fix building with disable ldap
Seth Spitzer <sspitzer@mozilla.org> has granted Seth Spitzer <sspitzer@mozilla.org>'s request for superreview: Bug 223560: clean up the ldap server migration code http://bugzilla.mozilla.org/show_bug.cgi?id=223560 Attachment 134250: fix building with disable ldap http://bugzilla.mozilla.org/attachment.cgi?id=134250&action=edit ------- Additional Comments from Seth Spitzer <sspitzer@mozilla.org> r/sr/a=sspitzer for 1.6a ...

Web resources about - $ldap->search triggers Bug in ASN1 and utf8 Net::LDAP code - perl.ldap

Resources last updated: 12/19/2015 7:00:46 AM