[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)



[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.

>>   * Even if an e500 port does not go upstream, would it be possible to get
>> the appropriate entries added to the upstream dpkg cpu and triplet tables?
>> We're using a simple 10-line patch to dpkg locally, hopefully that would be
>> acceptable?
> 
> That has been done in the past for unofficial architectures like "lpia"
> already.
> 
> Simply file a bug against dpkg using reportbug and send the patch along.

Wonderful!  I'll hopefully have time to get to it some time today.  I'll
also try to send over our tiny patches for "eglibc", "gcc-4.3", and
"gcc-4.4" at the same time.

Thanks again for your comments and advice!

Cheers,
Kyle Moffett

-- 
Kyle Moffett
eXMeritus Software
Integrated Intelligence
The Boeing Company

(703) 764-0925
(703) 832-0657 (fax)
Kyle.D.Moffett@boeing.com


Reply to: