For example, a simple layer of blocks like this of our primary stack (with links to the repos):

WASI / WASM (upstream)
wasmldr
enarx-keepldr
sgx | sev | etc...

We also have a ton of utility crates that may be represented as separate from all of these layers?

We need to provide the videos in multiple formats, as not everyone's default browser reads webm directly.

So encode the videos to h264 in an mp4 container and add them to the assets/video directory.

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

Current Behaviour

Expected Behaviour

getting error like release folder not found.

Environment Information

uname -a; enarx --version; enarx info

Steps To Reproduce

No response

Create info@ and press@ for immediate email needs.

Is there an existing issue for this?

• I have searched the existing issues

Description

The tutorials for C/C++ are oddly Windows-centric. Despite some instructions for compiling with gcc, g++ on Linux, the instructions point users to https://docs.microsoft.com/en-us/cpp/build/vscpp-step-0-installation?view=msvc-170

Acceptance Criteria

The introductions should break-down the instructions by operating system. The wasi-sdk supports Linux & macOS.

• Instructions for mac OS (install Xcode, for example)
• Instructions for Linux (use your package manager to install clang, for example)

Suggestions for a technical implementation

No response

Is there an existing issue for this?

• I have searched the existing issues

Description

As there will be more documentation upcoming around features documented in enarx, it would be useful to have the site support multiple versions. This could also be helpful in installing the appropriate version in the install section, as well as help keeping the documentation in lock step with currently supported and unreleased enarx version. This would also allow the Install documentation to be different depending if you are installing from git or from published crates.

Acceptance Criteria

• Design/proposal created
• Buy in from team
• Implementation of content
• Update in release automation

Suggestions for a technical implementation

An example of this could be found here.

What will be the First Steps section be about?

Is there an existing issue for this?

• I have searched the existing issues

Description

With the newly enabled GitHub actions enforcing conventional commits, it is critical to provide appropriate guidance to the developer community on how to contribute content.

Acceptance Criteria

Update https://enarx.dev/docs/Contributing/PRs section of the website with the appropriate material around commit messages (as well as GitHub PR titles).

Suggestions for a technical implementation

Please take a look at: https://github.com/dracutdevs/dracut/blob/master/docs/HACKING.md#commit-messages for inspiration.

Official spec here: https://www.conventionalcommits.org/en/v1.0.0/#summary

We should have a code of conduct to express clearly to any one looking to contribute that we intend to be a welcoming project and will enforce rules if necessary.

I suggest the Contributor Covenant, which is a well-established and well-written document:
https://www.contributor-covenant.org/version/1/4/code-of-conduct

The wiki has an incorrect link to "gibhub.com". Unfortunately I cannot send a pull request for the wiki.

https://desk.rocket.chat/portal/en/kb/articles/how-can-i-set-up-a-custom-domain

The new CNAME value is cdns.use1.cloud.rocket.chat. This is required before they can set up our certificate.

Original issue by @axelsimon:

Building the enarx.github.io landing page requires us to choose which tool we want to use to power the page / site.

@shaunix was telling me Jekyll is used in OSPO but only as a default, not a mandate.

I've also heard good things about Pelican (which I've played with a bit) and Hugo.

These are the choices that come to mind, any advice is welcome.

I'd like to settle on one of them quickly so we can then build a minimal but useful site.

Acceptance criteria: We have agreed on a site generator.

Description:

• Ensure that process around filing bugs and requesting new issues is standardized across repositories.
• Provide standardized issue filing landing page
• Add triage label, and automatically tag new issues with this label for triage.

We have already written a document explaining Enarx' threat model. It needs to be published, for the world to enjoy.

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

Current Behaviour

Due to inline asm feature not rolled out in rust stable, we need to update the documentation to ensure that users build enarx using the rust nightly to avoid compile time errors.

Expected Behaviour

Successful compilation and installation of enarx with the posted instructions.

Environment Information

Rust stable 1.58.1

Steps To Reproduce

1. Follow Install from Github section from: https://enarx.dev/docs/Installation/Enarx
2. Use the rust stable toolchain

Is there an existing issue for this?

• I have searched the existing issues

Description

We want to create a WebAssembly Guide with a simple example using various programming languages that currently have support for WASI:

https://enarx.dev/docs/WebAssembly/Introduction

Fermyon has a good matrix showing languages that support WASI:

https://www.fermyon.com/wasm-languages/webassembly-language-support

Among these languages, recently we saw JavaScrip/TypeScript getting support:

https://blog.suborbital.dev/bringing-javascript-and-typescript-to-suborbital

Acceptance Criteria

The languages we are interested in are the following, currently ordered by their support of WASI and importance:

• Rust
• C
• C++
• Go
• JavaScript
• TypeScript
• AssemblyScript
• .NET
• Ruby
• Grain
• Zig
• Python
• Swift
• Kotlin
• Java
• Erlang
• Haskell
• Lisp
• COBOL

Suggestions for a technical implementation

We are thinking in using Fibonacci as an example:

https://github.com/enarx/outreachy/tree/main/Jennifer/Rust-to-WASI

If you are interested in contributing, please:

• Implement Fibonacci in your language of choice
• Add a markdown file to docs/WebAssembly
• Add a sidebar link at sidebars.js
• Create a PR against this repo

Thank you!

Is there an existing issue for this?

• I have searched the existing issues

Description

It would be helpful to edit and post @npmccallum's Enarx project code walkthrough video and make it easily consumable.

Acceptance Criteria

• Break apart into sub-videos
• Remove crosstalk/digressions/non-enarx related discussions
• Add sub-video topic splash graphic containing enarx logo & section title.
• Add opening and closing enarx project splash graphic (to first video and the last)
• Create draft blog post providing overview to video series along with private youtube playlist for review
• Approval/signoff by @npmccallum and/or @MikeCamel
• Publish playlist & document/TOC in blog and/or post for full walkthrough

Suggestions for a technical implementation

No response

Is there an existing issue for this?

• I have searched the existing issues

Description

Add documentation for conventional commit for contributors: https://www.conventionalcommits.org/en/v1.0.0/#summary

Acceptance Criteria

No response

Suggestions for a technical implementation

No response

Is there an existing issue for this?

• I have searched the existing issues

Description

Installation instructions should be stored along with the enarx source code and embedded in the documentation during CI.

Acceptance Criteria

• Update GH actions to dynamically update the installation page from INSTALL.md
• Create GithHub action to update just the installation page using using a repository_dispatch trigger event which would be triggered by a workflow on in the enarx/enarx following a published release event.

Suggestions for a technical implementation

Example of cross repository automation: https://ayeshahansi.medium.com/trigger-your-test-automation-project-through-the-workflow-of-the-application-cross-repository-58759aa82d15

Description:

The current bug filling documentation requires an overhaul to ensure that the issue filing process is the coherent. This task is related to: enarx/.github#11 (comment)

Acceptance Criteria

• Rename Bugs to "Filing Issues"
• Add triage label to list of available labels
• Provide information about filing a bug
• Provide information about how to request a feature or enhancement

We should make a public mailing list for the project.

Is there an existing issue for this?

• I have searched the existing issues

Description

Docusaurus has official support for Algolia DocSearch. The service is free for any open-source project. Enarx applied to the DocSearch program and got accept (2nd round). We now need to make the necessary configurations to have this search functionality on our website.

Acceptance Criteria

No response

Suggestions for a technical implementation

No response

Is there an existing issue for this?

• I have searched the existing issues

Description

Add support for mermaid (markdown for diagrams):

https://mermaid-js.github.io/mermaid/#/

Acceptance Criteria

No response

Suggestions for a technical implementation

Instructions to implement mermaid on Docusaurus:

https://github.com/sjwall/mdx-mermaid

Is there an existing issue for this?

• I have searched the existing issues

Description

Update docusaurus from 2.0.0-beta 15 to 2.0.0-beta.16.

Acceptance Criteria

No response

Suggestions for a technical implementation

yarn upgrade @docusaurus/core@latest @docusaurus/preset-classic@latest

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

Current Behaviour

As we no longer rely on cargo make we should update the section for running the unit tests under the following url: https://enarx.dev/docs/Contributing/PRs#check-that-your-code-is-really-ready

Expected Behaviour

Documentation reflects build process.

Environment Information

Does not apply.

Steps To Reproduce

No response

Description:

Users should be provided with instructions on how to report issues with lab machines to ensure infrastructure issues are addressed as soon as possible.

Proposed Implementation:
Post instructions on enarx.dev website in the "Lab Machines" section. Instructions should include filing an issue on the https://gitlab.com/enarx/lab repository and optionally notifying the team on the infrastructure channel in Rocket.Chat.

The .gifs and .webms of SGX and SEV currently look different. I'm not sure how the SEV one was created, so am having trouble reproducing it. At some point, we should make them look more similar.

Cf. Github documentation.

We currently have contribution docs here:
https://github.com/enarx/enarx.github.io/wiki/How-to-contribute

These need to be migrated to the standard place for GitHub. See this link for more details:
https://github.com/enarx/enarx.github.io/community