-
Notifications
You must be signed in to change notification settings - Fork 276
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
[fix] #2422: Hide private keys in configuration endpoint response #2435
[fix] #2422: Hide private keys in configuration endpoint response #2435
Conversation
Codecov Report
@@ Coverage Diff @@
## iroha2-dev #2435 +/- ##
==============================================
- Coverage 67.61% 67.14% -0.47%
==============================================
Files 140 155 +15
Lines 26173 27552 +1379
==============================================
+ Hits 17696 18499 +803
- Misses 8477 9053 +576
Help us with your feedback. Take ten seconds to tell us how you rate us. |
a770f2e
to
3fcac59
Compare
data_model/src/config.rs
Outdated
pub struct Configuration { | ||
/// Public key of this peer. | ||
pub public_key: PublicKey, | ||
/// Disable coloring of the backtrace and error report on panic. | ||
pub disable_panic_terminal_colors: bool, | ||
/// `Kura` related configuration. | ||
pub kura: kura::Configuration, | ||
/// `Sumeragi` related configuration. | ||
pub sumeragi: sumeragi::Configuration, | ||
/// `Torii` related configuration. | ||
pub torii: torii::Configuration, | ||
/// `BlockSynchronizer` configuration. | ||
pub block_sync: block_sync::Configuration, | ||
/// `Queue` configuration. | ||
pub queue: queue::Configuration, | ||
/// `Logger` configuration. | ||
pub logger: logger::Configuration, | ||
/// Configuration for `GenesisBlock`. | ||
pub genesis: genesis::Configuration, | ||
/// Configuration for `WorldStateView`. | ||
pub wsv: wsv::Configuration, | ||
/// Network configuration | ||
pub network: network::Configuration, | ||
/// Configuration for telemetry | ||
#[cfg(feature = "telemetry")] | ||
pub telemetry: telemetry::Configuration, | ||
} |
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 thought that such config structure duplication will be simplified with code generated by View
macro. Why we can't use it for that?
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.
Duplicating by hand is quite dangerous for future changes
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 agree that having almost the same structure in two places could be not the best option.
However i can't came up with idea how we can deal with nested structures where structure's view fields are themself views (data_mode::config::Configuration
is example of such structure).
Any idea?
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.
What about to annotate such fields view #[view(...)]
attribute?
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.
The view attribute sounds good, but it might be difficult to implement.
config/src/lib.rs
Outdated
/// let view = View { a: 32 }; | ||
/// let structure: Structure = view.into(); |
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.
Why we may need to cast view to the actual struct if it's missing some fields? I'd like to have only one way conversion: Config -> View
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.
This situation could arise when we send public configuration to other peer and peer what to create full configuration from public (bootstrap peers).
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.
Does creating private keys with default()
will help much here?
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.
Then we can load keys from environment variable or other places.
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.
Careful! We did a lot of hard work to get rid of impl Default for *Key*
, and we should avoid reintroducing that. This is a security risk.
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.
@appetrosyan, ok, i will make one way conversion Config -> View
as suggested by @Arjentix to avoid relying on Default
, backward conversation could be achieved be using proxy configuration objects.
Also why do we need View-like configs in the |
If we want something to be queue result it must be in
I'm not sure if it will be good thing to aggregate all configuration from different domains in one place. |
If we will split this then we can't generate view from config. Then with updating of config we have to remember to update view. And event compiler won't say anything, because if we forgot then it will use |
It won't compile because without |
Oh, okay, I've missed that |
Also i think defining all configuration in one place go against upcoming refactoring #2392. IMO we should gather opinions from other team members. |
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.
Looks good to me.
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.
You must rebase onto iroha2-dev. And you must squash all your commits into one fix commit. That commit should be called [fix] #2422: Hide private keys in configuration endpoint response
.
i will squash commits on merge |
Signed-off-by: Shanin Roman <[email protected]>
…oint response Signed-off-by: Shanin Roman <[email protected]>
Co-authored-by: Ekaterina Mekhnetsova <[email protected]> Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
…` to `iroha_config` Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
…oint response Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
Signed-off-by: Shanin Roman <[email protected]>
…ssed Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
…oint response (hyperledger-iroha#2435) Signed-off-by: Shanin Roman <[email protected]>
Description of the Change
iroha_config
;view!
to generate configuration view (without private fields) and conversationConfig->View
;GetConfiguration
endpoint to return configuration view without private keys.Issue
Closses #2422.
Benefits
Possible Drawbacks
iroha_config
depends oniroha_data_model
.Alternate Designs
Simpler solution would be to mask or hide private keys during serialization but this would affect generated reference configuration.
Proc-macro
view!
was decided to make function-like because it should be expanded first, so with function-like invocation it's made explicit.Further work
kagami
functionality to generate reference configuration tobuild.rs
;iroha_config
dependency oniroha_data_model
to be able to useConfiguration
iniroha_data_model
and share config through query;view!
assumption that configuration hasDefault
implemented, it will be possible after RethinkDefault
configuration #2118.