Allow user to provide filename hint using `siemens:filename` or a "local copy" externalReference?

[gernot-h]

I recently noticed that the https://proxy.golang.org/ doesn't set a correct Content-Disposition for downloading a specific version of a module, so you will end up with filenames like v1.2.3.zip instead of foo-v1.2.3.zip which is somehow ugly. So I'd somehow need a way of providing a filename hint to CaPyCli.

As of today, CaPyCli has a kind-of-hidden feature for bom createcomponents --download - if there's an existing externalReference with comment source archive (local copy) (even if there's no local file available!), it will use that filename for the temporary download and especially for uploading the attachment for SW360. I think this dates back from the old proprietary CaPyCli SBOM format. However, this is currently not supported for the bom downloadsources command.

While I was happy to find that workaround, it seems quite confusing to provide a filename hint using a link to a non-existing local file.

As a possible alternative, there's siemens:filename from our Siemens property taxonomy. While it also has problems, e.g. it's defined per-component instead of per-externalReference, I think it's a somehow more natural way to provide filename hints.

So my suggestion would be to extend bom createcomponents --download as well as bom downloadsources to check for the siemens:filename property in the component, with this priority:

1. If there's siemens:filename, it will always win
2. If there's a Content-Disposition header, filename will be taken from there
3. Otherwise, derive filename from last part of download URL.

Other options would be:

• Respect siemens:filename, but with 2, 1, 3 priority (i.e. Content-Disposition wins over siemens:filename
• Ignore siemens:filename and instead just extend bom downloadsources to respect "source archive (local copy)".

@tngraf, any thoughts?

[tngraf]

@gernot-h Well, if I understand you correctly, the second option "Content-Disposition wins over siemens:filename" does not help you.
So lets start with your first option.

[gernot-h]

@gernot-h Well, if I understand you correctly, the second option "Content-Disposition wins over siemens:filename" does not help you.

No, I basically don't care - my problem is that the Go Proxy download server doesn't provide any Content-Disposition header and so CaPyCl falls back to guessing a filename from the URL (which ends in /v1.2.3, so it comes up with v1.2.3.zip, exactly like a browser does it).

So for my use case, both priority orders will work as number 2 is not available.

My question is more: Do we think that the siemens:filename in the SBOM is better (probably because a user deliberately wants to override a server filename hint) - or do we think that siemens:filename might end up in the SBOM without the user noticing it (e.g. from a random Siemens SBOM scanner), so we better go with what the download server suggests.