Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)
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" <jmm@inutil.org> wrote:
> > On 2010-03-23, Moffett, Kyle D <Kyle.D.Moffett@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
Reply to: