- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 15 2024
Mar 14 2024
Thanks for reporting this. Returning error codes to upper layers is not always easy because the original logic is that we have a global error counter to decide whether an operation succeeded. My fix to check the error code before emitting the DECRYPTION_OKAY status,
Mar 13 2024
Hello Werner,
the above is an excerpt from the exim log, I do not think the full bounce is more enlightening, vsrv21575.customer.vlinux.de got 550 from ellsberg.gnupg.com after " MAIL FROM:<ametzler@bebt.de>":
handle_plaintext gets data returned by iobuf_read, and does not check the error status of the iobuf object.
But only if you can figure out in a transaction or locked sytate whether the card needs a verify. Otherwise we have a race between changing the PIN and verifying a PIN.
This rejection could be relaxed.
Mar 12 2024
Changes:
- The maximum allowed difference of the expiration between subkey and primary key is now +/-1 hour.
- If the user has no choice whether to update the subkeys together with the primary key (because either all subkeys will be skipped because they don't fulfil the conditions mentioned in the first comment or because the subkeys share the expiration of the primary key) then the checkbox is not shown. That was easier to implement and it doesn't confuse the users with a "choice" they are not allowed to change.
Right. I think this task inherited the assignee from its parent task.
Done.