python-ldap-dev — discussion among developers

Re: TODO until python-ldap 2.0.0 final release

[<mi...@st...>]

David Leonard wrote:

 > >No GPL anymore. Please bring your working tree in sync.
 >
 > but fog's stuff in ldaplib/... has "GNU General Public
 > License"(sic) in it.

Ah, did not look at that. Fog's stuff is not part of the source 
distribution package generated with python setup.py sdist anyway.

I'd like to also remove it from CVS tree.

 > [just an english note: licence is a noun, and license is a
 > verb...

I found both "LICENSE" and "LICENCE" in the source packages of 
other projects. Maybe there's also a difference whether you speak 
American or British english?

Examples for use of term "license":
http://www.gnu.org/copyleft/gpl.html

Personally I have no preference.

Ciao, Michael.

Re: TODO until python-ldap 2.0.0 final release

[David L. <dav...@it...>]

On Wed, 21 Aug 2002, Michael Str=F6der typed thusly:

> No GPL anymore. Please bring your working tree in sync. I had the
> GPL in the header of some modules copied over from web2ldap. I
> just forgot to change that. Fixed that some time ago.

but fog's stuff in ldaplib/... has "GNU General Public License"(sic) in it.
[just an english note: licence is a noun, and license is a verb...
the mnemonic I use is that ICE is a noun.. ... [hey whats that crazy
german dish with frozen pig trotters and saurkraut?]]

> > another track is to ask all authors for permission to vary their licenc=
es to
> > a common licence... like GPL or BSD... but you couldnt guarantee that
> > everyone would agree! (or even be contactable!)
>
> I'd like to remove unmaintained and unpackaged code from the CVS
> anyway. This mainly affects Fog's Lib/perldap.py and ldaplib/*.
> The set of active authors boils down to Hans, David and me. The
> rest contributed patches and I'm pretty sure that the patched code
> is maintained in the python-ldap mainstream =3D> for published fixes
> I would just assume the overall license we can agree on.
> Personally I have no problem to choose a very liberal one which
> allows commercial use.

so.. heres a plan for you, michael-
=091) choose licence
=092) mail the GPL authors asking if its okay to degrade/unify their
=09   code under the new licence
=093) rm the files that are unmaintained?

d
--=20
David Leonard                           Dav...@it...
School of Inf. Tech. and Elec. Engg _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~

Re: TODO until python-ldap 2.0.0 final release

[<mi...@st...>]

Hans Aschauer wrote:
> On Montag, 19. August 2002 20:20, Michael Str=F6der wrote:
>=20
>>Modules/
>>- Validating server's certificate when calling start_tls_s() or
>>   ldap.initialize('ldaps://..')
>=20
> Seems to be interesting. However, I have no idea how much work it is,=20
> and honestly, I don't know the pitfalls which one has to overcome in=20
> order to get it right, but I will look into it.

Frankly at the moment I have no clue whether this is more an issue=20
of the OpenLDAP 2 lib itself or if we can do anything about it in=20
python-ldap's C module part. Additionally there will be built-in=20
support for CRL checking in OpenSSL 0.9.7 itself.

> Probably it would be a good=20
> idea to write wrappers for generic controls/extended operations only,=20
> and leave the details to python code.

Yepp!

>>Lib/
>>- Remove obsolete/unsupported modules
>>- Caching of search requests for each LDAPObject instance
>>- LDIF parser for replication logs
>>- DSML support
>>- Support for SASL mechanims GSS-API
>=20
> Huh, does SASL GSS-API not work?

Aah, sorry. I did not see and did not test this.

> I dont't have a working kerberos right=20
> now, but it used to work.

Ok, then I will remove it from TODO.

Ciao, Michael.

Re: TODO until python-ldap 2.0.0 final release

[<mi...@st...>]

David Leonard wrote:
 >
> as for the LICENCE.. i dunno.
> [..]
> The LICENSE (sic) file is a bit of a dubious licence ..

$ diff LICENSE Modules/LICENCE
2c2
< The python-ldap package is in the PUBLIC DOMAIN.
---
 > The _ldap C module is in the PUBLIC DOMAIN.
15c15
< $Id: LICENSE,v 1.1 2002/07/25 21:43:25 stroeder Exp $
---
 > $Id: LICENCE,v 1.1 2001/06/17 13:30:23 leonard Exp $

;-)

> The LICENSE file also appears to conflict with the explicit licencing in
> some files (gpl).

GPL?

$ egrep -i "(gnu|gpl)" Lib/*.py Lib/ldap/*.py
$

> Perhaps it could be changed to be more of a 'default'
> situation.. ie "Unless otherwise specified source files in this distribution
> are licenced for any use subject to acceptance of the following disclaimer,
> and may be otherwise treated as works in the public domain"...

I want to have exactly one file containing the license (or 
licence?) for all files distributed in the package.

> However, I do NOT want to see anyone FORCED into releasing their work or
> fixes into the public domain (although it would be nice).

Agreed.

> But any contribution with a licence more restrictive than the GPL should not
> be allowed to be committed into the repository! that would be bad.

Agreed. No doubt about that.

> Why? Because any packaging or distribution of python-ldap would have to
> comply with the strongest of licences. (GPL at the moment).

No GPL anymore. Please bring your working tree in sync. I had the 
GPL in the header of some modules copied over from web2ldap. I 
just forgot to change that. Fixed that some time ago.

> But, adding more lines of text to all the files
> (as suggested) is a bit of overkill, in my opinion.

Agreed.

> another track is to ask all authors for permission to vary their licences to
> a common licence... like GPL or BSD... but you couldnt guarantee that
> everyone would agree! (or even be contactable!)

I'd like to remove unmaintained and unpackaged code from the CVS 
anyway. This mainly affects Fog's Lib/perldap.py and ldaplib/*. 
The set of active authors boils down to Hans, David and me. The 
rest contributed patches and I'm pretty sure that the patched code 
is maintained in the python-ldap mainstream => for published fixes 
I would just assume the overall license we can agree on. 
Personally I have no problem to choose a very liberal one which 
allows commercial use.

Ciao, Michael.

Re: License (was: Re: TODO until python-ldap 2.0.0 final release)

[Jens V. <je...@zo...>]

just as a data point (this does not imply i want to follow the same =
route)
, here at zope corp every contributor to our CVS must sign a document =
that=20
allows us to put our ZPL (fully GPL-compatible) license onto anything =
they=20
contribute. only after signing will they get CVS access.

since we operate in commercial space doing custom zope applications this =
is=20
an absolute "must", and a lot of customer contracts now have clauses to =
the=20
effect that they never want to be the target of litigation because of =
any=20
licensing issues in the underlying software. so we have to have very =
tight=20
control over the license, and basically don't allow anything but=20
ZPL-licensed software in our repository.

i would suggest that the best way, for sanity's sake, is standardizing =
on=20
a single license and trying to contact contributors to get their =
agreement.
  every single file in the python-ldap package would carry a short blurb =
at=20
the top(1) that has the explicit "no warantees" assertion and a pointer =
to=20
the main license which is stored in a central file such as LICENSE.txt =
or=20
simply LICENSE (ZPL below, just as an example(2)). having a single =
license=20
for python-ldap would also make python-ldap "usable" for paranoid =
companies/
individuals who actually read these licenses.

unfortunately i am not sure what the legal situation is about wanting to=20=

change an existing license on a contribution if the original author =
cannot=20
be contacted anymore...

jens

(1) sample we use at zope corp (obviously this would look a tad =
different=20
for python-ldap)::

"""
=
##########################################################################=

####
#
# Copyright (c) 2001 Zope Corporation and Contributors. All Rights =
Reserved.
#
# This software is subject to the provisions of the Zope Public License,
# Version 2.0 (ZPL).  A copy of the ZPL should accompany this =
distribution.
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND =
FITNESS
# FOR A PARTICULAR PURPOSE
#
=
##########################################################################=

####
"""

(2) the ZPL:

"""
Zope Public License (ZPL) Version 2.0
-----------------------------------------------

This software is Copyright (c) Zope Corporation (tm) and
Contributors. All rights reserved.

This license has been certified as open source. It has also
been designated as GPL compatible by the Free Software
Foundation (FSF).

Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:

1. Redistributions in source code must retain the above
    copyright notice, this list of conditions, and the following
    disclaimer.

2. Redistributions in binary form must reproduce the above
    copyright notice, this list of conditions, and the following
    disclaimer in the documentation and/or other materials
    provided with the distribution.

3. The name Zope Corporation (tm) must not be used to
    endorse or promote products derived from this software
    without prior written permission from Zope Corporation.

4. The right to distribute this software or to use it for
    any purpose does not give you the right to use Servicemarks
    (sm) or Trademarks (tm) of Zope Corporation. Use of them is
    covered in a separate agreement (see
    http://www.zope.com/Marks).

5. If any files are modified, you must cause the modified
    files to carry prominent notices stating that you changed
    the files and the date of any change.

Disclaimer

   THIS SOFTWARE IS PROVIDED BY ZOPE CORPORATION ``AS IS''
   AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT
   NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
   AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
   NO EVENT SHALL ZOPE CORPORATION OR ITS CONTRIBUTORS BE
   LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
   LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
   HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
   CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
   OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
   SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
   DAMAGE.


This software consists of contributions made by Zope
Corporation and many individuals on behalf of Zope
Corporation.  Specific attributions are listed in the
accompanying credits file.
"""



On Wednesday, August 21, 2002, at 01:20 , David Leonard wrote:

> hi there python-ldap hackers!
>
> ahh ldap. although i don't do much with LDAP any more, i thought it =
would
> help i wrote something about the legal situation.
>
> the only necessary legalese to have in the distribution is a NOTICE =
that=20
> the
> software is provided AS IS and is not guranteed from exploding into =
small
> pieces. that is to cover our arses. this is a MINIMUM necessity in any
> software today. (It's because software engineering is generally of so
> abysmally low quality compared to any other human endeavour ... but =
that'
> s
> another story!)
>
> as for the LICENCE.. i dunno. it is up to the primary authors of each
> 'contribution' to licence their work. i think the sourceforge project =
as=20
> a
> whole is declared publicly as "GPL" in the SF databases, but any BSD =
or PD
> licencing on individual files would still be compatible with that, so =
its
> not a problem to have individual contributions licenced differently.
>
> The LICENSE (sic) file is a bit of a dubious licence .. it's claims =
public
> domain release (ie destroyed copyright) but it then imposes conditions =
on
> use (ie acceptance of the disclaimer). i think that would collapse =
under
> scrutiny.  Well at least there is a disclaimer there  - ie the notice =
of
> user risk, which is the most important thing.
>
> The LICENSE file also appears to conflict with the explicit licencing =
in
> some files (gpl). Perhaps it could be changed to be more of a =
'default'
> situation.. ie "Unless otherwise specified source files in this=20
> distribution
> are licenced for any use subject to acceptance of the following =
disclaimer,
> and may be otherwise treated as works in the public domain"...
>
> However, I do NOT want to see anyone FORCED into releasing their work =
or
> fixes into the public domain (although it would be nice). It's the =
primary
> author's right to restrict their work in any fashion that they desire =
(this
> ability stems from their natural copyright).
>
> But any contribution with a licence more restrictive than the GPL =
should=20
> not
> be allowed to be committed into the repository! that would be bad.
>
> Why? Because any packaging or distribution of python-ldap would have =
to
> comply with the strongest of licences. (GPL at the moment). And that=20=

> wouldnt
> be fair. today, if someone wants to extract the non-GPLd code for =
their own
> evil corporate frankenstein product, then its up to them to manually =
go
> through and separate the files from each other.. and maybe even go =
through
> the CVS commits (which, depending on their relative size may not merit =
the
> status of a separately licencable 'contrbution'... mmm controversial)
>
> so, if someone wants to clean up the legalese mess, and clarify the
> situation, then go for it. But, adding more lines of text to all the =
files
> (as suggested) is a bit of overkill, in my opinion.
>
> another track is to ask all authors for permission to vary their =
licences=20
> to
> a common licence... like GPL or BSD... but you couldnt guarantee that
> everyone would agree! (or even be contactable!)
>
> d
> --
> David Leonard
> ----- Original Message -----
> From: "Michael Str=F6der" <mi...@st...>
> To: "Jens Vagelpohl" <je...@zo...>
> Cc: "Python Developer List" <pyt...@li...>
> Sent: Tuesday, August 20, 2002 10:50 PM
> Subject: Re: TODO until python-ldap 2.0.0 final release
>
>
>> Jens Vagelpohl wrote:
>>> talking about the common license, is there such a beast yet and
>>> you're just looking for someone to go through every file and
>>> make sure it's in there? or is it more about producing the
>>> legalese gibberish itself? :)
>>
>> Well, a little bit of both.
>>
>> Ciao, Michael.
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone?  Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
>> _______________________________________________
>> Python-LDAP-dev mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>>
>

Re: TODO until python-ldap 2.0.0 final release

[Hans A. <Han...@Ph...>]

On Montag, 19. August 2002 20:20, Michael Ströder wrote:
> HI!
>
> I'd like to bring your attention to the TODO file in python-ldap.
> For your convenience it's attached below. ;-)
>
> Any takers? Especially I'd like to see a general approach for
> extended controls and extended operations. Yeah, C illiterate I am
> I'm asking for help...

[...]

> Modules/
> - Validating server's certificate when calling start_tls_s() or
>    ldap.initialize('ldaps://..')

Seems to be interesting. However, I have no idea how much work it is, 
and honestly, I don't know the pitfalls which one has to overcome in 
order to get it right, but I will look into it.

> - General support for controls
>    - VLV control
>    - server-side sorting control
>    - Binding in DSA control mode (rewrite necessary)
>    - Persistent search control
> - Wrap ldap_parse_reference()
> - Support for Win32 (and other platforms?)
> - Support Extended Operations by wrapping
>    ldap_extended_operation() and ldap_parse_extended_result()
>    - Set Password ext. op.
>    - Whoami ext. op.

Maybe I find some free time to do these things (except for Win32). The 
C-API does not seem to be too complicated. Probably it would be a good 
idea to write wrappers for generic controls/extended operations only, 
and leave the details to python code.


> Lib/
> - Remove obsolete/unsupported modules
> - Caching of search requests for each LDAPObject instance
> - LDIF parser for replication logs
> - DSML support
> - Support for SASL mechanims GSS-API

Huh, does SASL GSS-API not work? I dont't have a working kerberos right 
now, but it used to work.

Hans

-- 
Han...@Ph...

Re: TODO until python-ldap 2.0.0 final release

[David L. <dav...@it...>]

hi there python-ldap hackers!

ahh ldap. although i don't do much with LDAP any more, i thought it would
help i wrote something about the legal situation.

the only necessary legalese to have in the distribution is a NOTICE that =
the
software is provided AS IS and is not guranteed from exploding into small
pieces. that is to cover our arses. this is a MINIMUM necessity in any
software today. (It's because software engineering is generally of so
abysmally low quality compared to any other human endeavour ... but that'=
s
another story!)

as for the LICENCE.. i dunno. it is up to the primary authors of each
'contribution' to licence their work. i think the sourceforge project as =
a
whole is declared publicly as "GPL" in the SF databases, but any BSD or P=
D
licencing on individual files would still be compatible with that, so its
not a problem to have individual contributions licenced differently.

The LICENSE (sic) file is a bit of a dubious licence .. it's claims publi=
c
domain release (ie destroyed copyright) but it then imposes conditions on
use (ie acceptance of the disclaimer). i think that would collapse under
scrutiny.  Well at least there is a disclaimer there  - ie the notice of
user risk, which is the most important thing.

The LICENSE file also appears to conflict with the explicit licencing in
some files (gpl). Perhaps it could be changed to be more of a 'default'
situation.. ie "Unless otherwise specified source files in this distribut=
ion
are licenced for any use subject to acceptance of the following disclaime=
r,
and may be otherwise treated as works in the public domain"...

However, I do NOT want to see anyone FORCED into releasing their work or
fixes into the public domain (although it would be nice). It's the primar=
y
author's right to restrict their work in any fashion that they desire (th=
is
ability stems from their natural copyright).

But any contribution with a licence more restrictive than the GPL should =
not
be allowed to be committed into the repository! that would be bad.

Why? Because any packaging or distribution of python-ldap would have to
comply with the strongest of licences. (GPL at the moment). And that woul=
dnt
be fair. today, if someone wants to extract the non-GPLd code for their o=
wn
evil corporate frankenstein product, then its up to them to manually go
through and separate the files from each other.. and maybe even go throug=
h
the CVS commits (which, depending on their relative size may not merit th=
e
status of a separately licencable 'contrbution'... mmm controversial)

so, if someone wants to clean up the legalese mess, and clarify the
situation, then go for it. But, adding more lines of text to all the file=
s
(as suggested) is a bit of overkill, in my opinion.

another track is to ask all authors for permission to vary their licences=
 to
a common licence... like GPL or BSD... but you couldnt guarantee that
everyone would agree! (or even be contactable!)

d
--
David Leonard
----- Original Message -----
From: "Michael Str=F6der" <mi...@st...>
To: "Jens Vagelpohl" <je...@zo...>
Cc: "Python Developer List" <pyt...@li...>
Sent: Tuesday, August 20, 2002 10:50 PM
Subject: Re: TODO until python-ldap 2.0.0 final release


> Jens Vagelpohl wrote:
>  > talking about the common license, is there such a beast yet and
>  > you're just looking for someone to go through every file and
>  > make sure it's in there? or is it more about producing the
>  > legalese gibberish itself? :)
>
> Well, a little bit of both.
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: TODO until python-ldap 2.0.0 final release

[Jens V. <je...@zo...>]

where's the canonical "starting place", the "half-done" license? i'd be=20=

willing to finish that and make sure it appears wherever it is needed.

jens


On Tuesday, August 20, 2002, at 08:50 , Michael Str=F6der wrote:

> Jens Vagelpohl wrote:
> > talking about the common license, is there such a beast yet and > =
you're=20
> just looking for someone to go through every file and
> > make sure it's in there? or is it more about producing the
> > legalese gibberish itself? :)
>
> Well, a little bit of both.
>
> Ciao, Michael.
>

Re: TODO until python-ldap 2.0.0 final release

[<mi...@st...>]

Jens Vagelpohl wrote:
 > talking about the common license, is there such a beast yet and 
 > you're just looking for someone to go through every file and
 > make sure it's in there? or is it more about producing the
 > legalese gibberish itself? :)

Well, a little bit of both.

Ciao, Michael.

Re: Preparing 2.0.0pre06

[<mi...@st...>]

Tjabo Kloppenburg wrote:
 >
 >
 >>I consider the LDAPv3 schema support to have a more or less
 >>stable API now.
 >
 > are there any docs,

Not yet.

 > examples ?

Demo/schema.py and Demo/schema_tree.py

Ciao, Michael.

Re: TODO until python-ldap 2.0.0 final release

[Jens V. <je...@zo...>]

talking about the common license, is there such a beast yet and you're =
just=20
looking for someone to go through every file and make sure it's in =
there?=20
or is it more about producing the legalese gibberish itself? :)

jens


On Monday, August 19, 2002, at 02:20 , Michael Str=F6der wrote:

> HI!
>
> I'd like to bring your attention to the TODO file in python-ldap. For =
your=20
> convenience it's attached below. ;-)
>
> Any takers? Especially I'd like to see a general approach for extended=20=

> controls and extended operations. Yeah, C illiterate I am I'm asking =
for=20
> help...
>
> Ciao, Michael.
>
> *** List of things to-do in no particular order ***
>
> General:
> - Define common license for all modules
> - Create a test script that exercises everything with a public
>   server holding the BLITS 2.5 test data set
>
> Modules/
> - Validating server's certificate when calling start_tls_s() or
>   ldap.initialize('ldaps://..')
> - General support for controls
>   - VLV control
>   - server-side sorting control
>   - Binding in DSA control mode (rewrite necessary)
>   - Persistent search control
> - Wrap ldap_parse_reference()
> - Support for Win32 (and other platforms?)
> - Support Extended Operations by wrapping
>   ldap_extended_operation() and ldap_parse_extended_result()
>   - Set Password ext. op.
>   - Whoami ext. op.
>
> Lib/
> - Remove obsolete/unsupported modules
> - Caching of search requests for each LDAPObject instance
> - LDIF parser for replication logs
> - DSML support
> - Support for SASL mechanims GSS-API
>
> Tests/
> Clean up and finish the mess of test scripts started.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

TODO until python-ldap 2.0.0 final release

[<mi...@st...>]

HI!

I'd like to bring your attention to the TODO file in python-ldap. 
For your convenience it's attached below. ;-)

Any takers? Especially I'd like to see a general approach for 
extended controls and extended operations. Yeah, C illiterate I am 
I'm asking for help...

Ciao, Michael.

*** List of things to-do in no particular order ***

General:
- Define common license for all modules
- Create a test script that exercises everything with a public
   server holding the BLITS 2.5 test data set

Modules/
- Validating server's certificate when calling start_tls_s() or
   ldap.initialize('ldaps://..')
- General support for controls
   - VLV control
   - server-side sorting control
   - Binding in DSA control mode (rewrite necessary)
   - Persistent search control
- Wrap ldap_parse_reference()
- Support for Win32 (and other platforms?)
- Support Extended Operations by wrapping
   ldap_extended_operation() and ldap_parse_extended_result()
   - Set Password ext. op.
   - Whoami ext. op.

Lib/
- Remove obsolete/unsupported modules
- Caching of search requests for each LDAPObject instance
- LDIF parser for replication logs
- DSML support
- Support for SASL mechanims GSS-API

Tests/
Clean up and finish the mess of test scripts started.

Preparing 2.0.0pre06

[<mi...@st...>]

HI!

Please get your python-ldap working tree in sync since I'd like to 
release a 2.0.0pre06 real soon now. For those of your sitting 
behind a firewall or without CVS access there's a tar.gz 
temporarily available on:

http://www.web2ldap.de/download.html

I consider the LDAPv3 schema support to have a more or less stable 
API now.

Please test and comment!

Ciao, Michael.

Re: Segfault in python-ldap

[<mi...@st...>]

Peter Hawkins wrote:
> 
> This bug has been sitting in our BTS for a while:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=76722&repeatmerged=yes
> 
> ---  SNIP ---
> This piece of code might not be correct but it certainly should not
> make python segfault:

Yepp, python-ldap should not crash.

> --- python-ldap-2.0.0pre04/Modules/LDAPObject.c	Sat Feb  2 22:47:00 2002
> +++ python-ldap-2.0.0pre04-new2/Modules/LDAPObject.c	Tue Jul  2 22:09:26 2002

I've applied the patch you provided to my local working tree. It 
works. Thanks for submitting it.

Well, this is not a complete solution for this kind of problems. 
Maybe assertion statements in each method of 
ldap.ldapobject.LDAPObject could be of better help here...

Ciao, Michael.

Segfault in python-ldap

[Peter H. <pe...@ha...>]

Hi...

I'm the current debian maintainer for the debian python-ldap package.

This bug has been sitting in our BTS for a while:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D76722&repeatmerged=3Dy=
es

---  SNIP ---
This piece of code might not be correct but it certainly should not
make python segfault:

import ldap

class ldapObject:
        def __init__(self,dn=3D""):
                '''ldapObject constructor.'''

                self.dn=3Ddn
                self.attr=3D{}

db=3Dldap.open("db.mors.wiggy.net",389)
db.simple_bind("cn=3Dadmin,ou=3DPeople,dc=3Dmors,dc=3Dwiggy,dc=3Dnet", "1=
2345")
o=3DldapObject("uid=3Dtst,ou=3DPeople,dc=3Dmors,dc=3Dwiggy,dc=3Dnet")
o.attr["objectClass"]=3D"top"
o.attr["uid"]=3D"tst"
db.add_s(o.dn, o)

--- END SNIP ---

I just checked and it still causes problems with 2.0.0-pre05. (though=20
you may need to change db.mors.wiggy.net to something you can=20
actually contact).

A patch for this issue (against 2.0.0-pre04, but still applies=20
correctly against 2.0.0-pre05), the correctness of which I am not=20
totally certain, is attached. Could you please check it and apply it=20
to your source tree?

Thanks,
Peter

--
pe...@ha...
GPG key fingerprint:
C746 38A9 D3E4 A171 FB6A  56D4 5E30 DFCC BE11 F437

Re: Own pure Python parser for LDAPv3 schema support

[<mi...@st...>]

Jens Vagelpohl wrote:
 >> I hoped that someone bites the bullet and uses
 >> /usr/lib/python2.2/profile.py... ;-)
 >
 > hey, i told you i don't use python2.2 yet ;)

Hah, that's obviously no excuse... ;-)

 > i am noticing that the __init__ for ObjectClass, unlike all
 > others, does not just take the full schema_element_string, it
 > also takes all attributes as separate keyword arguments. that
 > seems a little redundant.

Python 2.2.1 (#2, May  4 2002, 19:50:26)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import ldap.schema
 >>>
str(ldap.schema.ObjectClass(oid='1.23.456.78.0',names=['myClass','myClassAlias'],must=['myRequiredAttr1','myRequiredAttr2'],may=['myAllowed1']))
"( 1.23.456.78.0 NAME ( 'myClass' 'myClassAlias' ) STRUCTURAL MUST
( myRequiredAttr1 $ myRequiredAttr2 ) MAY myAllowed1 )"
 >>>

Also works with Python 2.1.x! ;-)

Got the message? It's meant for automated schema element creation.
A schema editor comes to mind...

 > all other classes only take the schema_element_string and
 > extract the attributes from that.

Yes, they are not complete yet.

 > well, i would probably end up doing a widget that offers both a
 > dropdown and a text input field, maybe depending on errors
 > occurring during schema discovery.

Error handling is somewhat subtle.

Ciao, Michael.

Re: Own pure Python parser for LDAPv3 schema support

[Jens V. <je...@zo...>]

> I hoped that someone bites the bullet and uses
> /usr/lib/python2.2/profile.py... ;-)

hey, i told you i don't use python2.2 yet ;)


> Also the __init__() methods of the schema element classes need review to 
> check whether they are consistent.

you mean the classes inside schema.py such os "ObjectClass", "AttributeType"
  etc? i am noticing that the __init__ for ObjectClass, unlike all others, 
does not just take the full schema_element_string, it also takes all 
attributes as separate keyword arguments. that seems a little redundant. 
all other classes only take the schema_element_string and extract the 
attributes from that.


> Be warned that the API still might be changed without prominent
> notification (there are some significant changes in the pipe not checked 
> in). I developed the stuff while implementing schema support in web2ldap.
>  Therefore it should contain almost everything needed by applications.

i don't have time to implement it and throw it out right at this moment, 
anyway. i'm fully aware that something so "new" will change more frequently.


> Also be warned that there are many broken schemas out there in the wild. 
> Test your application against other products than OpenLDAP!

well, i would probably end up doing a widget that offers both a dropdown 
and a text input field, maybe depending on errors occurring during schema 
discovery.

jens

Re: Own pure Python parser for LDAPv3 schema support

[<mi...@st...>]

Jens Vagelpohl wrote:
 > as far as performance goes, the subjective performance seems to
 > be the same as it was with the other implementation. not sure if
 > that's any kind of useful indicator, though.

I hoped that someone bites the bullet and uses
/usr/lib/python2.2/profile.py... ;-)

Also the __init__() methods of the schema element classes need 
review to check whether they are consistent.

 > i plan on using this to
 > offer select widgets in places where i had to rely on people
 > typing objectClass names into text boxes before...

This is rather simple:

SubSchema.all_available(ldap.schema.ObjectClass)

Be warned that the API still might be changed without prominent
notification (there are some significant changes in the pipe not 
checked in). I developed the stuff while implementing schema 
support in web2ldap. Therefore it should contain almost everything 
needed by applications.

Also be warned that there are many broken schemas out there in the 
wild. Test your application against other products than OpenLDAP!

Ciao, Michael.

Re: Own pure Python parser for LDAPv3 schema support

[Jens V. <je...@zo...>]

well, for what it's worth, the schema.py and schema_tree.py demos in the=20=

Demo folder work very nicely against my test server (OpenLDAP 2.1.3).

as far as performance goes, the subjective performance seems to be the=20=

same as it was with the other implementation. not sure if that's any =
kind=20
of useful indicator, though.

i think this is great stuff. thanks michael!!! i plan on using this to=20=

offer select widgets in places where i had to rely on people typing=20
objectClass names into text boxes before...

jens


On Monday, August 12, 2002, at 04:42 , Michael Str=F6der wrote:

> HI!
>
> Please take note of the following check-ins related to LDAPv3 schema=20=

> support (see below).
>
> Tested on various servers:
> OpenLDAP 2.0/2.1
> IBM SecureWay
> Lotus Domino/LDAP R5(?)
> Novell eDirectory 8.6.1/8.7
> Novell Directory Server 4.16SP1, 5.0
> Siemens Dir/X (various unknown versions)
> Innosoft's IDDS 4.5.1
>
> There still might be some detailed issues.
> Reviews, profiling performance hot spots, testing, etc. is =
appreciated.
>
> If that code works reliably I will cvs remove schema support based on=20=

> OpenLDAP's schema parser from C _ldap.
>
> Ciao, Michael.
>
>
> -------- Original Message --------
> Subject: CVS: python-ldap
> Date: Mon, 12 Aug 2002 13:32:29 -0700
> From: Michael Str?der <str...@us...>
> Reply-To: pyt...@li...
> To: pyt...@li...
>
> CVSROOT: /cvsroot/python-ldap
> Module name:	python-ldap
> Changes by:	stroeder	2002/08/12 13:32:29
>
> Modified files:
> 	Demo           : schema.py schema_tree.py
> 	Lib/ldap       : schema.py
>
> Log message:
> Abandoned use of OpenLDAP's schema parser. Implemented own parsing =
with
> ldap.schema.split_tokens() and ldap.schema.extract_tokens(). Probably =
bad
> performance and robustness =3D> peer review needed.
>
> SubSchema.name2oid is now nested dictionary separated by schema =
element
> classes. This was needed since schema element names are reused for=20
> attribute
> types and object classes on e.g. Novell eDirectory.
>
>

Own pure Python parser for LDAPv3 schema support

[<mi...@st...>]

HI!

Please take note of the following check-ins related to LDAPv3 
schema support (see below).

Tested on various servers:
OpenLDAP 2.0/2.1
IBM SecureWay
Lotus Domino/LDAP R5(?)
Novell eDirectory 8.6.1/8.7
Novell Directory Server 4.16SP1, 5.0
Siemens Dir/X (various unknown versions)
Innosoft's IDDS 4.5.1

There still might be some detailed issues.
Reviews, profiling performance hot spots, testing, etc. is 
appreciated.

If that code works reliably I will cvs remove schema support based 
on OpenLDAP's schema parser from C _ldap.

Ciao, Michael.


-------- Original Message --------
Subject: CVS: python-ldap
Date: Mon, 12 Aug 2002 13:32:29 -0700
From: Michael Str?der <str...@us...>
Reply-To: pyt...@li...
To: pyt...@li...

CVSROOT: 
/cvsroot/python-ldap
Module name:	python-ldap
Changes by:	stroeder	2002/08/12 13:32:29

Modified files:
	Demo           : schema.py schema_tree.py
	Lib/ldap       : schema.py

Log message:
Abandoned use of OpenLDAP's schema parser. Implemented own parsing 
with
ldap.schema.split_tokens() and ldap.schema.extract_tokens(). 
Probably bad
performance and robustness => peer review needed.

SubSchema.name2oid is now nested dictionary separated by schema 
element
classes. This was needed since schema element names are reused for 
attribute
types and object classes on e.g. Novell eDirectory.



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
--
https://lists.sourceforge.net/lists/listinfo/python-ldap-commits

Re: problem with filter

[<mi...@st...>]

Tjabo Kloppenburg wrote:
> 
>>your scope is probably inappropriate. use ldap.SCOPE_BASE.
> 
> s = self.ldap.search_s( dn, ldap.SCOPE_BASE, "objectClass=*" )
> made it.

The filter is still not valid even though the LDAP server might 
accept it. Use "(objectClass=*)" instead and make sure that you 
fully understand RFC2254.

> QUESTION: why doesn't the reply-to tag point to the list?

To avoid flames intended to reach me to be sent to the list. ;-)

Ciao, Michael.

Re: problem with filter

[Tjabo K. <t.k...@bi...>]

hi,

> your scope is probably inappropriate. use ldap.SCOPE_BASE.

s = self.ldap.search_s( dn, ldap.SCOPE_BASE, "objectClass=*" )
made it.

tnx,
tk.
QUESTION: why doesn't the reply-to tag point to the list?

Re: problem with filter

[<mi...@st...>]

Tjabo Kloppenburg wrote:
> 
> I'm writing a program in python wir python-ldap2.0.0.-pre04 (linux).
> 
> I can do all sorts of things, like searching:
>   L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "uid=ma*" )

"uid=ma*" is not a valid search filter. Use "(uid=ma*)" instead. 
See RFC2254 as stated in the docs.

> let's say I have found twenty results, and I let the user chose one of the DNs.
> Now I want to retrieve the data of the object of a given dn.

If you did not specify args attrlist and attrsonly the entry data 
is already in the search result above.

> The problem is how to tell
> ldap.search_s to get the data of a dn like "uid=freak,ou=staff,o=company".
> 
>   L = myldap.search_s( base, ldap.SCOPE_SUBTREE, dn )
> gives an empty list.

This call is wrong. Should be:

     L = myldap.search_s( dn, ldap.SCOPE_BASE, "(objectClass=*)" )

Read the docs for search().

Ciao, Michael.

Re: problem with filter

[Jens V. <je...@zo...>]

your scope is probably inappropriate. use ldap.SCOPE_BASE.

jens


On Saturday, August 10, 2002, at 03:21 , Tjabo Kloppenburg wrote:

> hi,
>
> I'm writing a program in python wir python-ldap2.0.0.-pre04 (linux).
>
> I can do all sorts of things, like searching:
>   L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "uid=ma*" )
>
> let's say I have found twenty results, and I let the user chose one of 
> the DNs.
> Now I want to retrieve the data of the object of a given dn. The problem 
> is how to tell
> ldap.search_s to get the data of a dn like "uid=freak,ou=staff,o=company"
> .
>
>   L = myldap.search_s( base, ldap.SCOPE_SUBTREE, dn )
> gives an empty list.
>
>   L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "dn=" + dn )
> gives an empty list, too.
>
> what's the right filter/function for this?
>
>
> thanks a lot,
>   tk.
>

problem with filter

[Tjabo K. <t.k...@bi...>]

hi,

I'm writing a program in python wir python-ldap2.0.0.-pre04 (linux).

I can do all sorts of things, like searching:
  L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "uid=ma*" )

let's say I have found twenty results, and I let the user chose one of the DNs.
Now I want to retrieve the data of the object of a given dn. The problem is how to tell
ldap.search_s to get the data of a dn like "uid=freak,ou=staff,o=company".

  L = myldap.search_s( base, ldap.SCOPE_SUBTREE, dn )
gives an empty list.

  L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "dn=" + dn )
gives an empty list, too.

what's the right filter/function for this?


thanks a lot,
  tk.