Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Define Apple Developer Program "team ID" via repository variable #995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
per1234 merged 1 commit into arduino:main from per1234:AC_PROVIDER-env
Nov 3, 2025

Conversation

@per1234
Copy link
Contributor

@per1234 per1234 commented Nov 3, 2025

The macOS builds generated by the release workflows are notarized. The Apple Developer Program "team ID" associated with the signing certificate is provided to the Gon notarization tool (which refers to it as the "App Store Connect provider").

Previously, this was defined via a GitHub Actions secret. That implies it is secret information. However, the team ID is public information that can be seen by anyone simply by looking at the notarized application (e.g., using the macOS spctl utility), so there is need to use a secret for purposes of protecting the information.

The reason use of a secret was chosen for this purpose when the notarization system was originally developed was simply that the only alternative at that time was hardcoding the information in the workflow. Since the workflow is intended to be generally applicable even in 3rd party projects (including forks of Arduino projects), whereas the signing credentials are specific to Arduino, it is better to define them separately from the workflow so that it can be used without modification (though unfortunately some hardcoding of such information ended up being introduced to the workflows at at later time).

Since that time, GitHub has introduced the repository variable feature, which is intended to configure repository-specific non-secret information. This is the appropriate mechanism for defining the team ID.

Use of secrets to store non-secret information should be avoided as these have a higher maintenance burden. Likewise, ambiguity about what is truly secret makes it difficult to understand the attack surface of a project's infrastructure, resulting in a lack of focus on the true attack vectors.

The macOS builds generated by the release workflows are notarized. The Apple Developer Program "team ID" associated with
the signing certificate is provided to the notarization tool (which refers to it as the "App Store Connect provider").
Previously, this was defined via a GitHub Actions secret. That implies it is secret information. However, the team ID is
public information that can be seen by anyone simply by looking at the notarized application (e.g., using the macOS
"spctl" utility), so there is need to use a secret for purposes of protecting the information.
The reason use of a secret was chosen for this purpose when the notarization system was originally developed was simply
that the only alternative at that time was hardcoding the information in the workflow. Since the workflow is intended to
be generally applicable even in 3rd party projects (including forks of Arduino projects), whereas the signing
credentials are specific to Arduino, it is better to define them separately from the workflow so that it can be used
without modification (though unfortunately some hardcoding of such information ended up being introduced to the
workflows at at later time).
Since that time, GitHub has introduced the repository variable feature, which is intended to configure
repository-specific non-secret information. This is the appropriate mechanism for defining the team ID.
Use of secrets to store non-secret information should be avoided as these have a higher maintenance burden. Likewise,
ambiguity about what is truly secret makes it difficult to understand the attack surface of a project's infrastructure,
resulting in a lack of focus on the true attack vectors.
@per1234 per1234 self-assigned this Nov 3, 2025
@per1234 per1234 added type: enhancement Proposed improvement topic: infrastructure Related to project infrastructure os: macos Specific to macOS operating system labels Nov 3, 2025
@per1234 per1234 merged commit c2a5278 into arduino:main Nov 3, 2025
8 checks passed
@per1234 per1234 deleted the AC_PROVIDER-env branch November 3, 2025 05:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Labels

os: macos Specific to macOS operating system topic: infrastructure Related to project infrastructure type: enhancement Proposed improvement

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

AltStyle によって変換されたページ (->オリジナル) /