https://bugs.openldap.org/show_bug.cgi?id=10201
Issue ID: 10201
Summary: Update autotools to 2.71
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Update to newer autotools to work with current configure.ac requirements
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9042
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7982
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9393
Issue ID: 9393
Summary: Provider a LDAP filter validation function
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: best(a)univention.de
Target Milestone: ---
In many situations I need to validate if a user submitted LDAP filter has valid
syntax.
It seems there is no official function to check this.
Could you provide one?
libraries/libldap/filter.c: ldap_pvt_put_filter() can be used as a basis.
--
My current workaround is using a unconnected ldap connection and do a search
with that filter. This yields a FILTER_ERROR (invalid filter) or a SERVER_DOWN
error (invalid filter).
See also:
https://github.com/python-ldap/python-ldap/pull/272
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10399
Issue ID: 10399
Summary: pw-pbkdf2.so iterations parameter checks for wrong
argc
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: jj+openldap(a)sft.lol
Target Milestone: ---
f602563bf4a9512885c8e3488d03b3f812cf42d9 introduced a pw-pbkdf2.so argument for
specifying the number of hashing rounds.
this contains a bug since the argc is 1 instead of 2 when passing one argument
to the module - so the custom iterations are never considered (except when
passing a first bogus argument and the iterations as second :)
Background: We're integrating the pbkdf2-iteration configuration patch in
Ubuntu https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2125685
I've also just created an account on your gitlab instance - would be great if
it was approved :)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9009
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10150
Issue ID: 10150
Summary: liblber/etest.c calls open with O_CREAT without
specifying file mode
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: alan.coopersmith(a)oracle.com
Target Milestone: ---
https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_6/li…
has this call to the open() function:
if (( fd = open( "lber-test", O_WRONLY|O_CREAT|O_TRUNC|O_BINARY ))
Since O_CREAT is specified, there should be a third argument specifying
the file permissions for the newly created file, but it is missing here,
which may cause the file to be created with permissions based on whatever
noise is in the register or stack position the call reads the third argument
from on a given platform.
Fortunately, it looks like this code may never be compiled, since it's
inside #ifdef HAVE_CONSOLE_H and I can't find anywhere that is set, since
it's not in any AC_CONFIG_HEADER checks in the configure.ac file.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9859
Issue ID: 9859
Summary: fix test
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
Created attachment 904
--> https://bugs.openldap.org/attachment.cgi?id=904&action=edit
openldap-2.5-fix_test.patch
1. specifiy modulepath and moduleload
moduleload ../rel/mod.la works on build directry ex: make test
but it doesn't work with installed slapd.
It should be specified the modulepath and moduleload separately like other
tests.
```
modulepath ../servers/slapd/overlays/
moduleload mod.la
```
2. skip test020-proxycache for back-wt
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9914
Issue ID: 9914
Summary: Add OS pagesize to the back-mdb monitor information
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The pagesize that back-mdb is using for pages should be exposed via the
cn=monitor backend, as a remote client doing a query will not have that
information available to it.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10082
Issue ID: 10082
Summary: More dynlist eval tweaks
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When the memberOf attribute is a user attribute instead of operational, it will
be expanded on any search for (all user attributes). If the search is filtering
on objectclasses that don't contain this attribute, that's wasted work. Check
for a matching objectclass in the filter before doing that.
--
You are receiving this mail because:
You are on the CC list for the issue.