-
Notifications
You must be signed in to change notification settings - Fork 7
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
Github action fix - Caching #156
base: main
Are you sure you want to change the base?
Conversation
.github/workflows/test_workflow.yml
Outdated
@@ -559,6 +559,11 @@ jobs: | |||
sudo apt remove -y g++ | |||
sudo apt autoremove -y | |||
sudo apt install -y curl zip unzip clang make build-essential | |||
- name: Cache JDK Downloads | |||
uses: actions/cache@v3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
When using a third party action, one needs to provide its GitHub path (owner/project
) and can eventually pin it to a Git ref (a branch name, a Git tag, or a commit hash).
No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
🔧 Report generated by pr-comment-scanbuild Scan-Build Report
Bug Summary
Reports
|
b764e98
to
7a80348
Compare
@@ -565,27 +565,35 @@ jobs: | |||
with: | |||
distribution: 'temurin' | |||
java-version: "11" | |||
- name: Cache JDK Downloads | |||
uses: actions/cache@v3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
When using a third party action, one needs to provide its GitHub path (owner/project
) and can eventually pin it to a Git ref (a branch name, a Git tag, or a commit hash).
No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
Test caching the download of zing
7a80348
to
951eabb
Compare
uses: actions/cache@v3 | ||
with: | ||
path: /home/runner/jvm | ||
key: ${{ runner.os }}-zing-jdk-${{ matrix.java_version }}-v0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jbachorik any reason not to add caching to the JDK downloads ?
I would need to adjust this to all the jobs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caching the jdk binaries would be useful. We would key on the distro/version/arch but that should speed up builds significantly.
Test caching the download of zing
What does this PR do?:
Motivation:
Additional Notes:
How to test the change?:
For Datadog employees:
credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance
.Unsure? Have a question? Request a review!