pub enum SseError {
Show 19 variants
KeyFileIo {
path: PathBuf,
source: Error,
},
BadKeyLength {
got: usize,
},
TooShort {
got: usize,
},
BadMagic {
got: [u8; 4],
},
UnsupportedAlgo {
tag: u8,
},
KeyNotInKeyring {
id: u16,
},
DecryptFailed,
WrongCustomerKey,
InvalidCustomerKey {
reason: &'static str,
},
CustomerKeyAlgorithmUnsupported {
algo: String,
},
CustomerKeyRequired,
CustomerKeyUnexpected,
KmsAsyncRequired,
KmsFrameTooShort {
got: usize,
min: usize,
},
KmsFrameFieldOob {
what: &'static str,
},
KmsKeyIdNotUtf8,
KmsWrappedDekMismatch {
supplied: String,
stored: String,
},
KmsRequired,
KmsBackend(KmsError),
}Variants§
KeyFileIo
BadKeyLength
TooShort
BadMagic
UnsupportedAlgo
KeyNotInKeyring
DecryptFailed
WrongCustomerKey
The MD5 fingerprint stored in the S4E3 frame doesn’t match the
MD5 of the customer key the client supplied. This is the
“wrong customer key on GET” signal — distinct from
DecryptFailed so service.rs can map it to AWS S3’s
403 AccessDenied (S3 returns AccessDenied when the supplied
SSE-C key doesn’t match the one used at PUT time).
InvalidCustomerKey
parse_customer_key_headers saw a malformed input. reason is
a short human string (“base64 decode of key”, “key length”,
“md5 length”, “md5 mismatch”) for operator log lines — never
echoed to the client (would leak crypto details).
CustomerKeyAlgorithmUnsupported
Client asked for an SSE-C algorithm the gateway doesn’t speak.
AWS S3 only ever defines AES256 here; surfacing the offending
string lets us 400 with a useful message.
CustomerKeyRequired
S4E3 body lacks an SSE-C key — caller passed SseSource::Keyring
when decrypting an SSE-C-encrypted object. service.rs should
translate this into the same “missing customer key” 400 that
AWS S3 returns when SSE-C headers are absent on a GET.
CustomerKeyUnexpected
Inverse: client sent SSE-C headers on a GET for an object stored without SSE-C. The supplied key has no role in decryption, but AWS S3 actually 400s in this case (“expected an unencrypted object” / “extraneous SSE-C headers”), so we mirror that.
KmsAsyncRequired
decrypt (sync) was handed an S4E4 body. SSE-KMS unwrap is
async (it round-trips to the KMS backend), so callers must
peek the magic with peek_magic and dispatch S4E4 frames to
decrypt_with_kms instead. service.rs’s GET handler does
this; tests / direct callers may hit this if they forget.
KmsFrameTooShort
S4E4 frame is shorter than the minimum-possible header (38
bytes for an empty key_id + empty wrapped_dek, which is
itself impossible — we just sanity-check the floor).
KmsFrameFieldOob
S4E4 declared a key_id_len or wrapped_dek_len that runs
past the end of the body. Almost certainly truncation /
corruption rather than tampering (tampering would fail the
AES-GCM tag instead).
KmsKeyIdNotUtf8
key_id field of an S4E4 frame is not valid UTF-8. We require
UTF-8 because LocalKms uses the basename of a .kek file
(which is OS-string-but-typically-UTF-8) and AWS KMS uses ARNs
(which are ASCII).
KmsWrappedDekMismatch
service.rs handed decrypt_with_kms a WrappedDek whose
key_id doesn’t match the one stored in the S4E4 frame. This
is an integration bug (caller is meant to pull the wrapped
DEK from the frame, not from somewhere else), surface as a
distinct error so it shows up in tests rather than silently
failing the AES-GCM tag.
KmsRequired
SSE-KMS path got a non-Kms SseSource for an S4E4 body. The
async dispatch in decrypt_with_kms re-derives the source
internally so this can only happen if a future caller passes
SseSource::Keyring / CustomerKey to a path that expected
Kms — kept around for symmetry with the other “wrong source”
errors.
KmsBackend(KmsError)
Pass-through for crate::kms::KmsError surfaced from
KmsBackend::decrypt_dek — boxed so the variant stays small.
Trait Implementations§
Source§impl Error for SseError
impl Error for SseError
Source§fn source(&self) -> Option<&(dyn Error + 'static)>
fn source(&self) -> Option<&(dyn Error + 'static)>
1.0.0 · Source§fn description(&self) -> &str
fn description(&self) -> &str
use the Display impl or to_string()