Skip to content

Conversation

@tarcieri
Copy link
Member

@tarcieri tarcieri commented Jul 24, 2022

@codecov-commenter
Copy link

codecov-commenter commented Jul 24, 2022

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.21%. Comparing base (0b24c8d) to head (398134e).
Report is 164 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #444   +/-   ##
=======================================
  Coverage   87.21%   87.21%           
=======================================
  Files          40       40           
  Lines        1955     1955           
=======================================
  Hits         1705     1705           
  Misses        250      250           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@roy-work
Copy link

It would be nice to get a more specific callout in the CHANGELOG about this one, specifically, what I as a dev need to do around this in order to update (to aes-siv 0.7).

This PR makes it seem like it is just a dependency update, but this is a breaking change in aes-siv's interface.

@tarcieri
Copy link
Member Author

tarcieri commented Jan 23, 2023

@roy-work did you follow the link in the description? RustCrypto/traits#1058

As noted there, the only major change is replacing NewAead with KeyInit. The two traits are nearly identical, so it should just be s/NewAead/KeyInit/.

@roy-work
Copy link

roy-work commented Jan 23, 2023

@tarcieri I did, and I did make that replacement; there is still other breakage:

error[E0284]: type annotations needed: cannot satisfy `<_ as KeySizeUser>::KeySize == UInt<UInt<UInt<UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B0>, B0>, B0>, B0>`
   |
79 |     let key = Key::from_slice(self.key);
   |               ^^^ cannot satisfy `<_ as KeySizeUser>::KeySize == UInt<UInt<UInt<UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B0>, B0>, B0>, B0>`

which was introduced at 0.7, so it isn't as simple as just updating the use statements.

KeyInit seems to call it new_from_slice, but that doesn't seem to work, either:

error[E0599]: the function or associated item `new_from_slice` exists for struct `GenericArray<u8, _>`, but its trait bounds were not satisfied
    |
79  |     let key = Key::new_from_slice(self.key);
    |                    ^^^^^^^^^^^^^^ function or associated item cannot be called on `GenericArray<u8, _>` due to unsatisfied trait bounds
    |
   ::: /[…]/.cargo/registry/src/-662ab3103e52a138/generic-array-0.14.5/src/lib.rs:172:1
    |
172 | pub struct GenericArray<T, U: ArrayLength<T>> {
    | ---------------------------------------------
    | |
    | doesn't satisfy `GenericArray<u8, _>: KeyInit`
    | doesn't satisfy `GenericArray<u8, _>: crypto_common::InnerInit`
    | doesn't satisfy `GenericArray<u8, _>: crypto_common::InnerUser`
    |
    = note: the following trait bounds were not satisfied:
            `GenericArray<u8, _>: crypto_common::InnerInit`
            which is required by `GenericArray<u8, _>: KeyInit`
            `GenericArray<u8, _>: crypto_common::InnerUser`
            which is required by `GenericArray<u8, _>: KeyInit`
            `&GenericArray<u8, _>: crypto_common::InnerInit`
            which is required by `&GenericArray<u8, _>: KeyInit`
            `&GenericArray<u8, _>: crypto_common::InnerUser`
            which is required by `&GenericArray<u8, _>: KeyInit`
            `&mut GenericArray<u8, _>: crypto_common::InnerInit`
            which is required by `&mut GenericArray<u8, _>: KeyInit`
            `&mut GenericArray<u8, _>: crypto_common::InnerUser`
            which is required by `&mut GenericArray<u8, _>: KeyInit`

(The arg here, self.key, is a &[u8]. Nothing too surpising, I think…?)

@tarcieri
Copy link
Member Author

KeyInit isn't impl'd for Key. It's impl'd for the Aes*SivAead types, i.e. the types NewAead was previously impl'd for. Take a look at the example:

https://docs.rs/aes-siv/latest/aes_siv/#usage

Key is an alias for GenericArray which requires a type parameter:

https://docs.rs/aes-siv/latest/aes_siv/#usage

You need to explicitly specify the cipher the key is for, e.g. Key::<Aes256SivAead>

@roy-work
Copy link

You need to explicitly specify the cipher the key is for, e.g. Key::<Aes256SivAead>

That works, thank you! (The need for that is apparently new, though.)

Although, the two lines here are…

let key = Key::<Aes256SivAead>::from_slice(self.key);
Aes256SivAead::new(key)

Which seems equivalent to:

Aes256SivAead::new_from_slice(&self.key).unwrap()

… which I might leave it as.

(This code has been around since miscreant. This is getting dragged in with the recent git2 vuln., for me. cargo audit depends on both git2 and this crate, and so fixing the git2 vuln. pulls in a new aes-siv. That in turn conflicts with another crate of ours, due to aes-siv's MSRV requirements preventing two version from co-existing.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants