Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misc charter updates and simplifcations #66

Open
wants to merge 19 commits into
base: main
Choose a base branch
from
Open

Misc charter updates and simplifcations #66

Changes from all commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
17ccff5
Add name to charter
sjn Jan 19, 2024
a9bf513
Charter cleanup for v0.6.7
Feb 22, 2024
7a8487b
Merge branch 'main' into charter-v0.6.7
Feb 22, 2024
cf9de32
Remove TODO items; Minor language changes (by garu)
Feb 22, 2024
6e3a5d9
Refer to public contact points for joining CPANSec. Move website link…
Feb 22, 2024
faff480
Typo fixes, add license
Apr 8, 2024
0c28e8e
Merge branch 'main' into charter
Apr 8, 2024
3f56075
Add github contribution link
sjn May 14, 2024
2e1e755
Out of scope: All security issues regarding PAUSE
sjn May 14, 2024
b6c4e79
In scope: XS modules
sjn May 14, 2024
b96d862
In scope: CPAN Distributions that are pure wrappers around compiled l…
sjn May 14, 2024
b8b6572
In scope: The Alien:: distribution namespace
sjn May 14, 2024
45072d3
In scope: Mozilla::CA
sjn May 14, 2024
64e8e31
Out of scope: MetaCPAN
sjn May 14, 2024
f73d81c
Replace Projects section with a link to github
sjn May 14, 2024
135806b
Simplify Responsibilities and Mandates section
sjn May 14, 2024
9ed3fa4
Out of scope: Mozilla::CA
sjn May 15, 2024
3da6a65
Typo fixes
sjn May 15, 2024
3bfaedc
Merge branch 'main' into charter
sjn Aug 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 30 additions & 48 deletions docs/charter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,18 +10,20 @@ toc: true
What you see here is a **DRAFT** for the charter of a CPAN Security Group (_CPANSec_).
Until published by a founding member, all of the points and ideas below are *suggested*, and open to revision, deletion or amending.

Discussion on IRC: [ircs://ssl.irc.perl.org:7062/#cpan-security](ircs://ssl.irc.perl.org:7062/#cpan-security)
* Contribute on Github: [https://github.com/CPAN-Security/security.metacpan.org/blob/charter/docs/charter.md](https://github.com/CPAN-Security/security.metacpan.org/blob/charter/docs/charter.md)
* Discussion on IRC: [ircs://ssl.irc.perl.org:7062/#cpan-security](ircs://ssl.irc.perl.org:7062/#cpan-security)
sjn marked this conversation as resolved.
Show resolved Hide resolved


## Purpose

This charter lays out the background, intentions, mandate, scope, means and methods for the CPAN Security Group (CPANSec).
This charter lays out the background, intentions, mandate, scope, means and methods for the CPAN Security Group.
This document also explicitly acknowledges a few related organizations and communities, and spell out responsibility demarcation lines between these, if any.


## Name

The full name of the group is **CPAN Security Group**. Valid abbreviations are **CPANSec**.
The full name of the group is **CPAN Security Group**.
Valid abbreviations are **CPANSec**.


## Background
Expand Down Expand Up @@ -62,6 +64,10 @@ The _CPANSec_ intends to be a forum for coordinating and assisting in resolving
The _CPANSec_ concerns itself with a limited domain:

- Distributions published on CPAN, not including dual-life core modules;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

- CPAN distributions that function as shims (wrappers) for non-CPAN projects or resources. Examples:
- CPAN Distributions that are pure wrappers around compiled libraries (e.g. XS modules wrapping `libxml2` or `sqlite3`);
- CPAN Distributions (outside the `Alien::` namespace) that embed or use third-party (non-CPAN) projects or APIs directly;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as it is written, it feels like:

- A;
- ¬A;

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- The `Alien::` distribution namespace;
- CPAN supply chain security, Chain-of-Trust infrastructure, and security around the Perl/CPAN Toolchain, CPAN/MetaCPAN itself and PAUSE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

- CPAN distribution metadata and how these are communicated;
- Emergency security updates on CPAN;
Expand All @@ -76,21 +82,16 @@ For details, please consult the [Projects](#projects) list below.
- The perl interpreter itself
- Perl Core modules managed by <[email protected]>
- Supply-chain issues that are found outside of CPAN, for example:
- Downstream security issues related to repackaging or patching of CPAN distros by third party packaging system (e.g. Debian's apt, Redhat's rpm, etc).
- Downstream security issues related to repackaging or patching of CPAN distros by third party packaging system (e.g. Debian's apt, RedHat's rpm, etc).
- Third party libraries, files and services linked to or used by CPAN distributions (unless the library is packaged with the affected CPAN distribution);
- ~~CPAN distributions that function as shims (wrappers) for non-CPAN projects or resources.~~ Examples:
- ~~CPAN Distributions that are pure wrappers around compiled libraries (e.g. XS modules wrapping `libxml2` or `sqlite3`)~~
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

@garu garu May 18, 2024 •
edited by timlegge
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

  1. 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- **Rationale**: XS modules are _in scope_ until tooling for warning about upstream vulnerabilities is in place. (sjn)
- ~~CPAN Distributions (outside the `Alien::` namespace) that embed or use third-party (non-CPAN) projects or APIs directly.~~
- **Rationale**: Shims/wrappers/API modules on CPAN are _in scope_, but we cannot address issues related to the third-party (external) libraries or APIs they link to or use. So for example if `XML::LibXML` contains a vulnerability, it's in scope, but if libxml2 (which it links to) has a vulnerability, we have nothing to do with it, as it is not directly related to code *on* CPAN. (garu)
- ~~The `Alien::` distribution namespace~~
- **Rationale**: `Alien::` distributions are _in scope_ until tooling for warning about upstream vulnerabilities is in place. (stigo)
- ~~Mozilla::CA~~
- **Rationale**: `Mozilla::CA` is _in scope_ until the module is either phased out/deprecated or kept automatically in sync with upstream CA. (stigo); Furthermore, Mozilla::CA is apparently about to be auto-updated sometime soon?
- MetaCPAN
- **FIXME**: Offloading management of MetaCPAN security issues depends on getting an agreement with the MetaCPAN folks, which we don't have as of 2023-06-17. Also - is this necessary and desirable? Please share why we should (not) do this.
- Perl software published outside of CPAN (e.g. Github download links, or with private hosting).
- …
- Handled by the MetaCPAN team.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does my proposed change above make this clearer?

- Mozilla::CA
- Handled by the libwww-perl team, and semi-automatically updated.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- Perl software published outside of CPAN (e.g. via Github download links, or with private hosting).
- Security issues handled by <pause-admin@perl.org>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@stigtsp stigtsp May 20, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

- Compromised PAUSE accounts
- All other security issues regarding PAUSE


### Relations with CPAN Authors and Distributions
Expand All @@ -114,13 +115,12 @@ If you represent the management or legal department at your business and/or need

## Responsibilities and Mandates

While the _CPANSec_ has no formal mandate or responsibilities, it may still seek and accept public statements of support or acknowledgement from the following relevant community stakeholders.
In addition, the _CPANSec_ may ask for formal mandates from _delegating authorities_ (DA):
While the _CPANSec_ has no formal mandate or responsibilities, it may still seek and accept public statements of support, acknowledgement or formal mandates from the following relevant community stakeholders.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


- The Perl Steering Council (DA)
- The PAUSE team (DA)
- The MetaCPAN team (DA)
- The Perl Security list (DA)
- The Perl Steering Council
- The PAUSE team
- The MetaCPAN team
- The Perl Security list
- Perl NOC
- The Perl Modules list
- The CPAN Workers list
Expand All @@ -131,9 +131,9 @@ Public statements of support should not be considered more than an acknowledgmen

Formal mandates, on the other hand are intended to establish clear lines of responsibility and accountability, and with this, function as meaningful steps to establish legitimacy.

If the _CPANSec_ asks for a formal mandate from a delegating authority (DA), the _CPANSec_ members acknowledge that delegating authority may withdraw their mandate at any time if they decide the _CPANSec_ is incapable or unwilling to fulfil its mandate, or in case the CPANSec decides to delegate any received responsibilities to a third party.
If the _CPANSec_ receives _and accepts_ a formal mandate from a community stakeholder group, the _CPANSec_ members acknowledge that this group may withdraw their formal mandate at any time if they decide that _CPANSec_ is incapable or unwilling to fulfill this mandate, or in case the _CPANSec_ decides to delegate any received responsibilities to a third party.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@sjn sjn May 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


In the unfortunate situation when a delegating authority is disbanded, becomes unresponsive, or transfers/loses its authority to delegate responsibilities to us, the CPANSec members may ask for a formal mandate from a replacing authority.
In the unfortunate situation when a stakeholder group _CPANSec_ has received a mandate from is disbanded, becomes unresponsive, or transfers it's responsibilities to a third party, the _CPANSec_ members may ask for a formal mandate from a replacing community stakeholder group.


### Formal Mandates
Expand All @@ -150,32 +150,13 @@ This means that the products of our work should be considered _best effort_, and

### Joining the _CPANSec_

The _CPANSec_ forum itself is moderated and for invited volunteers. To join, please reach out through one of our [public contact points](#public-contact-points).
The _CPANSec_ has several forums, but the ones that manage embargoed information is moderated and for invited volunteers.
To join, please reach out through one of the _CPANSec_ [public contact points](#public-contact-points).


### Projects

- [Artifact Transparency Logs](https://github.com/orgs/CPAN-Security/projects/2)
- Introduce sigstore or sigsum to CPAN, possibly based on guidelines from [transparency.dev](https://transparency.dev)
- [Provenance and Supply Chain Security](https://github.com/orgs/CPAN-Security/projects/3)
- Introduce tooling and infrastructure for establishing provenance, chain-of-trust and chain-of-custody
- Introduce tooling for downstream verification of provenance, chain-of-trust and chain-of-custody
- [Metadata and Software Bill of Materials](https://github.com/orgs/CPAN-Security/projects/1)
- Tooling for the creation and verification of SBOM objects commonly used to communicate the composition and pedigree of CPAN dependencies, even when these dependencies cross ecosystem boundaries.
- Update CPAN package metadata to enable end-users to comply with legislative obligations.
- [Vulnerability Index](https://github.com/orgs/CPAN-Security/projects/10)
- Standardization and publishing of CPAN package vulnerabilities in relevant indexes (our own, CPANSA, CVE or whatever), to ensure that common (including third-party) tooling for Software Composition Analysis or vulnerability assessment work with CPAN dependencies.
- [Software Composition Analysis](https://github.com/orgs/CPAN-Security/projects/6)
- Improve or create user-interfacing tooling used for analyzing dependencies for known vulnerabilities.
- [Security Patch Tooling](https://github.com/orgs/CPAN-Security/projects/11)
- Develop tooling for publishing and applying third-party security patches to CPAN distributions that have non-responsive authors, to enable high-priority updates to CPAN packages.
- Explore opportunities for simplifying downstream fixes to reach upstream authors.
- [Security Outreach & Information](https://github.com/orgs/CPAN-Security/projects/12)
- Establish a website and social media presence for outreach and information sharing, and keep these up to date.
- [CPANSec Governance, Policy & Funding](https://github.com/orgs/CPAN-Security/projects/7)
- Establish procedures for responsible disclosure, communication and other related mechanisms, including documentation on how vulnerabilities and malicious code incidents are handled.
- Create a group charter and accountability procedures.
- Raise funds for CPAN Security Group projects.
For an up-to-date list of projects, please consult the _CPANSec_ [Projects page](https://github.com/orgs/CPAN-Security/projects) on Github.


### Public contact points
Expand Down Expand Up @@ -224,6 +205,7 @@ From left to right,
- …


## Version
## About this document

v0.6.7
Version: v0.7.0
License: CC-BY-SA-4.0