From space at wechall.net  Fri Jul  3 11:07:15 2015
From: space at wechall.net (Space One)
Date: Fri, 03 Jul 2015 11:07:15 +0200
Subject: [python-ldap] violation of exception arguments
Message-ID: <559650C3.5030901@wechall.net>

Hello,

The documentation of the LDAPError exception base class tells that the
arguments is a dict which might contain the keys 'info', 'dict', 'matched'.
http://python-ldap.org/doc/html/ldap.html#exceptions

This documentation is violated in the following places:

controls/__init__.py
138:        raise ldap.UNAVAILABLE_CRITICAL_EXTENSION('Received
unexpected critical response control with controlType %s' %
(repr(controlType)))

ldapobject.py
679:           raise ldap.TIMEOUT(
680:             "LDAP time limit (%d secs) exceeded." % (timeout)
681:           )

ldap.__version__ == 2.4.10

When unbinding twice the following exception happens which also doesn't
contain a dict:
>>> c = ldap.ldapobject.ReconnectLDAPObject('')
>>> c.unbind()
>>> c.unbind()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 590,
in unbind
    return self.unbind_ext(None,None)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 581,
in unbind_ext
    return
self._ldap_call(self._l.unbind_ext,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99,
in _ldap_call
    result = func(*args,**kwargs)
ldap.LDAPError: LDAP connection invalid

Best regards
spaceone

From michael at stroeder.com  Tue Jul  7 15:45:45 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 07 Jul 2015 15:45:45 +0200
Subject: [python-ldap] ANN: python-ldap 2.4.20
Message-ID: <559BD809.7040001@stroeder.com>

Find a new release of python-ldap:

  http://pypi.python.org/pypi/python-ldap/2.4.20

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAP URLs and LDAPv3 schema).

Project's web site:

  http://www.python-ldap.org/

Checksums:

$ md5sum python-ldap-2.4.20.tar.gz
f98ecd0581766a43954ba0f218053032
$ sha1sum python-ldap-2.4.20.tar.gz
3051f2b53ce73a60b852b7f4e994e4b14b7de7b4
$ sha256sum python-ldap-2.4.20.tar.gz
4b8891539a3171d993cf7896b632ff088a4c707ae85ac3c77db1454f7949f3e2

Ciao, Michael.

----------------------------------------------------------------
Released 2.4.20 2015-07-07

Changes since 2.4.19:

* New wrapping of OpenLDAP's function ldap_sasl_bind_s() allows
  to intercept the SASL handshake (thanks to Ren? Kijewski)

Modules/
* Added exceptions ldap.VLV_ERROR, ldap.X_PROXY_AUTHZ_FAILURE and
  ldap.AUTH_METHOD_NOT_SUPPORTED

Lib/
* Abandoned old syntax when raising ValueError in modules ldif and
  ldapurl, more information in some exceptions.
* ldap.ldapobject.LDAPObject:
  New convenience methods for SASL GSSAPI or EXTERNAL binds
* Refactored parts in ldif.LDIFParser:
  - New class attributes line_counter and byte_counter contain
    amount of LDIF data read so far
  - Renamed some internally used methods
  - Added support for parsing change records currently limited to
    changetype: modify
  - New separate methods parse_entry_records() (also called by parse())
    and parse_change_records()
  - Stricter order checking of dn:, changetype:, etc.
  - Removed non-existent 'AttrTypeandValueLDIF' from ldif.__all__
* New mix-in class ldap.controls.openldap.SearchNoOpMixIn
  adds convience method noop_search_st() to LDAPObject class
* Added new modules which implement the control classes
  for Virtual List View (see draft-ietf-ldapext-ldapv3-vlv) and
  Server-side Sorting (see RFC 2891) (thanks to Benjamin Dauvergne)
  Note: This is still experimental! Even the API can change later.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150707/23a72f70/attachment.bin>

From driddle at gmail.com  Tue Jul 14 16:42:35 2015
From: driddle at gmail.com (David Riddle)
Date: Tue, 14 Jul 2015 09:42:35 -0500
Subject: [python-ldap] Status of Python 3 support for python-ldap
Message-ID: <CABX-mpUzo=c2ohefL66H3ovgqJmpkWZ2qBMOUWO8K205MfC6sA@mail.gmail.com>

Greetings,

I am a software developer at the University of Illinois. We make
extensive use of python-ldap in our python projects. We are looking to
start moving to Python 3, and we would like to know what the status of
Python 3 support is for python-ldap. In addition we are willing to
help with the development work to port python-ldap to Python 3. If
there is anyway I can be of assistance please feel free to contact me
directly. We look forward to hearing what your current roadmap is for
python 3 support.

Thank you,

David Riddle
University of Illinois
TSI SDG Software Developer
ddriddle at illinois.edu

From mailinglist0 at skurfer.com  Tue Jul 14 20:42:41 2015
From: mailinglist0 at skurfer.com (Rob McBroom)
Date: Tue, 14 Jul 2015 14:42:41 -0400
Subject: [python-ldap] Status of Python 3 support for python-ldap
In-Reply-To: <CABX-mpUzo=c2ohefL66H3ovgqJmpkWZ2qBMOUWO8K205MfC6sA@mail.gmail.com>
References: <CABX-mpUzo=c2ohefL66H3ovgqJmpkWZ2qBMOUWO8K205MfC6sA@mail.gmail.com>
Message-ID: <C2CCE6C3-D0DF-49D3-8071-7AB16494DC87@skurfer.com>

On 14 Jul 2015, at 10:42, David Riddle wrote:

> I am a software developer at the University of Illinois. We make
> extensive use of python-ldap in our python projects. We are looking to
> start moving to Python 3, and we would like to know what the status of
> Python 3 support is for python-ldap.

Imagine the sound of crickets chirping.

This question has been asked many times and the idea has not been 
accepted, rejected, or otherwise commented on. I wouldn?t expect an 
answer this time.

If you have development cycles available, maybe you should start with 
the unofficial fork at https://github.com/rbarrois/python-ldap, which 
was announced here and? never acknowledged.

-- 
Rob McBroom
http://www.skurfer.com/

From michael at stroeder.com  Sun Jul 19 13:12:25 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sun, 19 Jul 2015 13:12:25 +0200
Subject: [python-ldap] Status of Python 3 support for python-ldap
In-Reply-To: <CABX-mpUzo=c2ohefL66H3ovgqJmpkWZ2qBMOUWO8K205MfC6sA@mail.gmail.com>
References: <CABX-mpUzo=c2ohefL66H3ovgqJmpkWZ2qBMOUWO8K205MfC6sA@mail.gmail.com>
Message-ID: <55AB8619.4050907@stroeder.com>

David Riddle wrote:
> I am a software developer at the University of Illinois. We make
> extensive use of python-ldap in our python projects. We are looking to
> start moving to Python 3, and we would like to know what the status of
> Python 3 support is for python-ldap.

I'm watching Python 3 activities with interest but have currently no spare
time and no business to contribute.

So personally I'd favor to see a complete rewrite for Python 3 because of
these reasons:

0. People do have to touch their calling code when migrating it from Python 2
to Python 3 anyway.

1. A clear contribution policy has to be defined and enforced to be able to
solve the blurry licensing situation.

2. A rewrite would be a good chance to get better code-base for solving some
of the long out-standing issues (e.g. response controls in LDAPError
exception). Some of the current C code is a real mess hard to maintain.

The ultimate goal should be to contribute an LDAP module into Python's
standard lib which up to now was not possible because of licensing issues.

Therefore I consider all the current quick-patch approaches to be the wrong
approach. And especially it's hard to attract people to quickly contributed
maintain code for years.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150719/cb95372e/attachment.bin>

From miroslaw.baran at gmail.com  Fri Jul 24 17:43:14 2015
From: miroslaw.baran at gmail.com (Miroslaw Baran)
Date: Fri, 24 Jul 2015 16:43:14 +0100
Subject: [python-ldap] OS X python-ldap woes, patch + request
Message-ID: <CALgW4fQevmF9e0OhoUyhy9mbOZSY0eZRmUZnYVMsEDo3d=Y0+w@mail.gmail.com>

Hey,

Michael, if that wouldn?t be much of a problem, would you consider changing
the order of library/include directories in setup.cfg?

It?s the only think that keeps python-ldap from working from scratch with
homebrew?s openldap package installed. Diff inline and as an attachment for
your convenience.

Best regards
? Miroslaw Baran

 --- setup.cfg.old    2015-07-24 16:32:10.000000000 +0100+++ setup.cfg
   2015-07-24 16:32:55.000000000 +0100@@ -1,6 +1,6 @@
 [_ldap]-library_dirs = /usr/lib /usr/lib64 /usr/local/lib
/usr/local/lib64 -include_dirs = /usr/include /usr/include/sasl
/usr/local/include /usr/local/include/sasl +library_dirs =
/usr/local/lib /usr/local/lib64 /usr/lib /usr/lib64+include_dirs =
/usr/local/include /usr/local/include/sasl /usr/include
/usr/include/sasl
 defines = HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R
 extra_compile_args =
 extra_objects =

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150724/fe5db62f/attachment.html>
-------------- next part --------------
--- setup.cfg.old	2015-07-24 16:32:10.000000000 +0100
+++ setup.cfg	2015-07-24 16:32:55.000000000 +0100
@@ -1,6 +1,6 @@
 [_ldap]
-library_dirs = /usr/lib /usr/lib64 /usr/local/lib /usr/local/lib64 
-include_dirs = /usr/include /usr/include/sasl /usr/local/include /usr/local/include/sasl 
+library_dirs = /usr/local/lib /usr/local/lib64 /usr/lib /usr/lib64
+include_dirs = /usr/local/include /usr/local/include/sasl /usr/include /usr/include/sasl 
 defines = HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R
 extra_compile_args = 
 extra_objects = 

From michael at stroeder.com  Mon Jul 27 23:11:06 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 27 Jul 2015 23:11:06 +0200
Subject: [python-ldap] apps page
Message-ID: <55B69E6A.7030800@stroeder.com>

HI!

I've radically cleaned up

http://www.python-ldap.org/apps.shtml

and hunked out all outdated links of unmaintained software.

If you feel an application uses python-ldap in a specific way and it is still
maintained feel free to suggest a link for the apps page

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150727/5deb52a2/attachment.bin>

From michael at stroeder.com  Mon Jul 27 23:07:58 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 27 Jul 2015 23:07:58 +0200
Subject: [python-ldap] FYI: Migrating from CVS to mercurial
Message-ID: <55B69DAE.30107@stroeder.com>

HI!

Given the current outage of SF it's definitely overdue to move away from their
service.

I will finally convert my backup CVS repo of python-ldap to mercurial and try
to publish that on python-ldap.org.

Good advice for this conversion is appreciated.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150727/4c4ede67/attachment.bin>

From djay at pretaweb.com  Tue Jul 28 06:02:42 2015
From: djay at pretaweb.com (Dylan Jay)
Date: Tue, 28 Jul 2015 11:02:42 +0700
Subject: [python-ldap] FYI: Migrating from CVS to mercurial
In-Reply-To: <55B69DAE.30107@stroeder.com>
References: <55B69DAE.30107@stroeder.com>
Message-ID: <03CDEE0E-CE06-4C73-A140-5BA479BF267E@pretaweb.com>


> On 28 Jul 2015, at 4:07 am, Michael Str?der <michael at stroeder.com> wrote:
> 
> HI!
> 
> Given the current outage of SF it's definitely overdue to move away from their
> service.
> 
> I will finally convert my backup CVS repo of python-ldap to mercurial and try
> to publish that on python-ldap.org.
> 
> Good advice for this conversion is appreciated.

git and github. Why not make contributions accessible to the most people?


From adam.polkosnik at ny.frb.org  Tue Jul 28 07:32:37 2015
From: adam.polkosnik at ny.frb.org (Polkosnik, Adam)
Date: Tue, 28 Jul 2015 05:32:37 +0000
Subject: [python-ldap] FYI: Migrating from CVS to mercurial
In-Reply-To: <03CDEE0E-CE06-4C73-A140-5BA479BF267E@pretaweb.com>
Message-ID: <3mgRWL6w33zPF7@mail.python.org>

+1 for git and github. The rest is either inferior or frustrating to contribute.

----- Original Message -----
From: Dylan Jay [mailto:djay at pretaweb.com]
Sent: Tuesday, July 28, 2015 12:02 AM Eastern Standard Time
To: Michael Str?der <michael at stroeder.com>
Cc: python-ldap at python.org <python-ldap at python.org>
Subject: Re: [python-ldap] FYI: Migrating from CVS to mercurial


> On 28 Jul 2015, at 4:07 am, Michael Str?der <michael at stroeder.com> wrote:
> 
> HI!
> 
> Given the current outage of SF it's definitely overdue to move away from their
> service.
> 
> I will finally convert my backup CVS repo of python-ldap to mercurial and try
> to publish that on python-ldap.org.
> 
> Good advice for this conversion is appreciated.

git and github. Why not make contributions accessible to the most people?

_______________________________________________
python-ldap mailing list
python-ldap at python.org
https://mail.python.org/mailman/listinfo/python-ldap



This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information.  If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.

From michael at stroeder.com  Tue Jul 28 08:51:04 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 28 Jul 2015 08:51:04 +0200
Subject: [python-ldap] FYI: Migrating from CVS to mercurial
Message-ID: <55B72658.6020608@stroeder.com>

Polkosnik, Adam wrote:
> +1 for git and github. The rest is either inferior or frustrating to contribute.

The decision is very simple:

1. Python uses mercurial and I prefer to stick to Python's mainstream.

2. I very much dislike this github monoculture. And I've
experienced with SF how such a platform changes over time.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150728/f38851ce/attachment-0001.bin>

From djay at pretaweb.com  Tue Jul 28 10:12:24 2015
From: djay at pretaweb.com (Dylan Jay)
Date: Tue, 28 Jul 2015 15:12:24 +0700
Subject: [python-ldap] FYI: Migrating from CVS to mercurial
In-Reply-To: <55B72658.6020608@stroeder.com>
References: <55B72658.6020608@stroeder.com>
Message-ID: <DA1D97F3-D75D-42F9-BD6E-4A5D16E72A15@pretaweb.com>


> On 28 Jul 2015, at 1:51 pm, Michael Str?der <michael at stroeder.com> wrote:
> 
> Polkosnik, Adam wrote:
>> +1 for git and github. The rest is either inferior or frustrating to contribute.
> 
> The decision is very simple:
> 
> 1. Python uses mercurial and I prefer to stick to Python?s mainstream.

The decision for cpython to use mercurial was made a long time back where it wasn?t clear that git would be the winner. Things have moved on a lot since then.
I wouldn?t say by any stretch mercurial is python mainstream. I don?t have stats on hand but I would say that the vast majority of open source python projects use git over mercurial. Certainly every python package I contribute to uses git.

> 
> 2. I very much dislike this github monoculture. And I've
> experienced with SF how such a platform changes over time.

Git doesn?t lock you into github. Both git and mercurial make it easy move repos. Your only lock in is bug tracking and with apis thats not so hard to move
In the very least use bitbucket which I believe lets you either git or mercurial on the same project.
But bitbucket still lags behind last time I looked at ease of use and numbers of users.
I suspect you?re only making your job harder by making it harder to contribute to and you will likely have to move to git eventually as it?s not declining in popularity like svn and mercurial.

> 
> Ciao, Michael.
> 
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap


From jdennis at redhat.com  Tue Jul 28 15:09:58 2015
From: jdennis at redhat.com (John Dennis)
Date: Tue, 28 Jul 2015 09:09:58 -0400
Subject: [python-ldap] FYI: Migrating from CVS to mercurial
In-Reply-To: <55B69DAE.30107@stroeder.com>
References: <55B69DAE.30107@stroeder.com>
Message-ID: <55B77F26.60708@redhat.com>

On 07/27/2015 05:07 PM, Michael Str?der wrote:
> HI!
>
> Given the current outage of SF it's definitely overdue to move away from their
> service.
>
> I will finally convert my backup CVS repo of python-ldap to mercurial and try
> to publish that on python-ldap.org.
>
> Good advice for this conversion is appreciated.

I would prefer git. I use both git and mercurial depending on the 
project. Git is used far more often and to my mind easier and more 
feature complete.

github is a good hosting service with the advantage it already has a 
large ecosystem and many developers are already familiar with it.


-- 
John

From pviktori at redhat.com  Tue Jul 28 16:06:01 2015
From: pviktori at redhat.com (Petr Viktorin)
Date: Tue, 28 Jul 2015 16:06:01 +0200
Subject: [python-ldap] Status of Python 3 support for python-ldap
In-Reply-To: <55AB8619.4050907@stroeder.com>
References: <CABX-mpUzo=c2ohefL66H3ovgqJmpkWZ2qBMOUWO8K205MfC6sA@mail.gmail.com>
 <55AB8619.4050907@stroeder.com>
Message-ID: <55B78C49.6000908@redhat.com>

On 07/19/2015 01:12 PM, Michael Str?der wrote:
> David Riddle wrote:
>> I am a software developer at the University of Illinois. We make
>> extensive use of python-ldap in our python projects. We are looking to
>> start moving to Python 3, and we would like to know what the status of
>> Python 3 support is for python-ldap.
> 
> I'm watching Python 3 activities with interest but have currently no spare
> time and no business to contribute.
> 
> So personally I'd favor to see a complete rewrite for Python 3 because of
> these reasons:
> 
> 0. People do have to touch their calling code when migrating it from Python 2
> to Python 3 anyway.
> 
> 1. A clear contribution policy has to be defined and enforced to be able to
> solve the blurry licensing situation.
> 
> 2. A rewrite would be a good chance to get better code-base for solving some
> of the long out-standing issues (e.g. response controls in LDAPError
> exception). Some of the current C code is a real mess hard to maintain.
> 
> The ultimate goal should be to contribute an LDAP module into Python's
> standard lib which up to now was not possible because of licensing issues.
> 
> Therefore I consider all the current quick-patch approaches to be the wrong
> approach. And especially it's hard to attract people to quickly contributed
> maintain code for years.

Unfortunately, I don't think anyone has the time to rewrite everything
from scratch. (And those who do tend to use a different API ? see the
ldap3 project.)
So I think porting python-ldap, and then improving it, is the way to go.

As for getting into the Python standard library, I don't think that's a
reasonable goal:
- Python is not likely to start depending on OpenLDAP libraries.
- New stdlib code is expected to have a pure-python implementation if
possible, so it can work on alternative interpreters (PyPy, Jython, ...)
unchanged.
- Python developers nowadays prefer having the "batteries" on PyPI,
unless needed by Python itself or its tests.


Recently there was some work on the Python3 porting front:

Rapha?l's patches are now rebased on top of the current upstream
python-ldap, and work on it continues here:
    https://github.com/pyldap/pyldap

A release is on PyPI: https://pypi.python.org/pypi/pyldap


I'd like to invite anyone interested in the Python3 port to join forces.
Any applicable improvements should be submitted back to python-ldap, and
any new functionality from python-ldap should be merged in. Hopefully,
this can all be merged back into python-ldap one day.



-- 
Petr Viktorin


From seph at directionless.org  Tue Jul 28 15:43:26 2015
From: seph at directionless.org (seph)
Date: Tue, 28 Jul 2015 09:43:26 -0400
Subject: [python-ldap] modifyModlist and MOD_DELETE
Message-ID: <ygewpxktn29.fsf@lame.message.id>

I've been playing with python-ldap, and I'm wondering why modifyModlist
works the way it does. Specifically, when deleting a attribute of a set,
it deletes then entire set, and then re-adds the remaining ones. Anyone
know why?

In other words, why aren't these the same?


modifyModlist({'memberUid': ['a_member', 'b_member', 'c_member']},
              {'memberUid': ['b_member', 'c_member']})

[(MOD_DELETE, 'memberUid', ['a_member'])]

seph

From michael at stroeder.com  Tue Jul 28 19:17:31 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 28 Jul 2015 19:17:31 +0200
Subject: [python-ldap] modifyModlist and MOD_DELETE
In-Reply-To: <ygewpxktn29.fsf@lame.message.id>
References: <ygewpxktn29.fsf@lame.message.id>
Message-ID: <55B7B92B.8000006@stroeder.com>

seph wrote:
> I've been playing with python-ldap, and I'm wondering why modifyModlist
> works the way it does. Specifically, when deleting a attribute of a set,
> it deletes then entire set, and then re-adds the remaining ones. Anyone
> know why?

If you delete by explicit value the attribute must have a EQUALITY matching
rule defined for it. This is typically not the case for BLOB attributes like
jpegPhoto, userPKCS12 etc. So the current behaviour gives the best generic
interoperability but is not necessarily the optimal way for every use-case.

In my web2ldap nothing works without schema knowledge. So I have a variant of
this function which also looks in subschema whether an attribute type has
EQUALITY matching rule and deletes by value in this case (plus some more
not-so-generic optimizations).

YMMV. If you have more control over the actual schema/data then you might want
to consider building the modification list yourself. That's what I do in some
specific use-cases.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150728/0870fe2a/attachment.bin>

From seph at directionless.org  Wed Jul 29 16:35:22 2015
From: seph at directionless.org (seph)
Date: Wed, 29 Jul 2015 10:35:22 -0400
Subject: [python-ldap] modifyModlist and MOD_DELETE
In-Reply-To: <55B7B92B.8000006@stroeder.com> ("Michael =?utf-8?Q?Str=C3=B6?=
 =?utf-8?Q?der=22's?= message of "Tue, 28 Jul 2015 19:17:31 +0200")
References: <ygewpxktn29.fsf@lame.message.id> <55B7B92B.8000006@stroeder.com>
Message-ID: <ygelhdzt4k5.fsf@lame.message.id>

Michael Str?der <michael at stroeder.com> writes:

> If you delete by explicit value the attribute must have a EQUALITY matching
> rule defined for it. This is typically not the case for BLOB attributes like
> jpegPhoto, userPKCS12 etc. So the current behaviour gives the best generic
> interoperability but is not necessarily the optimal way for every use-case.

Ah. That makes sense. Thank you for explaining it.

seph

From miroslaw.baran at gmail.com  Thu Jul 30 01:19:18 2015
From: miroslaw.baran at gmail.com (Miroslaw Baran)
Date: Thu, 30 Jul 2015 00:19:18 +0100
Subject: [python-ldap] OS X python-ldap woes, patch + request
In-Reply-To: <CALgW4fQevmF9e0OhoUyhy9mbOZSY0eZRmUZnYVMsEDo3d=Y0+w@mail.gmail.com>
References: <CALgW4fQevmF9e0OhoUyhy9mbOZSY0eZRmUZnYVMsEDo3d=Y0+w@mail.gmail.com>
Message-ID: <CALgW4fSNd72inQMzVdf6D7E4_p85Kk+mMDUKkAJFhBk2SC8P-A@mail.gmail.com>

Argh.

It seems that the latest openldap formula for homebrew is keg only (not
linked to /usr/local, that is).

Please find attached corrected patch:

--- setup.cfg.old    2015-07-24 16:32:10.000000000 +0100+++ setup.cfg
  2015-07-30 00:12:51.000000000 +0100@@ -1,6 +1,6 @@
 [_ldap]-library_dirs = /usr/lib /usr/lib64 /usr/local/lib
/usr/local/lib64-include_dirs = /usr/include /usr/include/sasl
/usr/local/include /usr/local/include/sasl+library_dirs =
/usr/local/opt/openldap/lib /usr/local/lib /usr/local/lib64 /usr/lib
/usr/lib64+include_dirs = /usr/local/opt/openldap/include
/usr/local/include /usr/local/include/sasl /usr/include
/usr/include/sasl
 defines = HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R
 extra_compile_args =
 extra_objects =

Sorry for the inconvenience,
Best regards
? Miroslaw Baran
?



On 24 July 2015 at 16:43, Miroslaw Baran <miroslaw.baran at gmail.com> wrote:

> Hey,
>
> Michael, if that wouldn?t be much of a problem, would you consider
> changing the order of library/include directories in setup.cfg?
>
> It?s the only think that keeps python-ldap from working from scratch with
> homebrew?s openldap package installed. Diff inline and as an attachment for
> your convenience.
>
> Best regards
> ? Miroslaw Baran
>
>  --- setup.cfg.old    2015-07-24 16:32:10.000000000 +0100+++ setup.cfg    2015-07-24 16:32:55.000000000 +0100@@ -1,6 +1,6 @@
>  [_ldap]-library_dirs = /usr/lib /usr/lib64 /usr/local/lib /usr/local/lib64 -include_dirs = /usr/include /usr/include/sasl /usr/local/include /usr/local/include/sasl +library_dirs = /usr/local/lib /usr/local/lib64 /usr/lib /usr/lib64+include_dirs = /usr/local/include /usr/local/include/sasl /usr/include /usr/include/sasl
>  defines = HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R
>  extra_compile_args =
>  extra_objects =
>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150730/cabcadf8/attachment.html>
-------------- next part --------------
--- setup.cfg.old	2015-07-24 16:32:10.000000000 +0100
+++ setup.cfg	2015-07-30 00:12:51.000000000 +0100
@@ -1,6 +1,6 @@
 [_ldap]
-library_dirs = /usr/lib /usr/lib64 /usr/local/lib /usr/local/lib64 
-include_dirs = /usr/include /usr/include/sasl /usr/local/include /usr/local/include/sasl 
+library_dirs = /usr/local/opt/openldap/lib /usr/local/lib /usr/local/lib64 /usr/lib /usr/lib64
+include_dirs = /usr/local/opt/openldap/include /usr/local/include /usr/local/include/sasl /usr/include /usr/include/sasl 
 defines = HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R
 extra_compile_args = 
 extra_objects = 

From whchen1080 at gmail.com  Mon Aug 10 11:26:04 2015
From: whchen1080 at gmail.com (=?UTF-8?B?6ZmI5Lyf5rSq?=)
Date: Mon, 10 Aug 2015 17:26:04 +0800
Subject: [python-ldap]  GSSAPI and Active Directory
Message-ID: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>

I'm unable to search Active Directory with GSSAPI for some reason.


Here's a small test script I've been using.

import ldap
import ldap.sasl

adconn = ldap.initialize('ldap://192.168.1.198:389/', trace_level=1)
adconn.protocol_version = ldap.VERSION3
sasl_auth = ldap.sasl.sasl(
           {
           },
             'GSSAPI'
             )

adconn.sasl_interactive_bind_s('', sasl_auth)



It fails every time with

  C:\Users\whchen\Downloads>python test_ldap.py

*** <ldap.ldapobject.SimpleLDAPObject instance at 0x02217CD8> ldap://
192.168.1.1 98:389/ - SimpleLDAPObject.set_option ((17, 3), {}) ***
<ldap.ldapobject.SimpleLDAPObject instance at 0x02217CD8> ldap://192.168.1.1
98:389/ - SimpleLDAPObject.set_option ((17, 3), {}) ***
<ldap.ldapobject.SimpleLDAPObject instance at 0x02217CD8> ldap://192.168.1.1
98:389/ - SimpleLDAPObject.sasl_interactive_bind_s (('', <ldap.sasl.sasl
instance at 0x0226E1E8>, None, None, 2), {}) Traceback (most recent call
last): File "test_ldap.py", line 16, in <module>
adconn.sasl_interactive_bind_s('', sasl_auth) File
"C:\Python27\lib\site-packages\ldap\ldapobject.py", line 244, in sasl_int
eractive_bind_s return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestContr
olTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) File
"C:\Python27\lib\site-packages\ldap\ldapobject.py", line 106, in _ldap_ca
ll result = func(*args,**kwargs) ldap.LOCAL_ERROR: {'info': 'SASL(-1):
generic failure: Unable to find a callback : 2', 'desc': 'Local error'}


I do not know how to configure the client authentication information,
and I know "ldap admin" software support auth mechanism is not simple
and exchange authentication information by username / password , I
would like to know python-ldap support?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150810/49df1904/attachment.html>

From michael at stroeder.com  Mon Aug 10 17:15:46 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 10 Aug 2015 17:15:46 +0200
Subject: [python-ldap] GSSAPI and Active Directory
In-Reply-To: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>
References: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>
Message-ID: <55C8C022.4010003@stroeder.com>

??? wrote:
> I'm unable to search Active Directory with GSSAPI for some reason.
> 
> 
> Here's a small test script I've been using.
> 
> import ldap
> import ldap.sasl
> 
> adconn = ldap.initialize('ldap://192.168.1.198:389/', trace_level=1)
> adconn.protocol_version = ldap.VERSION3
> sasl_auth = ldap.sasl.sasl(
>            {
>            },
>              'GSSAPI'
>              )
> 
> adconn.sasl_interactive_bind_s('', sasl_auth)
> 
> 
> 
> It fails every time with
> 
>   C:\Users\whchen\Downloads>python test_ldap.py

It seems you're on Windows.

I don't know the detailed status of SASL support in current Windows builds of
python-ldap but IMO SASL/GSSAPI does not work on Windows. Especially this
would require to install Kerberos for Windows and build against that. Current
KfW releases seem to be able to make use of the Windows ticket store but I
never tried out myself.

SASL/GSSAPI with MS AD works ok on most Linux boxes with LDAP libs built with
SASL and Kerberos libs.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150810/b196b04b/attachment.bin>

From whchen1080 at gmail.com  Tue Aug 11 09:50:22 2015
From: whchen1080 at gmail.com (=?UTF-8?B?6ZmI5Lyf5rSq?=)
Date: Tue, 11 Aug 2015 15:50:22 +0800
Subject: [python-ldap] GSSAPI and Active Directory
In-Reply-To: <55C8C022.4010003@stroeder.com>
References: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>
 <55C8C022.4010003@stroeder.com>
Message-ID: <CAJd5k5=W5zHCNvjHyAmo0fEU2vVbaWXJGoc7bU-wesKNFbygUQ@mail.gmail.com>

In the Linux environment, I tried to run this script:


import ldap
import ldap.sasl

adconn = ldap.initialize('ldap://192.168.1.198:389')
adconn.protocol_version = ldap.VERSION3
sasl_auth = ldap.sasl.sasl(
          {
            ldap.sasl.CB_AUTHNAME:"",
            ldap.sasl.CB_PASS    :"",
          },
            'GSSAPI'
            )
adconn.sasl_interactive_bind_s('', sasl_auth)

result:

root at 872d112a0c37:/var/edo/wo# bin/python test_ldap.py
Traceback (most recent call last):
  File "bin/python", line 275, in <module>
    exec(compile(__file__f.read(), __file__, "exec"))
  File "test_ldap.py", line 13, in <module>
    adconn.sasl_interactive_bind_s('', sasl_auth)
  File
"/opt/buildout-cache/eggs/python_ldap-2.4.14-py2.7-linux-x86_64.egg/ldap/ldapobject.py",
line 229, in sasl_interactive_bind_s
    return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
  File
"/opt/buildout-cache/eggs/python_ldap-2.4.14-py2.7-linux-x86_64.egg/ldap/ldapobject.py",
line 99, in _ldap_call
    result = func(*args,**kwargs)
ldap.LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (No
Kerberos credentials available)', 'desc': 'Local error'}

Is that python-ldap  no support username/password as credentials to login
in MS AD server which only support GSSAPI?

2015-08-10 23:15 GMT+08:00 Michael Str?der <michael at stroeder.com>:

> ??? wrote:
> > I'm unable to search Active Directory with GSSAPI for some reason.
> >
> >
> > Here's a small test script I've been using.
> >
> > import ldap
> > import ldap.sasl
> >
> > adconn = ldap.initialize('ldap://192.168.1.198:389/', trace_level=1)
> > adconn.protocol_version = ldap.VERSION3
> > sasl_auth = ldap.sasl.sasl(
> >            {
> >            },
> >              'GSSAPI'
> >              )
> >
> > adconn.sasl_interactive_bind_s('', sasl_auth)
> >
> >
> >
> > It fails every time with
> >
> >   C:\Users\whchen\Downloads>python test_ldap.py
>
> It seems you're on Windows.
>
> I don't know the detailed status of SASL support in current Windows builds
> of
> python-ldap but IMO SASL/GSSAPI does not work on Windows. Especially this
> would require to install Kerberos for Windows and build against that.
> Current
> KfW releases seem to be able to make use of the Windows ticket store but I
> never tried out myself.
>
> SASL/GSSAPI with MS AD works ok on most Linux boxes with LDAP libs built
> with
> SASL and Kerberos libs.
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150811/7017a3fd/attachment.html>

From chaoseternal at gmail.com  Wed Aug 12 00:52:23 2015
From: chaoseternal at gmail.com (Jun Sheng)
Date: Wed, 12 Aug 2015 06:52:23 +0800
Subject: [python-ldap] GSSAPI and Active Directory
In-Reply-To: <CAJd5k5=W5zHCNvjHyAmo0fEU2vVbaWXJGoc7bU-wesKNFbygUQ@mail.gmail.com>
References: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>
 <55C8C022.4010003@stroeder.com>
 <CAJd5k5=W5zHCNvjHyAmo0fEU2vVbaWXJGoc7bU-wesKNFbygUQ@mail.gmail.com>
Message-ID: <CAAYzEVB6gZ6zcqkNGhEWJ6YSOJnYVAXdSOa7jW6ccrjQRPfVug@mail.gmail.com>

I remember if GSSAPI is used, a successful kerberos login (kinit) must
be performed before doing ldap_bind, but I am not very sure.

Still, AD supports digest-md5, I suggest you try that first.

On Tue, Aug 11, 2015 at 3:50 PM, ??? <whchen1080 at gmail.com> wrote:
> In the Linux environment, I tried to run this script:
>
>
> import ldap
> import ldap.sasl
>
> adconn = ldap.initialize('ldap://192.168.1.198:389')
> adconn.protocol_version = ldap.VERSION3
> sasl_auth = ldap.sasl.sasl(
>           {
>             ldap.sasl.CB_AUTHNAME:"",
>             ldap.sasl.CB_PASS    :"",
>           },
>             'GSSAPI'
>             )
> adconn.sasl_interactive_bind_s('', sasl_auth)
>
> result:
>
> root at 872d112a0c37:/var/edo/wo# bin/python test_ldap.py
> Traceback (most recent call last):
>   File "bin/python", line 275, in <module>
>     exec(compile(__file__f.read(), __file__, "exec"))
>   File "test_ldap.py", line 13, in <module>
>     adconn.sasl_interactive_bind_s('', sasl_auth)
>   File
> "/opt/buildout-cache/eggs/python_ldap-2.4.14-py2.7-linux-x86_64.egg/ldap/ldapobject.py",
> line 229, in sasl_interactive_bind_s
>     return
> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
>   File
> "/opt/buildout-cache/eggs/python_ldap-2.4.14-py2.7-linux-x86_64.egg/ldap/ldapobject.py",
> line 99, in _ldap_call
>     result = func(*args,**kwargs)
> ldap.LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (No
> Kerberos credentials available)', 'desc': 'Local error'}
>
> Is that python-ldap  no support username/password as credentials to login in
> MS AD server which only support GSSAPI?
>
> 2015-08-10 23:15 GMT+08:00 Michael Str?der <michael at stroeder.com>:
>>
>> ??? wrote:
>> > I'm unable to search Active Directory with GSSAPI for some reason.
>> >
>> >
>> > Here's a small test script I've been using.
>> >
>> > import ldap
>> > import ldap.sasl
>> >
>> > adconn = ldap.initialize('ldap://192.168.1.198:389/', trace_level=1)
>> > adconn.protocol_version = ldap.VERSION3
>> > sasl_auth = ldap.sasl.sasl(
>> >            {
>> >            },
>> >              'GSSAPI'
>> >              )
>> >
>> > adconn.sasl_interactive_bind_s('', sasl_auth)
>> >
>> >
>> >
>> > It fails every time with
>> >
>> >   C:\Users\whchen\Downloads>python test_ldap.py
>>
>> It seems you're on Windows.
>>
>> I don't know the detailed status of SASL support in current Windows builds
>> of
>> python-ldap but IMO SASL/GSSAPI does not work on Windows. Especially this
>> would require to install Kerberos for Windows and build against that.
>> Current
>> KfW releases seem to be able to make use of the Windows ticket store but I
>> never tried out myself.
>>
>> SASL/GSSAPI with MS AD works ok on most Linux boxes with LDAP libs built
>> with
>> SASL and Kerberos libs.
>>
>> Ciao, Michael.
>>
>
>
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap
>

From whchen1080 at gmail.com  Wed Aug 12 03:17:36 2015
From: whchen1080 at gmail.com (=?UTF-8?B?6ZmI5Lyf5rSq?=)
Date: Wed, 12 Aug 2015 09:17:36 +0800
Subject: [python-ldap] GSSAPI and Active Directory
In-Reply-To: <CAAYzEVB6gZ6zcqkNGhEWJ6YSOJnYVAXdSOa7jW6ccrjQRPfVug@mail.gmail.com>
References: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>
 <55C8C022.4010003@stroeder.com>
 <CAJd5k5=W5zHCNvjHyAmo0fEU2vVbaWXJGoc7bU-wesKNFbygUQ@mail.gmail.com>
 <CAAYzEVB6gZ6zcqkNGhEWJ6YSOJnYVAXdSOa7jW6ccrjQRPfVug@mail.gmail.com>
Message-ID: <CAJd5k5k1=0VoJ=ZkkUQC-L6CZZ4yuhW4rOEPF0LLGHuHn1Hd9g@mail.gmail.com>

I try to use digest-md5:

source:

import ldap
import ldap.sasl

adconn = ldap.initialize('ldap://192.168.1.198:389')
adconn.protocol_version = ldap.VERSION3
sasl_auth = ldap.sasl.sasl(
          {
            ldap.sasl.CB_AUTHNAME:"administrator",
            ldap.sasl.CB_PASS    :"",
          },
          'digest-md5'
            )
adconn.sasl_interactive_bind_s('', sasl_auth)

result:

cwh at zopen05:~/gitlab/workonline$ python test_ldap.py
Traceback (most recent call last):
  File "test_ldap.py", line 13, in <module>
    adconn.sasl_interactive_bind_s('', sasl_auth)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 227, in
sasl_interactive_bind_s
    return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 96, in
_ldap_call
    result = func(*args,**kwargs)
ldap.INVALID_CREDENTIALS: {'info': "80090303: LdapErr: DSID-0C0904BE,
comment: The digest-uri does not match any LDAP SPN's registered for this
server., data 0, v1db1", 'desc': 'Invalid credentials'}



2015-08-12 6:52 GMT+08:00 Jun Sheng <chaoseternal at gmail.com>:

> I remember if GSSAPI is used, a successful kerberos login (kinit) must
> be performed before doing ldap_bind, but I am not very sure.
>
> Still, AD supports digest-md5, I suggest you try that first.
>
> On Tue, Aug 11, 2015 at 3:50 PM, ??? <whchen1080 at gmail.com> wrote:
> > In the Linux environment, I tried to run this script:
> >
> >
> > import ldap
> > import ldap.sasl
> >
> > adconn = ldap.initialize('ldap://192.168.1.198:389')
> > adconn.protocol_version = ldap.VERSION3
> > sasl_auth = ldap.sasl.sasl(
> >           {
> >             ldap.sasl.CB_AUTHNAME:"",
> >             ldap.sasl.CB_PASS    :"",
> >           },
> >             'GSSAPI'
> >             )
> > adconn.sasl_interactive_bind_s('', sasl_auth)
> >
> > result:
> >
> > root at 872d112a0c37:/var/edo/wo# bin/python test_ldap.py
> > Traceback (most recent call last):
> >   File "bin/python", line 275, in <module>
> >     exec(compile(__file__f.read(), __file__, "exec"))
> >   File "test_ldap.py", line 13, in <module>
> >     adconn.sasl_interactive_bind_s('', sasl_auth)
> >   File
> >
> "/opt/buildout-cache/eggs/python_ldap-2.4.14-py2.7-linux-x86_64.egg/ldap/ldapobject.py",
> > line 229, in sasl_interactive_bind_s
> >     return
> >
> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
> >   File
> >
> "/opt/buildout-cache/eggs/python_ldap-2.4.14-py2.7-linux-x86_64.egg/ldap/ldapobject.py",
> > line 99, in _ldap_call
> >     result = func(*args,**kwargs)
> > ldap.LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error:
> > Unspecified GSS failure.  Minor code may provide more information (No
> > Kerberos credentials available)', 'desc': 'Local error'}
> >
> > Is that python-ldap  no support username/password as credentials to
> login in
> > MS AD server which only support GSSAPI?
> >
> > 2015-08-10 23:15 GMT+08:00 Michael Str?der <michael at stroeder.com>:
> >>
> >> ??? wrote:
> >> > I'm unable to search Active Directory with GSSAPI for some reason.
> >> >
> >> >
> >> > Here's a small test script I've been using.
> >> >
> >> > import ldap
> >> > import ldap.sasl
> >> >
> >> > adconn = ldap.initialize('ldap://192.168.1.198:389/', trace_level=1)
> >> > adconn.protocol_version = ldap.VERSION3
> >> > sasl_auth = ldap.sasl.sasl(
> >> >            {
> >> >            },
> >> >              'GSSAPI'
> >> >              )
> >> >
> >> > adconn.sasl_interactive_bind_s('', sasl_auth)
> >> >
> >> >
> >> >
> >> > It fails every time with
> >> >
> >> >   C:\Users\whchen\Downloads>python test_ldap.py
> >>
> >> It seems you're on Windows.
> >>
> >> I don't know the detailed status of SASL support in current Windows
> builds
> >> of
> >> python-ldap but IMO SASL/GSSAPI does not work on Windows. Especially
> this
> >> would require to install Kerberos for Windows and build against that.
> >> Current
> >> KfW releases seem to be able to make use of the Windows ticket store
> but I
> >> never tried out myself.
> >>
> >> SASL/GSSAPI with MS AD works ok on most Linux boxes with LDAP libs built
> >> with
> >> SASL and Kerberos libs.
> >>
> >> Ciao, Michael.
> >>
> >
> >
> > _______________________________________________
> > python-ldap mailing list
> > python-ldap at python.org
> > https://mail.python.org/mailman/listinfo/python-ldap
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150812/392f905d/attachment-0001.html>

From michael at stroeder.com  Wed Aug 12 19:51:09 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 12 Aug 2015 19:51:09 +0200
Subject: [python-ldap] GSSAPI and Active Directory
In-Reply-To: <CAJd5k5k1=0VoJ=ZkkUQC-L6CZZ4yuhW4rOEPF0LLGHuHn1Hd9g@mail.gmail.com>
References: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>
 <55C8C022.4010003@stroeder.com>
 <CAJd5k5=W5zHCNvjHyAmo0fEU2vVbaWXJGoc7bU-wesKNFbygUQ@mail.gmail.com>
 <CAAYzEVB6gZ6zcqkNGhEWJ6YSOJnYVAXdSOa7jW6ccrjQRPfVug@mail.gmail.com>
 <CAJd5k5k1=0VoJ=ZkkUQC-L6CZZ4yuhW4rOEPF0LLGHuHn1Hd9g@mail.gmail.com>
Message-ID: <55CB878D.8020403@stroeder.com>

??? wrote:
> I try to use digest-md5:
> [..]
> ldap.INVALID_CREDENTIALS: {'info': "80090303: LdapErr: DSID-0C0904BE,
> comment: The digest-uri does not match any LDAP SPN's registered for this
> server., data 0, v1db1", 'desc': 'Invalid credentials'}
> 
> 
> 2015-08-12 6:52 GMT+08:00 Jun Sheng <chaoseternal at gmail.com>:
> 
>> I remember if GSSAPI is used, a successful kerberos login (kinit) must
>> be performed before doing ldap_bind, but I am not very sure.
>>
>> Still, AD supports digest-md5, I suggest you try that first.
>>
>> On Tue, Aug 11, 2015 at 3:50 PM, ??? <whchen1080 at gmail.com> wrote:
>>> In the Linux environment, I tried to run this script:
>>> [..]
>>> sasl_auth = ldap.sasl.sasl(
>>>           {
>>>             ldap.sasl.CB_AUTHNAME:"",
>>>             ldap.sasl.CB_PASS    :"",
>>>           },
>>>             'GSSAPI'
>>>             )
>>> adconn.sasl_interactive_bind_s('', sasl_auth)
>>> [..]
>>> ldap.LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error:
>>> Unspecified GSS failure.  Minor code may provide more information (No
>>> Kerberos credentials available)', 'desc': 'Local error'}

It works for me both GSSAPI and DIGEST-MD5.

But MS AD is pretty picky regarding correct DNS names to be used. So this
likely does not work:

ldap.initialize('ldap://192.168.1.198:389')

Put correct DNS names in their. Start with locating the DCs hostnames:

host -t srv _ldap._tcp.example.com

with example.com being the DNS domain name of your AD domain.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150812/d8353adf/attachment.bin>

From michael at stroeder.com  Thu Aug 13 10:08:31 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 13 Aug 2015 10:08:31 +0200
Subject: [python-ldap] LDAPcon 2015 in Edinburgh
Message-ID: <55CC507F.8020105@stroeder.com>

HI!

The fifth International Conference on LDAP, Directory Services and
Identity Management will be held in Edinburgh this year:

    Tutorials: 11th November 2015
    Conference: 12th and 13th November 2015

The LDAPcon web site now has all the relevant details for attending and
sponsoring(!) this year's LDAP conference in Edinburgh:

http://ldapcon.org/2015/

The conference has a full programme with 22 peer-reviewed papers across
two days plus a 2-track tutorial day and a poster session.

I'm looking forward to the great programme with well-known speakers and
especially I'd like to meet members of the python-ldap community there.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150813/6b1c594e/attachment.bin>

From chaoseternal at gmail.com  Thu Aug 13 13:08:03 2015
From: chaoseternal at gmail.com (Jun Sheng)
Date: Thu, 13 Aug 2015 19:08:03 +0800
Subject: [python-ldap] GSSAPI and Active Directory
In-Reply-To: <55CB878D.8020403@stroeder.com>
References: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>
 <55C8C022.4010003@stroeder.com>
 <CAJd5k5=W5zHCNvjHyAmo0fEU2vVbaWXJGoc7bU-wesKNFbygUQ@mail.gmail.com>
 <CAAYzEVB6gZ6zcqkNGhEWJ6YSOJnYVAXdSOa7jW6ccrjQRPfVug@mail.gmail.com>
 <CAJd5k5k1=0VoJ=ZkkUQC-L6CZZ4yuhW4rOEPF0LLGHuHn1Hd9g@mail.gmail.com>
 <55CB878D.8020403@stroeder.com>
Message-ID: <CAAYzEVBnHjvJciV1c3zZmsCethRUAEuVFTqLc+DeNUCzpLq46w@mail.gmail.com>

On Thu, Aug 13, 2015 at 1:51 AM, Michael Str?der <michael at stroeder.com> wrote:
> ??? wrote:
>> I try to use digest-md5:
>> [..]
>> ldap.INVALID_CREDENTIALS: {'info': "80090303: LdapErr: DSID-0C0904BE,
>> comment: The digest-uri does not match any LDAP SPN's registered for this
>> server., data 0, v1db1", 'desc': 'Invalid credentials'}
>>
>>
>> 2015-08-12 6:52 GMT+08:00 Jun Sheng <chaoseternal at gmail.com>:
>>
>>> I remember if GSSAPI is used, a successful kerberos login (kinit) must
>>> be performed before doing ldap_bind, but I am not very sure.
>>>
>>> Still, AD supports digest-md5, I suggest you try that first.
>>>
>>> On Tue, Aug 11, 2015 at 3:50 PM, ??? <whchen1080 at gmail.com> wrote:
>>>> In the Linux environment, I tried to run this script:
>>>> [..]
>>>> sasl_auth = ldap.sasl.sasl(
>>>>           {
>>>>             ldap.sasl.CB_AUTHNAME:"",
>>>>             ldap.sasl.CB_PASS    :"",
>>>>           },
>>>>             'GSSAPI'
>>>>             )
>>>> adconn.sasl_interactive_bind_s('', sasl_auth)
>>>> [..]
>>>> ldap.LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error:
>>>> Unspecified GSS failure.  Minor code may provide more information (No
>>>> Kerberos credentials available)', 'desc': 'Local error'}
>
> It works for me both GSSAPI and DIGEST-MD5.
>
> But MS AD is pretty picky regarding correct DNS names to be used. So this
> likely does not work:

I think this requirement is employed by DIGEST-MD5 or say Cyrus-SASL


>
> ldap.initialize('ldap://192.168.1.198:389')
>
> Put correct DNS names in their. Start with locating the DCs hostnames:
>
> host -t srv _ldap._tcp.example.com
>
> with example.com being the DNS domain name of your AD domain.
>
> Ciao, Michael.
>
>
>
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap
>

From michael at stroeder.com  Thu Aug 13 13:12:55 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 13 Aug 2015 13:12:55 +0200
Subject: [python-ldap] GSSAPI and Active Directory
In-Reply-To: <CAAYzEVBnHjvJciV1c3zZmsCethRUAEuVFTqLc+DeNUCzpLq46w@mail.gmail.com>
References: <CAJd5k5kHE-SvMxNYveC0pk2iEwWAAv98WyXPZPRkkCcoq_izTg@mail.gmail.com>	<55C8C022.4010003@stroeder.com>	<CAJd5k5=W5zHCNvjHyAmo0fEU2vVbaWXJGoc7bU-wesKNFbygUQ@mail.gmail.com>	<CAAYzEVB6gZ6zcqkNGhEWJ6YSOJnYVAXdSOa7jW6ccrjQRPfVug@mail.gmail.com>	<CAJd5k5k1=0VoJ=ZkkUQC-L6CZZ4yuhW4rOEPF0LLGHuHn1Hd9g@mail.gmail.com>	<55CB878D.8020403@stroeder.com>
 <CAAYzEVBnHjvJciV1c3zZmsCethRUAEuVFTqLc+DeNUCzpLq46w@mail.gmail.com>
Message-ID: <55CC7BB7.6010504@stroeder.com>

Jun Sheng wrote:
> On Thu, Aug 13, 2015 at 1:51 AM, Michael Str?der <michael at stroeder.com> wrote:
>> ??? wrote:
>>> I try to use digest-md5:
>>> [..]
>>> ldap.INVALID_CREDENTIALS: {'info': "80090303: LdapErr: DSID-0C0904BE,
>>> comment: The digest-uri does not match any LDAP SPN's registered for this
>>> server., data 0, v1db1", 'desc': 'Invalid credentials'}
>>>
>>>
>>> 2015-08-12 6:52 GMT+08:00 Jun Sheng <chaoseternal at gmail.com>:
>>>
>>>> I remember if GSSAPI is used, a successful kerberos login (kinit) must
>>>> be performed before doing ldap_bind, but I am not very sure.
>>>>
>>>> Still, AD supports digest-md5, I suggest you try that first.
>>>>
>>>> On Tue, Aug 11, 2015 at 3:50 PM, ??? <whchen1080 at gmail.com> wrote:
>>>>> In the Linux environment, I tried to run this script:
>>>>> [..]
>>>>> sasl_auth = ldap.sasl.sasl(
>>>>>           {
>>>>>             ldap.sasl.CB_AUTHNAME:"",
>>>>>             ldap.sasl.CB_PASS    :"",
>>>>>           },
>>>>>             'GSSAPI'
>>>>>             )
>>>>> adconn.sasl_interactive_bind_s('', sasl_auth)
>>>>> [..]
>>>>> ldap.LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error:
>>>>> Unspecified GSS failure.  Minor code may provide more information (No
>>>>> Kerberos credentials available)', 'desc': 'Local error'}
>>
>> It works for me both GSSAPI and DIGEST-MD5.
>>
>> But MS AD is pretty picky regarding correct DNS names to be used. So this
>> likely does not work:
> 
> I think this requirement is employed by DIGEST-MD5 or say Cyrus-SASL

Have a look at the error message in the DIGEST-MD5 case.
It starts with "80090303: LdapErr: DSID-0C0904BE .." which is typical for
diagnostic messages returned in LDAP results by MS AD.

In the GSSAPI case there are definitely additional dependencies on Kerberos
principal names and correct DNS entries used. In fact "fix your DNS" is the
standard answer when experiencing issues like that.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150813/26f40c8a/attachment.bin>

From william at blackhats.net.au  Wed Aug 26 03:35:26 2015
From: william at blackhats.net.au (William Brown)
Date: Wed, 26 Aug 2015 11:05:26 +0930
Subject: [python-ldap] Deref request control appears to not recieve results, 
Message-ID: <1440552926.3916.68.camel@blackhats.net.au>

Hi,

I am trying to write a dereference control [0] to use for the 389ds project,
with the intent that once it is working, to include it in python-ldap.

I am adding the control to the search with:

try:
    drc = DereferenceControl(True, deref=deref.encode('UTF-8'))
    sctrl = [drc]
    self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl)

    res = self.search(base, scope, *args, **kwargs)
    resp_type, resp_data, resp_msgid, decoded_resp_ctrls = self.result3(res,
resp_ctrl_classes={CONTROL_DEREF: DereferenceControl})
finally:
    self.set_option(ldap.OPT_SERVER_CONTROLS, [])
return resp_data, decoded_resp_ctrls

The request is formatted correctly through the control [1], and I can see the
search on the 389ds server as:

[26/Aug/2015:10:49:04 +091800] deref-plugin - --> deref_pre_search
[26/Aug/2015:10:49:04 +091800] deref-plugin - <-- deref_pre_op
[26/Aug/2015:10:49:05 +091800] - Calling plugin 'deref' #2 type 410
[26/Aug/2015:10:49:05 +091800] deref-plugin - deref slapi_value_get_string
uid=test,dc=example,dc=com
[26/Aug/2015:10:49:05 +091800] - Calling plugin 'deref' #2 type 403
[26/Aug/2015:10:49:05 +091800] deref-plugin - --> deref_pre_search
[26/Aug/2015:10:49:05 +091800] deref-plugin - <-- deref_pre_op
[26/Aug/2015:10:49:05 +091800] - Calling plugin 'deref' #2 type 410
[26/Aug/2015:10:49:05 +091800] deref-plugin - Added control -1073736768
[26/Aug/2015:10:49:05 +091800] deref-plugin - Sending deref results to client

So I can see that the control is processed, the search occurs, and the correct
result of uid=test is found and dereferenced, and the control is added to the
server response. 

However, with trace_level=3, I don't see this result in python ldap:

*** <lib389.DirSrv instance at 0x7f9625f6d2d8>
ldap://localhost.localdomain:54321/ - DirSrv.set_option
((18,
  [('1.3.6.1.4.1.4203.666.5.16',
    True,
    '0\x1b0\x19\x04\x0cuniqueMember0\t\x04\x03uid\x04\x02dn')]),
 {})
=> result:
None
...
*** <lib389.DirSrv instance at 0x7f9625f6d2d8>
ldap://localhost.localdomain:54321/ - DirSrv.search_ext
(('dc=example,dc=com', 2, '(cn=testgroup)', None, 0, None, None, -1, 0), {})
=> result:
8
...
*** <lib389.DirSrv instance at 0x7f9625f6d2d8>
ldap://localhost.localdomain:54321/ - DirSrv.result4
((8, 1, -1, 0, 0, 0), {})
=> result:
(101,
 [('cn=testgroup,dc=example,dc=com',
   {'cn': ['testgroup'],
    'objectClass': ['top', 'extensibleobject'],
    'uniqueMember': ['uid=test,dc=example,dc=com']})],
 8,
 [])
*** <lib389.DirSrv instance at 0x7f9625f6d2d8>
ldap://localhost.localdomain:54321/ - DirSrv.set_option
((18, []), {})
=> result:
None

Printing my values of resp_data, decoded_resp_ctrls:

[('cn=testgroup,dc=example,dc=com', {'objectClass': ['top', 'extensibleobject'],
'uniqueMember': ['uid=test,dc=example,dc=com'], 'cn': ['testgroup']})]
[]


Where should I go from here to continue to investigate this? I'm not seeing any
calls into my decodeControlValue function on the control, so I suspect either I
haven't registered my DereferenceControl correctly to be used for responses, or
the response is "going missing" at some stage. Doing this same deref with
ldapsearch -E yields a correct response, so it's not a server issue as I can
see.

Your advice is appreciated.

Sincerely,

William




[0] https://tools.ietf.org/html/draft-masarati-ldap-deref-00
[1]:

from pyasn1.type import namedtype,univ
from pyasn1.codec.ber import encoder,decoder
from pyasn1_modules.rfc2251 import AttributeDescription

# Could use AttributeDescriptionList

"""
 controlValue ::= SEQUENCE OF derefSpec DerefSpec

 DerefSpec ::= SEQUENCE {
     derefAttr       attributeDescription,    ; with DN syntax
     attributes      AttributeList }

 AttributeList ::= SEQUENCE OF attr AttributeDescription

 Needs to be matched by ber_scanf(ber, "{a{v}}", ... )
"""

CONTROL_DEREF = '1.3.6.1.4.1.4203.666.5.16'

class AttributeList(univ.SequenceOf):
    componentType = AttributeDescription()

class DerefSpec(univ.Sequence):
    componentType = namedtype.NamedTypes(
        namedtype.NamedType('derefAttr', AttributeDescription()),
        namedtype.NamedType('attributes', AttributeList()),
    )

class DerefControlValue(univ.SequenceOf):
    componentType = DerefSpec()

class DereferenceControl(LDAPControl):
    """
    Dereference Control
    """

    def __init__(self, criticality, deref):
        LDAPControl.__init__(self, CONTROL_DEREF, criticality)
        self.deref = deref

    def encodeControlValue(self):
        cv = DerefControlValue()
        cvi = 0
        for derefSpec in self.deref.split(';'):
            derefAttr, attributes = derefSpec.split(':')
            attributes = attributes.split(',')
            al = AttributeList()
            i = 0
            while len(attributes) > 0:
                al.setComponentByPosition(i, attributes.pop())
                i += 1
            ds = DerefSpec()
            ds.setComponentByName('derefAttr', derefAttr)
            ds.setComponentByName('attributes', al)
            cv.setComponentByPosition(cvi, ds)
            cvi += 1
        print(cv.prettyPrint())
        return encoder.encode(cv)

    def decodeControlValue(self,encodedControlValue):
        print('DEREF decode')
        print(encodedControlValue)

From seb at nmeos.net  Mon Sep  7 11:39:23 2015
From: seb at nmeos.net (=?ISO-8859-1?Q?S=E9bastien=20Douche?=)
Date: Mon, 07 Sep 2015 11:39:23 +0200
Subject: [python-ldap] Create a LDIF file with SSHA passwords
Message-ID: <1441618763.403684.376682449.2856FFE4@webmail.messagingengine.com>

Hi,
I want to create users in a file (with a LDIFParser class, user names
come from an another LDIF file). By defaults, the parser seems to write
simple text password. How to write SSHA password?


Thanks.



-- 
S?bastien Douche <seb at nmeos.net>
Twitter: @sdouche
http://douche.name

From michael at stroeder.com  Mon Sep  7 12:05:18 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 07 Sep 2015 12:05:18 +0200
Subject: [python-ldap] Create a LDIF file with SSHA passwords
In-Reply-To: <1441618763.403684.376682449.2856FFE4@webmail.messagingengine.com>
References: <1441618763.403684.376682449.2856FFE4@webmail.messagingengine.com>
Message-ID: <55ED615E.4050509@stroeder.com>

S?bastien Douche wrote:
> I want to create users in a file (with a LDIFParser class, user names
> come from an another LDIF file). By defaults, the parser seems to write
> simple text password. How to write SSHA password?

The LDIFWriter simply outputs raw binary strings in text representation
compliant to [1].

If you want to generate salted SHA-1 password then simply generate them
according to [2] and then write LDIF output.

Ciao, Michael.

[1] https://tools.ietf.org/html/rfc2849

[2] https://tools.ietf.org/html/draft-stroeder-hashed-userpassword-values

--
Michael Str?der
E-Mail: michael at stroeder.com
http://www.stroeder.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150907/559a869c/attachment.bin>

From seb at nmeos.net  Wed Sep  9 11:03:54 2015
From: seb at nmeos.net (=?ISO-8859-1?Q?S=E9bastien=20Douche?=)
Date: Wed, 09 Sep 2015 11:03:54 +0200
Subject: [python-ldap] Create a LDIF file with SSHA passwords
In-Reply-To: <55ED615E.4050509@stroeder.com>
References: <1441618763.403684.376682449.2856FFE4@webmail.messagingengine.com>
 <55ED615E.4050509@stroeder.com>
Message-ID: <1441789434.313589.378620025.0E48513F@webmail.messagingengine.com>

On Mon, 7 Sep 2015, at 12:05, Michael Str?der wrote:
> The LDIFWriter simply outputs raw binary strings in text representation
> compliant to [1].
> 
> If you want to generate salted SHA-1 password then simply generate them
> according to [2] and then write LDIF output.

Thanks Michael.



-- 
S?bastien Douche <seb at nmeos.net>
Twitter: @sdouche
http://douche.name

From stephen.butler at gmail.com  Sat Sep 12 11:34:18 2015
From: stephen.butler at gmail.com (Stephen J. Butler)
Date: Sat, 12 Sep 2015 04:34:18 -0500
Subject: [python-ldap] Adding msgid to LDAPError
Message-ID: <CAD4ANxW=ruTuT7w96G2cLpwLAbwQpnvHvyg3RcPjdLZj51WDzA@mail.gmail.com>

Hello,

I've run into a situation where I issue a bunch of LDAPObject.search()
requests and then loop while calling LDAPObject.result3() waiting for the
responses. However, some of my search() requests will return a
NO_SUCH_OBJECT error; and I'd like to just ignore that error and wait for
the rest of the results.

I can put the result3() in a try/except block, but when the exception
happens I won't know which messageID it belongs to. So in a loop like
this...

while active_msgids:
    try:
        res_type, res_data, res_msgid, res_sctrls =
conn.result3(self.result3(msgid=RES_ANY, all=0))
    except LDAPError as ldapErr:
        pass
    else:
        # Process successful result
        active_msgids.remove(res_msgid)

... the error msgid never gets removed from active_msgids, and I end up
looping forever.

Attached is a patch that adds "msgid" to LDAPError where it makes sense,
which is only for the result() set of methods. Link in case it gets
stripped: <https://uofi.box.com/s/nrhxqu1o3y37pjnbu5hkqopkfal1egfc>. It
lets me write code like this:

while active_msgids:
    try:
        res_type, res_data, res_msgid, res_sctrls =
conn.result3(self.result3(msgid=RES_ANY, all=0))
    except LDAPError as ldapErr:
        try:
            err_msgid = ldapErr.message['msgid']
        except:
            raise ldapErr
        else:
            active_args.remove(err_msgid)
    else:
        # Process successful result
        active_msgids.remove(res_msgid)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150912/e82e01af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-ldap-errmsgid.patch
Type: application/octet-stream
Size: 20337 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150912/e82e01af/attachment-0001.obj>

From michael at stroeder.com  Sat Sep 12 11:51:51 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 12 Sep 2015 11:51:51 +0200
Subject: [python-ldap] Adding msgid to LDAPError
In-Reply-To: <CAD4ANxW=ruTuT7w96G2cLpwLAbwQpnvHvyg3RcPjdLZj51WDzA@mail.gmail.com>
References: <CAD4ANxW=ruTuT7w96G2cLpwLAbwQpnvHvyg3RcPjdLZj51WDzA@mail.gmail.com>
Message-ID: <55F3F5B7.70608@stroeder.com>

Stephen J. Butler wrote:
> I've run into a situation where I issue a bunch of LDAPObject.search()
> requests and then loop while calling LDAPObject.result3() waiting for the
> responses. However, some of my search() requests will return a NO_SUCH_OBJECT
> error; and I'd like to just ignore that error and wait for the rest of the
> results.
> 
> I can put the result3() in a try/except block, but when the exception happens
> I won't know which messageID it belongs to. So in a loop like this...
> 
> while active_msgids:
>     try:
>         res_type, res_data, res_msgid, res_sctrls =
> conn.result3(self.result3(msgid=RES_ANY, all=0))
>     except LDAPError as ldapErr:
>         pass
>     else:
>         # Process successful result
>         active_msgids.remove(res_msgid)
> 
> ... the error msgid never gets removed from active_msgids, and I end up
> looping forever.
> 
> Attached is a patch that adds "msgid" to LDAPError where it makes sense, which
> is only for the result() set of methods.

Thanks for the patch. I will review more carefully later.

But just a quick question: Why not attach the msgid to also LDAPError
instances caused by write operations? Note that LDAP allows pipe-lining of
requests. You can send several write operations and deal with the result code
later. Your patch would be handy for those situations either.

While you're at it you could also attach the response controls (plural!)
returned by the server in the LDAPResult messages to the LDAPError instance.

This would e.g. solve the case of a simple bind failing because of an expired
password. Up to now the response control saying "password expired" cannot be
extracted.
Also OpenLDAP's experimental "What failed?" control would require this for
determining what went wrong when using slapo-constraint, slapo-unique...

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150912/44b4615a/attachment.bin>

From michael at stroeder.com  Sat Sep 12 12:09:36 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 12 Sep 2015 12:09:36 +0200
Subject: [python-ldap] Adding msgid to LDAPError
In-Reply-To: <55F3F5B7.70608@stroeder.com>
References: <CAD4ANxW=ruTuT7w96G2cLpwLAbwQpnvHvyg3RcPjdLZj51WDzA@mail.gmail.com>
 <55F3F5B7.70608@stroeder.com>
Message-ID: <55F3F9E0.5010407@stroeder.com>

Michael Str?der wrote:
> Stephen J. Butler wrote:
>> I've run into a situation where I issue a bunch of LDAPObject.search()
>> requests and then loop while calling LDAPObject.result3() waiting for the
>> responses. However, some of my search() requests will return a NO_SUCH_OBJECT
>> error; and I'd like to just ignore that error and wait for the rest of the
>> results.
>>
>> I can put the result3() in a try/except block, but when the exception happens
>> I won't know which messageID it belongs to. So in a loop like this...
>>
>> while active_msgids:
>>     try:
>>         res_type, res_data, res_msgid, res_sctrls =
>> conn.result3(self.result3(msgid=RES_ANY, all=0))
>>     except LDAPError as ldapErr:
>>         pass
>>     else:
>>         # Process successful result
>>         active_msgids.remove(res_msgid)
>>
>> ... the error msgid never gets removed from active_msgids, and I end up
>> looping forever.
>>
>> Attached is a patch that adds "msgid" to LDAPError where it makes sense, which
>> is only for the result() set of methods.
> 
> Thanks for the patch. I will review more carefully later.
> 
> But just a quick question: Why not attach the msgid to also LDAPError
> instances caused by write operations? Note that LDAP allows pipe-lining of
> requests. You can send several write operations and deal with the result code
> later. Your patch would be handy for those situations either.
> 
> While you're at it you could also attach the response controls (plural!)
> returned by the server in the LDAPResult messages to the LDAPError instance.
> 
> This would e.g. solve the case of a simple bind failing because of an expired
> password. Up to now the response control saying "password expired" cannot be
> extracted.
> Also OpenLDAP's experimental "What failed?" control would require this for
> determining what went wrong when using slapo-constraint, slapo-unique...

To add: For a while I've thought about a lock-free variant of LDAPObject class
which would also require this.

Ciao, Michael.


From stephen.butler at gmail.com  Sat Sep 12 12:09:55 2015
From: stephen.butler at gmail.com (Stephen J. Butler)
Date: Sat, 12 Sep 2015 05:09:55 -0500
Subject: [python-ldap] Adding msgid to LDAPError
In-Reply-To: <55F3F5B7.70608@stroeder.com>
References: <CAD4ANxW=ruTuT7w96G2cLpwLAbwQpnvHvyg3RcPjdLZj51WDzA@mail.gmail.com>
 <55F3F5B7.70608@stroeder.com>
Message-ID: <CAD4ANxWzPF2mRBVOLpiSDAjETj2=8p-pxv2Ri+5FKr843QNpZg@mail.gmail.com>

On Sat, Sep 12, 2015 at 4:51 AM, Michael Str?der <michael at stroeder.com>
wrote:

> But just a quick question: Why not attach the msgid to also LDAPError
> instances caused by write operations? Note that LDAP allows pipe-lining of
> requests. You can send several write operations and deal with the result
> code
> later. Your patch would be handy for those situations either.
>

Should work there too. It doesn't make sense to attach msgid inside stuff
like l_ldap_add_ext() because if it fails at that point there's no valid
msgid to track. So I did it all in l_ldap_result4(), which should be
generic enough to track any type of request, read or write.


> While you're at it you could also attach the response controls (plural!)
> returned by the server in the LDAPResult messages to the LDAPError
> instance.
>
> This would e.g. solve the case of a simple bind failing because of an
> expired
> password. Up to now the response control saying "password expired" cannot
> be
> extracted.
> Also OpenLDAP's experimental "What failed?" control would require this for
> determining what went wrong when using slapo-constraint, slapo-unique...
>

That's an interesting thought. Certainly useful, but I might want to rework
the patch into an LDAPerror and LDAPerrorExt so that we're constantly
specifying parameters that aren't used. Or is the project OK with default
parameters in the header file?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150912/c6d85cec/attachment.html>

From michael at stroeder.com  Sat Sep 12 12:15:36 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 12 Sep 2015 12:15:36 +0200
Subject: [python-ldap] Adding msgid to LDAPError
In-Reply-To: <CAD4ANxWzPF2mRBVOLpiSDAjETj2=8p-pxv2Ri+5FKr843QNpZg@mail.gmail.com>
References: <CAD4ANxW=ruTuT7w96G2cLpwLAbwQpnvHvyg3RcPjdLZj51WDzA@mail.gmail.com>
 <55F3F5B7.70608@stroeder.com>
 <CAD4ANxWzPF2mRBVOLpiSDAjETj2=8p-pxv2Ri+5FKr843QNpZg@mail.gmail.com>
Message-ID: <55F3FB48.6080408@stroeder.com>

Stephen J. Butler wrote:
> On Sat, Sep 12, 2015 at 4:51 AM, Michael Str?der <michael at stroeder.com
> <mailto:michael at stroeder.com>> wrote:
> 
>     But just a quick question: Why not attach the msgid to also LDAPError
>     instances caused by write operations? Note that LDAP allows pipe-lining of
>     requests. You can send several write operations and deal with the result code
>     later. Your patch would be handy for those situations either.
> 
> Should work there too. It doesn't make sense to attach msgid inside stuff
> like l_ldap_add_ext() because if it fails at that point there's no valid msgid
> to track. So I did it all in l_ldap_result4(), which should be generic enough
> to track any type of request, read or write.

Ah ok. Will test this.

>     While you're at it you could also attach the response controls (plural!)
>     returned by the server in the LDAPResult messages to the LDAPError instance.
> 
>     This would e.g. solve the case of a simple bind failing because of an expired
>     password. Up to now the response control saying "password expired" cannot be
>     extracted.
>     Also OpenLDAP's experimental "What failed?" control would require this for
>     determining what went wrong when using slapo-constraint, slapo-unique...
> 
> 
> That's an interesting thought. Certainly useful, but I might want to rework
> the patch into an LDAPerror and LDAPerrorExt

No, please not a different error class.

> so that we're constantly
> specifying parameters that aren't used. Or is the project OK with default
> parameters in the header file? 

The following options would be ok for me:

1. Set LDAPError's response control class attribute to None (not 0 or '').

2. Don't set response control class attribute at all so the application has to
properly deal with AttributeError/KeyError exception.

I have to admin the LDAPError class stuff is quite hackish and error-prone.
Since I'm not a C programmer I could not really fix it.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150912/286be066/attachment.bin>

From michael at stroeder.com  Fri Sep 18 13:32:09 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 18 Sep 2015 13:32:09 +0200
Subject: [python-ldap] Deref request control appears to not recieve
 results, 
In-Reply-To: <1440552926.3916.68.camel@blackhats.net.au>
References: <1440552926.3916.68.camel@blackhats.net.au>
Message-ID: <55FBF639.2090706@stroeder.com>

William Brown wrote:
> I am trying to write a dereference control [0] to use for the 389ds project,
> with the intent that once it is working, to include it in python-ldap.

Sorry for following up so late. Did you make any progress in the mean-time? Do
you want to contribute your deref implementation to python-ldap?

> So I can see that the control is processed, the search occurs, and the correct
> result of uid=test is found and dereferenced, and the control is added to the
> server response. 
> 
> However, with trace_level=3, I don't see this result in python ldap:
> 
> *** <lib389.DirSrv instance at 0x7f9625f6d2d8>
> ldap://localhost.localdomain:54321/ - DirSrv.set_option
> ((18,
>   [('1.3.6.1.4.1.4203.666.5.16',
>     True,
>     '0\x1b0\x19\x04\x0cuniqueMember0\t\x04\x03uid\x04\x02dn')]),
>  {})
> => result:
> None
> ...
> *** <lib389.DirSrv instance at 0x7f9625f6d2d8>
> ldap://localhost.localdomain:54321/ - DirSrv.search_ext
> (('dc=example,dc=com', 2, '(cn=testgroup)', None, 0, None, None, -1, 0), {})

Hmm, not sure whether using LDAPObject.set_option() method really works when
using controls.

You should add all the request controls for a search request to list argument
serverctrls when invoking LDAPObject.search_ext()/search_ext_s():

http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150918/9c168527/attachment.bin>

From pviktori at redhat.com  Fri Sep 18 15:36:18 2015
From: pviktori at redhat.com (Petr Viktorin)
Date: Fri, 18 Sep 2015 15:36:18 +0200
Subject: [python-ldap] [PATCH] Tests for the ldif module
Message-ID: <55FC1352.20105@redhat.com>

Hello,
I've written some basic tests for the ldif module. Do these look useful
to you?

-- 
Petr Viktorin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldif-tests.patch
Type: text/x-patch
Size: 4646 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150918/924ca72d/attachment.bin>

From michael at stroeder.com  Fri Sep 18 16:52:11 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 18 Sep 2015 16:52:11 +0200
Subject: [python-ldap] [PATCH] Tests for the ldif module
In-Reply-To: <55FC1352.20105@redhat.com>
References: <55FC1352.20105@redhat.com>
Message-ID: <55FC251B.4040101@stroeder.com>

Petr Viktorin wrote:
> I've written some basic tests for the ldif module. Do these look useful
> to you?

Highly appreciated. Committed to HEAD. Thanks!

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150918/8c051141/attachment-0001.bin>

From michael at stroeder.com  Sat Sep 19 15:48:19 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 19 Sep 2015 15:48:19 +0200
Subject: [python-ldap] New sub-module ldap.controls.deref
Message-ID: <55FD67A3.10806@stroeder.com>

HI!

I've committed new sub-module ldap.controls.deref which implements the
client-side of https://tools.ietf.org/html/draft-masarati-ldap-deref inspired
by some of William's snippets but slightly different. To be released pretty
soon in release 2.4.21.

See Demo/pyasn1/derefcontrol.py for a simple example script.
I've successfully tested with OpenLDAP 2.4.42+.
It would be nice if somebody could test with 389-ds.

Please test ASAP!

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150919/76a16a22/attachment.bin>

From michael at stroeder.com  Sat Sep 19 18:02:26 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 19 Sep 2015 18:02:26 +0200
Subject: [python-ldap] New sub-module ldap.controls.deref
In-Reply-To: <55FD67A3.10806@stroeder.com>
References: <55FD67A3.10806@stroeder.com>
Message-ID: <55FD8712.4070900@stroeder.com>

Michael Str?der wrote:
> I've committed new sub-module ldap.controls.deref which implements the
> client-side of https://tools.ietf.org/html/draft-masarati-ldap-deref inspired
> by some of William's snippets but slightly different. To be released pretty
> soon in release 2.4.21.
> 
> See Demo/pyasn1/derefcontrol.py for a simple example script.
> I've successfully tested with OpenLDAP 2.4.42+.
> It would be nice if somebody could test with 389-ds.

Demo/pyasn1/derefcontrol.py now simply uses FreeIPA's public demo server which
is 389-ds. It works.

Any more LDAP servers available with support for the Dereference Control which
should be tested?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150919/c6e1a14a/attachment.bin>

From michael at stroeder.com  Fri Sep 25 18:29:25 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 25 Sep 2015 18:29:25 +0200
Subject: [python-ldap] ANN: python-ldap 2.4.21
Message-ID: <56057665.703@stroeder.com>

Find a new release of python-ldap:

  http://pypi.python.org/pypi/python-ldap/2.4.21

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAP URLs and LDAPv3 schema).

Project's web site:

  http://www.python-ldap.org/

Checksums:

$ md5sum python-ldap-2.4.21.tar.gz
1ce26617e066f412fd5ba95bfba4ba5a
$ sha1sum python-ldap-2.4.21.tar.gz
35ed5913d804f14e952bec414c569e140feb889d
$ sha256sum python-ldap-2.4.21.tar.gz
2a3ce606465d2d5fbd0a620516b6648ffd85c343d9305d49a2a1f7d338b8bbd4

Ciao, Michael.

----------------------------------------------------------------
Released 2.4.21 2015-09-25

Changes since 2.4.20:

Lib/
* LDAPObject.read_s() now returns None instead of raising
  ldap.NO_SUCH_OBJECT in case the search operation returned emtpy result.
* ldap.resiter.ResultProcessor.allresults() now takes new key-word
  argument add_ctrls which is internally passed to LDAPObject.result4()
  and lets the method also return response control along with the search
  results.
* Added ldap.controls.deref implementing support for dereference control

Tests/
* Unit tests for module ldif (thanks to Petr Viktorin)

--
Michael Str?der
E-Mail: michael at stroeder.com
http://www.stroeder.com

From tobias.deb at gmail.com  Wed Sep 30 09:38:56 2015
From: tobias.deb at gmail.com (Tobias Diaz Diaz-Chiron)
Date: Wed, 30 Sep 2015 09:38:56 +0200
Subject: [python-ldap] Ldif parser bug?
Message-ID: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>

Hi,

I'm working with the ldif parser and I've found this behaviour:

If the DN is like:

dn: dc=operator,dc=com

it works fine, but if we remove the space after the quotes:

dn:dc=operator,dc=com

Parsing results in a ugly "referenced before assignment" error. I've
checked the RFC about LDIF format and it doesn't mention that the space is
mandatory, so I think the parser should allow this. The solution (I think)
it's easy: just add an "else" clause at the "_next_key_and_value(self)"
method just to allow this.

What do you think?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/f62ba413/attachment.html>

From michael at stroeder.com  Wed Sep 30 09:57:45 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 30 Sep 2015 09:57:45 +0200
Subject: [python-ldap] Ldif parser bug?
In-Reply-To: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
References: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
Message-ID: <560B95F9.50607@stroeder.com>

Tobias Diaz Diaz-Chiron wrote:
> I'm working with the ldif parser and I've found this behaviour:
> 
> If the DN is like:
> 
> dn: dc=operator,dc=com
> 
> it works fine, but if we remove the space after the quotes:
> 
> dn:dc=operator,dc=com
> 
> Parsing results in a ugly "referenced before assignment" error. I've
> checked the RFC about LDIF format and it doesn't mention that the space is
> mandatory, so I think the parser should allow this. The solution (I think)
> it's easy: just add an "else" clause at the "_next_key_and_value(self)"
> method just to allow this.
> 
> What do you think?

It seems you're right.

https://tools.ietf.org/html/rfc2849

dn-spec                  = "dn:" (FILL distinguishedName /
                                  ":" FILL base64-distinguishedName)
[..]
FILL                     = *SPACE

https://tools.ietf.org/html/rfc5234#section-3.6
and its pre-predecessor:
https://tools.ietf.org/html/rfc2234#section-3.6

=> *SPACE could also allow zero spaces.

It likely also affects parsing value-spec. Example 2 in RFC 2849 contains such
test data.

Feel free to submit a patch if you really need it. Start with adding the
test-cases to Tests/t_ldif.py which was fortunately contributed by Petr
Viktorin and recently released in 2.4.21.

Which software produces LDIF without the space after the colon?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/6bbbbb2a/attachment.bin>

From tobias.deb at gmail.com  Wed Sep 30 10:20:21 2015
From: tobias.deb at gmail.com (Tobias Diaz Diaz-Chiron)
Date: Wed, 30 Sep 2015 10:20:21 +0200
Subject: [python-ldap] Ldif parser bug?
In-Reply-To: <560B95F9.50607@stroeder.com>
References: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
 <560B95F9.50607@stroeder.com>
Message-ID: <CAFqvnpFm+OjNgGoObrZjjt0M6yDX3Bk0EyZB-JVMYKP+annnKw@mail.gmail.com>

Ok, thank you... I'm working on that...

My LDIF is obtained from a telecom server that send users data in ldif
format. In the ldif some DNs has spaces and some not...

2015-09-30 9:57 GMT+02:00 Michael Str?der <michael at stroeder.com>:

> Tobias Diaz Diaz-Chiron wrote:
> > I'm working with the ldif parser and I've found this behaviour:
> >
> > If the DN is like:
> >
> > dn: dc=operator,dc=com
> >
> > it works fine, but if we remove the space after the quotes:
> >
> > dn:dc=operator,dc=com
> >
> > Parsing results in a ugly "referenced before assignment" error. I've
> > checked the RFC about LDIF format and it doesn't mention that the space
> is
> > mandatory, so I think the parser should allow this. The solution (I
> think)
> > it's easy: just add an "else" clause at the "_next_key_and_value(self)"
> > method just to allow this.
> >
> > What do you think?
>
> It seems you're right.
>
> https://tools.ietf.org/html/rfc2849
>
> dn-spec                  = "dn:" (FILL distinguishedName /
>                                   ":" FILL base64-distinguishedName)
> [..]
> FILL                     = *SPACE
>
> https://tools.ietf.org/html/rfc5234#section-3.6
> and its pre-predecessor:
> https://tools.ietf.org/html/rfc2234#section-3.6
>
> => *SPACE could also allow zero spaces.
>
> It likely also affects parsing value-spec. Example 2 in RFC 2849 contains
> such
> test data.
>
> Feel free to submit a patch if you really need it. Start with adding the
> test-cases to Tests/t_ldif.py which was fortunately contributed by Petr
> Viktorin and recently released in 2.4.21.
>
> Which software produces LDIF without the space after the colon?
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/084523a4/attachment.html>

From michael at stroeder.com  Wed Sep 30 10:30:21 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 30 Sep 2015 10:30:21 +0200
Subject: [python-ldap] Ldif parser bug?
In-Reply-To: <CAFqvnpFm+OjNgGoObrZjjt0M6yDX3Bk0EyZB-JVMYKP+annnKw@mail.gmail.com>
References: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
 <560B95F9.50607@stroeder.com>
 <CAFqvnpFm+OjNgGoObrZjjt0M6yDX3Bk0EyZB-JVMYKP+annnKw@mail.gmail.com>
Message-ID: <560B9D9D.6040107@stroeder.com>

Tobias Diaz Diaz-Chiron wrote:
> Ok, thank you... I'm working on that...
> 
> My LDIF is obtained from a telecom server that send users data in ldif
> format. In the ldif some DNs has spaces and some not...

Thinking about this FILL some more I wonder how leading spaces in attribute
values shall be handled. This might get complex and I'm a bit concerned of
interop issues.

First try to fix your specific case in LDIFParser._next_key_and_value()
probably a *appending* another specific elif clause.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/2dc49f1a/attachment-0001.bin>

From pspacek at redhat.com  Wed Sep 30 11:55:17 2015
From: pspacek at redhat.com (Petr Spacek)
Date: Wed, 30 Sep 2015 11:55:17 +0200
Subject: [python-ldap] Ldif parser bug?
In-Reply-To: <560B9D9D.6040107@stroeder.com>
References: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
 <560B95F9.50607@stroeder.com>
 <CAFqvnpFm+OjNgGoObrZjjt0M6yDX3Bk0EyZB-JVMYKP+annnKw@mail.gmail.com>
 <560B9D9D.6040107@stroeder.com>
Message-ID: <560BB185.4080806@redhat.com>

On 30.9.2015 10:30, Michael Str?der wrote:
> Tobias Diaz Diaz-Chiron wrote:
>> Ok, thank you... I'm working on that...
>>
>> My LDIF is obtained from a telecom server that send users data in ldif
>> format. In the ldif some DNs has spaces and some not...
> 
> Thinking about this FILL some more I wonder how leading spaces in attribute
> values shall be handled. This might get complex and I'm a bit concerned of
> interop issues.
> 
> First try to fix your specific case in LDIFParser._next_key_and_value()
> probably a *appending* another specific elif clause.

I do not have reference to spec at hand but I believe that all values starting
or ending with whitespace should be base64-encoded to avoid ambiguity.

-- 
Petr Spacek  @  Red Hat

From michael at stroeder.com  Wed Sep 30 12:09:42 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 30 Sep 2015 12:09:42 +0200
Subject: [python-ldap] Ldif parser bug?
In-Reply-To: <560BB185.4080806@redhat.com>
References: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
 <560B95F9.50607@stroeder.com>
 <CAFqvnpFm+OjNgGoObrZjjt0M6yDX3Bk0EyZB-JVMYKP+annnKw@mail.gmail.com>
 <560B9D9D.6040107@stroeder.com> <560BB185.4080806@redhat.com>
Message-ID: <560BB4E6.8080602@stroeder.com>

Petr Spacek wrote:
> On 30.9.2015 10:30, Michael Str?der wrote:
>> Tobias Diaz Diaz-Chiron wrote:
>>> Ok, thank you... I'm working on that...
>>>
>>> My LDIF is obtained from a telecom server that send users data in ldif
>>> format. In the ldif some DNs has spaces and some not...
>>
>> Thinking about this FILL some more I wonder how leading spaces in attribute
>> values shall be handled. This might get complex and I'm a bit concerned of
>> interop issues.
>>
>> First try to fix your specific case in LDIFParser._next_key_and_value()
>> probably a *appending* another specific elif clause.
> 
> I do not have reference to spec at hand but I believe that all values starting
> or ending with whitespace should be base64-encoded to avoid ambiguity.

Unfortunately it's not that clear.

From RFC 2849:

      8)  Values or distinguished names that end with SPACE SHOULD be
          base-64 encoded.

This is only a SHOULD and AFAICS it says nothing about leading spaces. So
handling *SPACE as 0 or more space chars would require an lstrip() when
extracting the attribute value after colon. But this might not meet the
expectation of some LDIF producers trying to encode leading space(s) like this:

foo:  bar

And even this will be ambigous:

foo: bar

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/63dead23/attachment.bin>

From michael at stroeder.com  Wed Sep 30 13:08:06 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 30 Sep 2015 13:08:06 +0200
Subject: [python-ldap] Ldif parser bug?
In-Reply-To: <560BB4E6.8080602@stroeder.com>
References: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
 <560B95F9.50607@stroeder.com>
 <CAFqvnpFm+OjNgGoObrZjjt0M6yDX3Bk0EyZB-JVMYKP+annnKw@mail.gmail.com>
 <560B9D9D.6040107@stroeder.com> <560BB185.4080806@redhat.com>
 <560BB4E6.8080602@stroeder.com>
Message-ID: <560BC296.1020502@stroeder.com>

Michael Str?der wrote:
> Petr Spacek wrote:
>> On 30.9.2015 10:30, Michael Str?der wrote:
>>> Tobias Diaz Diaz-Chiron wrote:
>>>> Ok, thank you... I'm working on that...
>>>>
>>>> My LDIF is obtained from a telecom server that send users data in ldif
>>>> format. In the ldif some DNs has spaces and some not...
>>>
>>> Thinking about this FILL some more I wonder how leading spaces in attribute
>>> values shall be handled. This might get complex and I'm a bit concerned of
>>> interop issues.
>>>
>>> First try to fix your specific case in LDIFParser._next_key_and_value()
>>> probably a *appending* another specific elif clause.
>>
>> I do not have reference to spec at hand but I believe that all values starting
>> or ending with whitespace should be base64-encoded to avoid ambiguity.
> 
> Unfortunately it's not that clear.
> 
> From RFC 2849:
> 
>       8)  Values or distinguished names that end with SPACE SHOULD be
>           base-64 encoded.
> 
> This is only a SHOULD and AFAICS it says nothing about leading spaces. So
> handling *SPACE as 0 or more space chars would require an lstrip() when
> extracting the attribute value after colon. But this might not meet the
> expectation of some LDIF producers trying to encode leading space(s) like this:
> 
> foo:  bar
> 
> And even this will be ambigous:
> 
> foo: bar

Hopefully other implementors respond to this:

https://mailarchive.ietf.org/arch/msg/ldapext/mqLkF_ELVUZPD-6oiWUcX_x46Qg

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/1f07ffe3/attachment.bin>

From michael at stroeder.com  Wed Sep 30 19:18:20 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 30 Sep 2015 19:18:20 +0200
Subject: [python-ldap] Ldif parser bug?
In-Reply-To: <560B95F9.50607@stroeder.com>
References: <CAFqvnpF10DLgZQhcbtsV5i6R+H+CKGBEfDSoYfyvQBDC1JF9gg@mail.gmail.com>
 <560B95F9.50607@stroeder.com>
Message-ID: <560C195C.3080609@stroeder.com>

Michael Str?der wrote:
> Tobias Diaz Diaz-Chiron wrote:
>> I'm working with the ldif parser and I've found this behaviour:
>>
>> If the DN is like:
>>
>> dn: dc=operator,dc=com
>>
>> it works fine, but if we remove the space after the quotes:
>>
>> dn:dc=operator,dc=com
>>
>> Parsing results in a ugly "referenced before assignment" error. I've
>> checked the RFC about LDIF format and it doesn't mention that the space is
>> mandatory, so I think the parser should allow this. The solution (I think)
>> it's easy: just add an "else" clause at the "_next_key_and_value(self)"
>> method just to allow this.
>>
>> What do you think?
> 
> It seems you're right.

This is fixed now in CVS HEAD. Please test.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/a0b1262e/attachment-0001.bin>

From michael at stroeder.com  Wed Sep 30 19:23:35 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 30 Sep 2015 19:23:35 +0200
Subject: [python-ldap] [PATCH] Tests for the ldif module
In-Reply-To: <55FC1352.20105@redhat.com>
References: <55FC1352.20105@redhat.com>
Message-ID: <560C1A97.4020006@stroeder.com>

Petr Viktorin wrote:
> I've written some basic tests for the ldif module.

I had to restructure this a bit because the LDIF string representations are
ambigous. So you can only compare the parsed structures.

Checking whether LDIFWriter._needs_base64_encoding() etc. works correctly has
to be done in separate tests.

Please have a look at the version in CVS HEAD.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/5b2c1133/attachment.bin>