How do we track Perl modules with embedded dependencies by git commit instead of version

[robrwo]

There are some Perl modules like CryptX or DBD::SQLite that track their embedded dependencies by git commit id instead of version. (In part because these projects will go for a long time merging commits into the development branch before tagging another release.)

[briandfoy]

We can add a git commit ID, but there will be not be an easy way to know if the local version is in a range.

However, for external libraries, all we really care about is the Perl distribution version. The affected modules either have an affected embedded library or they don't. If they have an affected version, even between official releases, it can be listed under perl_distributions with the affected versions. Perhaps add a commit id past that version that's still in the source:

perl_distributions:
- affected:
  - distributed_library_version: '1.18.2'
    commit_id: abcdef...
    perl_module_versions: '>=0.14'
  name: Net-Dropbear

[stigtsp]

What we do in nixpkgs for example, when pinning on a particular commit, is that we use the commit date as a version. For example like 1.0-unstable-2025-01-01, maybe something like this could work?

[briandfoy]

I don't think a date would work since it doesn't mark the specific version necessarily. The date should still be the one in the source, and we can use another field to note that it's a version patched beyond the official release.

[briandfoy]

How about this? patched is a simple flag. patched_commit_id has the value if we know what it is. patch_details is the slop for everything else that doesn't fit into that. We signal that this version fixes a noted security report with the list in patched_fixes. All of these are optional fields.

perl_distributions:
- affected:
  - distributed_library_version: '1.18.2'
     patched: ...    # (true | false | nil )
     patched_fixes: 
         - <id>
         - <id>
         - ....
     patch_commit_id: .... # <commit_id | nil> (optional field)
     patch_details:  <free form text> 
    perl_module_versions: '>=0.14'
  name: Net-Dropbear
```

[robrwo]

That looks good. I will need to update the data to see how well it works.

There will be multiple affected rows with the same distributed_library_version but different patch_commit_ids. Will that be alright?

Also note that some modules (CryptX) have not always documented what commit id they have used. So that will have to be omitted.

[briandfoy]

Make the change and we'll see how it looks. If I understand what you are saying, I don't think there's a way around that because we have to identify different distributions/inclusions of the same library.

[briandfoy]

I've had this notion that I can't make go away, but it's probably a bit of work. I should probably give myself a thumbs down for this, but I want to record what I've been thinking the last couple of days. Normally bad ideas go away on their own, but not this time.

For some things, we might want to get rid of numerical comparison altogether. We simply order all of the versions in an array, and the position in the array determines if one version is after or before.

But then, how does this handle a situation where a project uses a particular unreleased commit that then does not make it into the next official release. Suppose that commit was backed out? Now we have a tree instead of an array.

Surely part of the problem is that we are trying to associate vulnerabilities to versions, instead of taking a version and listing all its vulnerabilities directly. Maybe if we had a way to note "not affected by" this would be easier.

So, imagine cpansa/CPANSA-Foo.yml has some special version 1.23 that would otherwise be reported as affected by CVE-2025-1234, but for whatever reason we know it is not.

---
advisories:
- affected_versions:
...
adjustments:
  - version: 1.23
     ignore:
       - CVE-2025-1234

That's a terrible way to do that, especially when we are mixing in reports from other files. But, also, maybe it's something we apply post-search. Here's a list of vulnerabilities we think we should report, we know the installed or requested module version, and we have a list of filters that say exclude this report. But then, that version is going to end up being a range of versions too.

[briandfoy]

Also, I think I'd like to move this to discussions or wiki. I like to reserve issues for actionable things. Anyone object?