DRAFT
Project Definition and Structure
Project Charter
To provide an Open-Source software development toolkit and enable collaboration on the development of a platform that provides client virtualization technology with high assurance security properties that are rooted in the platform hardware.
To engage with upstream software projects and contribute developments with the dual aims of increasing the use of OpenXT technologies and decreasing the specialization of OpenXT.
To continually raise the security capabilities of the OpenXT platform and upstream projects.
To satisfy the OpenXT Priority Use Cases.
Priority Use Cases
Provide the software platform for a Multi-Tenant Client Desktop.
Track upstream component developments and enable their introduction into the platform.
Enable hardware-based security technologies to used effectively.
Enable support for new generations of hardware platforms.
Enable opportunistic use of other Open Source technologies.
Provide the software platform for a hardened Single-VM endpoint.
Enable effective lockdown of a client machine to increase the challenge presented to a local adversary.
Be the best-in-class Open Source toolchain for support of measured launch into a virtualized environment.
Academic research platform for work on hardware-based security technologies.
Production software environment for validation of new hardware-based security technologies.
Organizational Entities
Individual Contributors
Software developers
Documentation authors
Program managers
Technical Subject Matter Experts
Corporate and Institutional Contributors
Contributing Customers
Subcontractors
Software Developers
Hardware Vendors
Consumers of the project software
Technical Advisory Board
Governance Committee
Component Maintainers
System Administrators of project infrastructure
Roles and Responsibilities
Repository Maintainer, Source Code Committer
Monitors the repositories for Pull Requests and comments and engages with them.
Will apply the Pull Request procedure and perform the actual approval or rejection actions of PRs to the source code repositories.
Will monitor mailing list postings that are relevant to RFCs and Pull Requests.
Current: Ross (AIS), Jed (AIS), Eric (AIS), Philip Tricca (unaffiliated)
Project Governance Committee
Structure of the Governance Committee
<n> Individual Contributor positions
<m> Corporate and Institutional Contributor positions
<n> + <m> must be an odd number.
Formal positions: Treasurer, Chairman, Primary Technical Advisory Board representative
Responsible for ensuring that decision making is effective within the project and acting as the decision maker of highest authority, for setting the project charter and for driving project activities in pursuit of project goals derived from the charter.
[ TODO:
The Project Governance Committee should be designed to accurately reflect the actual power structure present within the project and further its goals. It should also be able to be changed with such a process so that it continues to do so.
]
Proposed: ….
Project Technical Advisory Board
Structure of the Technical Advisory Board
Project contributors with demonstrated technical contribution to the project sustained over time.
Must be respected within the community as having sound technical judgement.
Must have no structural conflict of interest in being able to evaluate software against the Platform Definition and Security Properties.
In aggregate, the board must have sufficient breadth of expertise to be able to consider changes to any part of the platform.
Responsible for providing expertise to the Governance Committee to enable them to ensure that the OpenXT platform maintains properties that are important to the project.
eg.
Ensuring continuing support for priority Use Cases when significant changes are proposed. Requires understanding the details of the Use Cases and representing the interests of the users of actual deployments.
Evaluating new technologies or changes to upstream components for relevance to OpenXT work.
Directing attention of the Governance Committee to important decisions to be made.
Guidance from the Technical Advisory Board should be aimed at maintaining technical strengths and differentiation of the OpenXT platform.
Community Code of Conduct
Bug fixing is to be done in the open:
File a JIRA ticket at the point the defect is identified, to enable early participation from others in the community.
Presentation of a complex fix PR out of the blue is to be avoided, especially if it introduces new software dependencies or technologies, or changes security properties.
Processes
Decision making in the GC
Decision making in the TAB
Authorization of Pull Requests
Decision makers for Pull Requests
1. Component Maintainers
2. Technical Advisory Board
3. Governance Committee
Criteria for evaluation of Pull Requests
Syntax and Completeness of the request
JIRA ticket filed with description
RFC document and mailing list thread, for “significant” specification changes
Taxonomy of Change Types:
Security-related fix : import from external project
Security-related fix : OpenXT-specific patch
Bug fix : no specification change
Bug fix : with change of specification / loss of functionality as a side effect
Enhancement / Change of specification
Additive
Subtractive
Dead component elimination
Change relevant to the software license (eg. trademark introduction)
Infrastructure change : no specification change
Test coverage change : no specification change
Additive
Subtractive
Introduction of third-party software
Software license is the same as the existing license of linked material
Software license is a new license
Removal of third-party software
Relicensing of a software component
RFC procedure
Reference to the OpenXT Platform Definition and Security Properties
Reference to the OpenXT Priority Use Cases
Pull Request Process
Decision making for Pull Requests
Voting: not currently in use in practice because it doesn’t work and the community appears to have acknowledged that.
eg. balancing many members of a single organization versus a smaller number of opposing votes from individual contributors.
In practice, if an argument is made by any community member that the proposed change adversely affects the existing security properties of the system, especially if they are relevant to the Priority Use Cases, and the argument is not refuted, then the change is not approved.
If the argument ends in a stalemate, then the decision should progress to the Technical Advisory Board.
Method of Public Record of Decision Making
<JIRA and mailing lists.>