1ada606ed8
The problem: osbuild-composer used to have a rather uncomplete logic for selecting client certificates and keys while fetching data from repositories that use the "subscription model". In this scenario, every repo requires the user to use a client-side TLS certificate. The problem is that every repo can use its own CA and require a different pair of a certificate and a key. This case wasn't handled at all in composer. Furthermore, osbuild-composer can use remote workers which complicates things even more. Assumptions: The problem outlined above is hard to solve in the general case, but Red Hat Subscription Manager places certain limitations on how subscriptions might be used. For example, a subscription must be tight to a host system, so there is no way to use such a repository in osbuild-composer without it being available on the host system as well. Also, if a user wishes to use a certain repository in osbuild-composer it must be available on both hosts: the composer and the worker. It will come with different pair of a client certificate and a key but otherwise, its configuration remains the same. The solution: Expect all the subscriptions to be registered in the /etc/yum.repos.d/redhat.repo file. Read the mapping of URLs to certificates and keys from there and use it. Don't change the manifest format and let osbuild guess the appropriate subscription to use. |
||
|---|---|---|
| .. | ||
| cloud.google.com/go | ||
| github.com | ||
| go.opencensus.io | ||
| golang.org/x | ||
| google.golang.org | ||
| gopkg.in | ||
| modules.txt | ||