Fails to validate certificate of recent OpenLDAP; vague error message

[akorn]

I recently upgraded my OpenLDAP servers from 2.4.50+dfsg-1 to 2.4.56+dfsg-1 (Debian sid; since these were dist-upgrades, all library dependencies were also upgraded). Since then, sssd is (I think) unable to verify the server certificate and fails thusly:

2021-01-05 16:51:45.726654500 [be[ldap]] [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [(unknown error code)]
2021-01-05 16:51:45.726769500 [be[ldap]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
2021-01-05 16:51:45.761949500 [be[ldap]] [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [(unknown error code)]
2021-01-05 16:51:45.762025500 [be[ldap]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
2021-01-05 16:51:45.875568500 [be[ldap]] [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [(unknown error code)]
2021-01-05 16:51:45.875697500 [be[ldap]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
2021-01-05 16:51:45.875731500 [be[ldap]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP'
2021-01-05 16:51:45.875817500 [be[ldap]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error])
2021-01-05 16:51:45.875969500 [be[ldap]] [sdap_sudo_refresh_connect_done] (0x0020): SUDO LDAP connection failed [11]: Resource temporarily unavailable
2021-01-05 16:51:45.876006500 [be[ldap]] [be_ptask_done] (0x0040): Task [SUDO Full Refresh]: failed with [11]: Resource temporarily unavailable

The slapd log shows:

2021-01-05 16:51:45.726828500 local4.debug: Jan  5 16:51:45 slapd[14663]: conn=80164 fd=84 ACCEPT from IP=<sssd.client.ip>:52666 (IP=0.0.0.0:636)
2021-01-05 16:51:45.759922500 local4.debug: Jan  5 16:51:45 slapd[14663]: conn=80164 fd=84 TLS established tls_ssf=256 ssf=256
2021-01-05 16:51:45.761271500 local4.debug: Jan  5 16:51:45 slapd[14663]: conn=80164 fd=84 closed (connection lost)

Adding ldap_tls_reqcert = allow to the sssd configfile masks the error.

openssl s_client from the same box as where sssd runs can connect to ldapserver:636 and verify the certificate with no problem:

issuer=C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3829 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

My sssd.conf looks like this:

[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = ldap
debug_level = 1

[nss]
debug_level = 1
enum_cache_timeout = 600

[pam]
debug_level = 1
offline_credentials_expiration = 30

[domain/ldap]
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldaps://server1, ldaps://server2, ldaps://server3

ldap_search_base = dc=domain,dc=tld
enumerate = true
cache_credentials = true

account_cache_expiration = 30
dns_discovery_domain = domain.tld
ldap_user_search_base = ou=People,dc=domain,dc=tld

ldap_tls_cipher_suite = SECURE256:PFS:!NULL:!VERS-TLS1.0:!VERS-TLS1.1:!VERS-DTLS1.0:!SHA1
ldap_tls_cacertdir = /etc/ssl/certs

selinux_provider = none
autofs_provider = none
lookup_family_order = ipv4_only

Commenting out ldap_tls_cipher_suite results in no change.

Raising debug level to 9 still results in no meaningful error message:

2021-01-05 17:02:54.835520500 [be[ldap]] [be_ptask_execute] (0x0400): Task [Enumeration [id] of ldap]: executing task, timeout 300 seconds
2021-01-05 17:02:54.835682500 [be[ldap]] [sdap_id_op_connect_step] (0x4000): beginning to connect
2021-01-05 17:02:54.835719500 [be[ldap]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
2021-01-05 17:02:54.835755500 [be[ldap]] [get_server_status] (0x1000): Status of server 'ldap-server1.domain.tld' is 'name not resolved'
2021-01-05 17:02:54.835805500 [be[ldap]] [get_port_status] (0x1000): Port status of port 636 for server 'ldap-server1.domain.tld' is 'neutral'
2021-01-05 17:02:54.835840500 [be[ldap]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds
2021-01-05 17:02:54.835875500 [be[ldap]] [get_server_status] (0x1000): Status of server 'ldap-server1.domain.tld' is 'name not resolved'
2021-01-05 17:02:54.835909500 [be[ldap]] [resolv_is_address] (0x4000): [ldap-server1.domain.tld] does not look like an IP address
2021-01-05 17:02:54.835947500 [be[ldap]] [resolv_gethostbyname_step] (0x2000): Querying files
2021-01-05 17:02:54.835982500 [be[ldap]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ldap-server1.domain.tld' in files
2021-01-05 17:02:54.836016500 [be[ldap]] [set_server_common_status] (0x0100): Marking server 'ldap-server1.domain.tld' as 'resolving name'
2021-01-05 17:02:54.836050500 [be[ldap]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
2021-01-05 17:02:54.836087500 [be[ldap]] [resolv_gethostbyname_step] (0x2000): Querying DNS
2021-01-05 17:02:54.836121500 [be[ldap]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ldap-server1.domain.tld' in DNS
2021-01-05 17:02:54.836170500 [be[ldap]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 3 seconds
2021-01-05 17:02:54.836205500 [be[ldap]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
2021-01-05 17:02:54.836250500 [be[ldap]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher
2021-01-05 17:02:54.836285500 [be[ldap]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
2021-01-05 17:02:54.836319500 [be[ldap]] [request_watch_destructor] (0x0400): Deleting request watch
2021-01-05 17:02:54.836354500 [be[ldap]] [set_server_common_status] (0x0100): Marking server 'ldap-server1.domain.tld' as 'name resolved'
2021-01-05 17:02:54.836453500 [be[ldap]] [be_resolve_server_process] (0x1000): Saving the first resolved server
2021-01-05 17:02:54.836489500 [be[ldap]] [be_resolve_server_process] (0x0200): Found address for server ldap-server1.domain.tld: [<redacted>] TTL 85731
2021-01-05 17:02:54.836525500 [be[ldap]] [sdap_uri_callback] (0x0400): Constructed uri 'ldaps://ldap-server1.domain.tld'
2021-01-05 17:02:54.836559500 [be[ldap]] [sssd_async_socket_init_send] (0x4000): Using file descriptor [22] for the connection.
2021-01-05 17:02:54.836605500 [be[ldap]] [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting
2021-01-05 17:02:54.918400500 [be[ldap]] [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [(unknown error code)]
2021-01-05 17:02:54.918466500 [be[ldap]] [sss_ldap_init_state_destructor] (0x0400): calling ldap_unbind_ext for ldap:[0x559e4d0994a0] sd:[22]
2021-01-05 17:02:54.918516500 [be[ldap]] [sss_ldap_init_state_destructor] (0x0400): closing socket [22]
2021-01-05 17:02:54.918554500 [be[ldap]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
2021-01-05 17:02:54.918589500 [be[ldap]] [sdap_handle_release] (0x2000): Trace: sh[0x559e4d08f3a0], connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0], release_memory[0]
2021-01-05 17:02:54.918635500 [be[ldap]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: ../src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1605
2021-01-05 17:02:54.918671500 [be[ldap]] [fo_set_port_status] (0x0100): Marking port 636 of server 'ldap-server1.domain.tld' as 'not working'
2021-01-05 17:02:54.918707500 [be[ldap]] [fo_set_port_status] (0x0400): Marking port 636 of duplicate server 'ldap-server1.domain.tld' as 'not working'
2021-01-05 17:02:54.918742500 [be[ldap]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
2021-01-05 17:02:54.918808500 [be[ldap]] [get_server_status] (0x1000): Status of server 'ldap-server2.domain.tld' is 'name not resolved'
2021-01-05 17:02:54.918843500 [be[ldap]] [get_port_status] (0x1000): Port status of port 636 for server 'ldap-server2.domain.tld' is 'neutral'
2021-01-05 17:02:54.918880500 [be[ldap]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds
2021-01-05 17:02:54.918952500 [be[ldap]] [get_server_status] (0x1000): Status of server 'ldap-server2.domain.tld' is 'name not resolved'
2021-01-05 17:02:54.918995500 [be[ldap]] [resolv_is_address] (0x4000): [ldap-server2.domain.tld] does not look like an IP address
2021-01-05 17:02:54.919060500 [be[ldap]] [resolv_gethostbyname_step] (0x2000): Querying files
2021-01-05 17:02:54.919094500 [be[ldap]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ldap-server2.domain.tld' in files
2021-01-05 17:02:54.919128500 [be[ldap]] [set_server_common_status] (0x0100): Marking server 'ldap-server2.domain.tld' as 'resolving name'
2021-01-05 17:02:54.919164500 [be[ldap]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
2021-01-05 17:02:54.919198500 [be[ldap]] [resolv_gethostbyname_step] (0x2000): Querying DNS
2021-01-05 17:02:54.919233500 [be[ldap]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ldap-server2.domain.tld' in DNS
2021-01-05 17:02:54.919268500 [be[ldap]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 3 seconds
2021-01-05 17:02:54.919303500 [be[ldap]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
2021-01-05 17:02:54.919338500 [be[ldap]] [be_ptask_execute] (0x0400): Task [SUDO Full Refresh]: executing task, timeout 21600 seconds
2021-01-05 17:02:54.919372500 [be[ldap]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules
2021-01-05 17:02:54.919417500 [be[ldap]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete
2021-01-05 17:02:54.919450500 [be[ldap]] [be_ptask_execute] (0x0400): Task [Enumeration [resolver] of ldap]: executing task, timeout 300 seconds
2021-01-05 17:02:54.919484500 [be[ldap]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete
2021-01-05 17:02:54.919518500 [be[ldap]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher
2021-01-05 17:02:54.919552500 [be[ldap]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
2021-01-05 17:02:54.919586500 [be[ldap]] [request_watch_destructor] (0x0400): Deleting request watch
2021-01-05 17:02:54.919620500 [be[ldap]] [set_server_common_status] (0x0100): Marking server 'ldap-server2.domain.tld' as 'name resolved'
2021-01-05 17:02:54.919655500 [be[ldap]] [be_resolve_server_process] (0x0200): Found address for server ldap-server2.domain.tld: [<redacted>] TTL 26652
2021-01-05 17:02:54.919689500 [be[ldap]] [sdap_uri_callback] (0x0400): Constructed uri 'ldaps://ldap-server2.domain.tld'
2021-01-05 17:02:54.919735500 [be[ldap]] [sssd_async_socket_init_send] (0x4000): Using file descriptor [22] for the connection.
2021-01-05 17:02:54.919768500 [be[ldap]] [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting
2021-01-05 17:02:54.953896500 [be[ldap]] [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [(unknown error code)]
2021-01-05 17:02:54.953994500 [be[ldap]] [sss_ldap_init_state_destructor] (0x0400): calling ldap_unbind_ext for ldap:[0x559e4d0994a0] sd:[22]
2021-01-05 17:02:54.954058500 [be[ldap]] [sss_ldap_init_state_destructor] (0x0400): closing socket [22]
2021-01-05 17:02:54.954094500 [be[ldap]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
2021-01-05 17:02:54.954129500 [be[ldap]] [sdap_handle_release] (0x2000): Trace: sh[0x559e4d094f50], connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0], release_memory[0]

Cf. #4046.

I get the same behaviour with sssd 2.4.0-1 (as shipped by Debian) and 2.3.1-3. I didn't try other versions.

[akorn]

(Just to be clear: this same setup worked before upgrading the LDAP servers. After the upgrade, all sssd instances failed the same way, but due to caching being enabled, it wasn't immediately obvious.)

[alexey-tikhonov]

Hi,

could you please set ldap_library_debug_level = -1 option in domain section of sssd.conf (for 2.4.0 package it will enable additional debug from openldap libs - see commit 5fb2263 for details ) and share corresponding part of domain log?

[sumit-bose]

Hi,

how does your LDAP server certificate look like? There is a change in OpenLDAP-2.4.52 where a new option TLS_REQSAN was added, see man ldap.conf (https://www.openldap.org/software/man.cgi?query=ldap.conf&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&arch=default&format=html) for details.

HTH

bye,
Sumit

[akorn]

Hi,

how does your LDAP server certificate look like? There is a change in OpenLDAP-2.4.52 where a new option TLS_REQSAN was added, see man ldap.conf (https://www.openldap.org/software/man.cgi?query=ldap.conf&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&arch=default&format=html) for details.

I'm not sure I see how that's relevant; the default setting is the least strict (any certificate that fails it should have failed before too). FWIW, my certificate should match even with the strictest setting; it looks like this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: <redacted>
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
        Validity
            Not Before: Jun 21 13:37:09 2019 GMT
            Not After : Jun 21 13:37:09 2021 GMT
        Subject: OU = Domain Control Validated, CN = *.domain.tld
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus: [...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            Authority Information Access: 
                CA Issuers - URI:http://secure2.alphassl.com/cacert/gsalphasha2g2r1.crt
                OCSP - URI:http://ocsp2.globalsign.com/gsalphasha2g2

            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.4146.1.10.10
                  CPS: https://www.globalsign.com/repository/
                Policy: 2.23.140.1.2.1

            X509v3 Basic Constraints: CA:FALSE
            X509v3 CRL Distribution Points: 
                Full Name: URI:http://crl2.alphassl.com/gs/gsalphasha2g2.crl
            X509v3 Subject Alternative Name: 
                DNS:*.domain.tld, DNS:domain.tld
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Authority Key Identifier: 
                keyid:F5:CD:D5:3C:08:50:F9:6A:4F:3A:B7:97:DA:56:83:E6:69:D2:68:F7

            X509v3 Subject Key Identifier: <redacted>
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : <redacted>

I'll try to see what ldap_library_debug_level = -1 yields later today.

[akorn]

Hah!

2021-01-12 17:52:00.657730500 [be[ldap]] [sss_ldap_debug] (0x4000): libldap: TLS: warning: cacertdir not implemented for gnutls

So I need to specify ldap_tls_cacert insted of ldap_tls_cacertdir because my libldap is linked against gnutls, not openssl.

I wonder why this wasn't a problem before.

Either way, this issue needs to be easier to troubleshoot, and there should be sensible defaults for these ldap_tls settings (settable at compile time, I guess, so that distributions can set them as appropriate).

What I mean is: while my specific problem is apparently solved, others will run into this issue and the vague error message isn't going to help them either.

[sumit-bose]

Hi,

thanks for the feedback, it's good to know that OpenLDAP with gnutls does not support TLS_CACERTDIR, after checking the ldap,conf man page I found 'This parameter is ignored with GnuTLS'.

I'm currently not aware of a way to check the OpenLDAP crypto backend at runtime. Doing this a compile time is tricky as well since the system where SSSD is complied might not reflect the setting on the system where SSSD is run. So it might be a configure option but then distributors building OpenLDAP with gnutls have to actively use this option when building SSSD.

So, I'm currently not sure what might be the best solution but at least we can add a comment to the ldap_tls_cacertdir man page entry mentioning the issue.

bye,
Sumit

[akorn]

thanks for the feedback, it's good to know that OpenLDAP with gnutls does not support TLS_CACERTDIR, after checking the ldap,conf man page I found 'This parameter is ignored with GnuTLS'.

Apparently this is a bug in libldap, because gnutls does have the required feature; see http://bugs.debian.org/979995.

I'm currently not aware of a way to check the OpenLDAP crypto backend at runtime.

I don't think this is necessary, fwiw.

Doing this a compile time is tricky as well since the system where SSSD is complied might not reflect the setting on the system where SSSD is run. So it might be a configure option but then distributors building OpenLDAP with gnutls have to actively use this option when building SSSD.

I agree; however, such consistency is exactly the point of distributions. If a distribution has a sensible default for something, it should be possible to compile packages such that they use this sensible default. For example, Debian has a standard location for system-wide trusted CA certificates, and I think it'd be great if sssd could use it without requiring explicit configuration.

So, I'm currently not sure what might be the best solution but at least we can add a comment to the ldap_tls_cacertdir man page entry mentioning the issue.

That would be a good start. However, it still doesn't help with the vague error message ("unknown error").

I don't know, maybe you could suggest ldap_library_debug_level = -1 (in an sssd log message) when such an unknown error comes up, so people know how to troubleshoot?

[sumit-bose]

Doing this a compile time is tricky as well since the system where SSSD is complied might not reflect the setting on the system where SSSD is run. So it might be a configure option but then distributors building OpenLDAP with gnutls have to actively use this option when building SSSD.

I agree; however, such consistency is exactly the point of distributions. If a distribution has a sensible default for something, it should be possible to compile packages such that they use this sensible default. For example, Debian has a standard location for system-wide trusted CA certificates, and I think it'd be great if sssd could use it without requiring explicit configuration.

Hi,

with respect to system defaults, if you do not set ldap_tls_* options in sssd.conf SSSD will fall back to the libldap defaults, which should fall back to the gnutls defaults if there are no related options in /etc/openldap/ldap.conf. So as long as gnutls use the system-wide trusted CA store libldap and SSSD should use them with default settings.

bye,
Sumit

[akorn]

Doing this a compile time is tricky as well since the system where SSSD is complied might not reflect the setting on the system where SSSD is run. So it might be a configure option but then distributors building OpenLDAP with gnutls have to actively use this option when building SSSD.

I agree; however, such consistency is exactly the point of distributions. If a distribution has a sensible default for something, it should be possible to compile packages such that they use this sensible default. For example, Debian has a standard location for system-wide trusted CA certificates, and I think it'd be great if sssd could use it without requiring explicit configuration.

with respect to system defaults, if you do not set ldap_tls_* options in sssd.conf SSSD will fall back to the libldap defaults, which should fall back to the gnutls defaults if there are no related options in /etc/openldap/ldap.conf. So as long as gnutls use the system-wide trusted CA store libldap and SSSD should use them with default settings.

Do you mean this literally? As in, if I set e.g. ldap_tls_cipher_suite, the system-wide default for ldap_tls_cacert will no longer be used either?

Or do you mean that any options not explicitly overridden in sssd.conf will be inherited from libldap defaults, whatever those happen to be on a particular system? (If yes, then note to Debian users: install the libldap-common package which installs a sensible default ldap.conf.)

Anyway, this bug report is primarily about the unhelpful error message; so while I really, unironically appreciate you taking the time to answer what are essentially support questions, let's not lose sight of that. :)

[johannwagner]

I will just write down my problem I experienced after this error message:

We have Let's Encrypt Certificates for our LDAP servers and use sssd on network switches. However, my certificates - freshly created - still contain the DST Root CA X3, for whatever reason. Everything validates the certificates, even Google Chrome, but sssd is not happy.
You can check the certificate chain with openssl s_client -connect ldap.host.example.com:636

Broken Chain:

 0 s:CN = ldap.host.example.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

Known Good Chain:

 0 s:CN = good.ldap.host.example.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

I am not sure right now why I have those broken certificates - other certificates on other LDAP servers have the correct chain, but you can convince sssd to accept this certificate by providing the ISRG Root Certificate - which is actually be used to sign the certificates.

ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ISRG_Root_X1.pem

I think, they cross signed the ISRG Root CA with the old DST Root CA X3 certificate to keep compatability with old devices, but this certificate is expired now. I will keep you updated if I find out more.

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards,
André Boscatto