-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implemented proc/crypto parsing #296
Conversation
Where possible appropriate types have been used. Tests have been implemented for a few cases but not all.
to CryptoTable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, thanks for working on this! This is a good start
I made a few in-line comments. A few additional general comments:
- Can you add a test that will actually parse a live
/proc/crypto
file? - I don't see an obvious way to construct a
CryptoTable
- There's a few very minor things that
cargo clippy
will report
|
I mean open
Sorry, I didn't quite follow this. Can you give an example about how one would create a |
I can implement those, I just normally try and keep it all in test and not touch the system. I can implement current for a table, currently it's only implemented that if you pass an iterator of bytes that contains a crypto table it will parse from that. I'll get a push to you this weekend that will implement these. |
Changed to using a while let loop instead of a fixed loop.
I think I've got everything, if you could give it a look over :) There are some clippy lints outside of the crypto sections that I have left untouched, as I don't want to mess with other folks code! |
I'm looking at the
Since the crypto table is a HashMap, only the last |
…sier to read manner.
That was not the intention. My reckoning is that the easiest way to resolve this is to change from a |
…toBlock>>` to account for duplicate names. Minor changes to tests, added test for two blocks that share a name but are distinct drivers.
Added in a version that has a |
Looks pretty good on a quick skim, will do a more detailed review later. Thanks! |
Hey, just checking in if you've had a chance to look and see if anything else needs an update? |
Thanks for the ping, I'll take a look Very Soon Now |
#[cfg_attr(feature = "serde1", derive(Serialize, Deserialize))] | ||
pub enum Type { | ||
/// Symmetric Key Cipher | ||
Skcipher(Skcipher), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I might prefer using a struct variant, like:
pub enum Type {
/// Symmetric Key Cipher
Skcipher{async_capable: bool, block_size: bool, min_key_size: bool, ...}
...
}
It makes the whole enum a bit more complicated, but also you have less types overall (because you can get rid of the Skcipher
struct).
But this is a minor point, no need to change this now
Thank you for the contribution, and your patience with the long review! |
Hi, I have implemented parsing for the /proc/crypto file, as I noticed it wasn't implemented in the support file. I have tried to add in types where it felt relevant so it can restrict the output slightly and make handling the output a bit easier than throwing strings around. I've put in tests for various possibilities but admittedly they're far from exhaustive! I've tested on my local machine and a raspberry pi but nothing further.