Dash usage with C++ and versions

[behrisch]

We are currently trying to redo the IP checks for https://github.com/eclipse-sumo/sumo and my goal is to have as little manual work as possible, so I think the dash tool and clearlydefined are the way to go. Currently I am trying to build a dependencies.txt consisting of clearlydefined descriptors only and feed that into dash and encountered some problems on the way.

My question is about version numbers vs tags. Some projects do not tag versions in the format x.y.z. I currently use their tag (or even the commit hash) in the clearlydefined descriptor but now I learned from the docs that the numeric format is preferred by clearlydefined even if it does not refer to a tag. Will there be some automated conversion or does this mean I will need to give the source reference manually? Are hashes better than tags because they unmodifiable? Is there a way to define a source reference in addition to the clearlydefined directly in a text file like the dependencies.txt?

[waynebeaton]

Based on how you've phrased the question, I assume that you're making references to content that is on GitHub.

If you feed a git/github/... id to the Eclipse Dash License Tool it should accept either a tag or a full hash as the revision and do the right thing. If you use a hash as the revision, it probably won't find information on ClearlyDefined, but it will find it in IPLab if it exists and if you use the tool to create a review issue, the scanner will find the source with just that information.

The Eclipse Dash License Tool will accept Package URLs as input, but it doesn't pass the full URL to IPLab. I've been laying some groundwork to enable this, but don't currently have a time frame for completion.

[behrisch]

The content is not only on github, I also have gitlab references and code which just hangs around in zip files on the internet. My current strategy was to use Package URLs in a dependencies.txt with the numeric version format and provide a source link if it cannot be derived trivially, e.g.

pkg:generic/fox@1.6.59?download_url=http://fox-toolkit.org/ftp/fox-1.6.59.zip&checksum=sha256:73d16c2bbd32f432bd6f07212d4eb83cfdb7005e0386640a5996752d1a6e3281
pkg:github/apache/xerces-c@3.3.0?download_url=https://github.com/apache/xerces-c/archive/refs/tags/v3.3.0.zip
pkg:github/osgeo/proj@9.5.0

where the last one does not need a download link because it can be derived trivially.

Would this fit your expectations what dash will accept at least in a future version and generate nice IPLab issues from?

(Strangely enough ClearlyDefined seems to support gitlab while Package URL does not (yet?), so I would probably use only github and generic.)

[waynebeaton]

AFAIK, the specification does not specifically state that download_url points to the source. In fact, I'm pretty sure that you're using it incorrectly in the Apache Xerces example (that is, I believe that download_url should be pointing to the binary JAR in the Maven Central repository).

We may be able to make some good guesses at where the source is based on the repository_url and vcs_url.

[behrisch]

I am not so sure as well. There is only one example for a download url in https://github.com/package-url/purl-spec/blob/main/PURL-TYPES.rst and this points to sources

[waynebeaton]

But that example is for generic which is... well... generic. My interpretation is that example is pointing to a generic artifact that happens to be a source archive. IMHO, we cannot assume general meaning from this example.

[behrisch]

Currently we use only github and generic for sumo so I would be completely fine with guessing the source URL for github (so not allowing my apache example above). But the question remains how to handle generic. I think assuming download_url points to the source is not worse than any other guess

[behrisch]

I added code in #475 which has been used to generate the issues 21485 to 21528 in the iplab from https://github.com/eclipse-sumo/sumo/blob/main/docs/dependencies.txt