Closed garu closed 1 year ago
One addition; A topic we talked about at the PTS was about establishing a CPAN security group. At the moment, this is still a work in progress (currently awaiting the Perl NOC folks). In this spirit, maybe we could also consider gathering resources like these under a such an umbrella on github?
@sjn that's good and interesting.
(^former^ security person here (one can't actually just leave security anymore than one can just walk into Mordor), not quite fully retired from working in Perl.)
If you'd like to take over the repo and CPAN::Audit, let me know. I'm not interested in doing more than what I'm already doing.
On Sun, May 28, 2023 at 9:26 AM brian d foy wrote:
If you'd like to take over the repo and CPAN::Audit, let me know.
Having the primary repo and primary CPAN maintainer on an institutional account makes procedural and reputational sense to me, especially if endorsed by and outputs integrated into .cpan. . (I say this while having a current consulting client using CPAN::Audit to appease their auditors. A change in nothing but credibility is a positive change.)
(The naturally distributed nature of Git makes it less critical wrtp Bus Factor than other sorts of resources, but it's still cleaner; easier to reverse upstream/origin sooner rather than later.)
I'm not interested in doing more than what I'm already doing.
I would hope that hypothetically bringing this valuable effort under CPAN formally could lower the burden on bdf while keeping his experience and wisdom involved.
My prior offer (to bdf) as a semi-retired, ^former^ security person, CPAN author, etc, to assist CPANSA in triaging CVE/NVD entries would be transferable to a larger CPAN Security effort. (Glad to see the RSS shows "no new Perl CVEs for Mon May 29") (Former in ^air quotes^ because once one starts thinking security, it's impossible to stop!)
-- Bill Ricker @. aka @. https://www.linkedin.com/in/n1vux
@briandfoy, assuming you're fine with it, are there any specific steps or actions you'd like to see happen before the CPAN Security folks formally take over CPAN::Audit? :slightly_smiling_face:
BTW, there's also the option for us to join forces, of course. It's very much up to you. Personally, I'd love to have you an active part of this effort.
But if that's not in the cards, we'll definitely make an effort to continue managing the repo responsibly.
@sjn I'd like to be part of the effort
@sjn I'd like to be part of the effort
Awesome! Check out https://security.metacpan.org and join us in the #cpan-security IRC channel on irc.perl.org. Lots of stuff is still a work-in-progress (or being bootstrapped), so your tuits are extremely welcome! :grin:
Hi brian!
As we started working on several metacpan related security/advisory reporting tools during the toolchain summit, we came up with a small roadmap that I would like to share with you, and get your feedback on how (if at all)
cpan-security-advisory
should fit in.We have 1 main objective, which is to have a single repository (or folder inside a repository) containing only security advisories related to distributions that are or were on CPAN (meaning, available on either metacpan or backpan).
In order to be able to use this to populate third party initiatives like the GIthub Security Advisory and metacpan.org itself, it would also need to be stored in (or translated to) a common "immutable" schema, and the OSV Schema seems like the one most package manager ecosystems agree on. Data should also be licensed CC-BY-4.0 (attribution) or CC0 (public domain).
Finally, so interested parties can perceive it as something "official" to that particular package manager, or at least maintained/cared for by the same people that work on the associated package manager, the repository consumed by those external tools needs to sit under the package manager organization, meaning the consumed repo would be on "metacpan/", not "briandfoy/" (even if the one under "metacpan/" is just a clone).
Is this something you see as the future of "cpan-security-advisory" itself? Or do you think it should be something separate that could consume data from this repository but be its own independent thing?
We don't want to duplicate our efforts, and even if you rather we do this as a separate repository under metacpan, I would very much like to add you as a contributor with write access, if this is something that interests you directly.
Thanks! Hope to hear from you soon!