Proposed RFC Suggestion: Content approval process for canonical.o3de.org remote repository

[AMZN-alexpete]

Summary:

Publicly available remote content hosted in https://github.com/o3de and in https://o3debinaries.org/ that is linked to from https://canonical.o3de.org/repo.json must be approved following an established process to ensure:

1. Correctness and Quality - the content must work and appear as described and meet a minimum quality bar to prevent spam, duplication and meet user expectations.
2. Security and Privacy- the content must not be malicious or compromise the privacy of users per the O3D Foundation’s security and privacy policies.
3. Legal - the content must have an O3D Foundation compatible license and meet O3D Foundation legal restrictions including the O3D Foundation’s restrictions on patent-encumbered code, restricted proprietary content, age-limited content and content ownership. O3D Foundation also determines the terms the submitter accepts when submitting content.

What is the motivation for this suggestion?

• The O3DE community owns and maintains many optional gems, projects and templates that are useful but do not belong in the main o3de repository and are instead hosted in other repositories like o3de-extras.
• This approval process can be used as a model for other O3DE remote repositories, especially those with different licenses and ownership requirements.

Suggestion design description:

• Initially, SIG content will define and own the approval process until a new SIG is formed or chosen that is more suited.

• To add/update/remove content, a user will create a GitHub PR in the https://github.com/o3de/canonical.o3de.org repository from a pre-existing template for adding/updating/removing content.

• The approval PR will target the development branch which is used for staging/testing.

• Before the GitHub PR can be merged it must:

  • Have an automated GitHub Action run that attempts to verify O3D Foundation content policies:
    • scans for viruses and restricted code that uses licenses that are incompatible with O3DE or comes from external sources with incompatible licenses or usage.
    • checks static code analysis
      • Various languages if hosted on GitHub: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning
      • Python https://github.com/PyCQA/bandit
    • verifies a valid LICENSE file exists
    • verifies a valid origin (author) is defined
    • validates content requirements based on the type of content (gem, project, template, etc.)
      • the o3de python module has .json validation functions for each content type
    • checks for duplicates and possible spam
  • Be downloaded and checked by a SIG content maintainer or reviewer to verify
    • the contributed code and/or art abides by the O3DE contribution guidelines and policies.
    • if code is included, the code compiles and functions as described - exhaustive testing is not required
    • all new 3rd party dependencies are available via a package source the user has already approved or the O3DE 3rd party package system
      • An example of an already approved package source would be a built in Linux package source from the Linux distro provider like the Canonical repositories for Ubuntu.
    • if art is included it works in O3DE and Asset Processor does not throw errors
    • if the content uses a source_control_uri, that the source_control_ref is a git commit hash
    • no pre-built binaries from outside sources are including in the content or archive. Any pre-built binaries should be compiled and signed by O3DE.
    • included CMake scripts do not download additional content that has not been approved or is not hosted by O3DE
  • If an archive (.zip) is submitted, after validation, the archive is uploaded to the O3DE binaries S3 bucket so the content cannot be changed maliciously and so that it can be retrieved from a URL bearing an O3DE affiliated certificate.
    • It is recommended that archive files submitted for approval are publicly available in a GitHub release in the same GitHub repository that hosts the source for the content
    • It is recommended that archive files should include a SHA256 hash to validate the contents and be GPG signed to validate the source.

• After the GitHub PR part of the approval processes is complete the changes are merged to the development branch where the changes can be tested.

  • Testing using the latest compatible release of O3DE on the primary platform for the content should at minimum include:
    • downloading the content verifying the SHA256 hash is correct
    • any new Gems can be added to a project and it compiles if needed and the Editor opens and the content is available
    • any new Project compiles and the Editor opens
    • any new Templates can be used to create viable Gems or Projects

• When testing is complete, the changes are reverted or fixed if testing fails, otherwise the changes are merged to the main branch making the changes publicly available.

Technical design description

• The https://github.com/o3de/canonical.o3de.org repository does not contain any actual content, just the repo.json file that links to content hosted in https://github.com/o3de repositories and in https://o3debinaries.org/

• The repo.json in the main branch of https://github.com/o3de/canonical.o3de.org is made public using AWS S3 and CloudFront

  • All the download_source_uri fields point to locations hosted via https://o3debinaries.org/ or the O3DE 3rd party package system.
  • All source_control_refs are git hashes
  • All source_control_uris are publicly accessible in O3DE owned repositories in https://github.com/o3de
  • Because content can be downloaded as an archive or cloned, the content must have a download_source_uri or source_control_uri or both.
  • All downloadable archives have valid SHA256 hashes

• The engine.json in https://github.com/o3de/o3de contains the https://canonical.o3de.org/ remote repository URL so that every user has access to the content in the main branch by default

• When content is staged in the development branch users can test it by adding the remote repository URL https://raw.githubusercontent.com/o3de/canonical.o3de.org/development/src

What are the advantages of the suggestion?

• Content meets the O3DE requirements for public distribution

What are the disadvantages of the suggestion?

• Time, resources and effort are required to validate and approve content

Are there any alternatives to this suggestion?

• A standalone website with database backend could be created with forms similar to Godot's asset library
  • This approach requires more resources and effort than we currently have
• The 3rd party package system could be used
  • The 3rd party system is primarily set up for hosting source and binaries and not art, but it is hosted in S3 so it's possible the approval processes could be combined.

What is the strategy for adoption?

• Documentation on O3DE.org
• README on https://github.com/o3de/canonical.o3de.org
• GUIDE in https://github.com/o3de/community

Are there any open questions?

• What specific virus scanner will be used?
  • Defer to O3D Foundation to determine what virus scanners to use.
• What specific static code analysis tool will be used? What will we do about false positives and warnings?
  • Defer to O3D Foundation to determine what static code analysis scanners to use.
• How will we check if submitted content contains spam?
  • Spam content will contain garbage, unrelated content, and advertisement, usually in many languages. We can limit who can open a PR using GitHubs tools https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository and engage GitHub support to clean up the spam if it occurs, but otherwise, the simplest approach is to create a script that O3D Foundation can configure to look for
    • keywords and phrases from recent spam
    • check for missing template content
    • check how recently the user account was created - spam bot accounts will usually be recent
• How do we handle commercial licenses and closed source?
  • This initial approval process for https://canonical.o3de.org/ is designed to support content that is compatible with the O3DE contributor guidelines for code, which does not allow for commercial licenses or closed source. As part of the RFC we should gauge the interest of O3DF members in supporting commercially licensed content as part of https://canonical.o3de.org/, a separate O3DE remote repository, or multiple remote repositories not owned by O3DF.
• How do we handle monetized content (can owners sell or gate stuff behind paywalls)?
  • Currently this is capability is not included in the https://canonical.o3de.org/ repository and we should discuss if we want to mix that content with completely free and open source content, or keep the O3DE canonical content compatible with O3DE contributors guidelines and use non-O3DE controlled remote repositories for everything else. For example, PopcornFX and Kythera both provide gems under different licenses and if O3DE were to take on hosting and management of this kind of content there may be additional legal and security considerations. It may be simpler for O3DE to recommend remote repositories that are managed by PopcornFX and Kythera where they manage their own content.