On Tue, Mar 23, 2010 at 01:04:04PM -0500, Moffett, Kyle D wrote: > [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. > > On 2010/03/23 13:40, "Moritz Muehlenhoff" <j...@inutil.org> wrote: > > On 2010-03-23, Moffett, Kyle D <kyle.d.moff...@boeing.com> wrote: > >> * Regarding software security updates, I am aware that most vendors of OS > >> distributions participate in coordinated-disclosure and embargo agreements > >> in order to receive advance notice of certain vulnerabilities. My employer > >> is currently considering what we would need to do in order to get access to > >> those notifications; on the other hand we would much rather participate > >> directly in the Debian security release process. Would it be possible for > >> us as a third-party corporation to be a part of that process? > > > > The easiest approach for all parties involved would be if e500 becomes an > > official port. In that case you don't need to do anything on the security > > side, all security updates are autobuilt and if there's an embargoed > > security issue targeted for a specific release date it's automatically > > available for e500 on the release day. But even if e500 starts unofficially > > we can discuss/evaluate the possibilities to hook a e500 autobuild system > > into the security buildd network. > > 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: 1. Initial report and triage The comes from many different sources. In most cases this is a public source, e.g. a Debian bug report filed by a user or a security issue reported by a specific open source project by announcing in on their website. This comprises the majority of all security issues (no hard numbers, but my gut feeling is 3/4 of all issues). All this information is directly fed into the Debian Security Tracker, a very powerful framework for the analysis and tracking of security issues. You could participate in this process right-away. Please see the following links for more information: http://security-tracker.debian.org/tracker/data/report http://security-tracker.debian.org/tracker/ A key benefit of Debian is that we do (almost) everything in the open, we don't have inaccessible private Bugzilla or Launchpad bugs, so any information collected on our bugtracking is directly available for our appliance-specific analysis. 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. For step (1) you will be mostly interested in sufficient information to study whether this vulnerability affects our appliance. Since we do a lot of version specific tracking this should help you a lot. If e.g. a security issue only affects the latest release and not the versions included in Debian stable or oldstable this information is annotated in the Debian Security Tracker. You're welcome to participate in the analysis work done there; you don't need to be a Debian developer to contribute. 2. Development of the security fix / prerelease testing 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. Another planned feature is a patch review mailing list for security updates. The source diff of all Debian security updates would be send there to lower the entry level for the review of fixed packages. Likewise you'd be more than welcome to review. 3. Release of the update / rollout at the customers Once released, the update is out of the control of the Debian Security Team and site-specific modifications and rollouts will be entirely in your hands. However, Debian provides a powerful tool for evaluating the security status of a given system: http://packages.debian.org/lenny/debsecan You might be interested in evaluating it for your purposes. Cheers, Moritz -- 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/20100323210255.ga3...@galadriel.inutil.org
