-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
+2
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
added
type: enhancement
Proposed improvement
topic: infrastructure
Related to project infrastructure
os: macos
Specific to macOS operating system
labels
Nov 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.