Add "pubkey" insecure flag. #2278
Conversation
Documentation/commands.md
Outdated
| | `--debug` | `false` | `true` or `false` | Prints out more debug information to `stderr` | | ||
| | `--dir` | `/var/lib/rkt` | A directory path | Path to the `rkt` data directory | | ||
| | `--insecure-options` | none | **none**: All security features are enabled<br/>**http**: Allow HTTP connections. Be warned that this will send any credentials as clear text.<br/>**image**: Disables verifying image signatures<br/>**tls**: Accept any certificate from the server and any host name in that certificate<br/>**ondisk**: Disables verifying the integrity of the on-disk, rendered image before running. This significantly speeds up start time.<br/>**all**: Disables all security checks | Comma-separated list of security features to disable | | ||
| | `--insecure-options` | none | **none**: All security features are enabled<br/>**http**: Allow HTTP connections. Be warned that this will send any credentials as clear text.<br/>**image**: Disables verifying image signatures<br/>**tls**: Accept any certificate from the server and any host name in that certificate<br/>**ondisk**: Disables verifying the integrity of the on-disk, rendered image before running. This significantly speeds up start time.<br/>**pubkey**: Allow fetching pubkeys via insecure connections (via HTTP connections or from servers with unverified certificates). The keys will be fetched to a temporary keystore regardless of whether the connection was secure or not.<br/>**all**: Disables all security checks | Comma-separated list of security features to disable | |
There was a problem hiding this comment.
"The keys will be fetched to a temporary keystore"
It is confusing that this flag will do 2 independent things:
- enable download on http
- change the directory where it is downloaded
If users want to change the directory where it is downloaded, couldn't they use --local-config?
There was a problem hiding this comment.
+1, bit unclear on this behaviour, seems somewhat arbitrary
There was a problem hiding this comment.
Yeah, at first I thought we should keep the potentially insecure keys outside of the main keystore, but following this logic, we should have been downloading potentially insecure images to the temporary store too. But since we are putting them into the main store, there is little sense in having a separate keystore.
610b0d5 to
46ce5c7
Compare
|
Updated. |
|
Ooopz, we need rebaze. |
46ce5c7 to
179a4ab
Compare
|
Rebazed. |
|
There's no temporary keystore anymore, right? The commit message needs update. |
|
Right, will do it. |
The redundancy was mind-boggling. This just replaces all the tables in subcommands with a link to a global options section in general commands documentation. This also saves us the requirement to remember to update all the tables, when new global option is added.
When fetching images via a discovery mechanism, it is also possible to fetch the keys via the discovery and then trust them to verify the image signature. For the key to be fetched, HTTPS connection is required and the server's certificate must be successfully verified. Trusting the key puts it into a persistent keystore. This makes it hard to test it with a local server, which usually doesn't have a valid certificate. The "pubkey" option of the --insecure-options flag makes fetching keys from insecure places possible, that is - from HTTP connections or from servers with an invalid certificate.
179a4ab to
e525b6c
Compare
|
Updated. |
|
Lookz Good To Me |
| var tr *http.Transport | ||
| // default transport is hidden behind the RoundTripper | ||
| // interface, so we can't easily make a copy of it | ||
| if transport, ok := http.DefaultTransport.(*http.Transport); ok { |
There was a problem hiding this comment.
What's the point of these machinations? Why do we need divergent behaviour based on go version?
There was a problem hiding this comment.
Divergent behaviour based on go version?
For insecure connections I want to use the same transport as for secure ones, but with a slightly different TLS config. I guess that the else case could just panic instead.
There was a problem hiding this comment.
Well, what's the circumstance in which !ok? I thought the comment on line 250 was implying that this assertion woudl only work on 1.6 or newer.
There was a problem hiding this comment.
In general - in version 1.4, 1.5 and 1.6, DefaultTransport is an instance of http.Transport hidden behind the RoundTripper interface, so for these versions we have ok. I added the !ok case, just because I could. :P But I guess I should just panic here and when an incompatible change is made in go, we can adapt. The comment in 250 is simply saying that the ExpectContinueTimeout field exist only in go 1.6 and later, so we don't set it even if go1.6 sets it to some value, because we want the code to build with older go too.
So in short - !ok should not happen, should I panic here?
There was a problem hiding this comment.
This PR is merged, so there is another one addressing it - #2354
This adds a new, "pubkey" insecure option, so we can temporarily (by creating a second keystore in /tmp) trust keys from HTTP(S). We need this for testing, because local ACI server uses an invalid certificate (apparently for example.com, not for localhost), so to be able to download anything from it, we need to pass a "tls" insecure option. But then, the keys from discovery weren't downloaded at all.
It also deduplicates global flags documentation.