Jan 30th AnnouncementsNew column is created in projects to hold regular PRs Demos - do we have any? * Updates from the team Harald

Author Period State Dmitri Pal January, 2023 :red_circle: Draft Overview Current document describes our intended project management practices for the Enarx, Steward, Drawbridge and related projects and components under Enarx and Profianinc organizations on GitHub.

Author Period State Dmitri Pal December 2022 <span style="color: red;">Draft</span> High level architecture This document describes the detailed architecture of the Enarx attestation workflow. For a more high-level view and concepts related to the Confidential Computing Attestation flow please read the following document.

Upcoming meetings Jan 26th Design of the digest and SANsDeployment vs. ApplicationApplication is the instance of the software Deployment is the configuration of the application The instance of the group of applications requires verification of the peer application Proposal to have application digest and deployment digest

Author Period State Dmitri Pal January 2023 :red_circle: Draft Step-by-step release process instructions Preparation

Not Production Ready This release is a developer-only, preview release. It is not production ready. We hope that you will experiment with it to see the progress we are making. What's Changed Features Add support for threading and synchronization by @haraldh in https://github.com/enarx/enarx/pull/2179 Use tracing instead of log for logging by @haraldh in https://github.com/enarx/enarx/pull/2183 Error on unknown fields by @rvolosatovs in https://github.com/enarx/enarx/pull/2193 Print child stderr in tests by @rvolosatovs in https://github.com/enarx/enarx/pull/2194 Introduce file types by @rvolosatovs in https://github.com/enarx/enarx/pull/2197

Author Period State Nathaniel McCallum<br>Richard Zak<br>Harald Hoyer<br>Dmitri Pal November-December, 2022 🔴 Draft Introduction This document is the continuation of the discussion about the attestation flow, started in the Attestation Concept document. It focuses on the entity that receives the attestation report from a Keep, inspects it and validates that the Keep was properly created on the hardware which keys are still trusted.

January 12 RomanSmall company, people are not aware that is happening in the other parts of the org There have been cases when information has been missed Do not know what to do when blocked Not enough releases Standups are not fulfilling their purpose Richard There was friction with putting together a featureThere was misalignment behind the feature

Author Period State Nathaniel McCallum<br>Dmitri Pal January 2023 :red_circle: Draft graph BT Steward(Steward)

Author Period State Dmitri Pal<br>Roman Volosatovs December, 2022 🔴 Draft Overview Current document defines the agreed to conventions related to the introduction and implementation of the shared (reusable) workflows in Enarx and Profian organizations.

Author Period State Nathaniel McCallumRichard ZakHarald HoyerDmitri Pal November-December, 2022 :red_circle: Draft Introduction The purpose of this document to provide a high level explanation of the attestation concept. Attestation plays a key role in Confidential Computing. We will start with why attestation is needed and work our way "downwards" to how each point of data is required.

Top-Level 1.3.6.1.4.1.58270 is the space registered to Profian for OIDs. More information at oid-info.com. Current Usage 1.3.6.1.4.1.58270.1: Keep technologies 1.3.6.1.4.1.58270.1.1: KVM/Nil 1.3.6.1.4.1.58270.1.2: Intel SGX 1.3.6.1.4.1.58270.1.3: AMD SEV

Author Period State Dmitri Pal December, 2022 :thumbsup: Active Overview This document describes a convention on tagging the documents used to govern the projects under Enarx and Profianinc GitHub organizational umbrella.

Author Period State Dmitri Pal December, 2022 :thumbsup: Active Overview Current document describes the common practices adopted in the projects that fall under Enarx and Profianinc organizational umbrella.

:::info Saved for reference ::: :::warning Raw notes captured from a review: Update the deployment information to include the information about priming and keeping the information Systemd service Operator

:::danger This document is the raw notes and a precursor of the Attwestion Flow document, which supercedes it. ::: Introduction TBD Authentication & Authorization Authentication is a system which attempts to identify the person or organization associated with an operation. It often looks something like the following scenario where Jane wants to find out how much money is in her bank account:

Introduction The current document describes the (proposed) flow of how the Exartx team handles the triage and execution of the tickets in the backlog. Overview Enarx is a project that leverages GitHub for all aspects of development, review and automation. The primary way to make changes to the project is by submitting a Pull Request (PR). The team tracks the work via issues and PRs. Developers mostly look at those issues and PRs and don't see value in other project management tools. In this given situation the introduction of additional project management tools seems artificial. The closer and the more natural the process and flow for the development team is - the better. GitHub offers a feature called Projects. Projects allow a flexible view of the tickets in tabular and board modes. Requirements for Project Management Tools and Flow The process and tools chosen for the management of the Enarx project shall address the following functional and non-functional requirements:

Problem definition The attestation of the workload includes the CPU state information. When the workload that was running in the AMD keep exits, the system stores the state in the special area (VMSA). When the workload is started again, it loads the state back. This is a well-defined process and works. The initial state, however, needs to be better defined. Currently, it is defined by Kernel without userspace knowledge or ability to influence. As a result, Enarx does not know the initial state and has to guess. If it guesses right the attestation would include the correct data and everything would check out. If Enarx guesses wrong the attestation of the workload would be incorrect. VMSA MUST be public, since all parties need to agree on it. So the kernel choosing this information on its own and making everyone guess is unexpected behavior. There are two questions: Who chooses the initial state?

Crypto Libraries Ring - BoringSSL Rust Crypto - Pure Rust HTTPS libraries Rustls - Uses Ring Where used