[Note: I'm not authorized to speak "on behalf of" my employer, but this represents (to the best of my knowledge) our current plans and goals]
Please maintain the CC list, all of us here at eXMeritus are interested in comments and advice. Thanks for your detailed comments! I'm very optimistic that we'll be able to work out a long-term solution that keeps us as close to upstream (in this case Debian) as possible. I've added further commentary below. On 2010/03/23 17:02, "Moritz Muehlenhoff" <j...@debian.org> wrote: > On Tue, Mar 23, 2010 at 01:04:04PM -0500, Moffett, Kyle D wrote: >> This would be wonderful from the official-Debian-port side of things, but we >> would still like to get our company into the security process. If at all >> possible, we would like to be able to participate in the Debian security >> release process enough to identify which security updates pertain to our >> specific configurations and provide our clients with release-day updates. >> >> Specifically, we are going to be distributing a derivative/fork of Debian >> that has been patched-and-hardened for our specific use-case (as a network >> security appliance on aircraft). We certainly plan to collaborate with the >> general Debian (and other open-source) communities as we build this product, >> including releasing all the open-source debs and source packages. On the >> other hand, the very strictly locked-down and feature-neutered environment >> that actually gets installed on the aircraft will be unlikely to be >> interesting on general-purpose servers or desktops. >> >> If you have any suggestions or comments, I am very interested to hear them. > > I think we rather need to analyse this the other way round: What specific > part of the "life cycle" of a security issue are you interested in and in > what way do you want to want to be involved in the process? > > The general life cycle looks roughly like this: [snip] > For a limited subset of vulnerabilities the initial report information is > brought to our attention by other distributions through a cross-distribution > mailing list called vendor-sec. In that case we cannot disclose the > information > prior to the release of the updated package. This is something we're not fond > of, but which is an unpleasant fact of reality. Fortunately vendor-sec is > less important these days in comparison to the situation some years ago, since > a lot of discussion has been shifted to the oss-security mailing list. The vendor-sec coordinated-disclosure nonsense is my major concern. We are already subscribed appropriately to the DSA mailing lists, and we will set up an automatic internal notification that polls the debsecan databases. Our local Debian servers already monitor that data on a regular basis anyways. > The backport of the security fix is usually done by the Debian Security Team > or the maintainers of the relevant packages (especially if a backport is > needed for non-standard packages). Currently all testing prior to the release > is performed by the Security Team and the respective maintainers. We're > planning to have a "security beta test" program for large customers (which > usually deploy/test security fixes in test environment prior to the rollout). > Hopefully we'll be able to have the necessary infrastructure ready during this > year. Once we have such a program you would be very welcome to contribute your > testing feedback. What I am a little worried about is getting completely blindsided by some update that all the "other" OS vendors have known about for months. Right now we would only find out about it when Debian officially releases its security update packages. Ideally we would monitor vendor-sec and identify which vulnerabilities apply to our appliance, then acquire, test, and comment on the Debian-specific patch before the disclosure date. Our backup plan is to simply monitor vendor-sec and attempt to patch the security problems ourselves, though again we'd rather stay close to upstream (IE: Debian). We are certainly going to try to get ourselves on the vendor-sec mailing list, as we believe our network security appliance would certainly qualify us as an "OS vendor" with a real need to know about such vulnerabilities. In particular, the commercial software application we are deploying onto our network appliances is called the "HardwareWall"; it provides a safe government-certified system for connecting government networks of different classification levels. Cheers, Kyle Moffett -- Kyle Moffett eXMeritus Software Integrated Intelligence The Boeing Company (703) 764-0925 (703) 832-0657 (fax) kyle.d.moff...@boeing.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c7ceb7c9.7f8c%kyle.d.moff...@boeing.com
