Your question:
FWIU we currently don't have much of a "security policy" regarding conda-forge packages (xref #830). We have Security Policy covering conda-forge infrastructure and tooling, but for packages we merely say "contact the upstream maintainers directly".
I've attempted to add some basic guidelines in #2801 but this is merely trying to duct-tape on what we have right now, rather than create a new policy.
I think we should consider:
- Providing a dedicated way of reporting security issues against feedstocks, possibly with an option to make the reports non-public (i.e. restricted to maintainers, core, security team?) and with clear guidelines when to use it. While reporting bugs upstream would remain the main venue, downstream reporting would be particularly useful for:
- important bugs that need immediate attention
- bugs in packages that are no longer maintained upstream
- issues introduced specifically due to cf packaging (i.e. not applicable upstream)
- Providing a way to track security issues in packages. Things to consider:
- while CVE/GLSA integration would certainly be useful, we also need to account for security issues that aren't in an "upstream" database (though possibly we could just file CVEs/GLSAs for cf packages then, I guess)
- if we were to go further and enable some kind of security scanning using this data, we'd need to account for the possibility that "fixed" cf versions are different than upstream (e.g. because we backported patches); we also need to account for multiple branches being active
- we certainly need to account that some issues won't be fixed, at least within a reasonable time frame
I'm coming from Gentoo background where we have a dedicated Security team. However, since it's all volunteer-run, we all help out to some degree, and there's no strong "obligation" to handle these issues. I think cf could operate in a similar way, with a focus on improving user experience when you can, without specific obligations.
That said, Gentoo's way of doing things is a bit primitive (but we've been bitten hard by attempts to modernize): we file plain bugs on Gentoo Bugzilla with minimal amount of machine-readability for security issues in package, we manually track their resolution. For significant issues, the Security team issues Gentoo advisories (GLSAs) that are afterwards machine-consumed to warn users about vulnerable versions. However, unlike conda-forge Gentoo normally only offers a narrow range of available versions at a time, so most of the time removing a vulnerable version suffices to stop it from being installed.
Here's an example of a Gentoo security bug covering the full process: adding new version, moving it to stable "channel", removing old and issuing a GLSA: https://bugs.gentoo.org/961498.
Your question:
FWIU we currently don't have much of a "security policy" regarding conda-forge packages (xref #830). We have Security Policy covering conda-forge infrastructure and tooling, but for packages we merely say "contact the upstream maintainers directly".
I've attempted to add some basic guidelines in #2801 but this is merely trying to duct-tape on what we have right now, rather than create a new policy.
I think we should consider:
I'm coming from Gentoo background where we have a dedicated Security team. However, since it's all volunteer-run, we all help out to some degree, and there's no strong "obligation" to handle these issues. I think cf could operate in a similar way, with a focus on improving user experience when you can, without specific obligations.
That said, Gentoo's way of doing things is a bit primitive (but we've been bitten hard by attempts to modernize): we file plain bugs on Gentoo Bugzilla with minimal amount of machine-readability for security issues in package, we manually track their resolution. For significant issues, the Security team issues Gentoo advisories (GLSAs) that are afterwards machine-consumed to warn users about vulnerable versions. However, unlike conda-forge Gentoo normally only offers a narrow range of available versions at a time, so most of the time removing a vulnerable version suffices to stop it from being installed.
Here's an example of a Gentoo security bug covering the full process: adding new version, moving it to stable "channel", removing old and issuing a GLSA: https://bugs.gentoo.org/961498.