Add support for CA bundles for fetching the ignition config

[sohankunkerkar]

Fixes #931

[coreosbot]

Can one of the admins verify this patch?

[LorbusChris]

ok to test

[LorbusChris]

god the mobile UI has me confused. What is needed here to make coreosbot happ? 😅

[jlebon]

ok to test

[jlebon]

Can you try rebasing on the latest master?

[bgilbert]

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 source can contain multiple CA certs.

Once complete, this PR should probably also be backported to spec2x.

[jlebon]

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?

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.

[arithx]

I think I'd agree with @jlebon that we can just view this as a bugfix and push to all versions.

[bgilbert]

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.

[lucab]

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.

[miabbott]

FWIW, I'm in agreement with the rest...I see this as more of a bug fix than anything else.