From c49df03e74e9cb02bfab6afa464f194db9e5777f Mon Sep 17 00:00:00 2001 From: Tinamaam <166918090+Tinamaam@users.noreply.github.com> Date: Mon, 15 Jul 2024 00:54:39 -1000 Subject: [PATCH 1/2] Create generator-generic-ossf-slsa3-publish.yml --- .../generator-generic-ossf-slsa3-publish.yml | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 .github/workflows/generator-generic-ossf-slsa3-publish.yml diff --git a/.github/workflows/generator-generic-ossf-slsa3-publish.yml b/.github/workflows/generator-generic-ossf-slsa3-publish.yml new file mode 100644 index 00000000..35c829b1 --- /dev/null +++ b/.github/workflows/generator-generic-ossf-slsa3-publish.yml @@ -0,0 +1,66 @@ +# This workflow uses actions that are not certified by GitHub. +# They are provided by a third-party and are governed by +# separate terms of service, privacy policy, and support +# documentation. + +# This workflow lets you generate SLSA provenance file for your project. +# The generation satisfies level 3 for the provenance requirements - see https://slsa.dev/spec/v0.1/requirements +# The project is an initiative of the OpenSSF (openssf.org) and is developed at +# https://github.com/slsa-framework/slsa-github-generator. +# The provenance file can be verified using https://github.com/slsa-framework/slsa-verifier. +# For more information about SLSA and how it improves the supply-chain, visit slsa.dev. + +name: SLSA generic generator +on: + workflow_dispatch: + release: + types: [created] + +jobs: + build: + runs-on: ubuntu-latest + outputs: + digests: ${{ steps.hash.outputs.digests }} + + steps: + - uses: actions/checkout@v4 + + # ======================================================== + # + # Step 1: Build your artifacts. + # + # ======================================================== + - name: Build artifacts + run: | + # These are some amazing artifacts. + echo "artifact1" > artifact1 + echo "artifact2" > artifact2 + + # ======================================================== + # + # Step 2: Add a step to generate the provenance subjects + # as shown below. Update the sha256 sum arguments + # to include all binaries that you generate + # provenance for. + # + # ======================================================== + - name: Generate subject for provenance + id: hash + run: | + set -euo pipefail + + # List the artifacts the provenance will refer to. + files=$(ls artifact*) + # Generate the subjects (base64 encoded). + echo "hashes=$(sha256sum $files | base64 -w0)" >> "${GITHUB_OUTPUT}" + + provenance: + needs: [build] + permissions: + actions: read # To read the workflow path. + id-token: write # To sign the provenance. + contents: write # To add assets to a release. + uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.4.0 + with: + base64-subjects: "${{ needs.build.outputs.digests }}" + upload-assets: true # Optional: Upload to a new release From 61d59531837649944ee2f4303d6e881fc5310dfd Mon Sep 17 00:00:00 2001 From: Tinamaam Date: Thu, 27 Feb 2025 18:33:02 +0000 Subject: [PATCH 2/2] chore(tidy): tidy up document --- index.html | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/index.html b/index.html index 66b16995..ddd20267 100644 --- a/index.html +++ b/index.html @@ -1013,16 +1013,16 @@

This allows the user agent to not require user activation, for example to support redirect flows where a user activation may - not be present upon redirect. See - for security + not be present upon redirect. See for security considerations.

- See also - - issue #1022 for discussion around providing more guidance - in the specification on when user agents should or should not - require a user activation for {{PaymentRequest/show()}}. + See also issue + #1022 for discussion around providing more guidance in the + specification on when user agents should or should not require + a user activation for {{PaymentRequest/show()}}.

@@ -4514,24 +4514,24 @@

If the user agent does not require user activation as part of the - {{PaymentRequest/show()}} method, some additional security mitigations - should be considered. Not requiring user activation increases the risk - of spam and click-jacking attacks, by allowing a Payment Request UI - to be initiated without the user interacting with the page immediately - beforehand. + {{PaymentRequest/show()}} method, some additional security + mitigations should be considered. Not requiring user activation + increases the risk of spam and click-jacking attacks, by allowing a + Payment Request UI to be initiated without the user interacting with + the page immediately beforehand.

- In order to mitigate spam, the user agent may decide to enforce a user - activation requirement after some threshold, for example after the - user has already been shown a Payment Request UI without a user + In order to mitigate spam, the user agent may decide to enforce a + user activation requirement after some threshold, for example after + the user has already been shown a Payment Request UI without a user activation on the current page. In order to mitigate click-jacking - attacks, the user agent may implement a time threshold in which clicks - are ignored immediately after a dialog is shown. + attacks, the user agent may implement a time threshold in which + clicks are ignored immediately after a dialog is shown.

Another relevant mitigation exists in step 6 of - {{PaymentRequest/show()}}, where the document must be visible in order - to initiate the user interaction. + {{PaymentRequest/show()}}, where the document must be visible in + order to initiate the user interaction.