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
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
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
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
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
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
C
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
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
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
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.
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.
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 evaluate
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.
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.
>>&g
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.
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 ciphersuit
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
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_t
Filed ITS:
https://bugs.openldap.org/show_bug.cgi?id=9546
Ciao, Michael.
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
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: 'Passw
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
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 beha
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
>> smbk5pw
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/op
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-
On 11/20/20 1:52 PM, Howard Chu wrote:
> Paul B. Henson wrote:
>> On 11/19/2020 1:37 PM, Howard Chu wrote:
>>
>>> This would require that you actually read and process the proxy header
>>> immediately after the accept call. It strikes me that this is the wrong
>>> thing to do, if you also want to s
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 thoug
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/
>>
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 in
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.
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
>> change
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/ba
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.
Th
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 overl
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 "nee
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$roun
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
>>>
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
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
>> fi
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 t
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.
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
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 w
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:
>>&g
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 pr
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.
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.
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=914
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
Happy New Year!
It's me again... ;-)
I've changed the subject to make it more clear what the real issue is.
Is there actually a test for cancel operation in the test suite?
Ciao, Michael.
On 12/23/19 9:08 PM, Michael Ströder wrote:
> On 12/23/19 8:57 PM, Michael Ströder wrote:
&g
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
>
&
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.
Cou
On 12/18/19 6:09 PM, Howard Chu wrote:
> Howard Chu wrote:
>> Quanah Gibson-Mount wrote:
>>> It would be great along with all of this to finally fix memberOf
>>> so it's actually functional (and replication safe) (I.e., can
>>> maintain membership regardless of user/group creation order).>>
>> That
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 settin
HI!
It seems that git://git.openldap.org is not reachable since yesterday.
Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
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 w
On 7/21/19 3:37 PM, Howard Chu wrote:
A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP client.
Yes, of course.
But both behaved differently regarding usage of ldap.conf before 6f623df
(ITS#8427).
Quanah's question is:
Is it generally required that all slapd-internal LDA
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.
>
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 initi
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
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 conf
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 trigg
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 f
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
> &
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 seem
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
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
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 " */ /* a
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
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:
>>&g
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'
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-constra
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
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
>
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
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.
Many many moons ago there was ITS#7087 which has been fixed.
Test is running here...
Ciao, Michael.
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 f
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.
&g
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.
HI!
Any blockers for releasing 2.4.48?
Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
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/0
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
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
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
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.
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 Cryptogra
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 propo
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/
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 prop
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 vario
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
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
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 O
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
On 07/26/2018 01:38 PM, Hallvard Breien Furuseth wrote:
I wrote:
(...) any particular value will be wrong for someone.
Depends on how safe your filesystem setup is and whether it's easier
to break in to get at the ldapi socket than it is to just attack slapd.
You could forge ldapi: credentials
On 07/26/2018 01:34 PM, Hallvard Breien Furuseth wrote:
On 26. juli 2018 09:04, Dieter Klünter wrote:
Am Thu, 26 Jul 2018 08:19:34 +0200
schrieb Michael Ströder :
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
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
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 sett
chael.
> - 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 ..)
>
>> Q
1 - 100 of 513 matches
Mail list logo
