analyzer: Fix SPDX metadata to point to a source artifact

[sschuberth]

The "curl-7.70.0.tar.gz" archive contains the source code, so it should
be treated as a source artifact instead of a binary artifact, which is
signalled by setting "filesAnalyzed" to "true".

Also see 15512d3.

Signed-off-by: Sebastian Schuberth sebastian.schuberth@bosch.io

[tsteenbe]

We can't set filesAnalyzed to true as then Package Verification Code becomes mandatory per the spec which is something we don't want as makes creating SPDX package manifest more complicated.

The current definition of "Files Analyzed" has been problematic since I started working on SPDX, hope to drop it from the spec in 3.0.

[sschuberth]

We can't set filesAnalyzed to true as then Package Verification Code becomes mandatory per the spec

Argh. Fortunately, our SPDX reader does not check for that 😁 So maybe we could slightly violate the spec here? Or, maybe we could simply set packageVerificationCode to NONE?

hope to drop it from the spec in 3.0.

How would v3 then distinguish between download URLs of binary vs sources? Ideally, these would just be separate fields (like in ORT 😉 ) so that you can also capture both at the same time.

[sschuberth]

Ping @tsteenbe, mind having another look?

[tsteenbe]

@sschuberth Setting filesAnalyzed to true and not providing Package Verification Code will cause an exception in SPDX reader whilst keeping it false and misusing downloadLocation as source code location will not cause any issues.

[sschuberth]

Setting filesAnalyzed to true and not providing Package Verification Code will cause an exception in SPDX reader

Which reader exactly?

misusing downloadLocation as source code location will not cause any issues.

But we'll also have no man to tell that it is a source location. It will be treated as a binary location instead.

[sschuberth]

Anyway, I've added the packageVerificationCode fields now.

[neubs-bsi]

would it not make sense to have the changes in the same commit, as otherwise there will be a commit which "cause[s] an exception in [the] SPDX reader"

[sschuberth]

would it not make sense to have the changes in the same commit, as otherwise there will be a commit which "cause[s] an exception in [the] SPDX reader"

I didn't want to "mix-in" an otherwise unrelated change to project.spdx.yml, that's why I separated the commits. I'll simply swap the order of the commits to make it impossible to run such an SPDX reader on an invalid file in our Git history.

[tsteenbe]

@sschuberth Adding just packageVerificationCode with filesAnalyzed set to true you also for instance need to add PackageLicenseInfoFromFiles see https://spdx.github.io/spdx-spec/3-package-information/#314-all-licenses-information-from-files

It's a bad idea to set filesAnalyzed to true

[sschuberth]

It's a bad idea to set filesAnalyzed to true

But how can we then distinguish between downloadLocations to source artifacts vs, downloadLocations to binary artifacts?

[tsteenbe]

But how can we then distinguish between downloadLocations to source artifacts vs, downloadLocations to binary artifacts?

A rather simple solution for that would be to require that source artifacts have to use VCS identifiers in the URLs e.g. git+https://git.myproject.org/MyProject.git. I know this does not work for maven source artifacts but for the few exceptions we could build in regexes to detected the edge cases.

[sschuberth]

I know this does not work for maven source artifacts but for the few exceptions we could build in regexes to detected the edge cases.

Unfortunately, it's not only a "few exceptions". We heavily rely on custom SPDX files that refer to source artifacts in ZIP files in arbitrary locations. There's no sane way to deal with these with regexes.

[sschuberth]

@tsteenbe I just checked on this PR again. I'm reading the spec so that for filesAnalyzed == true

• the packageVerificationCode has a cardinality of 0..1
• the packageLicenseInfoFromFiles has a cardinality of 0..*

So as both allow a cardinality of 0, these fields should be optional even with filesAnalyzed == true. Do we agree here?

[sschuberth]

Closing this in favor of the different approach in #4816.