[contrib] Add versions to SDPX file.

[evetion]

This PR tries to find versions for both the deps and stdlibs used in the Julia build process and updates the SDPX file.

It seems the SDPX file hasn't been fully updated since Julia 1.9, but has seen incremental updates when new dependencies were added. Nonetheless, given stricter security laws/automated vulnerability scanning it is essential to know which version of dependencies are built/ship with a Julia release.

@mbauman Given his current security work
@SamuraiAku Given that he contributed the files in the first place

[mbauman]

Nice! This seems quite valuable; thank you.

I am a little concerned about putting the version numbers in here, however. Right now, as this file goes stale, it simply becomes less complete. With the (optional) version numbers included, it means that the stale file has wrong data.

I think we may be better situated to track these things externally — perhaps in https://github.com/JuliaRegistries/GeneralMetadata.jl, which is still very new and still very much a work in progress. Note that julia itself is a registered name in the General registry (as are many stdlibs). Doing this externally also makes it much easier to retrospectively populate this data for older Julia versions.

[vtjnash]

Adding them via a script seems fine, since this script is part of the steps of make release-candidate checklist of requirements

[SamuraiAku]

An issue is that this script is not being run regularly. If it had, the version of Julia in the SPDX file would not have been 1.9.0 prior to this update.

[DilumAluthge]

Why don't we go with Matt's suggestion for now (external metadata repo), and then we can re-evaluate later?

[evetion]

I am a little concerned about putting the version numbers in here, however. Right now, as this file goes stale, it simply becomes less complete. With the (optional) version numbers included, it means that the stale file has wrong data.

I understand where you're coming from, but a stale dependency (removed in practice) will also count as wrong data. I think completing the version numbers here is a net improvement in practice.

That said, this script should be run more often, which should be its own issue. We could automate this by a Github workflow/check when .version files are touched?

Doing this externally also makes it much easier to retrospectively populate this data for older Julia versions.

Yes, this PR can work for all future versions, but past releases are problematic. I'm looking forward to having this externally, but I'm unsure about the timeline there? Otherwise this could be an improvement until the external service is available (e.g. perfect can be the enemy of good).