Re: make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))

[Michael Ströder]

On 11/16/22 19:52, Howard Chu wrote:

Ondřej Kuzník wrote:

On Wed, Nov 16, 2022 at 11:32:09AM +0100, Michael Ströder wrote:

On 10/4/22 18:49, Quanah Gibson-Mount wrote:

This is the first testing call for OpenLDAP 2.6.4.  Depending on the
results, this may be the only testing call.


make test seems to fail for openSUSE on riscv64 already for test000-rootdse.



Also of note might be ITS#9916 which has a proposed
patch already[0], can you give that a try?


Irrelevant, since test000 does no backend operations.


test000 fails with message

backend_startup_one (type=mdb, suffix="o=OpenLDAP Project,l=Internet"): 
bi_db_open failed! (95)


tests/testrun/slapd.1.log attached herein:

https://bugs.openldap.org/show_bug.cgi?id=9954

Ciao, Michael.

Re: make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))

[Michael Ströder]

On 11/18/22 18:41, Howard Chu wrote:

Michael Ströder wrote:

AFAICT the OBS builds are always run on temporarily spawned VMs
(IIRC qemu-kvm), not only containers. For most platforms the VMs
are spawned on real native hardware .. >

Your log clearly shows the build is running under a QEMU VM.


Also on riscv64 OBS starts the build VM with:

qemu-kvm [..] -cpu host -M pc,accel=kvm,[..]

AFAICT this results in KVM being used without CPU emulation.

Ciao, Michael.

Re: make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))

[Michael Ströder]

On 11/18/22 14:35, Howard Chu wrote:

Michael Ströder wrote:

Could you please have a short look at the build log in OBS and
watch out for the compiler options used? They use many of the build
hardening options: >>
https://build.opensuse.org/public/build/home:stroeder:branches:home:stroeder:openldap26/openSUSE_Factory_RISCV/riscv64/openldap-ms/_log


I don't have permissions on the box to install some of the dev libraries.


Are you referring to OBS or cfarm.tetaneutral.net?

You could alter the .spec file to install additional tools and libs.


Are you sure systemd is working on your build machine?


Are you concerned about --with-systemd in my .spec file? The build also 
failed before I introduced this.


AFAICT the OBS builds are always run on temporarily spawned VMs (IIRC 
qemu-kvm), not only containers. For most platforms the VMs are spawned 
on real native hardware (e.g. ARM and S/390). I have to ask OBS folks 
whether that's also true for riscv64.


Also the OBS builds including make test on the various platforms are 
spawned from the very same .spec file:


https://build.opensuse.org/package/show/home:stroeder:branches:home:stroeder:openldap26/openldap-ms

Currently riscv64 is blocked by rebuilds of other dependencies. Maybe 
those rebuilds will fix an issue. Let's see...


Ciao, Michael.

Re: make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))

[Michael Ströder]

On 11/18/22 07:32, Howard Chu wrote:

Michael Ströder wrote:

make test seems to fail for openSUSE on riscv64 already for test000-rootdse.

Not sure whether that's an issue with build options in the .spec file or 
whatever.


Built fine for me on Ubuntu 22.04 and make test passes.

hyc@gcc92:/tmp/openldap/tests$ gcc --version
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0

Using the gcc92 machine from the compile farm 
https://cfarm.tetaneutral.net/machines/list/


Ok. So let's find the possibly relevant difference.

Could you please have a short look at the build log in OBS and watch out 
for the compiler options used? They use many of the build hardening options:


https://build.opensuse.org/public/build/home:stroeder:branches:home:stroeder:openldap26/openSUSE_Factory_RISCV/riscv64/openldap-ms/_log

Ciao, Michael.

Re: make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))

[Michael Ströder]

On 11/16/22 13:51, Ondřej Kuzník wrote:

On Wed, Nov 16, 2022 at 01:33:55PM +0100, Michael Ströder wrote:

On 11/16/22 12:08, Ondřej Kuzník wrote:

Also of note might be ITS#9916 which has a proposed
patch already[0], can you give that a try?


Are you refererring to this commit?

https://git.openldap.org/openldap/openldap/-/merge_requests/582/diffs?commit_id=a1b220c26d3e79f0f1682faa708ef1ab9b4c3097


That's the one. If this makes a difference, please comment on the MR to
that account as well.


Hmm, maybe I got something wrong. But this patch does not apply to RE26.

I'll wait with tests until this change reached RE26.

Ciao, Michael.

Re: make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))

[Michael Ströder]

On 11/16/22 12:08, Ondřej Kuzník wrote:

Also of note might be ITS#9916 which has a proposed
patch already[0], can you give that a try?


Are you refererring to this commit?

https://git.openldap.org/openldap/openldap/-/merge_requests/582/diffs?commit_id=a1b220c26d3e79f0f1682faa708ef1ab9b4c3097

Ciao, Michael.

make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))

[Michael Ströder]

On 10/4/22 18:49, Quanah Gibson-Mount wrote:
This is the first testing call for OpenLDAP 2.6.4.  Depending on the 
results, this may be the only testing call.


make test seems to fail for openSUSE on riscv64 already for test000-rootdse.

Not sure whether that's an issue with build options in the .spec file or 
whatever.


Those package builds run in temporary VMs [1]. Do you have a command at 
hand how to dump all relevant files in case any of the tests aborts? Can 
I lookup how the OpenLDAP project runs automated builds and tests in 
gitlab and borrow from that?


Ciao, Michael.

[1] 
https://build.opensuse.org/package/show/home:stroeder:branches:home:stroeder:openldap26/openldap2

Re: FOSDEM 2023

[Michael Ströder]

On 10/17/22 19:29, Michael Ströder wrote:

On 10/17/22 19:22, Howard Chu wrote:

Michael Ströder wrote:

On 10/17/22 18:31, Howard Chu wrote:

Anyone interested in setting up at FOSDEM next year?


Run an OpenLDAP stand or request an IAM dev room for some talks?


An IAM dev room sounds like a more worthwhile use of time.  ?


Yes, IMO an IAM devroom is much better.

Would you like to suggest one to the FOSDEM organizers?


Or how about an ODD before FOSDEM like other projects are doing it?

They call it Fringe:

https://archive.fosdem.org/2020/fringe/
https://archive.fosdem.org/2021/fringe/
https://archive.fosdem.org/2022/fringe/

Ciao, Michael.

Re: FOSDEM 2023

[Michael Ströder]

On 10/17/22 19:22, Howard Chu wrote:

Michael Ströder wrote:

On 10/17/22 18:31, Howard Chu wrote:

Anyone interested in setting up at FOSDEM next year?


Run an OpenLDAP stand or request an IAM dev room for some talks?


An IAM dev room sounds like a more worthwhile use of time.  ?


Yes, IMO an IAM devroom is much better.

Would you like to suggest one to the FOSDEM organizers?

Ciao, Michael.

Re: FOSDEM 2023

[Michael Ströder]

On 10/17/22 18:31, Howard Chu wrote:

Anyone interested in setting up at FOSDEM next year?


Run an OpenLDAP stand or request an IAM dev room for some talks?

Ciao, Michael.

Patch for SSL ctx

[Michael Ströder]

HI!

Could someone please review whether this patch makes sense?

https://build.opensuse.org/package/view_file/home:firstyear:branches:network:ldap/openldap2/0017-Resolve-error-handling-in-new-ctx-when-global.patch?expand=1

Ciao, Michael.

Re: order of clauses in ACLs

[Michael Ströder]

On 8/15/21 4:36 PM, Michael Ströder wrote:
> First tests (OpenLDAP 2.5/master) show with customer ACLs reading all
> attrs of 100k user entries and one huge group entry takes
> 
> 2m23.459s with standard acl.c
> 
> but only
> 
> 1m22.718s with patched acl.c which evaluates attrs= before dn.regex= and
> val.regex=.

https://bugs.openldap.org/show_bug.cgi?id=9634

Ciao, Michael.

Re: order of clauses in ACLs

[Michael Ströder]

On 8/15/21 9:12 PM, Howard Chu wrote:
> And what about non-regex forms of DN checking, which are more common
> than regex?
And that's why I suggest in ITS#9634 that DN simple checks are split
from dn.regex.

> Nobody can validate your conclusions since you haven't provided the
> actual test cases.
I can come up with test config and data but I'd like to know whether
it's worth the effort or whether you just reject any optimization
attempts in this field.

Ciao, Michael.

Re: order of clauses in ACLs

[Michael Ströder]

HI!

Moving this thread here to openldap-devel because it's not a usage
question anymore:

https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/message/E4BK5DA5DUAUYLJT6DRGKV45SQBZJ5XZ/

TL;DR:
1. Would you consider the attached patch as a valid solution?
2. Improving slapo-constraint would also help.

On 8/13/21 10:59 AM, Michael Ströder wrote:
> On 8/13/21 1:51 AM, Howard Chu wrote:
>> Michael Ströder wrote:
>>> Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".."
>>> in the  clauses.
>>>
>>> Obviously depending on complexity of regex-pattern and length of DNs /
>>> avals the regex checking is more expensive than equality checking of attrs=.
>>>
>>> Can I improve ACL performance by order of  clauses or are they
>>> processed in fixed order anyway? If in fixed order, which one?
>>
>> The order is fixed, in order of increasing granularity. DN first,
>> attribute next, value-specific last.
> 
> Is this order implemented in function slap_acl_get() in acl.c?
> The last seems to be filter= after val=. Right?
> 
>> That is the only order that makes logical sense.
> 
> Why?
> 
> IMHO attrs= should be checked first because
> 
>   dn.regex=".."
>   val.regex=".."
>   filter=".."
> 
> are all potentially way more CPU-intensive than checking attrs= against
> a simple hash-map.

First tests (OpenLDAP 2.5/master) show with customer ACLs reading all
attrs of 100k user entries and one huge group entry takes

2m23.459s with standard acl.c

but only

1m22.718s with patched acl.c which evaluates attrs= before dn.regex= and
val.regex=.

The reason for improved performance here is that the test data has one
really big group entry (100k members) with expensive ACLs on
uniqueMember attribute. Thus quickly skipping the ACLs with
attrs=uniqueMember saves lots of CPU.

Yes, the tests are somewhat artificial and optimizing the clients is
also needed. But anyway I'd like to avoid clients accidently causing
unneeded load. And I expect this to also improve things for lots of
smaller groups in real-world usage.

Ciao, Michael.

P.S.: The uniqueMember-ACLs are so complex because the original author
wanted to work-around deficiencies of slapo-constraint. Have a
set-relation for fully checking partical sets would make this problem go
away...

P.P.S.: Before you ask: These are *not* tests with Æ-DIR ACLs.

P.P.P.S: I like the new etime= logging. :-)
diff --git a/servers/slapd/acl.c b/servers/slapd/acl.c
index ac00c4163..4db0c9bc2 100644
--- a/servers/slapd/acl.c
+++ b/servers/slapd/acl.c
@@ -545,6 +545,14 @@ slap_acl_get(
 		if ( a != frontendDB->be_acl && state->as_fe_done )
 			state->as_fe_done++;
 
+		if ( a->acl_attrs && !ad_inlist( desc, a->acl_attrs ) ) {
+			matches->dn_data[0].rm_so = -1;
+			matches->dn_data[0].rm_eo = -1;
+			matches->val_data[0].rm_so = -1;
+			matches->val_data[0].rm_eo = -1;
+			continue;
+		}
+
 		if ( a->acl_dn_pat.bv_len || ( a->acl_dn_style != ACL_STYLE_REGEX )) {
 			if ( a->acl_dn_style == ACL_STYLE_REGEX ) {
 Debug( LDAP_DEBUG_ACL, "=> dnpat: [%d] %s nsub: %d\n", 
@@ -605,14 +613,6 @@ slap_acl_get(
 *count );
 		}
 
-		if ( a->acl_attrs && !ad_inlist( desc, a->acl_attrs ) ) {
-			matches->dn_data[0].rm_so = -1;
-			matches->dn_data[0].rm_eo = -1;
-			matches->val_data[0].rm_so = -1;
-			matches->val_data[0].rm_eo = -1;
-			continue;
-		}
-
 		/* Is this ACL only for a specific value? */
 		if ( a->acl_attrval.bv_val ) {
 			if ( val == NULL ) {

Bugzilla spam (was: [Issue 9606] New: What is [..])

[Michael Ströder]

HI!

This looks like spam to me:

https://bugs.openldap.org/show_bug.cgi?id=9606

Please make this bug invisible so nobody clicks on the link.

Ciao, Michael.

Re: ssl_cipher_list_to_bytes:no ciphers available

[Michael Ströder]

On 5/6/21 9:30 PM, Howard Chu wrote:
> With this patch 
> https://git.openldap.org/openldap/openldap/-/commit/cd3567d750b653949e50b6245428e594dff1d8a4
> the above problem will no longer occur.> That is, if your ciphersuite doesn't 
> contain any TLS1.3 ciphers, then
> the existing TLS1.3 ciphersuites will not be changed. So you'll get
> the compiled-in defaults if nothing else was changed. That means you
> can continue to use old configs without any further changes.

That's helpful and will avoid lots of questions on the mailing lists.

Ciao, Michael.

Re: ssl_cipher_list_to_bytes:no ciphers available

[Michael Ströder]

On 5/5/21 1:29 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> TLSProtocolMin 3.3
>> TLSCipherSuite HIGH
> 
> Then you're getting TLSv1.3 on these connections. Your ciphersuite config
> has no TLSv1.3 ciphers though; cipher suite "HIGH" only affects TLSv1.2 and
> below.

Ah sorry. I've wrongly implied that OpenSSL automagically chooses
appropriate TLSv1.3 ciphers for HIGH.

> Change your suite config to include some actual TLSv1.3 suites and it will be
> fine. There's no bug here, just a change in OpenSSL behavior which is covered
> in their documentation. https://wiki.openssl.org/index.php/TLS1.3

Thanks for your explanations.

Your text seems worth to be added herein:

https://www.openldap.org/doc/admin25/guide.html#More%20extensive%20TLS%20configuration%20control

Ciao, Michael.

Re: ssl_cipher_list_to_bytes:no ciphers available

[Michael Ströder]

On 5/5/21 2:51 AM, Howard Chu wrote:
> Michael Ströder wrote:
>> I have issues with OpenSSL ciphers on my openSUSE Tumbleweed and release
>> 2.5.4 when connecting to an 2.4 provider:
>>
>> TLS: can't connect: error:141A90B5:SSL
>> routines:ssl_cipher_list_to_bytes:no ciphers available.
>>
>> An 2.4.58 consumer replica works just fine.
>>
>> There is this commit in RE25 and I'm not sure whether that introduces a
>> regression on my system:
>>
>> b72bce2400ce303766f355a1dd37f4012754c942
>> ITS#9521 Set TLSv1.3 cipher suites for OpenSSL 1.1
>>
>> BTW: openSUSE has implemented something like a crypto policy configuration:
>>
>> https://build.opensuse.org/package/view_file/security:tls/openssl-1_1/openssl-1.1.1-system-cipherlist.patch?expand=1
>>
>> Any clue what's going on?
> 
> What ciphers have you configured on your client and server? What versions of 
> OpenSSL are running on each?

TL;DR: If I comment TLSCipherSuite in the 2.5.4 slapd.conf everything works.

It fails when setting this in slapd provider (2.4.58) *and* consumer
(2.5.4):

TLSProtocolMin 3.3
TLSCipherSuite HIGH

BTW: I didn't know that these server-side settings also affect the
syncrepl-client config.

This works when connecting with 2.5.4 CLI tools to 2.4.58 server:

LDAPNOINIT=1 LDAPTLS_PROTOCOL_MIN=3.3 LDAPTLS_CIPHER_SUITE=HIGH
/opt/openldap-ms/bin/ldapwhoami ..

But connecting even only with openssl s_client to 2.5.4 server does not
work with the above TLSCipherSuite settings.

All systems have OpenSSL 1.1.1k. The symlink
/etc/crypto-policies/back-ends/openssl.config points to
/usr/share/crypto-policies/DEFAULT/openssl.txt which has this single line:

@SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

Not sure what is really affected by this file.

You can see how RPMs are built in OBS:

https://build.opensuse.org/package/show/security:tls/openssl-1_1

https://build.opensuse.org/package/show/home:stroeder:openldap25/openldap-ms

Ciao, Michael.

Re: ssl_cipher_list_to_bytes:no ciphers available

[Michael Ströder]

Filed ITS:

https://bugs.openldap.org/show_bug.cgi?id=9546

Ciao, Michael.

ssl_cipher_list_to_bytes:no ciphers available

[Michael Ströder]

HI!

I have issues with OpenSSL ciphers on my openSUSE Tumbleweed and release
2.5.4 when connecting to an 2.4 provider:

TLS: can't connect: error:141A90B5:SSL
routines:ssl_cipher_list_to_bytes:no ciphers available.

An 2.4.58 consumer replica works just fine.

There is this commit in RE25 and I'm not sure whether that introduces a
regression on my system:

b72bce2400ce303766f355a1dd37f4012754c942
ITS#9521 Set TLSv1.3 cipher suites for OpenSSL 1.1

BTW: openSUSE has implemented something like a crypto policy configuration:

https://build.opensuse.org/package/view_file/security:tls/openssl-1_1/openssl-1.1.1-system-cipherlist.patch?expand=1

Any clue what's going on?

Ciao, Michael.

Re: slapo-ppolicy 2.4 vs. 2.5

[Michael Ströder]

On 5/4/21 9:47 AM, Ondřej Kuzník wrote:
> On Sat, May 01, 2021 at 05:31:44PM +0200, Michael Ströder wrote:
>> slapo-ppolicy in OpenLDAP 2.5 shows slightly different behaviour in
>> python-ldap0 tests (see test output below).
>> [..]
>> AssertionError: 'Password expired! 1 grace logins left.' != 'Password
>> expired! 2 grace logins left.'
> 
> Does the count reported match the wording of the draft in section 6.2?
> [..]
> If not, please reopen ITS#7596 with a test case.

Thanks for pointing out ITS#7596. I've now updated my test to match the
new behaviour when running on OpenLDAP 2.5.

Still I have failures in my draft-vchu-ldap-pwd-policy tests (see
below). These might be related to ITS#9279, though I'm not sure. Any
changes in this area?

Ciao, Michael.

==
FAIL: test001_pwdpolicy_expiration (tests.test_ppolicy.TestPwdPolicy)
--
Traceback (most recent call last):
  File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py",
line 287, in test001_pwdpolicy_expiration
self.assertIsInstance(bind_res.ctrls[0], PasswordExpiringControl)
AssertionError:  is not an instance of 

==
FAIL: test002_pwdpolicy_expired (tests.test_ppolicy.TestPwdPolicy)
--
Traceback (most recent call last):
  File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py",
line 308, in test002_pwdpolicy_expired
l.simple_bind_s(self.user_dn, user_password.encode('utf-8'))
AssertionError: INVALID_CREDENTIALS not raised

Re: slapo-ppolicy 2.4 vs. 2.5

[Michael Ströder]

On 5/3/21 5:39 PM, smckin...@symas.com wrote:
>> From: "Michael Ströder" 
>> Do you have any tests you could run against 2.4 and 2.5 to verify
>> whether both have same behaviour?
> 
> I have tested 2.4 and 2.5 pw policies using Apache Fortress tests:

Do you also look at the decreasing grace login counter in diagnostic
message?

> The only functional difference that I found was 2.5 now requires
> sending the RelaxControl ("1.3.6.1.4.1.4203.666.5.12") on the
> following ops:>
> - lock/unlock
> - mods of user's pwdPolicySubentry attribute

Currently not relevant for my tests.

> Other than that, everything else worked the same, besides no longer
> including the pwpolicy.schema in the server config of course.
This is already covered since quite a while by checking whether file
ppolicy.ldif exists in the schema/ directory or not.

Ciao, Michael.

slapo-ppolicy 2.4 vs. 2.5

[Michael Ströder]

HI!

slapo-ppolicy in OpenLDAP 2.5 shows slightly different behaviour in
python-ldap0 tests (see test output below).

Tests:
https://gitlab.com/ae-dir/python-ldap0/-/blob/master/tests/test_ppolicy.py

When working with Ondřej for solving ITS#9279 I finally "fixed" ldap0
tests to accomodate the behaviour of OpenLDAP 2.4.x. I did not feel
comfortable back then because it was not clear to me whether it was the
correct fix.

Do you have any tests you could run against 2.4 and 2.5 to verify
whether both have same behaviour?

Ciao, Michael.

==
FAIL: test003_ppolicy_grace_logins (tests.test_ppolicy.TestPPolicy)
--
Traceback (most recent call last):
  File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py",
line 235, in test003_ppolicy_grace_logins
self.assertEqual(
AssertionError: 'Password expired! 1 grace logins left.' != 'Password
expired! 2 grace logins left.'
- Password expired! 1 grace logins left.
?   ^
+ Password expired! 2 grace logins left.
?   ^


==
FAIL: test001_pwdpolicy_expiration (tests.test_ppolicy.TestPwdPolicy)
--
Traceback (most recent call last):
  File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py",
line 285, in test001_pwdpolicy_expiration
self.assertIsInstance(bind_res.ctrls[0], PasswordExpiringControl)
AssertionError:  is not an instance of 

==
FAIL: test002_pwdpolicy_expired (tests.test_ppolicy.TestPwdPolicy)
--
Traceback (most recent call last):
  File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py",
line 306, in test002_pwdpolicy_expired
l.simple_bind_s(self.user_dn, user_password.encode('utf-8'))
AssertionError: INVALID_CREDENTIALS not raised

Re: some overlays missing with --enable-overlays=mod

[Michael Ströder]

On 2/10/21 5:00 PM, Quanah Gibson-Mount wrote:
> --On Wednesday, February 10, 2021 9:56 AM +0100 Michael Ströder
>  wrote:
>> It seems that some overlays were moved from contrib to main source. I
>> appreciate that.
>>
>> autogroup
>> lastbind
>> smbk5pwd
> 
> The source code does not agree with this statement.

Ah, sorry. I probably was confused by the config.h issue.

Ciao, Michael.

some overlays missing with --enable-overlays=mod

[Michael Ströder]

HI!

It seems that some overlays were moved from contrib to main source. I
appreciate that.

autogroup
lastbind
smbk5pwd

But it seems these are not built with --enable-overlays=mod, at least
not with my .spec file:

https://build.opensuse.org/package/view_file/home:stroeder:openldap25/openldap2/openldap2.spec?expand=1

Anything I have to tweak on my side?

Ciao, Michael.

2.5 build failure on OBS

[Michael Ströder]

HI!

As usual I'm using openSUSE Build Service to build openldap2 RPMs. This
smoothly works with 2.4.x.

But building 2.5 branch snapshot fails.

Maybe OBS compiler options are set pretty strict because it outputs:

[  147s] cc1: some warnings being treated as errors
[  147s] make[2]: *** [: slapd-watcher.o] Error 1

You can look at the full build log with some warnings here:

https://build.opensuse.org/public/build/home:stroeder:branches:home:stroeder:iam/openSUSE_Tumbleweed/x86_64/openldap25/_log

Ciao, Michael.

Re: HAProxy proxy protocol support

[Michael Ströder]

On 11/19/20 5:04 PM, Howard Chu wrote:
> Paul B. Henson wrote:
>> In general, I believe applications listening on a specific port are either 
>> expecting the proxy protocol header, or not, I do not think it is dynamically
>> determined. As such, from an implementation perspective, my initial thought 
>> is that it would be implemented in terms of configuration as an additional 
>> URL
>> specified via the -h option, something like "ldapp://" or "ldap_p://", 
>> "ldapsp://" or "ldaps_p://" or whatever seems most desirable. A server might 
>> listen on
>> the standard ports accepting only proxied connections, or it might listen 
>> for normal connections on the standard ports and for proxy connections on 
>> alternative
>> ports.
> 
> Yeah, that agrees with my read of the document. I think "ldapp://" and 
> "ldapsp://"
> would be usable.

My suggestions:

1. Config directives for specifying IP address(es) and network(s)
expected and trusted to send proxy protocol header.

2. Separate who peernamestyle for explicitly using the proxied IP
addresses in ACLs. This would allow to specify ACLs with client-proxy
relationship.

3. Log the proxied peername separately, similar how session tracking
control is logged.

Ciao, Michael.

Re: HAProxy proxy protocol support

[Michael Ströder]

On 11/19/20 9:52 AM, Michael Ströder wrote:
> On 11/19/20 2:49 AM, Paul B. Henson wrote:
>> Amazon's solution for that is to support HAProxy's proxy protocol in
>> their load balancer:
>>
>> https://www.haproxy.com/blog/haproxy/proxy-protocol/
>>
>> Basically, this is an in band signaling mechanism that inserts an
>> additional header in the initial connection data containing the original
>> client IP address/source port and destination IP address/source port,
> 
> AFAICS this only works with HTTP and SMTP.

Aaargh! I've missed the binary header part. So forget my former comments.

Ciao, Michael.

Re: HAProxy proxy protocol support

[Michael Ströder]

On 11/19/20 2:49 AM, Paul B. Henson wrote:
> Amazon's solution for that is to support HAProxy's proxy protocol in
> their load balancer:
> 
> https://www.haproxy.com/blog/haproxy/proxy-protocol/
> 
> Basically, this is an in band signaling mechanism that inserts an
> additional header in the initial connection data containing the original
> client IP address/source port and destination IP address/source port,

AFAICS this only works with HTTP and SMTP.

> openLDAP does not support the protocol, and I was unable to find any
> past discussion of it.

LDAP uses BER-encoded ASN.1, not ASCII.

The LDAP session tracking extended control [1] can be used to pass the
client's IP address of a proxied connection to the LDAP server.
Currently slapd only logs the content of this control.

But it would have to be implemented in the proxy, here the AWS
load-balancer. *And* slapd's ACLs would have to be extended to evaluate
this.

Would be a nice feature for lloadd [2].

[1] https://tools.ietf.org/html/draft-wahl-ldap-session-03

[2] https://bugs.openldap.org/show_bug.cgi?id=8747

Ciao, Michael.

bugzilla spam?

[Michael Ströder]

HI!

To this seems to be spam:

https://bugs.openldap.org/show_bug.cgi?id=6036#c5

Maybe also block the user fieldenginee...@yahoo.com?

Ciao, Michael.

Re: RE25 make depend

[Michael Ströder]

On 7/26/20 12:43 AM, Quanah Gibson-Mount wrote:
> --On Saturday, July 25, 2020 2:27 PM +0200 Michael Ströder
>  wrote:
>> With RE25 branch make depend fails on my system (see below).
>>
>> Find attached my build script which works just fine for RE24. Any
>> changes needed for RE25?
> 
> <https://bugs.openldap.org/show_bug.cgi?id=9236>
> 
> Apparently your build script is referencing non-existent backends.
> 
> cd back-shell && make -w depend

Actually I've only added
  --enable-shell=no

to avoid building back-shell.

Removing this line does *not* help.

Ciao, Michael.

RE25 make depend

[Michael Ströder]

HI!

With RE25 branch make depend fails on my system (see below).

Find attached my build script which works just fine for RE24. Any
changes needed for RE25?

Ciao, Michael.

  cd back-shell && make -w depend
make[3]: Entering directory
'/home/michael/src/openldap-git/re25/openldap/servers/slapd/back-shell'
make[3]: *** No rule to make target 'Makefile.in', needed by 'Makefile'.
 Stop.
make[3]: Leaving directory
'/home/michael/src/openldap-git/re25/openldap/servers/slapd/back-shell'
make[2]: *** [Makefile:589: depend-local-srv] Error 1
make[2]: Leaving directory
'/home/michael/src/openldap-git/re25/openldap/servers/slapd'
make[1]: *** [Makefile:328: depend-common] Error 1
make[1]: Leaving directory
'/home/michael/src/openldap-git/re25/openldap/servers'
make: *** [Makefile:349: depend-common] Error 1


build-openldap.sh
Description: application/shellscript

Re: ppolicy control exposure in RE24?

[Michael Ströder]

On 7/7/20 11:55 PM, Quanah Gibson-Mount wrote:
> Currently the ppolicy overlay does not expose the related control in the
> supportedControl attribute of the rootDSE.  This is due to the general
> policy that controls for items that are not part of a finalized
> specification are not published.

This policy was broken right from the beginning.

> However, at this point, ppolicy while not finalized, is long
> established. For 2.5, we will be exposing the control, but I think it
> could be useful to do this for 2.4.51+ as well.
> 
> Does anyone have any objections to this change being backported to RE24?
> 
> 

I highly appreciate it. And I use -DSLAP_SCHEMA_EXPOSE in all my
OpenLDAP builds and never experienced any issue with that.

Except that I forget about -DSLAP_SCHEMA_EXPOSE when answering "works
for me" on the mailing list... ;-)

Ciao, Michael.

Re: contrib modules to promote to mainline for 2.5?

[Michael Ströder]

On 4/23/20 2:47 PM, Clément OUDOT wrote:
> 
> Le 22/04/2020 à 18:15, Quanah Gibson-Mount a écrit :
>> Are there any contrib modules that we should consider promoting to
>> mainline for the 2.5 series?  I.e., sha2, argon2 seem like potential
>> options.
> 
> Maybe smbk5pwd module and autogroup overlay?

Is smbk5pwd really useful today?

I'm asking although I made use of it in former deployments.

1. Kerberos functionality does not work with MIT Kerberos.

2. AFAICS NTLM password hashes (WinNT domain) will stop working with
newer Windows versions. At least that's what I understood on the Samba
mailing lists. Also storing NT password hashes is a security nightmare.

Ciao, Michael.

Re: contrib modules to promote to mainline for 2.5?

[Michael Ströder]

On 4/22/20 8:57 PM, Quanah Gibson-Mount wrote:
> Ok.  I would note that the argon2 module adds a dependency on a 3rd
> party library, so we'd need to add detection for it?

If an automatic check is too much work I could live with a simple
configure option --enable-argon2 with a textual comment "needs
libsodium". The default could be --disable-argon2. So every downstream
package can easily switch it on.

Ciao, Michael.

Re: contrib modules to promote to mainline for 2.5?

[Michael Ströder]

On 4/22/20 8:17 PM, Gavin Henry wrote:
> What's the recommended hash for UserPassword at the moment? 

Tough question.

In Æ-DIR's default config I'm using non-portable settings available on
mainstream Linux distros since a couple of years:

password-hash {CRYPT}
password-crypt-salt-format "$6$rounds=2$%.16s"

I'm looking forward to get a strong portable hash algorithm.

Ciao, Michael.

Re: contrib modules to promote to mainline for 2.5?

[Michael Ströder]

On 4/22/20 8:01 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> On 4/22/20 6:15 PM, Quanah Gibson-Mount wrote:
>>> Are there any contrib modules that we should consider promoting to
>>> mainline for the 2.5 series?  I.e., sha2, argon2 seem like potential
>>> options.
>>
>> +1 for pw-sha2 and pw-argon2.
> 
> sha2 is already obsolete, for password purposes. I see no reason to promote 
> it.

Yes, SHA-2 is really weak. But moving pw-sha2 into mainline is *not*
promoting it.

I see some use when migrating from other LDAP servers.

Ciao, Michael.

Re: contrib modules to promote to mainline for 2.5?

[Michael Ströder]

On 4/22/20 6:15 PM, Quanah Gibson-Mount wrote:
> Are there any contrib modules that we should consider promoting to
> mainline for the 2.5 series?  I.e., sha2, argon2 seem like potential
> options.

+1 for pw-sha2 and pw-argon2.

FWIW:
slapo-noopsrch and slapo-lastbind is what I use in almost every
installation.

Ciao, Michael.

Re: Two log lines for SRCH parameters?

[Michael Ströder]

On 2/11/20 1:48 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> I'm wondering why there are two log lines for listing the search
>> parameters for a single search operation:
>>
>> SRCH base="dc=ae-dir,dc=example,dc=org" scope=2 deref=0
>> filter="(objectClass=aePerson)"
>>
>> SRCH attr=cn givenName sn mail aeStatus
>>
>> Is there any rationale for that?
> 
> Because any of DN, filter, or attrs could be too long for a single syslog 
> message.
> On many systems the limit was 1024 characters; using a single log message 
> resulted
> in too many truncated messages.

Oh, I see [1].

Even in 2009 only a SHOULD for 2048 octets was defined while the MUST
minimum was _lowered_ to 480 [2].

Ciao, Michael.

[1] https://tools.ietf.org/html/rfc3164#section-4.1

[2] https://tools.ietf.org/html/rfc5424#section-6.1

Two log lines for SRCH parameters?

[Michael Ströder]

HI!

I'm wondering why there are two log lines for listing the search
parameters for a single search operation:

SRCH base="dc=ae-dir,dc=example,dc=org" scope=2 deref=0
filter="(objectClass=aePerson)"

SRCH attr=cn givenName sn mail aeStatus

Is there any rationale for that? Wouldn't it be better to also list
attr= along with the other search parameters? The attributes could also
be listed as comma-separated list, so parsing with space as separator
would be easy.

I'm asking for a rather *small* change. I deliberately do not want to
start a let's-fix-all-the-log-issues discussion.

Ciao, Michael.

get rid of -releng suffix

[Michael Ströder]

HI!

Is the releng suffix for the shared libs still needed? It made sense in
former times.

But given automatic testing in VMs, containers, CI/CD delivery pipelines
it just adds this small extra complexity without any benefit. I suggest
to drop it for 2.5.x.

Opinions?

Ciao, Michael.

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:
> --On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
>  wrote:
> 
>> On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
>>> Also, I really really really would like 2.4.49 to be the end of 2.4,
>>> outside the possibility of some critical CVEs.
>> But that's just your personal goal which is leaving systems in
>> production unpatched until you feel you're done. IMO that's totally
>> wrong.
> 
> No, it's the project goal to switch the focus to getting OpenLDAP 2.5
> released.  At some point, work on 2.4 needs to stop.  Unless you'd like
> to see 2.5 dragged out another decade?

Is it realistic to enforce that 2.4.49 will be the final 2.4.x release
before we saw at least one 2.5.x release? Sounds really strange to me.

Ciao, Michael.

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
> Also, I really really really would like 2.4.49 to be the end of 2.4,
> outside the possibility of some critical CVEs.
But that's just your personal goal which is leaving systems in
production unpatched until you feel you're done. IMO that's totally wrong.

If releasing a new version is so much stress then there's something
fundamentally broken in the whole process.

I'd like to emphasize here that this is likely not your personal fault.
It rather shows a deficiencies of the infrastructure. I've offered help
in the past various times.

> As for the new release numbering, I've thought about that as well, and
> was thinking potentially we may skip a release.  I.e., go from 2.5.1 to
> 2.5.3 with no 2.5.2 if we just need to do a bug fix release (or vice
> versa if we match Gnome's strategy as Ryan brought up.

I'm not a friend of artificial constraints which likely do not fit
reality later. I think there were good reasons why this scheme was
abandoned for Linux kernel development. I don't know the details though.

> But my point was, I think it's a fallacy to tie software quality and
> frequency of releases.

Of course such a simple assumption is bullshit. To me the list of
outstanding unfixed/unreleased issues matters most.

Ciao, Michael.

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/28/20 6:30 PM, Quanah Gibson-Mount wrote:
> --On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder
>  wrote:
> 
>> On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
>>> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
>>>  wrote:
>>>
>>>> On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
>>>>> To me, frequent releases
>>>>> generally indicate an immature, unstable, and buggy product. ;)
>>>>
>>>> Are you sarcastic here?
>>>
>>> No, not at all.  [..] If we release every 2 weeks, but slapd core
>>> dumps 90% of the time, is that really better?  Sure, the project
>>> looks more "active", but I wouldn't see that as a benefit/gain.
>> ITS#9124 is known since almost two months now and there's no upstream
>> release with a fix. (And remember that I've tested RE24 branch revealing
>> that the first fix was seg faulting.)
> 
> You're switching topics.

Nope. I'm very much on-topic.

ITS#9124 is a good example that the "stable" status of the release
branch is just an assumption. It makes clear that a quicker process for
more urgent releases is needed.

I'm not blaming anybody that there are bugs. We are all humans and we
make faults. Period. But stating that there are bugs in "stable"
releases is what really concerns me.

Today releasing is already way too slow. And I'm concerned that a
release policy with additional constraints, as suggested with
odd-/even-numbered releases, will make it even harder to get important
fixes out of the door.

Ciao, Michael.

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
>  wrote:
> 
>> On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
>>> To me, frequent releases
>>> generally indicate an immature, unstable, and buggy product. ;)
>>
>> Are you sarcastic here?
> 
> No, not at all.  [..] If we release every 2 weeks, but slapd core
> dumps 90% of the time, is that really better?  Sure, the project
> looks more "active", but I wouldn't see that as a benefit/gain.
ITS#9124 is known since almost two months now and there's no upstream
release with a fix. (And remember that I've tested RE24 branch revealing
that the first fix was seg faulting.)

=> The OpenLDAP project needs more continuous testing to be able to
provide quicker releases in such an emergency case.

Just being slower and leave such a security issue to packagers adding
back-ports is not stable (for whatever definition of "stable").

Ciao, Michael.

P.S.: And yes, cyrus-sasl is even worse by not handling CVE-2019-19906
(first filed as ITS#9123).

Re: New release policy for OpenLDAP

[Michael Ströder]

On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
> To me, frequent releases
> generally indicate an immature, unstable, and buggy product. ;)

Are you sarcastic here?

Ciao, Michael.

OpenLDAP BoF session at FOSDEM?

[Michael Ströder]

HI!

Is anyone of the OpenLDAP devs around at FOSDEM this year?

Would it make sense to apply for a BoF session room to discuss things
face-to-face?

Ciao, Michael.

Re: 2.4 commit review

[Michael Ströder]

On 1/10/20 11:25 PM, Quanah Gibson-Mount wrote:
> --On Friday, January 10, 2020 6:06 PM +0100 Clément OUDOT
>  wrote:
>> I would like to know if there was some date planned for 2.4.49, and if
>> this ITS could be added to this release:
>> http://www.openldap.org/its/index.cgi/Software%20Bugs?id=9146;selectid=91
>> 46
> 
> It was already merged into RE24 and added to the CHANGES file for 2.4.49.
> 
> There are a few open ITSes that need addressing before I can proceed
> with a testing call.

The fix for ITS#9124 is pretty urgent. So other ITS should not block
releasing 2.4.49.

Ciao, Michael.

Re: ITS#9124: slapd RE24 crashes (was: ldap0 does not work with RE24)

[Michael Ströder]

On 1/3/20 12:55 PM, Ondřej Kuzník wrote:
> On Thu, Jan 02, 2020 at 03:12:26PM +0100, Michael Ströder wrote:
>> I've changed the subject to make it more clear what the real issue is.
> 
> Yup, was away over the holidays, this should now be fixed in master if
> you want to have a look.

AFAICS it has not been merged into RE24 yet.

Does it make sense to test master?
master currently fails in test022-ppolicy.

Ciao, Michael.

Re: ldap0 does not work with RE24

[Michael Ströder]

On 12/23/19 8:57 PM, Michael Ströder wrote:
> It seems I'm experiencing a regression when running tests of
> python-ldap0 with current RE24 which does not fail with 2.4.48:
> 
> test016_cancel (__main__.Test00_LDAPObject) ... munmap_chunk(): invalid
> pointer
> ERROR
> 
> There was this change for ITS#9124. So I guess it's causing this regression.

I forgot to mention that slapd crashes and not the test client.

Ciao, Michael.

ldap0 does not work with RE24

[Michael Ströder]

HI!

It seems I'm experiencing a regression when running tests of
python-ldap0 with current RE24 which does not fail with 2.4.48:

test016_cancel (__main__.Test00_LDAPObject) ... munmap_chunk(): invalid
pointer
ERROR

There was this change for ITS#9124. So I guess it's causing this regression.

Could someone look into this?

Ciao, Michael.

Re: Session tracking control

[Michael Ströder]

On 11/5/19 11:30 AM, Howard Chu wrote:
> It looks like we currently parse this control, but only to allow
> logging its contents, and nothing more. Seems like it would be useful
> to carry the parsed info along with the o_authz struct, and make it
> usable in the ACL engine. This would allow setting ACLs that can
> distinguish between different applications acting on behalf of a
> given user (or service).>
> Any security downside to this?

If the LDAP client got hacked the content of the control value cannot be
trusted. So security considerations similar like with proxy authz apply.

Anyway I'd like to have it available also in set-based ACLs.

Furthermore I'd like to have normal peer address available in set-based
ACLs e.g. to grant auth access to userPassword only to bind requests
coming from a certain IP address stored in the attribute of a user's
entry (e.g. 'aeRemoteHost' in Æ-DIR [1] and [2]).

Ciao, Michael.

[1] https://www.ae-dir.com/docs.html#schema-oc-aeUser-attributes

[2] https://www.ae-dir.com/docs.html#schema-oc-aeService-attributes



smime.p7s
Description: S/MIME Cryptographic Signature

git://git.openldap.org down?

[Michael Ströder]

HI!

It seems that git://git.openldap.org is not reachable since yesterday.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Please review 2.5 plan (non-development items)

[Michael Ströder]

On 7/23/19 3:37 PM, Ondřej Kuzník wrote:

I've prepared a plan what the project wants to achieve as part of the
2.5 stream apart from core OpenLDAP development that I intend to send to
-technical for wider discussion and as a call for participation.

It has been suggested to me that people might want to comment/propose
changes to it so attaching a draft here. Please let me know what you
think or if you agree in broad terms it is fit to be circulated more
widely.


Thanks for driving this. Text looks good to me.

Eventually there will be lengthy discussions about various tools (now 
reaching out for the popcorn bag). So you might want to tighten it some 
more by suggesting all the gitlab stuff (Wiki, CI pipelines) as possible 
tools. E.g. AFAIK the Wiki in gitlab is just a git repo of markdown files.


Regarding the test suite:
Would it be feasible to use Python for the job? If yes, you can directly 
use the unittest module from its standard lib which gives you much 
better control, error handling and reporting.


And I already enjoy using gitlab's CI runner stuff for this (but using 
static slapd.conf generated):

https://gitlab.com/ae-dir/python-aedir/blob/master/.gitlab-ci.yml

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/20/19 8:45 PM, Nikos Voutsinas wrote:
> Weird... My build of OPENLDAP_REL_ENG_2_4_48 on Debian/Buster against
> openssl was working, without using the olcTLSCACertificateFile.

Why that happens is a good question.

You probably have to dig a bit deeper and examine whether the OpenSSL
lib initializes a default trust store generated by
update-ca-certificates (from Debian package ca-certificates) and whether
your CA cert is present there.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Drop support for GNUTLS and libnss in 2.5?

[Michael Ströder]

On 7/20/19 6:07 PM, Ryan Tandy wrote:
> On Sat, Jul 20, 2019 at 12:13:38PM +0200, Michael Ströder wrote:
>> The question is whether this is still revelavant with OpenSSL 3.0.0
>> moving to Apache-2.0 license [1]. [2] says APL-2.0 is not compatible
>> with GPLv2 though.
> 
> Unfortunately that's correct - the Apache license does not solve the
> issue for binaries containing GPLv2 code without an OpenSSL exception.

How many GPLv2 licensed Debian packages link libldap?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/21/19 4:32 AM, Quanah Gibson-Mount wrote:
> You missed the point.  It wasn't about syncrepl vs back-ldap, it was
> about whether or not *anything* used in slapd should ever pull in data
> from ldap.conf.

From my understanding up to now ldap.conf was used in back-ldap and
people make use of it. Aside from whether this was a doc or
implementation bug you should seriously consider whether it's worth the
trouble to change back-ldap's behaviour within 2.4.x release series.

Personally I'm in the camp of explicitly specifying (possibly different)
trust anchors for every aspect. Especially since we all should use a
decent config management today it's really easy. So I'd like to propose
a change for 2.5.x that nothing within slapd uses ldap.conf
(LDAPNOINIT=1 for all of slapd's internal stuff).

Also I don't want to use system-wide trust stores by default without
explicitly being configured. But that's another issue.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/20/19 3:41 PM, Michael Ströder wrote:
> On 7/20/19 1:31 PM, Nikos Voutsinas wrote:
>> Ok that can be done, although I am pretty sure that it will work with
>> OpenSSL since you have already tested a similar setup  on openSUSE.
>>
>> The idea here is to first confirm with others the problem and then early
>> identify the change set that triggers this before the announcement of
>> the release
>>
>> What worries me is that the exact config options and gnutls libs with
>> the 2.4.47 source works as expected, thus we can not blame GNUTLS for
>> that, despite any arguments one may have against GNUTLS.
> 
> Let's not speculate about whatever might be the cause or not.
> 
> Just start testing. Take care not to mess up builds and test results
> (like I did sometimes during the last days).

BTW: Are your 2.4.47 and 2.4.48 builds are done exactly the same way?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/20/19 1:31 PM, Nikos Voutsinas wrote:
> Ok that can be done, although I am pretty sure that it will work with
> OpenSSL since you have already tested a similar setup  on openSUSE.
> 
> The idea here is to first confirm with others the problem and then early
> identify the change set that triggers this before the announcement of
> the release
> 
> What worries me is that the exact config options and gnutls libs with
> the 2.4.47 source works as expected, thus we can not blame GNUTLS for
> that, despite any arguments one may have against GNUTLS.

Let's not speculate about whatever might be the cause or not.

Just start testing. Take care not to mess up builds and test results
(like I did sometimes during the last days).

Ciao, Michael.

Drop support for GNUTLS and libnss in 2.5?

[Michael Ströder]

HI!

IMHO OpenLDAP project should drop support for building against GNUTLS
and libnss. Support for these seems to be largely non-existent and it's
a waste of time, especially since there is no build pipeline and no
automatic testing for all the variants.

The support for libnss was done by RedHat for the unified crypto project
which is AFAICS obsolete. Does anybody maintain the stuff?

The support for GNUTLS was requested by Debian folks because of OpenSSL
licensing paranoia. Does anybody maintain the stuff?
The question is whether this is still revelavant with OpenSSL 3.0.0
moving to Apache-2.0 license [1]. [2] says APL-2.0 is not compatible
with GPLv2 though.

Ciao, Michael.

[1] https://www.openssl.org/blog/blog/categories/license/

[2] https://www.gnu.org/licenses/license-list.html#apache2



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/20/19 10:51 AM, Nikos Voutsinas wrote:
> On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder  <mailto:mich...@stroeder.com>> wrote:
> On 7/20/19 8:25 AM, Nikos Voutsinas wrote:
> > In the view of the new openldap release, I ran some tests by using the
> > current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree
> Which snapshot? Really the latest 407ce9d prepared for release and with
> latest mdb merge?
> Yeap the one tagged for 2.4.48

Ok.

> > The testing environment was a Debian (Stable/Buster) and
> > Openldap was compiled with the Debian's gnu TLS libs.
> 
> Could you try to link with OpenSSL and test that to preclude that it's
> an issue with GnuTLS?
>  
> Whenever it was a gnutls library issue, even the plain ldapsearch -H
> ldaps:// had problems. Now this is not the case, cmd line utils from the
> same build at the same remote ldaps:/// work.

There are changes in libldap and slapd-ldap related to TLS which might
not work correctly with GnuTLS.

So could you try to first link with OpenSSL? If that works it would mean
that the GnuTLS support needs some more work.

BTW: During the last days Quanah and me investigated an issue with a
(now reverted) patch for libldap only occuring with dhcpd using libldap.
ldapsearch and many other LDAP clients were working just fine.

Ciao, Michael.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/20/19 8:25 AM, Nikos Voutsinas wrote:
> In the view of the new openldap release, I ran some tests by using the
> current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree

Which snapshot? Really the latest 407ce9d prepared for release and with
latest mdb merge?

> and based on my
> findings It seems that this build breaks the back_ldap backend when it
> is used with a remote ldaps:/// server.

I have a similar config working just fine with git snapshot 407ce9d.
But I'm running this on openSUSE Tumbleweed with OpenLDAP linked against
OpenSSL.

> The testing environment was a Debian (Stable/Buster) and
> Openldap was compiled with the Debian's gnu TLS libs.

Could you try to link with OpenSSL and test that to preclude that it's
an issue with GnuTLS?

> TLS: peer cert untrusted or revoked (0x42)
> TLS: can't connect: (unknown error code).

Could you try with gnutls-cli to check whether TLS just works?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Issues ISC dhcpd using libldap of OpenLDAP 2.4.48

[Michael Ströder]

On 7/17/19 4:41 PM, Howard Chu wrote:
> strace is not useful here. Pretty sure we've stated this many times before.

Sorry. Indeed ltrace output is more helpful.

Here's the test with 2.4.48:


27337 ldap_initialize()
 = 
27337 free(0x560583024230)
 = 
27337 ldap_set_option()
 = 
27337 ldap_set_option()
 = 
27337 ldap_set_rebind_proc()
 = 
27337 strdup("")
 = 0x560583024230
27337 strlen()
 = 
27337 ldap_sasl_bind_s()
 = 
27337 free(0x560583024230)
 = 
27337 ldap_err2string()
 = 
27337 __vsnprintf_chk(0x5605829dbde0, 1024, 1, 1024)
 = 77
27337 __syslog_chk(3, 1, 0x5605828fa7f1, 0x5605829dbde0)
 = 0
27337 write(2, "Error: Cannot login into ldap se"..., 77)
 = 77
27337 write(2, "\n", 1)
 = 1


With 2.4.47 it looks different:


27776 ldap_initialize( 
27776 inet_pton(2, 0x7ffc9ca4b370, 0x7ffc9ca4aed0, 0x557ed75725ff)
 = 0
27776 inet_pton(10, 0x7ffc9ca4b370, 0x7ffc9ca4aed0, 62)
 = 0
27776 malloc(312)
 = 0x557ed8afa810
27776 malloc(35232)
 = 0x557ed8afa950
27776 memset(0x557ed8afa950, '\0', 35232)
 = 0x557ed8afa950
27776 malloc(8800)
 = 0x557ed8b03300
27776 memset(0x557ed8b03300, '\0', 8800)
 = 0x557ed8b03300
27776 malloc(8192)
 = 0x557ed8b05570


Ciao, Michael.

Issues ISC dhcpd using libldap of OpenLDAP 2.4.48

[Michael Ströder]

HI!

I've tried the following without success:

Disabled Link Time Optimization (LTO), recently introduced for openSUSE
Tumbleweed, in packages openldap2 and dhcp-server. Just to make sure it
does not cause any harm.

Upstream update to dhcp 4.4.1 without any of openSUSE's back-port patches.

dhcpd does not even contact the LDAP server. It seems there's some call
into libldap failing and this is handled by dhcpd as connection error.

FWIW: I've attached the strace output of the following command which
does not say much:
LDAPNOINIT=1 /usr/sbin/dhcpd -T

I have no clues where to look now and I have to give up.

Could someone review the source of dhcpd?
The relevant files are ldap*.c:

https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=tree;f=server

Ciao, Michael.

- dhcpd.conf --
ldap-server "127.0.0.1";
ldap-port 389;
ldap-username "cn=host.example.com,ou=DHCP,example,dc=com";
ldap-password "host-secret";
ldap-base-dn "ou=DHCP,example,dc=com";
ldap-ssl off;
ldap-method dynamic;



strace-dhcpd.txt.gz
Description: application/gzip


smime.p7s
Description: S/MIME Cryptographic Signature

Re: NO-USER-MODIFICATION for attribute type description memberOf

[Michael Ströder]

On 7/11/19 6:43 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> Currently attribute type description memberOf does not have
>> NO-USER-MODIFICATION.
>>
>> memberof.c contains a commented line:
>>  /* "NO-USER-MODIFICATION " */   /* add? */
>>
>> But it's my understanding that if the memberof overlay is responsible
>> maintaining this attribute NO-USER-MODIFICATION should be added.
>>
>> Any objections against adding it?
>
> ISTR a few things would break when that was uncommented. Feel free to
> test it out though.

Hmm, the git log is pretty terse. This commit after intial import only
added comments:

 snip 
commit e33abd467c526a740a10f77e84ccc78d7b18e6d7
Author: Pierangelo Masarati 
Date:   Sat Aug 25 16:02:43 2007 +

needs work: memberOf should not be replicated
 snip 

There's no reasoning why 'memberOf' should not be replicated.
IMHO it should be replicated to avoid the effects described in ITS#8613 [1].

Can anyone shed some light on this?

Ciao, Michael.

[1] https://www.openldap.org/its/index.cgi/?findid=8613

NO-USER-MODIFICATION for attribute type description memberOf

[Michael Ströder]

HI!

Currently attribute type description memberOf does not have
NO-USER-MODIFICATION.

memberof.c contains a commented line:

/* "NO-USER-MODIFICATION " */   /* add? */

But it's my understanding that if the memberof overlay is responsible
maintaining this attribute NO-USER-MODIFICATION should be added.

Any objections against adding it?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8866 (was: ITS review 6/14/2019)

[Michael Ströder]

On 6/27/19 6:37 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> On 6/27/19 6:23 PM, Michael Ströder wrote:
>>> On 6/27/19 6:18 PM, Howard Chu wrote:
>>>> Michael Ströder wrote:
>>>>> On 6/14/19 5:15 PM, Quanah Gibson-Mount wrote:
>>>>>> Thanks to Ondrej, this list is a bit shorter now. :)
>>>>>
>>>>> But one more I'd love to see in 2.4.48:
>>>>>
>>>>> ITS#8866: RFE: slapo-constraint to return filter used in diagnostic 
>>>>> message
>>>>>
>>>>> https://www.openldap.org/its/index.cgi?findid=8866
>>>>
>>>> I don't believe the information disclosure issues have been
>>>> sufficiently answered there. Overall it's a bad idea and goes against
>>>> our standing policy of minimal disclosure.
>>> Sorry, you already have the disclosure.
>>>
>>> Citing from my old e-mail found here:
>>> https://www.openldap.org/lists/openldap-devel/201711/msg3.html
>>>
>>>> But this problem exists anyway because an attacker can probe
>>>> values by adding entries with non-unique attributes and determine
>>>> whether an attribute value exists or not by distinguishing the result
>>>> code constraintViolation(19) vs. insufficientAccessRights(50).
>>>> Even worse this even works in case the attacker does not have read
>>>> access anywhere!
> 
> Then that's a bug that should be fixed.

If you really want to fix this bug then you have to fully enforce access
control when processing the write operation *before* enforcing the
constraints. (I guess this is not easily done with the current overlay
stack processing.)

But if you fixed it then the disclosure will only happen if the user is
authorized to modify the entry. So same fix for the very same problem. ;-)

Conclusion:
1. Applying ITS#8866 patch to RE24 will not make things worse.
2. The real fix will also fix the disclosure issue.

Ciao, Michael.

Re: ITS#8866 (was: ITS review 6/14/2019)

[Michael Ströder]

On 6/27/19 6:23 PM, Michael Ströder wrote:
> On 6/27/19 6:18 PM, Howard Chu wrote:
>> Michael Ströder wrote:
>>> On 6/14/19 5:15 PM, Quanah Gibson-Mount wrote:
>>>> Thanks to Ondrej, this list is a bit shorter now. :)
>>>
>>> But one more I'd love to see in 2.4.48:
>>>
>>> ITS#8866: RFE: slapo-constraint to return filter used in diagnostic message
>>>
>>> https://www.openldap.org/its/index.cgi?findid=8866
>>
>> I don't believe the information disclosure issues have been
>> sufficiently answered there. Overall it's a bad idea and goes against
>> our standing policy of minimal disclosure.
> Sorry, you already have the disclosure.
> 
> Citing from my old e-mail found here:
> https://www.openldap.org/lists/openldap-devel/201711/msg3.html
> 
>> But this problem exists anyway because an attacker can probe
>> values by adding entries with non-unique attributes and determine
>> whether an attribute value exists or not by distinguishing the result
>> code constraintViolation(19) vs. insufficientAccessRights(50).
>> Even worse this even works in case the attacker does not have read
>> access anywhere!

Furthermore the security of a system should not rely on confidentiality
of the configuration. E.g. with Æ-DIR the config is publicly known.

Also note I'm usually blamed for making directory contents too confidential.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8866 (was: ITS review 6/14/2019)

[Michael Ströder]

On 6/27/19 6:18 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> On 6/14/19 5:15 PM, Quanah Gibson-Mount wrote:
>>> Thanks to Ondrej, this list is a bit shorter now. :)
>>
>> But one more I'd love to see in 2.4.48:
>>
>> ITS#8866: RFE: slapo-constraint to return filter used in diagnostic message
>>
>> https://www.openldap.org/its/index.cgi?findid=8866
> 
> I don't believe the information disclosure issues have been
> sufficiently answered there. Overall it's a bad idea and goes against
> our standing policy of minimal disclosure.
Sorry, you already have the disclosure.

Citing from my old e-mail found here:
https://www.openldap.org/lists/openldap-devel/201711/msg3.html

> But this problem exists anyway because an attacker can probe
> values by adding entries with non-unique attributes and determine
> whether an attribute value exists or not by distinguishing the result
> code constraintViolation(19) vs. insufficientAccessRights(50).
> Even worse this even works in case the attacker does not have read
> access anywhere!

Ciao, Michael.

Re: libldap 2.4.48 compability (was: RE24 testing call)

[Michael Ströder]

On 6/25/19 4:10 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> For my understanding: Does 2.4.48 require applications linked to libldap
>> to be rebuilt or is it ABI compatible?
> 
> There should be no ABI changes.

Thanks for the confirmation.

>> But dhcpd (using LDAP as backend) refuses to correctly start when using
>> libldap 2.4.48. It says "Can't contact LDAP server" although the server
>> is reachable. Looking at its strace output and slapd syslog dhcpd does
>> not even try connecting to slapd. After reinstalling libldap 2.4.47
>> everything works again.

Any idea how I could find out what's going wrong? dhcpd seems to
dynamically link libldap 2.4.48 but fails to properly use it.

Ciao, Michael.

libldap 2.4.48 compability (was: RE24 testing call)

[Michael Ströder]

On 6/22/19 10:08 PM, Quanah Gibson-Mount wrote:
> --On Saturday, June 22, 2019 11:24 AM +0200 Michael Ströder
>  wrote:
> 
>> Furthermore I've generated RPM packages of this snapshot [1] and did
>> some short tests with Æ-DIR which uses a combination of many different
>> overlays. For now it seems to work just fine.
> 
> Thanks for the extended testing Michael!

For my understanding: Does 2.4.48 require applications linked to libldap
to be rebuilt or is it ABI compatible?

In most of my tests I can use 2.4.48 as binary drop-in replacement for
2.4.47. For this to work I've patched away the "releng" suffix. [1]

But dhcpd (using LDAP as backend) refuses to correctly start when using
libldap 2.4.48. It says "Can't contact LDAP server" although the server
is reachable. Looking at its strace output and slapd syslog dhcpd does
not even try connecting to slapd. After reinstalling libldap 2.4.47
everything works again.

It's not a big deal because in this packaged environment everything gets
rebuilt anyway if OpenLDAP upgrade is pushed. But I want to make sure I
fully understand everything and there's no issue left e.g. by
introducing openldap.h.

Ciao, Michael.

[1]
https://build.opensuse.org/package/view_file/home:stroeder:branches:home:stroeder:AE-DIR/openldap2/openldap-no-releng.diff?expand=1

Re: Persistent failures of test050

[Michael Ströder]

On 6/22/19 10:06 PM, Quanah Gibson-Mount wrote:
> I've noticed that when running test050 in a loop, it often fails, even
> after increasing the sleep timeout defaults.  Where it fails in the test
> is inconsistent and which servers differ is inconsistent as well.

I can confirm that it fails on my system too.

Ciao, Michael.

ITS#8866 (was: ITS review 6/14/2019)

[Michael Ströder]

On 6/14/19 5:15 PM, Quanah Gibson-Mount wrote:
> Thanks to Ondrej, this list is a bit shorter now. :)

But one more I'd love to see in 2.4.48:

ITS#8866: RFE: slapo-constraint to return filter used in diagnostic message

https://www.openldap.org/its/index.cgi?findid=8866

I have a back-port patch for this in my own 2.4.47 packages because it
is very useful.

Ciao, Michael.

Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)

[Michael Ströder]

On 6/21/19 4:57 PM, Michael Ströder wrote:
> On 6/21/19 3:19 PM, Quanah Gibson-Mount wrote:
>> This is expected to be the final testing call for 2.4.48, with an
>> anticipated release, depending on feedback, during the week of 2019/06/24.
> 
> make test worked just fine.
> 
> revision ee4538080
> openSUSE Tumbleweed x86_64
> gcc 9.1.1

Furthermore I've generated RPM packages of this snapshot [1] and did
some short tests with Æ-DIR which uses a combination of many different
overlays. For now it seems to work just fine.

And thanks for adding ITS#7770. That's really useful.

[1]
https://build.opensuse.org/package/show/home:stroeder:branches:home:stroeder:AE-DIR/openldap2

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)

[Michael Ströder]

On 6/21/19 3:19 PM, Quanah Gibson-Mount wrote:
> This is expected to be the final testing call for 2.4.48, with an
> anticipated release, depending on feedback, during the week of 2019/06/24.

make test worked just fine.

revision ee4538080
openSUSE Tumbleweed x86_64
gcc 9.1.1

Ciao, Michael.

2.4.48

[Michael Ströder]

HI!

Any blockers for releasing 2.4.48?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

need info for bug #955210: patch for openldap2 package

[Michael Ströder]

HI!

Please Cc: openldap-devel@openldap.org when replying.

I need more information about this locked bug report:

https://bugzilla.opensuse.org/show_bug.cgi?id=955210

The bug is referenced in openldap2.changes for this patch:

https://build.opensuse.org/package/view_file/network:ldap/openldap2/0009-Fix-ldap-host-lookup-ipv6.patch?expand=1

OpenLDAP upstream (Cc:-ed) asks whether SUSE folks could file an 
upstream issue here:


https://www.openldap.org/its/

Upstream requires an IPR notice when submitting patches as described here:

https://www.openldap.org/devel/contributing.html#notice

Thanks in advance.

Ciao, Michael.

Re: SuSE engagement?

[Michael Ströder]

Hi Quanah,

On 4/18/19 6:12 PM, Quanah Gibson-Mount wrote:
I'm looking at the patches SuSE applies to OpenLDAP, and it would be 
nice to have some engagement from SuSE on kicking some of these back,


I'm sometimes trying to push them to coordinate with upstream. Problem 
is that SLE customer bugs in https://bugzilla.opensuse.org are most 
times locked. (I miss Ralf working on that.)


You can always lookup who has maintainer role:
https://build.opensuse.org/package/users/network:ldap/openldap2

particularly something like 0017-Fix-segfault-in-nops.patch, which it 
appears is to address ITS#8759.  Do you know what we need to do on our 
end to encourage SuSE to contribute back to the community?


In particular the fight regarding 0017-Fix-segfault-in-nops.patch was 
pretty hard. Basically the private e-mail exchange after their OBS 
request between Howard Chu and SUSE devs faded out without any clear result.


To summarize Howard's statements:
In the best case the patch does nothing.

Especially the SUSE customer did not run a clean test environment for 
reliably reproducing the issue.


Therefore in my own packages I dropped 0017-Fix-segfault-in-nops.patch:

https://build.opensuse.org/package/show/home:stroeder:AE-DIR/openldap2

https://build.opensuse.org/package/show/home:stroeder:openldap/openldap-ms

(The above builds are stripped down even a bit more, e.g. no BDB-based 
backends.)


Ciao, Michael.

Re: libldap vs libldap_r ?

[Michael Ströder]

On 3/18/19 5:15 PM, Howard Chu wrote:
> I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which 
> means that now
> even our "non-threaded" libldap, when built with OpenSSL, must actually be 
> linked with the
> threads library. In this age of multicore processors, is it really important 
> to have a single-threaded
> LDAP library any more? Should we just make libldap_r become the standard 
> library?

Mainstream Linux distributions started to remove libldap anyway.
So +1 to abandon it.

Ciao, Michael.

Google's "Season of Docs"

[Michael Ströder]

HI!

Does anybody here think it's worth to give this a try?

https://developers.google.com/season-of-docs/docs/

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS review

[Michael Ströder]

On 1/31/19 3:50 AM, Quanah Gibson-Mount wrote:
> There have been some reports coming in to the ITS system that likely
> should go into OpenLDAP 2.4.48/LMDB 0.9.23.

I know feature requests are not welcome.
But it would help to have this in RE24:

ITS#7770 - mdb_stat in cn=monitor

Ciao, Michael.

Re: ITS review

[Michael Ströder]

On 1/31/19 3:50 AM, Quanah Gibson-Mount wrote:
There have been some reports coming in to the ITS system that likely 
should go into OpenLDAP 2.4.48/LMDB 0.9.23.


Probably this should also be added:

(ITS#8971) slapo-accesslog hits assert​

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenLDAP stand at FOSDEM

[Michael Ströder]

On 11/22/18 10:13 PM, Michael Ströder wrote:

On 10/15/18 9:46 PM, Howard Chu wrote:

Michael Ströder wrote:

On 10/9/18 8:05 AM, Michael Ströder wrote:

As discussed yesterday we could run a stand at FOSDEM which takes place
2 & 3 February 2019 at Brussels.


I've submitted the proposal for a stand.


Congrats! It seems your proposal was accepted.
I'll be there. Who else is willing to spend some time at the stand?


Up to now no response at all.. :-(

Is anybody else besides me attending FOSDEM and willing to run the 
OpenLDAP stand? Bear in mind that there's only a month left to organize 
things.


Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

CVE-2017-17740 aka ITS#8759

[Michael Ströder]

HI!

This ITS was answered with won't fix / send patches:
https://www.openldap.org/its/index.cgi?findid=8759

But in the mean-time somebody assigned a CVE number to it:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17740

The SUSE folks added a patch:

https://build.opensuse.org/package/view_file/network:ldap/openldap2/0017-Fix-segfault-in-nops.patch?expand=1

Could anybody review this and comment whether it makes sense at all?

If the patch is correct would it make sense to release it with 2.4.47?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenLDAP stand at FOSDEM

[Michael Ströder]

On 10/15/18 9:46 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> On 10/9/18 8:05 AM, Michael Ströder wrote:
>>> As discussed yesterday we could run a stand at FOSDEM which takes place
>>> 2 & 3 February 2019 at Brussels.
> 
> I've submitted the proposal for a stand.

Congrats! It seems your proposal was accepted.

I'll be there. Who else is willing to spend some time at the stand?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenLDAP stand at FOSDEM

[Michael Ströder]

On 10/15/18 9:46 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> On 10/9/18 8:05 AM, Michael Ströder wrote:
>>> As discussed yesterday we could run a stand at FOSDEM which takes place
>>> 2 & 3 February 2019 at Brussels.
>>>
>>> The CfP for various kinds of contributions:
>>> https://fosdem.org/2019/news/
>>>
>>> Application form for a stand:
>>> https://submission.fosdem.org/stands.php
>>
>> So how about having a stand?
> 
> I've submitted the proposal for a stand.

Great!

Usually there's also the possibility to reserve a small room for a BoF
session during FOSDEM. Should we also try that for discussing issues
with the community?

@Howard: Are you subscribed to [1]?
That's where some orga messages are published.

[1] https://lists.fosdem.org/listinfo/fosdem

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenLDAP stand at FOSDEM

[Michael Ströder]

On 10/9/18 8:05 AM, Michael Ströder wrote:
> As discussed yesterday we could run a stand at FOSDEM which takes place
> 2 & 3 February 2019 at Brussels.
> 
> The CfP for various kinds of contributions:
> https://fosdem.org/2019/news/
> 
> Application form for a stand:
> https://submission.fosdem.org/stands.php

So how about having a stand?

Note the dates:

2 November - deadline for stand proposals
11 November - accepted stands announced

Information about what is provided by the organizers, see sections
"Stands" herein:

https://fosdem.org/2019/news/2018-08-10-call-for-participation/

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenLDAP stand at FOSDEM

[Michael Ströder]

On 10/9/18 9:56 AM, Alexander Bokovoy wrote:
> On ti, 09 loka 2018, Michael Ströder wrote:
>> I'm not sure whether somebody requested a IAM devroom again.
>
> Yes, I did request an IAM devroom this time. FOSDEM organizers are a bit
> late with responses yet

Looking at the https://www.fosdem.org/2019/schedule/ it seems there
won't be a IAM devroom in 2019. :-(

Ciao, Michael.

OpenLDAP stand at FOSDEM

[Michael Ströder]

HI!

As discussed yesterday we could run a stand at FOSDEM which takes place
2 & 3 February 2019 at Brussels.

The CfP for various kinds of contributions:
https://fosdem.org/2019/news/

Application form for a stand:
https://submission.fosdem.org/stands.php

I'd be willing to spend some time at an OpenLDAP booth.

@Howard: Would you like to apply for it?

I'm not sure whether somebody requested a IAM devroom again.
Will try to monitor that.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

TLS 1.3 and 0-RTT

[Michael Ströder]

HI!

Are there any plans to support TLS 1.3?

The 0-RTT feature could be a significant performance gain in case LDAP 
applications open a new TLS connection each time they check a password 
with a bind request.


Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Increase default olcLocalSSF to 128

[Michael Ströder]

On 07/26/2018 09:04 AM, Dieter Klünter wrote:

Am Thu, 26 Jul 2018 08:19:34 +0200
schrieb Michael Ströder :

But why not choosing an even higher value like 256?
I really wonder why it was set to 71.


As Kurt mentioned on 1st. LDAPCon in Cologne, it is higher value than 56
and less than 128.


But why? What's the technical reason for it?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Increase default olcLocalSSF to 128

[Michael Ströder]

On 07/26/2018 04:47 AM, Ryan Tandy wrote:
I propose increasing the default olcLocalSSF to 128. Mentioned initially 
on IRC, now bringing it to the list for completeness and archival.


In typical setups people want to require TLS *or* ldapi, and ssf=128 
seems like a pretty common olcSecurity setting for current systems.


+1

But why not choosing an even higher value like 256?
I really wonder why it was set to 71.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: 2.4.27? (was: RE24 testing call ..)

[Michael Ströder]

On 04/13/2018 08:27 PM, Quanah Gibson-Mount wrote:
> I'm currently out of the office (last week, this week, next week), so
> there is no further release work going on at this time.  Once I'm
> back in the office, I'll be happy to look into the 2.4.47 release
> with the additional features we'd previously discussed.
Any chance that there will be a 2.4.47 release with my back-sock patches?

People keep asking me about the password sync to MS AD and it is much
easier for them to just build a release than to add back-port patches
themselves.

Ciao, Michael.

> - Original Message -
>> From: "Michael Ströder" 
>> To: "Quanah Gibson-Mount" , "hyc" 
>> Cc: openldap-devel@openldap.org
>> Sent: Friday, April 6, 2018 11:31:47 AM
>> Subject: 2.4.27? (was: RE24 testing call ..)
> 
>> Quanah Gibson-Mount wrote:
>>> --On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder
>>>  wrote:
>>>
>>>> Howard Chu wrote:
>>>>> We can schedule it for .47, and .47 can be pushed out shortly after .46.
>>>>> We can also include other minor non-core enhancements in.47 (like
>>>>> back-sock extensions) as well.
>>>>
>>>> Hmm, the back-sock changes are well tested and do not have any
>>>> incompatible impact. When .47 would be released?
>>>
>>> Howard and I discussed probably 2-3 weeks after 2.4.46 is released.
>>
>> Any chance this will happen in this time-frame?
>>
>> Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Config questions for back-ldap, back-meta, and back-asyncmeta

[Michael Ströder]

On 06/14/2018 11:58 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> On 06/14/2018 10:44 PM, Howard Chu wrote:
>>> Quanah Gibson-Mount wrote:
>>>> idle-timeout -> The man page says takes an integer, but is defined as
>>>> a string.  However, I think the man page for this parameter is
>>>> incorrect, and in fact it takes a possible string as defined in the
>>>> back-meta/async manual pages for this same parameter. (I.e, it can
>>>> have a format of something like 1d15h5s)
>>>
>>> I don't see this. The man page says "". It looks correct to me.
>>
>> Wouldn't it be better to consequently convert time strings such as
>> 1d15h5s to integer seconds during migration of static config to dynamic
>> config? IMO for LDAP-on-the-wire those values should always be integer
>> representing seconds (or milli-seconds if needed).
>>
>> I mean back-config content is meant to be machine-processable and
>> cleaner syntax would reduce unneeded complexity.
> 
> The complexity is already there, and obviously somebody thought it was
> desirable for these things to be human-readable. We're doing them no
> favors by converting to straight integers.

It's not only about the complexity in OpenLDAP software itself. All
3rd-party components which want to make use of back-config for automated
configuration have to deal with it. And that's not going to happen.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Config questions for back-ldap, back-meta, and back-asyncmeta

[Michael Ströder]

On 06/14/2018 10:44 PM, Howard Chu wrote:
> Quanah Gibson-Mount wrote:
>> idle-timeout -> The man page says takes an integer, but is defined as
>> a string.  However, I think the man page for this parameter is
>> incorrect, and in fact it takes a possible string as defined in the
>> back-meta/async manual pages for this same parameter. (I.e, it can
>> have a format of something like 1d15h5s)
> 
> I don't see this. The man page says "". It looks correct to me.

Wouldn't it be better to consequently convert time strings such as
1d15h5s to integer seconds during migration of static config to dynamic
config? IMO for LDAP-on-the-wire those values should always be integer
representing seconds (or milli-seconds if needed).

I mean back-config content is meant to be machine-processable and
cleaner syntax would reduce unneeded complexity.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

cn=config schema, matching rules and UX with web2ldap

[Michael Ströder]

HI!

I'd like to highlight a bit why I'm nitpicking on schema definitions for 
back-config and how careful schema crafting can help to have a better UX 
with less effort (even though I'm personally using back-config read-only 
for monitoring).


The goals of web2dap are:

1. guide the user to do it right rather than enforce stuff unless 
"stuff" is really well-known and thus can be handled strictly


2. no overzealous actions, don't surprise the user, be trustworthy

3. do as much as possible just by looking at the subschema

So why is the syntax or a known attribute constraint important for that?

Internally web2ldap uses plugin classes which are registered to
- a syntax or
- list of attribute types or
- combinations of attribute types and structural object classes.

Lots of plugin classes cover handling of well-defined application 
schema, some proprietary stuff, and weird quirks for broken schema. The 
classes are organized in plugin modules described here:

https://www.web2ldap.de/features.html#plugin

This all turned out to be quite powerful. Details upon request.

Now why this long story?

Of course there's also a plugin module for OpenLDAP-specific schema, 
especially for slapo-accesslog but also some stuff for cn=config 
(remember my presentation at ODD in Tübingen long time ago?).


https://fossies.org/linux/web2ldap/web2ldap/app/plugins/openldap.py

So here's a simple example for the case-exact vs. case-insensitive 
discussion:


For attribute 'olcMemberOfDangling' I could add such a class:

class OlcMemberOfDangling(SelectList):
  oid = 'OlcMemberOfDangling-oid'
  desc = 'Behavior in case of dangling references during modification'
  attr_value_dict = {
u'':u'-/-',
u'ignore':u'ignore',
u'drop':u'drop',
u'error':u'error',
  }

syntax_registry.registerAttrType(
  OlcMemberOfDangling.oid,[
'1.3.6.1.4.1.4203.1.12.2.3.3.18.1', # olcMemberOfDangling
  ]
)

As you can imagine the dict keys in attr_value_dict are the real values, 
the values are the UI description.


Now if the existing entry contains a mixed-case value exactly this value 
is added to the select list to preserve this exact value in any case.


Example:

dn: olcOverlay={7}memberof,olcDatabase={2}mdb,cn=config
olcMemberOfDangling: IGNore

The select list in the UI would contain:
ignore
drop
error
IGNore

Hmm, that likely looks confusing to the user in the UI.

So I could define a lower-case sanitizing like this:

class OlcMemberOfDangling(SelectList):
  [..class attrs like above..]
  simpleSanitizers = (
str.lower,
  )

But in this case the existing value would be altered and sent along with 
the modify request thus also confusing the user because the altering was 
not result of his/her action.


So it boils down that being more strict with values can lead to a better 
user experience. In this case I'd recommend that slapd would always 
*sanitize* the value to lower-case.


I'd be glad if OpenLDAP developers could consider those aspects in the 
future. Bear in mind that the above is just one very simple example.


web2ldap has also base classes for attribute type names or object class 
names where it displays direct links into the schema browsers. Hence I 
proposed to declare some cn=config attributes as OID syntax.


Interested readers can directly play with web2ldap and Æ-DIR's cn=config:

https://demo.ae-dir.com/web2ldap/dit?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2Fldapi/olcDatabase%3D%7B2%7Dmdb%2Ccn%3Dconfigbindname=uid%3Daead%2Ccn%3Dae%2Cou%3Dae-dir,X-BINDPW=CorrectHorseBatteryStaple

Sorry, read-only, but you can display the input forms and see what's 
displayed along the attributes.


There is more you could do in later releases beyond 2.5.
For inspiration here's the plugin module for OpenDJ's cn=config:

https://fossies.org/linux/web2ldap/web2ldap/app/plugins/opends.py

It can make heavy use of web2ldap's DynamicDNSelectList because many 
config values are just references to other entries.


Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8286 pending questions

[Michael Ströder]

Howard Chu wrote:
> Michael Ströder wrote:
>> Quanah Gibson-Mount wrote:
>>>  servers/slapd/bconfig.c ---
>>> olcInclude -- case ignore match?
>>
>> Is already defined with caseExactMatch via "SUP labeledURI".
>> IMO deriving from labeledURI does not make sense though.
> 
> olcInclude takes URIs. Typically file:// URIs. It could also take
> ldap:// URIs.

Ok. Anyway nothing to change because file and ldap URIs must be treated
case-sensitive.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8286 pending questions

[Michael Ströder]

Some more comments on a sub-set of the attributes.

Quanah Gibson-Mount wrote:
> olcReferral -- case ignore match?

It's already declared SUP labeledURI and therefore has caseExactMatch.
This makes sense because it could specify an LDAPI URL with
case-sensitive socket path name.

> olcRootPw -- case exact match?

Any EQUALITY matching rule needed at all?
If yes, use EQUALITY octetStringMatch as with userPassword.

> olcTCPBuffer -- case ignore match?

Also might contain listener URL. So maybe same like olcReferral even
though an LDAPI URI does not make sense with TCP buffers?

> olcTLSCipherSuite -- case ignore match?

I don't have a strong opinion on that because I don't have an oversight
how the supported crypto libs treat this strings.

> olcTLSSECName -- case ignore match?

??? Cannot find this in 2.4 schema. Is that new in 2.5?

> olcTLSProtocolMin -- case ignore match?
> 
>  BACKENDS ---
> --- back-asyncmeta
> olcDbURI -- case ignore match?

Same like olcReferral.

> olcDbURI -- case ignore match?

Same like olcReferral for back-ldap and back-meta.

> --- back-sql
> olcDbHost -- case ignore match?

This could also contain a Unix domain socket?
If yes, caseExactMatch.

> olcDbName -- case ignore match?

Hmm, I'm not sure. Also not sure about all the attrs containing SQL
statements.

> --- dds.c
> olcDDSmaxTtl -- case ignore match?
> olcDDSminTtl -- case ignore match?
> olcDDSdefaultTtl -- case ignore match?
> olcDDSinterval -- case ignore match?
> olcDDStolerance -- case ignore match?

Why are the TTL attributes strings at all? I see no reason why there are
not defined as Integer syntax.

> --- memberof.c
> olcMemberOfDangling -- case ignore match?

This serves as a good example for an enum type. I'd argue that it should
be limited to this particular set of lower-cased values.

> olcMemberOfGroupOC -- case ignore match?
> olcMemberOfMemberAD -- case ignore match?
> olcMemberOfMemberOfAD -- case ignore match?

AFAICS these always reference a single object class or attribute type.
So why not declare them with syntax OID?
Same suggestion for similar attributes of other overlays.

> olcMemberOfDanglingError -- case ignore match?

Is this just the LDAP error code?
If yes, define it as Integer.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8286 pending questions

[Michael Ströder]

Quanah Gibson-Mount wrote:
> I've done a first pass through the source tree adding missing matching
> rules to the olc* attributes to address ITS#8286
> ().  However,
> many of the attributes are string types, and can either be case
> exact/ignore match.  The following is a list of those attributes, and my
> best guess at which they should be.

It really depends on the default use-case and whether an attribute could
be used in a RDN or not.

Since POSIX file systems are case-sensitive I'd say that all attributes
containing file-system path names must be defined with caseExactMatch.

  Once I have a definitive answer on
> these, I'll commit them:
> 
>  servers/slapd/bconfig.c ---
> olcInclude -- case ignore match?

Is already defined with caseExactMatch via "SUP labeledURI".
IMO deriving from labeledURI does not make sense though.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

2.4.27? (was: RE24 testing call ..)

[Michael Ströder]

Quanah Gibson-Mount wrote:
> --On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder
> <mich...@stroeder.com> wrote:
> 
>> Howard Chu wrote:
>>> We can schedule it for .47, and .47 can be pushed out shortly after .46.
>>> We can also include other minor non-core enhancements in.47 (like
>>> back-sock extensions) as well.
>>
>> Hmm, the back-sock changes are well tested and do not have any
>> incompatible impact. When .47 would be released?
> 
> Howard and I discussed probably 2-3 weeks after 2.4.46 is released.

Any chance this will happen in this time-frame?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature