lcome your review and suggestions.
[0]. http://coccinelle.lip6.fr/
[1]. https://github.com/coccinelle/coccinelle
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
w and hope this can be merged
soon and extended further.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
formation), we should still be able to use whatever we
built until then, but can't continue
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Tue, Oct 24, 2017 at 01:43:21PM +0200, Ondřej Kuzník wrote:
> ITS#8486 suggests we use a more efficient structure to maintain the
> sessionlog in. If we're messing with sessionlog already, we might as
> well see if we can address another issue - it is always empty on slapd
> s
On Tue, Oct 24, 2017 at 04:52:57PM +0100, Howard Chu wrote:
> Ondřej Kuzník wrote:
>> ITS#8486 suggests we use a more efficient structure to maintain the
>> sessionlog in. If we're messing with sessionlog already, we might as
>> well see if we can address another iss
On Tue, Oct 24, 2017 at 06:45:42PM +0200, Ondřej Kuzník wrote:
> On Tue, Oct 24, 2017 at 04:52:57PM +0100, Howard Chu wrote:
>> Ondřej Kuzník wrote:
>>> ITS#8486 suggests we use a more efficient structure to maintain the
>>> sessionlog in. If we're messing with
to the client and decide which error code is
appropriate. This would help plug that side channel, but might be quite
expensive if there are many offending entries and as such would provide
a different one again (open to the same class of attackers that you
highlighted).
Not sure that's worth it
o operations performed
on each of its client's behalf.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
ion between the mutex types and drop
recursive mutex (un)locking functions
3. Update accesslog to use the above
4. Drop rmutex.c
Any objections?
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solut
On Fri, Nov 24, 2017 at 01:16:47PM +0100, Ondřej Kuzník wrote:
> Trying to get SASL bind support into the Load Balancer now and a bit
> stuck when it comes to figuring out what the resulting authorisation
> identity is (SASL or LDAP say it's backend specific) for use with the
> p
cally linked so it can be used from there?
Are there other options on the table?
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
re
running with SLAP_SINGLE_SHADOW(be) which means we might be a cascading
replica.
Is there a scenario that would break things? How about starting with an
empty DB, should we still put a contextCSN there?
Thanks,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation
reduce search time
> (has patch, IPR OK)
This one isn't ready yet, might not belong to 2.4 anyway, also pending
answer on https://www.openldap.org/lists/openldap-devel/201903/msg00011.html
> OpenLDAP related ITSes for RE25
> ---
> ITS#8875 - back-
'll see in the meantime why the CSN was generated on server2. Might
take a while to reproduce this again though.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
option would be to revert ITS#8427, although I'd
> prefer to see a fix rather than a revert.
I will have another look at ITS#8427 after I have a better grasp of what
things are involved in breaking test050. Also not sure we will be able
to get all of those fixed in the 2.4 series, but rema
the test.
It's probably the consumer CSN checks that need to be run again if we
don't receive the CSN with the PDU (which is what happens in present
phase), but that might have to be a '>=' on the contextCSN set rather
than a strict '>'? Something tells me that we n
On Mon, Jul 01, 2019 at 03:07:15PM +0200, Ondřej Kuzník wrote:
> On Tue, Jun 25, 2019 at 04:45:30PM -0700, Quanah Gibson-Mount wrote:
> > --On Saturday, June 22, 2019 2:06 PM -0700 Quanah Gibson-Mount
> > wrote:
> >
> >> [build@freebsd12 ~/git/openldap-2-4/tests
* manage
> olcSuffix: cn=authn
> olcRootDN: cn=admin,cn=authn
> olcRootPW: {SSHA}
> olcDbURI: ldaps://remote-authn.acme.foo:636
>
> The debug output shows the following:
>
> TLS: peer cert untrusted or revoked (0x42)
> TLS: can't connect: (unknown error code).
Hi N
a regression?
>
> And we need to know the answer to that and have a fix in rather quickly.
I'll see tomorrow about reproducing the regression with ldap.conf. If
I'm successful, extending the test case and a fix should not take long.
Thanks,
--
Ondřej Kuzník
Senior Software Engin
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,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solu
On Tue, Jul 23, 2019 at 05:03:48PM +0200, Michael Ströder wrote:
> 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 f
ithout your
help, it will take a long while before it's ready!
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Thu, Jul 25, 2019 at 12:34:13AM +0100, Howard Chu wrote:
> Ondřej Kuzník wrote:
>> Historically, there has been a decent coverage in the test suite and
>> that's what's being run before anyone pushes, but it's not been enough
>> to capture some of the issue
s seems like a messy loose end to leave dangling, but not sure what
> a better approach would be.
> Suggestions?
How about being able to merge identical attribute definitions whether
they come from config or directly from code?
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation
On Wed, Dec 18, 2019 at 02:02:40AM +, Howard Chu wrote:
> Ondřej Kuzník wrote:
>> How about being able to merge identical attribute definitions whether
>> they come from config or directly from code?
>
> We've got other overlays that do something similar, ignor
you want to have a look.
> Is there actually a test for cancel operation in the test suite?
There is now, in a way :)
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Fri, Jan 03, 2020 at 04:48:51PM +0100, Michael Ströder wrote:
> 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.
>>
>> Yu
looks more "active",
> but I wouldn't see that as a benefit/gain.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
ost of it is moved out of the runtime hot path, which is the main
> goal. Suggestions?
Moving a lot of work to the log postprocessor is good.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
> +1 for pw-sha2 and pw-argon2.
>
> FWIW:
> slapo-noopsrch and slapo-lastbind is what I use in almost every
> installation.
Might want to improve the core lastbind support to make that overlay
obsolete instead?
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation
o something more
complete. Please review and come back with suggestions or, if you feel
so inclined, patches.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Thanks again and wishing you nice holidays,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
ight not be the best fit, there's also way to request review from a
particular person.
BTW non-project members are invited to help with review and testing,
it's a great way to get familiar with the codebase and helps the project
move faster and at higher quality.
--
Ondřej Kuzník
Senio
t;
The graceAuthNsRemaining warning specifies the remaining number of times
a user will be allowed to authenticate with an expired password.
"""
If not, please reopen ITS#7596 with a test case.
Thanks,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
bute on the entry), see ITS#7084
and the ppolicy draft. It it makes a difference, it's possible that some
of this is interfering, or that it's intentional, will probably have to
decide on a case by case basis.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation
On Wed, Jul 14, 2021 at 03:40:35PM +0100, Howard Chu wrote:
> Howard Chu wrote:
>> Just some initial thoughts on what a new logging daemon should do for us:
>
> Scaling back to something easier for now:
>
> We'll use the existing Debug msgs as-is. The olcLogFile directive will
> specify the
> pa
losure, or unauthorized
> remote code execution. We do not consider assert() failures or crashes
> resulting only in Denial of Service as security flaws.
Sounds good and to the point.
Thanks,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.
recreate an entry in the future.
Since we do not follow RFC 4533 in many aspects already, e.g. we send
cookies in the middle of a refresh, our cookies are often unusable on
their own, we can just own up to this and define an extension to the
protocol if needed.
--
Ondřej Kuzník
Senior Software E
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> p
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> p
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> p
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> p
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> p
hat a try?
Thanks,
[0]. https://git.openldap.org/openldap/openldap/-/merge_requests/582
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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.ope
ed%20mappings
[1]. Admin guide for direct mappings already says "it allows mapping to
DNs which refer to entries not held by this server" in the first
paragraph
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged,
o a
reasonably competent C developer (I'm sure we can assume that they
understand how strings are laid out etc.)
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Wed, Apr 03, 2024 at 02:08:15PM +0100, Graham Leggett wrote:
> On 03 Apr 2024, at 13:03, Ondřej Kuzník wrote:
>
>>> This has been historically vague - first off, what happens if an
>>> attempt is made to call ldap_get_values() on binary data, do you get
>>&g
Should that be added for 2.7?
There is a LDAP_OPT_REFHOPLIMIT in ldap.h and a commented out entry in
the manpage. But yeah, it seems like it fell of the wagon at some point
and since then noone actually needed it.
Assuming this works "as advertised", yes, I think that's a good idea
49 matches
Mail list logo
