aktualizr-lite: Support using TLS keys #1237
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1237 +/- ##
==========================================
+ Coverage 79.27% 79.38% +0.11%
==========================================
Files 170 170
Lines 10140 10146 +6
==========================================
+ Hits 8038 8054 +16
+ Misses 2102 2092 -10
Continue to review full report at Codecov.
|
doanac
changed the title
doanac
changed the title
src/aktualizr_lite/main.cc
Outdated
| hwid = Utils::getHostname(); | ||
| } | ||
| if (serial.empty()) { | ||
| serial = Utils::getHostname(); |
There was a problem hiding this comment.
I'm not sure if I understand this logic for generating a serial. Reusing hostname seems like a problem. Serials should be unique, at least within a namespace, and hostnames are rather likely to be non-unique. Our standard technique is to use the key ID of the ECU's Uptane key.
There was a problem hiding this comment.
The problem there is that in "lite" mode there is no uptane key. I guess I could grab the UUID from the client.pem and use that since it would be unique? However, aktualizr-lite doesn't require TLS, so that might not be there either. I guess I could just generate a UUID and use that?
| @@ -205,7 +205,7 @@ InitRetCode Initializer::initEcuRegister() { | |||
| Initializer::Initializer( | |||
| const ProvisionConfig& config_in, std::shared_ptr<INvStorage> storage_in, | |||
| std::shared_ptr<HttpInterface> http_client_in, KeyManager& keys_in, | |||
| const std::map<Uptane::EcuSerial, std::shared_ptr<Uptane::SecondaryInterface> >& secondary_info_in) | |||
| const std::map<Uptane::EcuSerial, std::shared_ptr<Uptane::SecondaryInterface> >& secondary_info_in, bool lite_mode) | |||
There was a problem hiding this comment.
I don't particularly like punching holes in our initialization logic, but I haven't yet thought of a better way that isn't just duplicating code. But can we at least change the name? lite_mode seems rather hard to understand without already knowing the context. Perhaps tls_only would be better? I do like that it defaults to false, though!
There was a problem hiding this comment.
I'm a bit uneasy about this as well. Adding conditional logic into a security related flow could cause a subtle bug some day. I think there are two other options here:
-
Keep this patch out-of-tree.
Its kind of specific to something we are doing. I can understand if this isn't interesting to you guys. -
Have aktualizr-lite use the SotatUptaneClient constructor rather than calling
newDefaultClient
If we changed things to this, then I could actually just call what I needed directly,keys_.copyCertsToCurl(*http_client_);
I haven't tried out option 2 but I think that might work better here and not leak details of the lite stuff into sotauptaneclient. Sound reasonable?
|
I think this new version is a bit better. I can understand if you guys don't want the 2nd commit "Set a default ECU Serial", but I think the first commit is probably worth merging. |
|
Generating a random serial is fine if you have nothing else to go off. But I'd still prefer if we could rename |
|
@patrickvacek - sorry - i need to back out the changes to the sotauptaneclient and initializr. The latest revision doens't call those paths. |
This is a bit of an edge case, but I've found it useful to run devices in the lite mode, but to still restrict who can access the tuf/treehub repos via TLS. Signed-off-by: Andy Doan <andy@foundries.io>
You get a warning message every time this tool is run when there is no ecu serial configured: warning: Could not find primary ecu serial, defaulting to empty serial: unknown error This detects the situation and will give it a "good enough" default. Signed-off-by: Andy Doan <andy@foundries.io>
|
This new diff should be better. |
This is a bit of an edge case, but I've found it useful to run
devices in the lite mode, but to still restrict who can access
the tuf/treehub repos via TLS.
Signed-off-by: Andy Doan andy@foundries.io