zcertstore has no API to get the disk state from a custom loader

[santupari]

Hello everyone,

We encountered 2 different issues listed below w.r.t CURVE authentication which uses zcertstore internally to store the client keys.

1. If there are multiple client certs with same timestamp or one of the cert has timestamp
   a. On client connection request certstore gets refreshed
   b. after that a new client cert is copied or valid cert is overwritten as the previous cert was invalid or corrupted, the certstore does not get refreshed and there after that connection will never be allowed as there is not change w.r.t timestamp, count and current size of the cert dir
2. If an application wants to load its custom disk loader (which loads all the certs on a change), then there is no API available to access the state store in zcertstore struct.

The above issues are observed on libczmq 4.2.0 version.
I have attached test code along with the patch for zcertstore.c and zcertstore.h.

Please let me know for any clarification.

czmq_certstore_custom_loader.zip

Thanks,
Santosh Bidaralli

[bluca]

Please send a pull request with the patches rather than attachments

[santupari]

Thank you @bluca. I will send the pull request at the earliest.

[stale]

This issue has been automatically marked as stale because it has not had recent activity for 90 days. It will be closed if no further activity occurs within 21 days. Thank you for your contributions.

[Yashashree-Jadhav]

Hi Everyone,

I am seeing the same issue as mentioned in 1st bullet here:

1. If there are multiple client certs with same timestamp or one of the cert has timestamp. On client connection request certstore
   gets refreshed after that a new client cert is copied or valid cert is overwritten as the previous cert was invalid or corrupted,
   the certstore does not get refreshed and there after that connection will never be allowed as there is not change w.r.t
   timestamp, count and current size of the cert dir

Before jumping to 4.2.1, I am curious how does the custom disk loader helps fix this issue.
I see in my case the default disk loader in zcertstore (s_disk_loader ) never makes into this if block:

---

if (dir
&& (state->modified != zdir_modified (dir)
|| state->count != zdir_count (dir)
|| state->cursize != (size_t) zdir_cursize (dir)))
{

---

[santupari]

Yashashree, You can create a custom disk loader that checks the hash of the directory (cert dir) every time a change is detected instead of count and size. Thanks, Santosh From: Yashashree-Jadhav <notifications@github.com> Sent: Wednesday, February 10, 2021 1:11 PM To: zeromq/czmq Cc: Bidaralli, Santosh; Author Subject: Re: [zeromq/czmq] zcertstore has no API to get the disk state from a custom loader (#2113) [EXTERNAL EMAIL] Hi Everyone, I am seeing the same issue as mentioned in 1st bullet here: 1. If there are multiple client certs with same timestamp or one of the cert has timestamp. On client connection request certstore gets refreshed after that a new client cert is copied or valid cert is overwritten as the previous cert was invalid or corrupted, the certstore does not get refreshed and there after that connection will never be allowed as there is not change w.r.t timestamp, count and current size of the cert dir Before jumping to 4.2.1, I am curious how does the custom disk loader helps fix this issue. I see in my case the default disk loader in zcertstore (s_disk_loader ) never makes into this if block:

…

________________________________ if (dir && (state->modified != zdir_modified (dir) || state->count != zdir_count (dir) || state->cursize != (size_t) zdir_cursize (dir))) {

________________________________ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2113 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACGXE3RWCQR7IYZQB6TYUQ3S6LK4NANCNFSM4RPUCNQQ>.

[stale]

This issue has been automatically marked as stale because it has not had recent activity for 90 days. It will be closed if no further activity occurs within 21 days. Thank you for your contributions.