Date: Wed, 24 May 2023 15:41:30 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: Clarification on embargoed testing in a partner cloud On Wed, May 24, 2023 at 10:45:15AM +0200, Moritz Muhlenhoff wrote: > Am Thu, May 11, 2023 at 01:57:04PM +0200 schrieb Marcus Meissner: > > > > I understand that while some of the operators of the public clouds are also on > > the distro lists, these are parts of very large cooperations and not the same > > team as the intake PSIRT subscribed to distros. > > > > So from my point I would suggest to exclude testing on third party public clouds. > > I agree, FWIW. Thank you. So far, we have Marc's request for clarification (which didn't express an opinion/preference) and two "suggest[ions] to exclude testing on third party public clouds" above. I also suggest the same, yet I am not sure whether/how to make that part of the policy. It is non-obvious whether/where/how to draw the line between (disallowed) sharing and mere (allowed) usage of third-party/rented resources. If we explicitly disallow "testing on third party public clouds", then what about testing on rented dedicated servers (which are often also centrally managed through the provider's infrastructure), or on own servers in rented racks in third-party datacenters (where the datacenter staff has physical access), etc. And then there's communication over third-party Internet infrastructure, whereas our policy currently doesn't mandate usage of encryption except for messages from the list to its immediate subscribers. Also, I guess these days there are distros that are primarily built in the cloud yet are not projects of the cloud providers - e.g., projects of startups that got free cloud credits, as well as those that like the flexibility and not needing to manage physical servers themselves. If one of those wants to join the distros list, do we reject them and require that they setup security build/testing, private issue tracking, e-mail infrastructure out of cloud first, or do we accept (if they meet all other criteria)? So far, we didn't even ask new members whether they possibly build/test/track in the cloud, and maybe we already have some that do. On Tue, May 16, 2023 at 09:04:01AM -0400, Marc Deslauriers wrote: > They were requesting we test the default package set that is shipped in > cloud images, including userland packages that don't have anything specific > to their cloud. Of course, testing of kernel and other close-to-hardware updates also benefits from having a userland similar to or the same as what would be used in production. However, maybe the timing of such testing could be dictated by presence of close-to-hardware updates needing the testing. In other words, when there are pending userland updates only, don't do the testing. This is just a suggestion on how to reduce the exposure _if_ any testing in the cloud is to be done at all. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.