Codesign: Continue work on Azure Trusted Signing implementation #98

New Issue

Bart van der Braak · 2024-07-26T12:10:52+02:00

2024-07-26 12:10:52 +02:00

Tasks

Create Azure tenant
Create and deploy Bicep/Terraform templates for ATS
Implement as build step into Buildbot
Add signed libraries to Git LFS for "caching" purposes

GitHub Workflow example

name: Build and Sign on Windows

permissions:
  id-token: write
  contents: read

on:
  push:
    branches:
      - "signing"
  pull_request:
    branches:
      - "main"
    paths:
      - ".github/workflows/test.yaml"
  workflow_dispatch:

jobs:
  build-windows:
    runs-on: [self-hosted, Windows, X64]
    environment: sign
    steps:
      - name: Download Sources
        uses: actions/checkout@v3
        with:
          lfs: true

      - name: Get external libraries
        shell: cmd
        run: |
          git config --local "submodule.lib/windows_x64.update" "checkout"
          git submodule update --progress --init "lib/windows_x64"
          git lfs pull          

      - name: Update
        shell: cmd
        run: make update
        
      # - name: Build
      #   shell: cmd
      #   run: make

      - name: Catalog
        shell: pwsh
        run: |
          $workspace = "${{ github.workspace }}\"
          $searchPath = "$workspace..\build_windows_x64_vc17_Release\bin\Release"
          $workspaceTrimmed = $workspace -replace "blender\\$"
          $files = Get-ChildItem -Path $searchPath -Recurse -Include *.exe, *.dll, *.pyd | Where-Object { $_.FullName -notmatch "\\blender\.crt" }
          $files | ForEach-Object { $_.FullName -replace [regex]::Escape($workspaceTrimmed), "..\" } | Out-File sign-catalog.txt -Encoding utf8          

      - name: Sign
        uses: azure/trusted-signing-action@v0.3.20
        with:
          azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          azure-client-id: ${{ secrets.AZURE_CLIENT_ID }}
          azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
          endpoint: https://weu.codesigning.azure.net/
          trusted-signing-account-name: bartvdbraak-blender
          certificate-profile-name: production
          files-catalog: ${{ github.workspace }}\sign-catalog.txt
          file-digest: SHA256
          timestamp-rfc3161: http://timestamp.acs.microsoft.com
          timestamp-digest: SHA256

Caveats

Sergey:

The self-hosted solutions for RSA 4k is tricky and has a lot of unknowns, and it is quote difficult to get knowledge out of CAs. So now we are investigating cloud-based HSM, Bart did some tests and it seems very promising. The tricky part is that they are essentially charging per-request. So we might need to switch to a situation when we code-sign libraries in Git-LFS, instead of code-signing them for every blender build.

## Tasks - [ ] Create Azure tenant - [ ] Create and deploy Bicep/Terraform templates for ATS - [ ] Implement as build step into Buildbot - [ ] Add signed libraries to Git LFS for "caching" purposes ## GitHub Workflow example ```yaml name: Build and Sign on Windows permissions: id-token: write contents: read on: push: branches: - "signing" pull_request: branches: - "main" paths: - ".github/workflows/test.yaml" workflow_dispatch: jobs: build-windows: runs-on: [self-hosted, Windows, X64] environment: sign steps: - name: Download Sources uses: actions/checkout@v3 with: lfs: true - name: Get external libraries shell: cmd run: | git config --local "submodule.lib/windows_x64.update" "checkout" git submodule update --progress --init "lib/windows_x64" git lfs pull - name: Update shell: cmd run: make update # - name: Build # shell: cmd # run: make - name: Catalog shell: pwsh run: | $workspace = "${{ github.workspace }}\" $searchPath = "$workspace..\build_windows_x64_vc17_Release\bin\Release" $workspaceTrimmed = $workspace -replace "blender\\$" $files = Get-ChildItem -Path $searchPath -Recurse -Include *.exe, *.dll, *.pyd | Where-Object { $_.FullName -notmatch "\\blender\.crt" } $files | ForEach-Object { $_.FullName -replace [regex]::Escape($workspaceTrimmed), "..\" } | Out-File sign-catalog.txt -Encoding utf8 - name: Sign uses: azure/trusted-signing-action@v0.3.20 with: azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }} azure-client-id: ${{ secrets.AZURE_CLIENT_ID }} azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }} endpoint: https://weu.codesigning.azure.net/ trusted-signing-account-name: bartvdbraak-blender certificate-profile-name: production files-catalog: ${{ github.workspace }}\sign-catalog.txt file-digest: SHA256 timestamp-rfc3161: http://timestamp.acs.microsoft.com timestamp-digest: SHA256 ``` ## Caveats Sergey: > The self-hosted solutions for RSA 4k is tricky and has a lot of unknowns, and it is quote difficult to get knowledge out of CAs. So now we are investigating cloud-based HSM, Bart did some tests and it seems very promising. The tricky part is that they are essentially charging per-request. So we might need to switch to a situation when we code-sign libraries in Git-LFS, instead of code-signing them for every blender build.

Bart van der Braak added this to the DevOps Progress Board project 2024-07-26 12:21:21 +02:00

Sergey Sharybin commented

2024-07-26 12:24:46 +02:00

I'll dump some thoughts here, maybe it will simplify some integration in the future.

We already using some custom client-server solution for code-signing using Yubikey FIPS, the code is available at: https://projects.blender.org/infrastructure/codesign

Basically, on Windows builders, worker calculates digest of a file to be signed, sends it to the sever to sign, and server signs it using Yubikey. The are a couple of speculations:

We can move server folder in the repository to server-yubikey, and add another folder server-azure, which will use Azure Trusted Server to sign the digest. Doing so will be pretty much transparent for all the workers, and changes would need to be done on a single machine.

On the implementation side, it is hopefully as easy as using some requests.get instead subprocess.check_output in the server's implementation of sign request handler (https://projects.blender.org/infrastructure/codesign/src/branch/main/server/handler/sign.py#L93)

I think digest is deterministic in a sense that if the input file does not change its digest does not change as well. This could open the doors for implementing a cache on the codesign-server side: it could store results for codesign requests, and avoid sending the request to the Azure. If that's indeed possible, it will let us quite easily lower the number of codesign request to Azure, stay on a cheaper plan, and not change the way we update precompiled libraries.

I'll dump some thoughts here, maybe it will simplify some integration in the future. We already using some custom client-server solution for code-signing using Yubikey FIPS, the code is available at: https://projects.blender.org/infrastructure/codesign Basically, on Windows builders, worker calculates digest of a file to be signed, sends it to the sever to sign, and server signs it using Yubikey. The are a couple of speculations: 1. We can move `server` folder in the repository to `server-yubikey`, and add another folder `server-azure`, which will use Azure Trusted Server to sign the digest. Doing so will be pretty much transparent for all the workers, and changes would need to be done on a single machine. On the implementation side, it is hopefully as easy as using some `requests.get` instead `subprocess.check_output` in the server's implementation of sign request handler (https://projects.blender.org/infrastructure/codesign/src/branch/main/server/handler/sign.py#L93) 2. I think digest is deterministic in a sense that if the input file does not change its digest does not change as well. This could open the doors for implementing a cache on the codesign-server side: it could store results for codesign requests, and avoid sending the request to the Azure. If that's indeed possible, it will let us quite easily lower the number of codesign request to Azure, stay on a cheaper plan, and not change the way we update precompiled libraries.

🚀 1

Bart van der Braak self-assigned this 2024-07-29 16:58:17 +02:00

Bart van der Braak added the

Type

Setup

label 2024-08-01 11:15:04 +02:00

Bart van der Braak closed this issue

2024-08-14 10:31:29 +02:00

Bart van der Braak reopened this issue

2024-08-14 10:32:57 +02:00

Sign in to join this conversation.