Matthias Büchse

I added a rudimentary scheme for signing the report to be posted and for verifying the signature. **edit** the scheme is based upon this post:

FYI: will proceed with deployment soon. Thanks to https://github.com/SovereignCloudStack/docs/pull/200 we have a potential target 👍

FYI: I managed to do a test deployment to a VM within the dedicated gx-scs project. Now Kurt will configure a subdomain. After that, I will get let's encrypt to...

Is this a duplicate of https://github.com/SovereignCloudStack/standards/issues/769? It sure seems so to me.

This is not controversial – I agree on all accounts. Thanks for spotting this.

For context: When we crafted this standard, the docs page wasn't as advanced nor as widely adopted as today. So it should be updated without question.

On second thought, the crux here is the following: from my point of view, this standard merely regulates the format of the YAML file; which YAML file is ultimately used...

Let me expand on my previous statement. Currently, what YAML is relevant is solely determined in the [certificate scope](https://github.com/SovereignCloudStack/standards/blob/main/Tests/scs-compatible-iaas.yaml#L37): ```yaml - name: Standard images url: https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Standards/scs-0104-v1-standard-images.md checks: - executable: ./iaas/standard-images/images-openstack.py...

This issue should be mitigated by [formal parameters](https://github.com/SovereignCloudStack/standards/issues/592). Nevertheless, we should also change this into a Procedural and add implementation notes.

@berendt I agree that scs:disk0-type is most likely the property that is intended for this purpose. BTW, I only stumbled upon this issue by coincidence.