Thread: LDIF.pm patch -- print modrdn in write_cmd()

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I have submitted a patch to LDIF.pm via sourceforge. It enables
write_cmd() to print modrdn operations properly.

	-Kartik

Kartik Subbarao <sub...@co...> wrote:
> I have submitted a patch to LDIF.pm via sourceforge. It enables
> write_cmd() to print modrdn operations properly.
> 
>	 -Kartik
> 

It doesn't handle newsuperior...

Shouldn't the code be calling _write_attr instead of _wrap? Calling
_write_attr will automatically base-64 encode 'unsafe' values. Hm, printing
the DN should use _write_attr too...

Does the attached patch work any better?

Cheers,

Chris
I don't think the DN should be base64 encoded, it should be encoded
using rules from rfc2253, which should result in a printable string
and avoid the need for base64 encoding

Graham.

On Wed, Mar 07, 2001 at 11:18:12AM -0000, Chris Ridd wrote:
> Kartik Subbarao <sub...@co...> wrote:
> > I have submitted a patch to LDIF.pm via sourceforge. It enables
> > write_cmd() to print modrdn operations properly.
> > 
> >	 -Kartik
> > 
> 
> It doesn't handle newsuperior...
> 
> Shouldn't the code be calling _write_attr instead of _wrap? Calling
> _write_attr will automatically base-64 encode 'unsafe' values. Hm, printing
> the DN should use _write_attr too...
> 
> Does the attached patch work any better?
> 
> Cheers,
> 
> Chris
> Index: ldap/lib/Net/LDAP/LDIF.pm
> ===================================================================
> RCS file: /cvsroot/perl-ldap/ldap/lib/Net/LDAP/LDIF.pm,v
> retrieving revision 1.4
> diff -b -c -r1.4 LDIF.pm
> *** ldap/lib/Net/LDAP/LDIF.pm	2001/02/12 09:27:08	1.4
> --- ldap/lib/Net/LDAP/LDIF.pm	2001/03/07 11:17:09
> ***************
> *** 291,312 ****
>     my $saver = SelectSaver->new($self->{'fh'});
>     
>     foreach $entry (grep { defined } @_) {
> !     my @changes = $entry->changes or next;
>       my $type = $entry->changetype;
>   
>       # Skip entry if there is nothing to write
>       next if $type eq 'modify' and !@changes;
>   
> -     my $dn = "dn: " . $entry->dn;
> - 
>       print "\n" if tell($self->{'fh'});
> !     print _wrap($dn,$wrap),"\n","changetype: ",$type,"\n";
>   
>       if ($type eq 'delete') {
>         next;
>       }
>       elsif ($type eq 'add') {
>         _write_attrs($entry,$wrap);
>         next;
>       }
>   
> --- 291,317 ----
>     my $saver = SelectSaver->new($self->{'fh'});
>     
>     foreach $entry (grep { defined } @_) {
> !     my @changes = $entry->changes;
>       my $type = $entry->changetype;
>   
>       # Skip entry if there is nothing to write
>       next if $type eq 'modify' and !@changes;
>   
>       print "\n" if tell($self->{'fh'});
> !     print _write_attr('dn',$entry->dn,$wrap),"\n","changetype: $type\n";
>   
>       if ($type eq 'delete') {
>         next;
>       }
>       elsif ($type eq 'add') {
>         _write_attrs($entry,$wrap);
> +       next;
> +     }
> +     elsif ($type eq 'modrdn') {
> +       print _write_attr('newrdn',$entry->get_value('newrdn'),$wrap);
> +       print 'deleteoldrdn: ',$entry->get_value('deleteoldrdn')),"\n";
> +       my $ns = $entry->get_value('newsuperior');
> +       print _write_attr('newsuperior',$ns,$wrap) if defined $ns;
>         next;
>       }
>   

Graham Barr <gb...@po...> wrote:
> I don't think the DN should be base64 encoded, it should be encoded
> using rules from rfc2253, which should result in a printable string
> and avoid the need for base64 encoding

Interesting.

RFC 2849 says that DNs should be base-64 encoded if any of the RDN values
contain 'unsafe' characters.

RFC 2253 format DNs 'may' escape any character using the \hexpair notation.

So what you're suggesting is that we display DNs by always backslashifying
unsafe characters instead of base-64 encoding them.

I think that RFC 2849 would permit that, and it does have the benefit of
making the DNs semi-readable. Well, more readable than a blob of base 64.

So we need an extra bit of code to backslashify a DN.

	my $dn = $entry->dn;
	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;

(NB colon and < are special in LDIF, hence the additions in the regex.)

Cheers,

Chris

On Thu, Mar 08, 2001 at 09:50:45AM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > I don't think the DN should be base64 encoded, it should be encoded
> > using rules from rfc2253, which should result in a printable string
> > and avoid the need for base64 encoding
> 
> Interesting.
> 
> RFC 2849 says that DNs should be base-64 encoded if any of the RDN values
> contain 'unsafe' characters.
> 
> RFC 2253 format DNs 'may' escape any character using the \hexpair notation.
> 
> So what you're suggesting is that we display DNs by always backslashifying
> unsafe characters instead of base-64 encoding them.
> 
> I think that RFC 2849 would permit that, and it does have the benefit of
> making the DNs semi-readable. Well, more readable than a blob of base 64.

That was my reasoning behind it.

> So we need an extra bit of code to backslashify a DN.
> 
> 	my $dn = $entry->dn;
> 	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;
> 
> (NB colon and < are special in LDIF, hence the additions in the regex.)

They are only special if they are the first character though, which would
not happen with a DN, right ?

We could just do the above, or we could call the cannonify sub in ::Util
if /[\x00-\x1f\x7f-\xff]/ or is that too much is it could change the
way a DN looks

Graham.

Graham Barr <gb...@po...> wrote:
> On Thu, Mar 08, 2001 at 09:50:45AM -0000, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > I don't think the DN should be base64 encoded, it should be encoded
>> > using rules from rfc2253, which should result in a printable string
>> > and avoid the need for base64 encoding
>> 
>> Interesting.
>> 
>> RFC 2849 says that DNs should be base-64 encoded if any of the RDN values
>> contain 'unsafe' characters.
>> 
>> RFC 2253 format DNs 'may' escape any character using the \hexpair
>> notation.
>> 
>> So what you're suggesting is that we display DNs by always
>> backslashifying unsafe characters instead of base-64 encoding them.
>> 
>> I think that RFC 2849 would permit that, and it does have the benefit of
>> making the DNs semi-readable. Well, more readable than a blob of base 64.
> 
> That was my reasoning behind it.

Uh huh.

>> So we need an extra bit of code to backslashify a DN.
>> 
>> 	my $dn = $entry->dn;
>> 	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;
>> 
>> (NB colon and < are special in LDIF, hence the additions in the regex.)
> 
> They are only special if they are the first character though, which would
> not happen with a DN, right ?

Right.

> We could just do the above, or we could call the cannonify sub in ::Util
> if /[\x00-\x1f\x7f-\xff]/ or is that too much is it could change the
> way a DN looks

Let's see, what canonicalisation does canonical_dn do..

* it lowercases values that are # followed by hex,
* it lowercases types that start with an OID,
* it backslashifies RFC 2253-magic characters,
* it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters,
* it surrounds values with leading/trailing/multiple spaces with quotes.

(Actually, that last part is not permitted by RFC 2253. You should replace
those spaces with "\20" or "\ ". I suspect "\20" would be safer especially
at the end of a string, to avoid someone simply ripping trailing spaces off
and leaving the string ending with a dangling slash.)

Those canonicalisations look OK to me. Have I missed any others?

Cheers,

Chris

On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Thu, Mar 08, 2001 at 09:50:45AM -0000, Chris Ridd wrote:
> >> Graham Barr <gb...@po...> wrote:
> >> > I don't think the DN should be base64 encoded, it should be encoded
> >> > using rules from rfc2253, which should result in a printable string
> >> > and avoid the need for base64 encoding

> >> So we need an extra bit of code to backslashify a DN.
> >> 
> >> 	my $dn = $entry->dn;
> >> 	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;
> >> 

> > We could just do the above, or we could call the cannonify sub in ::Util
> > if /[\x00-\x1f\x7f-\xff]/ or is that too much is it could change the
> > way a DN looks
> 
> Let's see, what canonicalisation does canonical_dn do..
> 
> * it lowercases values that are # followed by hex,
> * it lowercases types that start with an OID,
> * it backslashifies RFC 2253-magic characters,
> * it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters,
> * it surrounds values with leading/trailing/multiple spaces with quotes.
> 
> (Actually, that last part is not permitted by RFC 2253. You should replace
> those spaces with "\20" or "\ ". I suspect "\20" would be safer especially
> at the end of a string, to avoid someone simply ripping trailing spaces off
> and leaving the string ending with a dangling slash.)

Hm, bust have been a leftover from the original implementation which
followed 1779, I will change it to use \20

> Those canonicalisations look OK to me. Have I missed any others?

I don't think so. So do you agree that we should do this for LDIF ?

And should we always call cannonify or only if there is a special
character in the DN ?

Graham.

Chris Ridd wrote:
> 
> Kartik Subbarao <sub...@co...> wrote:
> > I have submitted a patch to LDIF.pm via sourceforge. It enables
> > write_cmd() to print modrdn operations properly.
> >
> >        -Kartik
> >
> 
> It doesn't handle newsuperior...

[...]

Thanks for the enhancements Chris! Interesting discussion about base64
vs escaping the DN, I hadn't even considered that. Looks like you guys
have got it well in hand.

	-Kartik

Thread: LDIF.pm patch -- print modrdn in write_cmd()

perl-ldap-dev