Clarify documentation for rnp_key_set_expiration

[kaie]

The documentation for rnp_key_set_expiration says that if the key is locked, it may call the password retrieval callback.

In my testing, the callback wasn't called, and the function failed. It was necessary to call rnp_key_unlock before calling rnp_key_set_expiration.

[kaie]

I'm running into some unexpected behavior.

(1) Given a key that has already expired. I'm calling the API and request a new expiry of 2 days (2*86400 seconds). The function completes. However, the new expiration isn't the date. Rather, the new value is zero - never expire.

(2) given a key that is currently set to never expire. I'm calling the API to change the expiry to a specific day, I'm again using 2 days. The function completes. However, the new value isn't set. The key still displays as "never expire".

[kaie]

On the positive side, if an existing key is not expired, and has a specific expiry date currently set, then using the API to set a new expiration date works.

[ni4]

The documentation for rnp_key_set_expiration says that if the key is locked, it may call the password retrieval callback.In my testing, the callback wasn't called, and the function failed.

Thanks, this was somehow missed, needs fixing.

Given a key that has already expired. I'm calling the API and request a new expiry of 2 days (2*86400 seconds). The function completes. However, the new expiration isn't the date. Rather, the new value is zero - never expire.

Given a key that has already expired. I'm calling the API and request a new expiry of 2 days (2*86400 seconds). The function completes. However, the new expiration isn't the date. Rather, the new value is zero - never expire.

Hm, will check these, should be working. Probably something with marking keys/signatures as valid/invalid. Thanks for reporting!

[ni4]

@kaie Most likely the reason of (1) and (2) is a too short key expiration time - it is actually calculated not from the current time, but from the key creation time. So afterwards certification signature is considered as invalid (since was made by the expired key), so key expiration time defaults to 0. Also in this case key will be marked as invalid.

This definitely needs to be reflected in documentation.

[kaie]

@ni4 Thank you for the clarification, I indeed had a bug in the calculation of the new expiration value, and had used small value.

But there's still a bug there, here's my scenario:

• I have a key that already expired
• now = "current unix epoch date".
• currentKeyAge = now - keyCreationDateSeconds
• newExpiryDate = currentKeyAge + (2 30 24 60 60) // approx. 2 months in the future from today

I call rnp_key_set_expiration(handle, newExpiryDate);

Afterwards, I use the usual APIs to query the key attributes. It tells me: key never expires

Then I restart the application, and use the same code to query the expiration again. Now I get the expected value!

So apparently changing the expiration data on the key data structure works, but your in-memory cache uses an incorrect value.

[kaie]

This only happens if the key has already expired. It works correctly, when changing the expiration date of a not-yet-expired key.