jotools/innosetup repository overview

⁠Azure Artifact Signing

⁠Configuration

Create the following two .json files on your host machine:

azure.json

{
  "TenantId": "[Azure Tenant Id]",
  "ClientId": "[Azure Client Id]",
  "ClientSecret": "[Azure Client Secret]"
}

acs.json

{
  "Endpoint": "https://weu.codesigning.azure.net",
  "CodeSigningAccountName": "[ACS Code Signing Account Name]",
  "CertificateProfileName": "[ACS Certificate Profile Name]"
}

And mount them into the following location when running the Docker Container:

/etc/aas-codesign/azure.json
/etc/aas-codesign/acs.json

Instead of mounting the two .json files, you can also provide the configuration via Environment Variables:

AZURE_TENANT_ID=[Azure Tenant Id]
AZURE_CLIENT_ID=[Azure Client Id]
AZURE_CLIENT_SECRET=[Azure Client Secret]
ACS_ENDPOINT=https://weu.codesigning.azure.net
ACS_ACCOUNT_NAME=[ACS Code Signing Account Name]
ACS_CERTIFICATE_PROFILE_NAME=[ACS Certificate Profile Name]

⁠Timestamp Server

The Timestamp Server will be automatically chosen by jsign.
To change it you can set the Environment Variables:

TIMESTAMP_SERVER=http://timestamp.domain.org
TIMESTAMP_MODE=[RFC3161|Authenticode]

⁠Codesign certificate .pfx

⁠Configuration

Create the following .json file on your host machine:

pfx.json

{
  "Password": "pfx-password",
  "TimestampServer": "http://timestamp.digicert.com",
  "TimestampMode": "Authenticode"
}

Have your codesign certificate certificate.pfx located on your host machine.

Mount them into the following location when running the Docker Container:

/etc/pfx-codesign/pfx.json
/etc/pfx-codesign/certificate.pfx (Note: always required)

Instead of mounting the .json file, you can also provide the configuration via Environment Variable:

PFX_PASSWORD=[PFX Password]
TIMESTAMP_SERVER=http://timestamp.domain.org
TIMESTAMP_MODE=[RFC3161|Authenticode]

The following example will

• run the Docker Image jotools/innosetup⁠
• use Azure Artifact Signing configuration from .json files stored on the host machine
• mount a folder on the host machine into /data
  that should include
  • the application to be packaged in a windows installer
  • the InnoSetup script my-installer.iss
• use entry point iscc.sh
• run InnoSetup to create a codesigned windows installer

docker run \
    --rm \
    -v /local/path/to/acs.json:/etc/aas-codesign/acs.json \
    -v /local/path/to/azure.json:/etc/aas-codesign/azure.json \
    -v /local/path/to/build-folder:/data \
    -w /data \
    --entrypoint iscc.sh \
    jotools/innosetup \
    '"/SCodeSignScript=Z:/usr/local/bin/aas-codesign.bat \$f" /O"Z:/data" /Dsourcepath="Z:/data/My Windows Application" "Z:/data/my-installer.iss"'

The following example will

• use the locally stored Azure Artifact Signing configuration files acs.json and azure.json
• mount a folder on the host machine into /data
• run the Docker Container interactively (removing it after)
  • use entry point sh
  • you then can manually create a codesigned windows installer, e.g.:
    iscc.sh '"/SCodeSignAAS=Z:/usr/local/bin/aas-codesign.bat \$f" /O"Z:/data" /Dsourcepath="Z:/data/My Windows Application" "Z:/data/my-installer.iss"'

docker run \
    --rm \
    -it \
    --entrypoint sh \
    -v /local/path/to/acs.json:/etc/aas-codesign/acs.json \
    -v /local/path/to/azure.json:/etc/aas-codesign/azure.json \
    -v /local/path/to/build-folder:/data \
    jotools/innosetup

The following example will

• run the Docker Image jotools/innosetup⁠
• use a codesigning certificate .pfx and configuration pfx.json stored on the host machine
• mount a folder on the host machine into /data
  that should include
  • the application to be packaged in a windows installer
  • the InnoSetup script my-installer.iss
• use entry point iscc.sh
• run InnoSetup to create a codesigned windows installer

docker run \
    --rm \
    -v /local/path/to/pfx.json:/etc/pfx-codesign/pfx.json \
    -v /local/path/to/my-certificate.pfx:/etc/pfx-codesign/certificate.pfx \
    -v /local/path/to/build-folder:/data \
    -w /data \
    --entrypoint iscc.sh \
    jotools/innosetup \
    '"/SCodeSignScript=Z:/usr/local/bin/pfx-codesign.bat \$f" /O"Z:/data" /Dsourcepath="Z:/data/My Windows Application" "Z:/data/my-installer.iss"'

The following example will

• use a codesigning certificate .pfx and configuration pfx.json stored on the host machine
• mount a folder on the host machine into /data
• run the Docker Container interactively (removing it after)
  • use entry point sh
  • you then can manually create a codesigned windows installer, e.g.:
    iscc.sh '"/SCodeSignScript=Z:/usr/local/bin/pfx-codesign.bat \$f" /O"Z:/data" /Dsourcepath="Z:/data/My Windows Application" "Z:/data/my-installer.iss"'

docker run \
    --rm \
    -it \
    --entrypoint sh \
    -v /local/path/to/pfx.json:/etc/pfx-codesign/pfx.json \
    -v /local/path/to/my-certificate.pfx:/etc/pfx-codesign/certificate.pfx \
    -v /local/path/to/build-folder:/data \
    jotools/innosetup

The following example will

• run the Docker Image jotools/innosetup⁠
• mount a folder on the host machine into /data
  that should include
  • the application to be packaged in a windows installer
  • the InnoSetup script my-installer.iss
• use entry point iscc.sh
• run InnoSetup to create a windows installer

docker run \
    --rm \
    -v /local/path/to/build-folder:/data \
    -w /data \
    --entrypoint iscc.sh \
    jotools/innosetup \
    '/O"Z:/data" /Dsourcepath="Z:/data/My Windows Application" "Z:/data/my-installer.iss"'

The following example will

• mount a folder on the host machine into /data
• run the Docker Container interactively (removing it after)
  • use entry point sh
  • you then can manually create a windows installer, e.g.:
    iscc.sh '/O"Z:/data" /Dsourcepath="Z:/data/My Windows Application" "Z:/data/my-installer.iss"'

docker run \
    --rm \
    -it \
    --entrypoint sh \
    -v /local/path/to/pfx.json:/etc/pfx-codesign/pfx.json \
    -v /local/path/to/my-certificate.pfx:/etc/pfx-codesign/certificate.pfx \
    -v /local/path/to/build-folder:/data \
    jotools/innosetup

Storing secrets in plaintext files poses significant security risks, including:

• Exposure to unauthorized users if file permissions are not properly set.
• Inclusion in backups or version control (e.g., Git), leading to unintentional leaks.
• Easy access for malware or attackers on a compromised system.

Instead of storing secrets in a .json configuration file, consider these more secure approaches:

1. Use OS-Level Secret Storage

   • macOS: Store secrets in Keychain Access and retrieve them using the security CLI tool.
   • Linux: Use GNOME Keyring or KWallet to securely store and retrieve secrets.
   • Windows: Store credentials in Windows Credential Manager and access them via PowerShell.

2. Use a Secrets Manager

   • Cloud providers like AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager offer secure, centralized secret storage with access control.
   • Local alternatives like 1Password CLI, Bitwarden CLI, or HashiCorp Vault allow secure retrieval of secrets at runtime.

3. Use GitHub Actions Secrets (for CI/CD Pipelines)

• If using this Docker Container in GitHub Actions, store secrets securely in GitHub Secrets.
• Reference secrets in workflows using ${{ secrets.MY_SECRET }} instead of storing them in the repository.