You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment umbral is designed to never panic and always return a Result/Option. In some cases this results in rather silly errors that, if happen, are not something one can recover from, but rather indicate a bug in the rust-umbral, or the calling code. Perhaps we can introduce some panics to simplify the API. Although we need to remember that rust-umbral may be run in embedded environments.
A (perhaps non-exhaustive) list of candidates for replacement with panic:
OpenReencryptedError::NoCapsuleFrags - the caller should ensure that the list of cfrags is not empty
OpenReencryptedError::ZeroHash - very low probability of happening either randomly or intentionally (caused by some malicious actor)
SecretKeyFactoryError::ZeroHash - see above.
EncryptionError::PlaintextTooLarge - this is basically an OOM situation. In all other cases of OOM the code will panic anyway. For embedded environments we may provide an infallible encrypt_to_buffer or something.
Some errors may be merged, since they are effectively the same from the user's point of view:
IncorrectKeyFragSignature and IncorrectReencryption in CapsuleFragVerificationError
CiphertextTooShort and AuthenticationFailed in DecryptionError
IncorrectCommitment and IncorrectSignature in KeyFragVerificationError. Possibly merged with DelegatingKeyNotProvided and ReceivingKeyNotProvided too.
The text was updated successfully, but these errors were encountered:
At the moment
umbral
is designed to never panic and always return aResult
/Option
. In some cases this results in rather silly errors that, if happen, are not something one can recover from, but rather indicate a bug in therust-umbral
, or the calling code. Perhaps we can introduce some panics to simplify the API. Although we need to remember thatrust-umbral
may be run in embedded environments.Additional reading:
https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html
https://www.unwoundstack.com/blog/rust-error-handling.html
A (perhaps non-exhaustive) list of candidates for replacement with
panic
:OpenReencryptedError::NoCapsuleFrags
- the caller should ensure that the list of cfrags is not emptyOpenReencryptedError::ZeroHash
- very low probability of happening either randomly or intentionally (caused by some malicious actor)SecretKeyFactoryError::ZeroHash
- see above.EncryptionError::PlaintextTooLarge
- this is basically an OOM situation. In all other cases of OOM the code will panic anyway. For embedded environments we may provide an infallibleencrypt_to_buffer
or something.Some errors may be merged, since they are effectively the same from the user's point of view:
IncorrectKeyFragSignature
andIncorrectReencryption
inCapsuleFragVerificationError
CiphertextTooShort
andAuthenticationFailed
inDecryptionError
IncorrectCommitment
andIncorrectSignature
inKeyFragVerificationError
. Possibly merged withDelegatingKeyNotProvided
andReceivingKeyNotProvided
too.The text was updated successfully, but these errors were encountered: