-
Notifications
You must be signed in to change notification settings - Fork 243
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
Add support for CA bundles for fetching the ignition config #968
Conversation
Can one of the admins verify this patch? |
ok to test |
god the mobile UI has me confused. What is needed here to make coreosbot happ? 😅 |
4b84ef9
to
ae6dde7
Compare
dde3cc7
to
13f229a
Compare
ok to test |
Can you try rebasing on the latest master? |
916f609
to
d103567
Compare
d103567
to
8369def
Compare
64bc230
to
2d47757
Compare
88b6b44
to
7d24484
Compare
As currently implemented, this change is retroactive to all spec versions. That creates a problem: if someone writes a 3.0 config that uses this functionality, and passes it to an older version of Ignition, the second and subsequent certs will be ignored. (Which, if it affected the outcome at all, would cause fetch failures elsewhere in the config -- so the issue would be detected at least.) The other approach is to make this change only in the -experimental spec, and on older config versions, intentionally parse only the first cert. That's more explicit, but would substantially delay rollout of the functionality, and requires us to add code to intentionally limit certificate parsing. @miabbott @cgwalters @lucab @jlebon thoughts? If we continue on the current path, the config spec docs (all versions) should be updated to specify that a Once complete, this PR should probably also be backported to |
acf66b0
to
ddfd7cc
Compare
Hmm, it's debatable, though I think I see this more as a bugfix than a spec change. IOW, one could see the previous behaviour as wrong and this PR fixing it for all spec versions. Or a related question: could parsing more certificates now reasonably cause a regression? If not, then I think it's fine to just let it get into all the specs even though we're technically changing the semantics of that field. |
I think I'd agree with @jlebon that we can just view this as a bugfix and push to all versions. |
I'm okay with making the change for all spec versions, as we're doing now. @sohankunkerkar, please clarify the wording in the spec docs as well. |
41d1ae6
to
de46364
Compare
de46364
to
51ce731
Compare
I imagine that a likely outcome of this is that it will start detecting malformed bundles with trailing garbage. Even if that may break some previously-accepted configs, I tend to agree with @jlebon that this still fits into the "soundness bugfix" bucket. |
51ce731
to
0d3d0a3
Compare
FWIW, I'm in agreement with the rest...I see this as more of a bug fix than anything else. |
Fixes #931