Closed Alpha-3 closed 8 months ago
Hi,
Thank you for the bug report, it took me some time to get back in the code and then figure out entirely what is happening.
After investigating, the chain of events leading to the problem is:
Option::from_der
calls T::from_der
hereFromDer::from_der
, first calls Any::from_der
here ) which suceeds (parsing an integer), then calls <T>::check_constraints
with T = bool
(which will fail).It is not directly possible to add Error::DerConstraintFailed
to Option::from_der
, this would be too laxist and would allow any encoding to pass.
I'm still investigating, but I think the solution is to change Option::from_der
to
T::from_der
impl<'a, T> FromDer<'a> for Option<T>
has a bug where deserialization ofOption<T>
in a struct annotated with#[derive(DerSequence)]
will fail in withDerConstraintFailed(..)
in certain cases.Example of test failure where
test()
here will fail withError(DerConstraintFailed(InvalidBoolean))
fromTestBool::from_der(expected).unwrap()
as bool/Boolean has a strict DER constraint check on the first byte of the following field:A similar example where the contained type has more relaxed constraints (u32 instead of bool) works:
This could be fixed by accounting for
Error::DerConstraintFailed
inimpl<'a, T> FromDer<'a> for Option<T>
, but perhaps there are other edge cases to consider as well?