stdenv: pURL perl implementation

[h0nIg]

continue perl aspect of #421125

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[h0nIg]

@stigtsp:

An issue with the CPAN pURLs is the inclusion of the (required) author id. Since authors can vary across versions for authorized distributions, this could cause problems with version ranges and mapping to the single affected.packageURL field coming to CVE.

According to cpan-definition.md, the implementation in this PR is correct however.

On CPAN multiple maintainers can have permissions to publish authorized releases for a distribution, for example:

• TIMB published DBI 1.643
• HMBRAND published DBI 1.644

Since the pURL support in the new CVE format seems to only support a single packageURL in the affected section, a correct pURL like pkg:cpan/HMBRAND/DBI would give a false negative for a hypothetical vulnerability that effects versions 1.643 through 1.644.

I think we should wait adding pURLs to perl-packages.nix until this concern has been addressed or resolved in the pURL specification. @pombredanne @sjn

[h0nIg]

@stigtsp:

An issue with the CPAN pURLs is the inclusion of the (required) author id. Since authors can vary across versions for authorized distributions, this could cause problems with version ranges and mapping to the single affected.packageURL field coming to CVE.
According to cpan-definition.md, the implementation in this PR is correct however.
On CPAN multiple maintainers can have permissions to publish authorized releases for a distribution, for example:

• TIMB published DBI 1.643
• HMBRAND published DBI 1.644

Since the pURL support in the new CVE format seems to only support a single packageURL in the affected section, a correct pURL like pkg:cpan/HMBRAND/DBI would give a false negative for a hypothetical vulnerability that effects versions 1.643 through 1.644.
I think we should wait adding pURLs to perl-packages.nix until this concern has been addressed or resolved in the pURL specification. @pombredanne @sjn

your fear is that the lines below the fetchurl may get missed for such a scenario?

what about the following? drv.src.meta may get referenced in the same way as python and others on the main PR? The lines which will get changed are near to each other, but the chance of backport cherry-pick conflicts is higher as well

  ActionCircuitBreaker = buildPerlPackage rec {
    pname = "Action-CircuitBreaker";
    version = "0.1";
    src = fetchurl {
      url = "mirror://cpan/authors/id/H/HA/HANGY/Action-CircuitBreaker-0.1.tar.gz";
      hash = "sha256-P49dcm+uU3qzNuAKaBmuSoWW5MXyQ+dypTbvLrbmBrE=";
      meta = {
        identifiers.purlParts = {
          type = "cpan";
          spec = "HANGY/${pname}@${version}";
        };
      };
    };

What about backporting the stdenv.identifiers check, so we could theoretically backport the identifiers on fetchurl without having them actively accessed? Would you support something?