https://bugs.openldap.org/show_bug.cgi?id=7982
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8943
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |SUSPENDED
--- Comment #6 from Howard Chu <hyc(a)openldap.org> ---
One major problem here is that overlays assume they all execute in the same
thread for the duration of an operation. Putting the response in the worker
thread would break overlay response callbacks.
It would be quite a lot of refactoring to make overlays thread-independent, and
that's not going to happen soon.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10255
Issue ID: 10255
Summary: OpenLDAP should leak the SSL ctx and not try to free
it in an atexit() handler
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
As mentioned in the subject, OpenLDAP incorrectly handles OpenSSL in its
destructor.
Сomprehensive information can be found here (along with a possible solution):
https://github.com/openssl/openssl/issues/25294
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9796
Issue ID: 9796
Summary: Deprecate GnuTLS support
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due
to the license objections at the time that the Debian project had for the
OpenSSL license.
Since that time, Debian has reclassified OpenSSL as a core library and the
OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and
later under the Apache License v2.
Thus there is no longer a reason to maintain support for GnuTLS and given the
long standing concerns over the security and quality of the GnuTLS bridge in
addition to the extra cost of maintaining that code, it should be marked as
deprecated and removed in a future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10252
Issue ID: 10252
Summary: Unable to fetch groups and users at duo admin panel
for enabling MFA for Ldap users
Product: OpenLDAP
Version: 2.5.18
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ajay41.kumar(a)airtel.com
Target Milestone: ---
Hi Team,
I got stuck at configuring openldap server with member of overlay for
groups with below requirement.We are trying to enable Multifactor
authentication using duo auth proxy & duo admin panel configuration for ldap
users.
Ldap server is getting synced successfully with Duo admin portal but
groups and users details not fetching at duo admin portal. Duo support team
mentioned to change ldap configuration as mention article. Can someone help me,
How i can make these changes.
https://duo.my.site.com/s/article/4529?language=en_US
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10251
Issue ID: 10251
Summary: wrong type passed to getsockname
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
New compilers don't allow passing sockaddr_storage * to getsockname() so
clients/tools/common.c no longer compiles. Fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10250
Issue ID: 10250
Summary: syncrepl_diff_entry assumes attributes come in the
same order
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When trying to diff an entry, syncrepl_diff_entry explicitly assumes attribute
come in the same order. That's not always the case and could cause it to report
a spurious rewrite of the attribute.
Normally this is ok, unless the rewrite itself (not) occurring has other
side-effects, when it could cause issues. (e.g. a DB with memberof
inconsistencies being mysteriously repaired in some scenarios, which is how it
was found).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10244
Issue ID: 10244
Summary: Fix pointer type
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: zanaviska(a)tutanota.com
Target Milestone: ---
Created attachment 1026
--> https://bugs.openldap.org/attachment.cgi?id=1026&action=edit
passed temprorary variable
Hi I am trying to add MINGW support for another project, But each time I get an
error
```
mdb.c:3921:76: error: passing argument 3 of 'GetOverlappedResult' from
incompatible pointer type [-Wincompatible-pointer-types]
note: expected 'LPDWORD' {aka 'long unsigned int *'} but argument is of type
'ssize_t *' {aka 'long long int *'}
```
So I came up with a fix for your software, with I attach in attachment
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10243
Issue ID: 10243
Summary: Looking to get account on OpenLDAP Gitlab
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ak.openldap(a)anroet.com
Target Milestone: ---
I'm trying to open an account on Gitlab.
The purpose for having an account on gitlab is so that I can start the process
of building a docker image for use in our Production K8s environment.
Currently, I can only find docker images for version 2.4 and the admission
controllers in out production k8s clusters isn't having none of that.
I'm attempting to create an account using the following email address:
ak.openldap(a)anroet.com
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10246
Issue ID: 10246
Summary: Impossible to add integerOrderingMatch ordering rule
for integer syntax attribute
Product: OpenLDAP
Version: 2.5.18
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: thierryblaise(a)hotmail.com
Target Milestone: ---
Hi everyone,
As I don't know anymore where to search, I'm trying here:
I added a custom objectClass to my v2.5.18 openLDAP deployment schema, and in
that schema, there's an attribute of type integer that I need to be able to
search for with filter "<=" and ">=".
To that end, and to my knowledge and following documentation
(https://www.openldap.org/doc/admin25/schema.html#Attribute%20Type%20Specifi…),
I need to declare an ordering matching rule in attribute definition of the
schema.
However, when I do that with the following olcAttributeTypes definition :
olcAttributeTypes: ( 1.3.6.1.4.1.xxx.x.x.xxx
NAME 'last-modified'
DESC 'Object Last Modified Time'
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
and try to import the ldif containing this definition, the following error
appears:
modifying entry "cn={5}clients,cn=schema,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: olcAttributeTypes: AttributeType inappropriate
matching rule: "integerOrderingMatch"
I tried with all documented OrderingMatch rules in case, but same error modulo
name of OrderingMatch rule.
Basic schemas only have been imported (core, nis, cosine, inetOrgPerson)
Any idea what I do wrong?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10245
Issue ID: 10245
Summary: mdb_env_set_maxdbs signature appears incorrect
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: bchik(a)meta.com
Target Milestone: ---
The current signature for mdb_env_set_maxdbs:
int mdb_env_set_maxdbs(MDB_env *env, MDB_dbi dbs);
The documentation says the second parameter is intended to be the maximum
number of databases, however, the parameter is typed as a DB handle. This
appears to work because MDB_dbi is typedef'd to an unsigned int.
I believe the intended signature would be:
int mdb_env_set_maxdbs(MDB_env *env, unsigned int dbs);
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10241
Issue ID: 10241
Summary: Crash in mdb_page_search_root()
Product: LMDB
Version: 0.9.24
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: david.komarek(a)whalebone.io
Target Milestone: ---
Hello,
The LMDB is crashing in mdb_page_search_root() on following instruction
`0x7f85221479d2 movzwl 0xa(%rdx),%eax`. This instruction corresponds to
following line in source code -
https://github.com/LMDB/lmdb/blob/LMDB_0.9.24/libraries/liblmdb/mdb.c#L5485
(while access mp_flags in MDB_page structure)
Here is callstack as generated by core dump (without symbols as we're using
package from Ubuntu repositories)
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f85221479d2 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#1 0x00007f8522147d15 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#2 0x00007f8522148432 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#3 0x00007f8522148a70 in mdb_get () from
/usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
```
Translation
```
#0 mdb_page_search_root()
#1 mdb_page_search()
#2 mdb_cursor_set()
#3 mdb_get()
```
Registers in time of crash:
```
rax 0x2 2
rbx 0x7ffcd8d2a100 140723946168576
rcx 0x3 3
rdx 0x7f825baf7000 140197860700160
rsi 0x1000 4096
rdi 0x7f851c00f4d0 140209677202640
rbp 0x0 0x0
rsp 0x7ffcd8d29e40 0x7ffcd8d29e40
r8 0x7ffcd8d29e50 140723946167888
r9 0x7f851c00f5b8 140209677202872
r10 0x7f851c003090 140209677152400
r11 0x2ce33e6c02ce33e7 3234497591006606311
r12 0x0 0
r13 0x7ffcd8d2a510 140723946169616
r14 0x79 121
r15 0x7f851c003098 140209677152408
rip 0x7f85221479d2 0x7f85221479d2
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
k0 0x40 64
k1 0xfffff0f0 4294963440
k2 0xff01 65281
k3 0xffffffff 4294967295
k4 0xffffffff 4294967295
k5 0xffffffff 4294967295
k6 0xffffffff 4294967295
k7 0x0 0
```
Our setup is following:
We have single process (running in separate container) which reads and writes
to LMDB. It opens environment with following flags
MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_NOSYNC. The environment contain
several DBs. All DBIs are open with MDB_CREATE flag. Transactions are open
without flags.
On the other hand we have several processes running in the single container,
which are only allowed read (these processes crash). The environment is open
with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_RDONLY. All DBIs
are open without flags. Transactions are open with MDB_RDONLY flag.
Could you please investigate it? If you will need some other artifacts or
comments, please let me know.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10240
Issue ID: 10240
Summary: Information required about the end of support date for
OpenLDAP ver 2.6.3
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: bluesoulprince(a)gmail.com
Target Milestone: ---
Hi Team,
As we have integrated OpenLDAP 2.6.3 version in our application, we would like
to know the community support availability end of date for this version, to
plan our application maintenance accordingly.
Could you please help us with this information.
Thanks,
Vivek S
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10236
Issue ID: 10236
Summary: fragmentation makes mdb_page_alloc slow
Product: LMDB
Version: 0.9.31
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: aalekseyev(a)janestreet.com
Target Milestone: ---
Created attachment 1022
--> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit
patch is relative to LMDB_0.9.31
It's a known problem that mdb_page_alloc can be slow
when the free list is large and fragmented. [1] [2] [3]
I'm not sure it's known *how* slow it can be.
In our workload we saw a fragmented freelist leading
to a pathological O(n^2) behavior.
To handle a multi-page allocation we iterate loading chunks of the
free list one by one, and at every iteration we do O(n) work to check
if the allocation can succeed.
Even small-ish allocations (tens of pages) are repeatedly hitting
this edge case, with free list growing to ~1000000, and the outer loop
taking ~2000 iterations (10^9 worth of work in total, just to allocate a
few pages).
Even though I'm sure there are ways to avoid hitting this pathological
scenario so much (avoid values larger than 4k, or fix whatever causes
fragmentation), it seems unacceptable to have a performance cliff this bad.
I made a patch to make the allocation take ~O(n*log(n)), by loading
and merging multiple chunks at once instead of doing it one-by-one.
I'd appreciate it if someone could review the patch (attached), improve it,
and/or come up with an alternative fix.
The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but
it performs well enough to speed up our pathological workload by ~20x (which is
still ~3x away from the non-fragmented case).
Anyway, the main thing that warrants scrutiny is the change in `mdb.c`:
I understand very little about lmdb internals and I worry that loading
multiple pages at once instead of one-by-one might break something.
[1] issue #8664
[2]
https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa…
[3]
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10239
Issue ID: 10239
Summary: The slapd domain name is inconsistent, synchronization
cannot be modified by the rewrite dn parameter dc.
Product: OpenLDAP
Version: 2.4.44
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: 2458943823(a)qq.com
Target Milestone: ---
/etc/openldap/slapd:
syncrepl rid=002
provider=ldap://172.18.1.1
bindmethod=simple
binddn="cn=Manager,dc=wsc,dc=ls,dc=com"
credentials=lnewnews1tter
searchbase="dc=wsc,dc=ls,dc=com"
schemachecking=off
type=refreshAndPersist
retry="60 +"
rewrite dn "dc=wsc,dc=ls,dc=com" "dc=wsc,dc=slave1,dc=ls,dc=com"
The error is as follows:
66912211 /etc/openldap/slapd.conf: line 281: Error: parse_syncrepl_line: unable
to parse "rewrite"
.
66912211 failed to add syncinfo
slaptest: bad configuration directory!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10222
Issue ID: 10222
Summary: mdb_dump page has outdated information about
user-defined comparison functions
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: tools
Assignee: bugs(a)openldap.org
Reporter: zach.vonler(a)sambanovasystems.com
Target Milestone: ---
Created attachment 1019
--> https://bugs.openldap.org/attachment.cgi?id=1019&action=edit
Patch to mdb_dump man page
The `mdb_dump` man page contains an outdated section warning that databases
created with user-defined comparison functions cannot be dumped and reloaded
without changes to the `mdb_load` program. The `-a` option that was added to
the `mdb_load` program in this commit
https://github.com/openldap/openldap/commit/7796aaebcd1b937233adab5b1f3d3a1…
made it possible to reload such databases, so this patch updates the `mdb_dump`
man page to reflect that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10147
Issue ID: 10147
Summary: Bind dn is getting malformed inside ldap_sasl_bind
function
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: satishkumar1728(a)gmail.com
Target Milestone: ---
Hi team,
We are using open ldap version 2.6 in one of our application processes.
We are using ldap_sasl_bind function defined in open ldap api to send bind
request to ldap server.
We are passing the dn name to the above function and it is parsing the dn name
as expected.
We have added some print statements inside ldap_sasl_bind function and it is
printing the dn string that we passed to the function.
Also, ldap_sasl_bind function will accept const char pointer to dn as an
argument. So, it cannot modify the dn string inside the function.
But somehow the bind dn is getting malformed and we are getting failed bind
response from the ldap server (invalid DN).
We did some analysis using tcpdump and we found out that the dn string that we
passed to the ldap_sasl_bind function and the dn string from the tcpdump are
different.
We did some code walkthrough of ldap_sasl_bind function and it is observed that
it is doing some ber encoding of dn name inside the function.
We are suspecting that the encoding is not happening properly.
Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users,
dc=fds, dc=mr"
Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc=
dc=mr"
Is there any specific reason for the bind DN to get malformed like this inside
ldap_sasl_bind function.
Do you have any observations like this in any scenario. Kindly provide some
inputs to resolve this issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10175
Issue ID: 10175
Summary: Secure LDAP is not working on GCC 10.3.0
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: bluesoulprince(a)gmail.com
Target Milestone: ---
Hi Team,
We have recently migrated our C++ application which is using OpenLDAP 2.6 to
GCC version 10.3.0.
We are observing difference in LDAP behavior. The non-secure version of LDAP is
able to return the result in GCC 10.3.0, however when we switch to secure LDAP,
it is not able to return with result.
There was no compilation / build issue observed while building our application.
Our query is, does secure LDAP from OpenLDAP ver 2.6 have any compatibility
issues over GCC 10.3.0?
If there are any issues identified over this version, how to resolve those? in
which version fixes for them are available?
Thanks,
Vivek
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10228
Issue ID: 10228
Summary: config LDAP_BACK_CONN_PRIV_MAX to higher value
Product: OpenLDAP
Version: 2.5.16
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: shaosong.li(a)salesforce.com
Target Milestone: ---
Hi,
LDAP_BACK_CONN_PRIV_MAX parameter is set to 256 by below config,
https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv…
Can we set this value to a higher value, such as 7k/10k, which is commonly used
in PingDirectory. Any reason that we set this value to a low value like 256,
thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10138
Issue ID: 10138
Summary: Allow generating multiple nested read transactions
from a write transaction
Product: LMDB
Version: 0.9.30
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hello,
I have a feature request. Would it be possible to read a database from the
point of view of a non-yet-committed write transaction?
What I want to do is to write a lot of entries into a database, use a couple of
threads to read those entries (using MDB_NOTLS) to generate a lot of new
entries (that will be written to disk and then once the generation is done,
drop the read-transaction handles and write (with MDB_APPEND) those new entries
from disk into LMDB.
This would have been possible if I had committed the first entries, but
unfortunately, it is impossible. I need to do this in the same transaction.
Have a great day,
kero
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10225
Issue ID: 10225
Summary: tlso_session_pinning: will crash if
digest/keyhash.bv_val is not properly initialized over
the lifetime of the function
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: yaneurabeya(a)gmail.com
Target Milestone: ---
tlso_session_pinning(..) does not initialize the `digest` stack memory before
referring to it later on in the function. This can result in a library crash if
(for whatever reason) keyhash.bv_val fails to initialize properly on line 1191
[1].
This issue kind of goes hand in hand with bug 10224.
1.
https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5…
--
You are receiving this mail because:
You are on the CC list for the issue.