Browse Source

Update GHA trigger security and packaging in contributor forks

Signed-off-by: Mike Chang <[email protected]>
Mike Chang 2 years ago
parent
commit
55fbee61b7
1 changed files with 4 additions and 4 deletions
  1. 4 4
      rfcs/rfc-bld-20230302-1-3p-development.md

+ 4 - 4
rfcs/rfc-bld-20230302-1-3p-development.md

@@ -138,8 +138,8 @@ $~$
 3.  The build step uses a Github Action to execute a build script (currently the `[build_packages.py](https://github.com/o3de/3p-package-scripts/blob/main/o3de_package_scripts/build_package.py)` script but can be agnostic), which will consume a primary metadata file for each platform  
 3.  The build step uses a Github Action to execute a build script (currently the `[build_packages.py](https://github.com/o3de/3p-package-scripts/blob/main/o3de_package_scripts/build_package.py)` script but can be agnostic), which will consume a primary metadata file for each platform  
     1.  This primary metadata file will be part of contribution prior to the build (currently the [`package_build_host_list_<platform>.json`](https://github.com/o3de/3p-package-source/blob/main/package_build_list_host_windows.json) file), which will define custom steps specific to each package
     1.  This primary metadata file will be part of contribution prior to the build (currently the [`package_build_host_list_<platform>.json`](https://github.com/o3de/3p-package-source/blob/main/package_build_list_host_windows.json) file), which will define custom steps specific to each package
     2.  The package source path could include **`PackageInfo.json`**, a metadata file containing package version and licenses, but one can be generated as part of the build
     2.  The package source path could include **`PackageInfo.json`**, a metadata file containing package version and licenses, but one can be generated as part of the build
-4.  If the build step succeeds, a separate Github Actions step will create the OCI image from the output, then upload it to Github Packages. A download location and hash of the package will be generated in the build output. 
-5.  To allow a developer to consume their own packages, they would add the Github Packages CDN URL in [cmake/3rdPartyPackages.cmake](https://github.com/o3de/o3de/blob/development/cmake/3rdPartyPackages.cmake#L32) or add to the **`LY_PACKAGE_SERVER_URLS`** environment variable  
+4.  If the build step succeeds, a separate Github Actions step will create the OCI image from the output, then upload it to Github Packages. This will be contained inside the contributor's Github account if forked. A download location and hash of the package will be generated in the build output. 
+5.  To allow a developer to consume their own packages, they would add the Github Packages CDN URL for their fork in [cmake/3rdPartyPackages.cmake](https://github.com/o3de/o3de/blob/development/cmake/3rdPartyPackages.cmake#L32) or add to the **`LY_PACKAGE_SERVER_URLS`** environment variable  
 
 
 $~$
 $~$
 
 
@@ -222,8 +222,8 @@ Security and license Considerations
 *   How do we prevent supply chain attacks?
 *   How do we prevent supply chain attacks?
 
 
     - Github Action trigger abuse
     - Github Action trigger abuse
-        - *Potential threat:* Threat actors DDoSing Github Actions or causing it to trigger automatically and merge without review
-        - *Mitigation:* Only maintainers will be able to trigger the GHA manually. We require a PR of the contribution before it is merged, and must be signed off by 2 people
+        - *Potential threat:* Threat actors DDoSing Github Actions or causing it to trigger automatically and build without review
+        - *Mitigation:* Only maintainers will be able to trigger the GHA manually to build the package. Builds will not be triggered automatically. We require a PR of the contribution before it is merged, and must be signed off by 2 people
     - Remote execution on Github Action
     - Remote execution on Github Action
         - *Potential threat:* Threat actors injecting remote execution code or binaries into the package
         - *Potential threat:* Threat actors injecting remote execution code or binaries into the package
         - *Mitigation:* Static analysis and virus scan is performed on the code and any binary artifacts. The package itself should be vetted by a maintainer (the code should come from the original repo), and any CVEs are resolved before moving to the AR stage
         - *Mitigation:* Static analysis and virus scan is performed on the code and any binary artifacts. The package itself should be vetted by a maintainer (the code should come from the original repo), and any CVEs are resolved before moving to the AR stage