Misc charter updates and simplifcations

[sjn]

Please check each commit to see if it's acceptable, before signing off!

Some of these changes may require discussion or revisions!

[timlegge]

Looks good, minor spelling change. Great work

[garu]

great work! we're almost there 🍰
just added some minor questions, mostly to either try and simplify statements or to avoid ambiguity.

[garu]

my understanding is that we now care for both perl itself and core modules, and both are to be treated like any other release on CPAN. Is this mistaken?

[timlegge]

@garu - so yes, I think the discussion was in the context of a CNA however it was decided that perl is simply another dist on CPAN. Really we can treat the same way - if we receive reports we can redirect the reporter to the [email protected] list the same as we would refer them to the module owner. In lieu of that we can contact [email protected] on their behalf

[garu]

I think this can be made clearer by merging both statements together, e.g.:

- CPAN Distributions that embed or use third party (non-CPAN)
 projects or APIs directly, including but not limited to the Alien:: and Net:: namespaces);

[garu]

as it is written, it feels like:

- A;
- ¬A;

so we might as well join them (unless I misread something)

[sjn]

Hm. Yes, this section requires a little more thought.

• The "shims" or "wrappers" terms imply a compilation step, meaning we concern ourselves just with the bits published on CPAN, and not any shared object files they enable the use of in Perl code. (e.g. XS modules wrapping libxml2 or sqlite3);
  • Or do we also concern ourselves with out-of-ecosystem dependencies like these?
• The Alien:: modules are different in the sense that they can (and do) actually download and install their dependencies locally, instead of relying on dependencies that are supplied by a native packaging system.
  • Do we care about Alien modules that may install vulnerable dependencies, even if these are not installed in a system location like /usr/local/lib?
• The second example is about "non-Alien" modules that embed their dependencies. These may include web framworks that contain Javascript code made part and distributed together with the CPAN dist tarball.
  • An example of this may be the bootstrap.js files that come with Mojolicious. If a vulnerability is discovered in a release of bootstrap.js that is embedded with Mojolicious, do we concern ourselves with this?

I think these are distinct enough examples that they are worth listing separately.

[garu]

Quick question: let's say some issue is found on PAUSE or MetaCPAN themselves. Do we create a CPANSec Advisory entry in our feed? Or do we only care about what's uploaded to CPAN? From this statement, I gather it's the former, but I don't think we ever discussed this specifically in terms of creating an advisory. Should we separate our concerns and have advisories only for dists uploaded to CPAN, but "care" and "projects" for the toolchain outside of CPAN?

[garu]

@sjn @stigtsp @timlegge @Tux and everyone else, please chime in!

[timlegge]

@garu There was no discussion of PAUSE or MetaCPAN. I would recommend including them as part of the in scope treated the same way as perl - defer to the PAUSE and MetaCPAN folks if someone reports something to us. Act as the intermediary IF necessary. However, we should ask whether Pause and MetaCPAN are fine with that.

[garu]

@timlegge but specifically in terms of published security advisories, their code is public but hosted outside of CPAN. If someone finds an issue, should we craft an advisory for it as well? My vote is "no", with the reasoning that we should limit our advisories scope only to artifacts published on CPAN (i.e. uploaded through PAUSE, indexed by CPAN, visible on MetaCPAN), so we get a very clearly delimited activity domain and avoid the slippery slope of "how about software X? how about software Y?"

I agree that both PAUSE and MetaCPAN (and others) fall under the "toolchain" that we love and care about, and would of course be part of the "we're open to formal mandates and responsibility requests by their teams" (which is covered elsewhere in the document), my point is just to try and make sure everyone has both a clear understanding of what is and isn't part of the scope, and agrees to it.

What do you think?

[sjn]

The term in question here, is

• CPAN supply chain security, Chain-of-Trust infrastructure, and security around the Perl/CPAN Toolchain, CPAN/MetaCPAN itself and PAUSE

I'm reading this as general and ecosystem-level concerns around these technologies, and not specific vulnerabilities in the projects mentioned.

But I guess we can make this clearer?

As far as I'm concerned, both MetaCPAN and PAUSE have security contact points (though the former's isn't explicitly mentioned), and capable of handling both vulnerabilities, incident response and managing other security issues directly affecting their projects.

If they want us to be involved in these aspects, I think it's completely fair for us to step up and help if we can, but I don't think we should unilaterally take upon ourselves any responsibilities like these.

[sjn]

Is this clearer?

Overarching CPAN ecosystem and supply chain security, like the establishing of chain-of-trust infrastructure, or other efforts to improve general security, possibly involving the Perl/CPAN Toolchain, CPAN/MetaCPAN itself and PAUSE.

[timlegge]

@timlegge but specifically in terms of published security advisories, their code is public but hosted outside of CPAN. If someone finds an issue, should we craft an advisory for it as well? My vote is "no", with the

No would be my vote as well. I suspect it is our interest to be aware of vulnerabilities disclosed there though and as responsible people we would pass along issue we hear about but we have no responsibility there.

reasoning that we should limit our advisories scope only to artifacts published on CPAN (i.e. uploaded through PAUSE, indexed by CPAN, visible on MetaCPAN), so we get a very clearly delimited activity domain and avoid the slippery slope of "how about software X? how about software Y?"

Yes, I occasionally work on a plugin for Foswiki (a perl based wiki) we have no responsibility to it for example. I may hear of issues and make others aware but not necessarily as a CPANSec member.

I agree that both PAUSE and MetaCPAN (and others) fall under the "toolchain" that we love and care about, and would of course be part of the "we're open to formal mandates and responsibility requests by their teams" (which is covered elsewhere in the document), my point is just to try and make sure everyone has both a clear understanding of what is and isn't part of the scope, and agrees to it.

Agreed

[garu]

do we have "tooling for warning about upstream vulnerabilities" in place? Or this is resolved some other way? If we're just dropping that rationale, we need to be clear in terms of boundary/scope, since the dist itself is not vulnerable, but the code that it links could be.

[timlegge]

@garu my thought is that we are only concerned with what is delivered in the CPAN distribution. If the module itself (xs code) has vulnerabilities that is in scope.

If the CPAN distribution includes the vulnerable library (IO::Compress::Brotli) or downloads and builds a library as part of the install (Math::Pari) that is in scope.

If a user links to a vulnerable library on their system (whether distro delivered or downloaded by the user) that is not in scope.

[garu]

@garu

1. the Image-Magick distribution on CPAN. It looks for the ImageMagick library and headers already on the user's system, builds itself and uses XS code to talk to it. If that lib is vulnerable, it would fall under the _"if a user links to a vulnerable lib, it's not in scope" _ so we wouldn't worry about it, wouldn't publish advisories, nothing. Ok.

That makes sense.

2. The Alien::ImageMagick (BLESS THEM) dist is a helper that downloads and installs the ImageMagick library and headers for you, then builds PerlMagick (which is a copy of the Image-Magick dist above but bundled in the ImageMagick tarball). It falls under the "if the dist downloads and builds a lib, it's in scope", so any vulnerability in ImageMagick would have to be associated to Alien::ImageMagick and we would need to publish an advisory for it. There is a catch, though: Alien::ImageMagick, by default, always downloads and builds the latest version available on the ImageMagick website. So it would be vulnerable only if you have installed ImageMagick before the date that the patched version was made available. That is, unless you have set the PERL_ALIEN_IMAGEMAGICK_VERSION env var to force a specific version of ImageMagick during Alien::ImageMagick's installation, in which case your install may or may not be vulnerable. How would we decide what to report here? Whatever we decide, how do we justify our decision?

Because it defaults to the latest version and the user must override that it is out of scope for us. The user has made a conscious decision to compile against "external" code. The same can be said of Crypt::OpenSSL::RSA compiling against what ever SSL version is installed. - Not our concern.

However if the module specifically sets a version of the library to download and that version is vulnerable that is our concern. It should be reported to us, a CVE created and if possible the author should fix it.

Take CVE-2024-21646 for example. It says "Azure uAMQP is a general purpose C library for AMQP 1.0. The UAMQP library is used by several clients to implement AMQP protocol communication. When clients using this library receive a crafted binary type data, an integer overflow or wraparound or memory safety issue can occur and may cause remote code execution. This vulnerability has been patched in release 2024-01-01.". Ok. Are any CPAN distributions affected by this? How can we tell one way or the other? Can we replicate that workflow for each and every new CVE that comes out?

The real question is are we responsible for the vulnerabilities that are reported to us/publicly known, etc. or all possible vulnerabilities. For workload and sanity I vote for the former. If a tree falls in the forest is it a vulnerability? :-) While we may be able to grep cpan looking for UAMQP being used that may be something for future scope. We would need to not only identify the issue but determine whether an unfamiliar module uses the vulnerable code paths. More than expected at this point I think

I understand (and agree) that if a module comes bundled with or downloads a specifically vulnerable version, then we may want to file an advisory for it, yes. But it will be super hard to achieve, because we have no control over what goes on CPAN, nor do we have the proper tooling to identify whether a dist downloads/builds/uses third-party code (or how it uses it).

Again, it needs to be reported to us or become known to us to require us to act. If we eventually get the tooling in place and it finds issues then we need to act. Otherwise it depends on someone reporting it.

[sjn]

Still, I have trouble imagining how this would translate in our workflow.

This could be handled if we had a way for CPAN distributions to specify out-of-ecosystem dependencies and their resolution, in a standardized way. Luckily, this can be achieved by introducing support for PackageURLs in the toolchain, which is something that is an ongoing discussion here and here.

Because I don't have an answer for those questions, my vote would be we place them out of scope, at least for now.

I agree.

[timlegge]

Still, I have trouble imagining how this would translate in our workflow.

This could be handled if we had a way for CPAN distributions to specify out-of-ecosystem dependencies and their resolution, in a standardized way. Luckily, this can be achieved by introducing support for PackageURLs in the toolchain, which is something that is an ongoing discussion here and here.

Because I don't have an answer for those questions, my vote would be we place them out of scope, at least for now.

I agree.

I agree - we don't have the resources to proactively look for issues. But if an issue is reported to us and it is caused by a decision the module author made (specific library versions) then it is in our scope

[garu]

This feels in conflict with CPAN supply chain security, Chain-of-Trust infrastructure, and security around the Perl/CPAN Toolchain, CPAN/MetaCPAN itself and PAUSE; (listed as in-scope)

[garu]

I understand it could be the exception, but if so then there might be other exceptions (like PAUSE code)

[sjn]

Does my proposed change above make this clearer?

[garu]

I don't think that should automatically exempt Mozilla::CA from it. In my mind, it is just another CPAN dist, one that happens to be semi-automatically updated and thus gives us very little worries. But if this changes for whatever reason, I don't think we should have to update our charter.

[timlegge]

+1 I think if its delivered on CPAN its in scope

[sjn]

I think @stigtsp should chime in here, as he had some good arguments regarding this.

[stigtsp]

I agree that vulnerabilities in Mozilla::CA is in our scope, similar to other dists on CPAN.

The updating of certs from mozilla nss is managed by the libwww-perl team though.

(On a sidenote, I hope the module becomes obsolete in favor of system certs soon. HTTP::Tiny's default usage of it can be a problem if users have an outdated version of Mozilla::CA in their @INC)

[garu]

Cool. The point I guess is that, although it is good that we know what Mozilla::CA is and what it does, we shouldn't think of it as any different from any other dist on CPAN, just like Net::SSLeay, IO::Socket::SSL, Digest::SHA, Crypt::CBC or any other, therefore it shouldn't be listed/acknowledged in our charter.

[garu]

I think we can be more generic here and simply say "handled by the PAUSE team"

[garu]

Also, it triggers the same "maybe in conflict with in-scope clause" as MetaCPAN.

[timlegge]

We did not really talk to the PAUSE team potential for inclusion in CPANSec scope. As part of the supply chain it is very much in scope though.

[sjn]

I still think it's fair to let the PAUSE folks decide if they want us to care, and to what extent. Let's not make a unilateral decision here. They already exist and handle security issues, and if they want to coordinate or need help, I think we'll still be around to have that conversation 😄

[timlegge]

My very much in scope is around the supply chain and how we might be able to influence improvements - such as SBOM creation etc.

[stigtsp]

My interpretation of this is:

• The opsec of the PAUSE platform is handled by the PAUSE admins
• Since parts of PAUSE is also a distributions on CPAN, vulnerabilities in PAUSE components that are on CPAN is in our scope
• Facilitating security improvements in the CPAN supply chain is within our scope

(Edit: Made more clear that all of PAUSE is unlikely to be on CPAN, and that our scope is only what's on CPAN)

[garu]

So maybe we should just have "Facilitating security improvements in the CPAN supply chain", drop all mentions to PAUSE & friends and add a specific entry stating something like "issues related to accounts or services provided by the supply chain (e.g. PAUSE, MetaCPAN, NOC, CPANTesters, etc) are out of scope and handled by their own teams, unless specifically mentioned otherwise"

Would that make sense?

[garu]

does that mean we must update the charter if we ever get a formal mandate to do something?

[timlegge]

One of the things here I wonder is if anyone ever received a formal mandate for anything. I suppose Larry may have approved some things but I get the feeling many things happened because some one showed up to do it.

[garu]

I guess it depends on one's definition of "formal". I'm ok with defining formal as "the current project's leadership placed their intent in writing", either via email or meetup or chat or whatever. So if, say, the PSC asks us in writing to handle X, it would be a "formal mandate".

Is that what you meant, @sjn ?

[sjn]

For me, a "formal mandate" is achieved when…

• One organization publicly gives a responsibility/mandate to another organization,
• …and the receiving organization publicly accepts this responsibility/mandate,
  • …with the implication that this responsibility/mandate can be withdrawn by the organization giving it, if they deem it necessary.

For me, "publicly give" or "publicly accept" implies some sort of public record being used, e.g. a weekly report mail, or some meeting minutes where a vote was successfully conducted on the matter.

[garu]

@sjn should we have to update our charter if we ever receive formal mandates?

[garu]

Couldn't we make this simpler/clearer by just saying that "...this group may withdraw their formal mandate at any time and for any reason"?

[timlegge]

As I think of it I am not sure we even need to speculate on why a group which has not granted formal mandate might withdraw that mandate. We should simply act within any granted formal mandate. If it is revoked we no longer have that mandate so we should not act as if we do have that formal mandate.

However, the lack of a formal mandate or a revoked mandate does not imply that we stop acting on things. We just cannot imply that we have the mandate to act. We can still act as we see fit within the scope of our charter.

[garu]

I agree. I guess it is here just to make it super clear that CPANSec doesn't take ownership on anything that it hasn't created itself, and that while toolchain groups may ask us to handle some things for them, they are (obviously) free to take it back from us and we should update our documents so people outside those projects are made aware.

[sjn]

I agree. I guess it is here just to make it super clear that CPANSec doesn't take ownership on anything that it hasn't created itself, and that while toolchain groups may ask us to handle some things for them, they are (obviously) free to take it back from us and we should update our documents so people outside those projects are made aware.

Spot on.

I've also added this language to function as an example for other communities to adopt, in order to make relationships, mandates, lines of communication and such explicit. And by explicitly adding the "withdraw" language, to communicate a create clearly where the accountability lies.

[timlegge]

Added some comments

[timlegge]

+1 I think if its delivered on CPAN its in scope

[timlegge]

We did not really talk to the PAUSE team potential for inclusion in CPANSec scope. As part of the supply chain it is very much in scope though.

[timlegge]

One of the things here I wonder is if anyone ever received a formal mandate for anything. I suppose Larry may have approved some things but I get the feeling many things happened because some one showed up to do it.

[timlegge]

As I think of it I am not sure we even need to speculate on why a group which has not granted formal mandate might withdraw that mandate. We should simply act within any granted formal mandate. If it is revoked we no longer have that mandate so we should not act as if we do have that formal mandate.

However, the lack of a formal mandate or a revoked mandate does not imply that we stop acting on things. We just cannot imply that we have the mandate to act. We can still act as we see fit within the scope of our charter.

[timlegge]

Comments

[timlegge]

@timlegge but specifically in terms of published security advisories, their code is public but hosted outside of CPAN. If someone finds an issue, should we craft an advisory for it as well? My vote is "no", with the

No would be my vote as well. I suspect it is our interest to be aware of vulnerabilities disclosed there though and as responsible people we would pass along issue we hear about but we have no responsibility there.

reasoning that we should limit our advisories scope only to artifacts published on CPAN (i.e. uploaded through PAUSE, indexed by CPAN, visible on MetaCPAN), so we get a very clearly delimited activity domain and avoid the slippery slope of "how about software X? how about software Y?"

Yes, I occasionally work on a plugin for Foswiki (a perl based wiki) we have no responsibility to it for example. I may hear of issues and make others aware but not necessarily as a CPANSec member.

I agree that both PAUSE and MetaCPAN (and others) fall under the "toolchain" that we love and care about, and would of course be part of the "we're open to formal mandates and responsibility requests by their teams" (which is covered elsewhere in the document), my point is just to try and make sure everyone has both a clear understanding of what is and isn't part of the scope, and agrees to it.

Agreed

[timlegge]

Still, I have trouble imagining how this would translate in our workflow.

This could be handled if we had a way for CPAN distributions to specify out-of-ecosystem dependencies and their resolution, in a standardized way. Luckily, this can be achieved by introducing support for PackageURLs in the toolchain, which is something that is an ongoing discussion here and here.

Because I don't have an answer for those questions, my vote would be we place them out of scope, at least for now.

I agree.

I agree - we don't have the resources to proactively look for issues. But if an issue is reported to us and it is caused by a decision the module author made (specific library versions) then it is in our scope

[timlegge]

My very much in scope is around the supply chain and how we might be able to influence improvements - such as SBOM creation etc.