-
Notifications
You must be signed in to change notification settings - Fork 312
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
Verify yaml #4639
Verify yaml #4639
Conversation
Overall package sizeSelf size: 8.26 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | @datadog/libdatadog | 0.2.2 | 29.27 MB | 29.27 MB | | @datadog/native-appsec | 8.3.0 | 19.37 MB | 19.38 MB | | @datadog/native-iast-taint-tracking | 3.2.0 | 13.9 MB | 13.91 MB | | @datadog/pprof | 5.4.1 | 9.76 MB | 10.13 MB | | protobufjs | 7.2.5 | 2.77 MB | 5.16 MB | | @datadog/native-iast-rewriter | 2.6.0 | 2.58 MB | 2.72 MB | | @opentelemetry/core | 1.14.0 | 872.87 kB | 1.47 MB | | @datadog/native-metrics | 3.0.1 | 1.06 MB | 1.46 MB | | @opentelemetry/api | 1.8.0 | 1.21 MB | 1.21 MB | | import-in-the-middle | 1.11.2 | 112.74 kB | 826.22 kB | | source-map | 0.7.4 | 226 kB | 226 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | lru-cache | 7.18.3 | 133.92 kB | 133.92 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | @datadog/sketches-js | 2.1.0 | 109.9 kB | 109.9 kB | | semver | 7.6.3 | 95.82 kB | 95.82 kB | | lodash.sortby | 4.7.0 | 75.76 kB | 75.76 kB | | ignore | 5.3.1 | 51.46 kB | 51.46 kB | | shell-quote | 1.8.1 | 44.96 kB | 44.96 kB | | istanbul-lib-coverage | 3.2.0 | 29.34 kB | 29.34 kB | | rfdc | 1.3.1 | 25.21 kB | 25.21 kB | | @isaacs/ttlcache | 1.4.1 | 25.2 kB | 25.2 kB | | tlhunter-sorted-set | 0.1.0 | 24.94 kB | 24.94 kB | | limiter | 1.1.5 | 23.17 kB | 23.17 kB | | dc-polyfill | 0.1.4 | 23.1 kB | 23.1 kB | | retry | 0.13.1 | 18.85 kB | 18.85 kB | | jest-docblock | 29.7.0 | 8.99 kB | 12.76 kB | | crypto-randomuuid | 1.0.0 | 11.18 kB | 11.18 kB | | path-to-regexp | 0.1.12 | 6.6 kB | 6.6 kB | | koalas | 1.0.2 | 6.47 kB | 6.47 kB | | module-details-from-path | 1.0.3 | 4.47 kB | 4.47 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
BenchmarksBenchmark execution time: 2024-12-13 21:15:16 Comparing candidate commit b5c8eb2 in PR branch Found 1 performance improvements and 0 performance regressions! Performance is the same for 262 metrics, 3 unstable metrics. scenario:plugin-graphql-with-depth-and-collapse-on-18
|
@@ -16,6 +16,10 @@ concurrency: | |||
|
|||
jobs: | |||
aerospike-node-16: | |||
strategy: | |||
matrix: | |||
node-version: [16] |
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.
Seems like node-version is not actually used?
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.
Yeah, it's for validation in the script. I'm gonna try to work out a better way of expressing this though.
a9149f6
to
6c1a50f
Compare
node-version: [16, 18, 20, 22] | ||
runs-on: ubuntu-latest | ||
steps: | ||
- uses: actions/checkout@v4 |
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)
Pin third party actions by hash, or at least by tag for trusted sources
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 will use 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.
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.
Shouldn't actions
always be a trusted org? If we can't trust GitHub then why is our code on GitHub?
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.
Can we just disable this entirely? It just complains about everything, making it effectively useless as it just pollutes PRs with dozens of comments like this constantly everywhere.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4639 +/- ##
==========================================
- Coverage 65.05% 64.85% -0.20%
==========================================
Files 304 127 -177
Lines 13950 4146 -9804
==========================================
- Hits 9075 2689 -6386
+ Misses 4875 1457 -3418 ☔ View full report in Codecov by Sentry. |
97d938b
to
f302e1e
Compare
.github/workflows/project.yml
Outdated
steps: | ||
- uses: actions/checkout@v4 | ||
- uses: ./.github/actions/install | ||
- uses: actions/setup-node@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)
Pin third party actions by hash, or at least by tag for trusted sources
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 will use 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.
98d2f89
to
1d4c5ed
Compare
f93c231
to
1bbc567
Compare
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.
Seems better than what we have today. That said I'm not sure how a developer can figure out how to fix things based on the resulting error.
@@ -147,3 +147,10 @@ jobs: | |||
- run: yarn type:test | |||
- run: yarn type:doc | |||
|
|||
verify-yaml: |
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.
I think this (and the name of the script file too) could use a more descriptive name of what it's doing. Something like verify-plugin-versions
or anything more descriptive.
b6d1e93
to
c4078f3
Compare
b4c28fe
to
c334ed9
Compare
Note that this now removes support (i.e. no longer instruments) Next.js |
c334ed9
to
5a4d6a9
Compare
5a4d6a9
to
3fa3454
Compare
3fa3454
to
2fcd426
Compare
Do you know why they won't run? According to Next documentation, Next 12 supports Node.js >=12. |
.github/workflows/plugins.yml
Outdated
include: | ||
- node-version: 14 # yes, out of range, but the only way to test the oldest version |
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.
Doesn't that mean that this version isn't supported anymore?
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.
We'd have to take it out of instrumentation as well, not just the GitHub yaml. Meaning we'd never attempt to to instrument those versions. Is that fine?
file: 'dist/next-server/server/serve-static.js' | ||
}, serveStatic => shimmer.wrap(serveStatic, 'serveStatic', wrapServeStatic)) | ||
|
||
addHook({ name: 'next', versions: ['>=11.1'], file: 'dist/server/next-server.js' }, nextServer => { | ||
addHook({ name: 'next', versions: ['>=11.1 <12.0.0', '>=12.2.0'], file: 'dist/server/next-server.js' }, nextServer => { |
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.
This is a breaking change.
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.
For the versions removed from the range (12.0.x
and 12.1.x
), next build
fails, so the tests fail. It doesn't appear that we can test these versions (or that we ever could) so the claim of support was always incorrect.
* add script to verify plugin yaml * add github actions job to verify yaml * fix instrumentations * fix up aerospike * better version ranges for aerospike * fix ci script * make it pass hopefully * update license 3rdparty * fix it no longer assuming nodejs versions * fix aerospike * since node version is now ignored, run on only one version of node
* add script to verify plugin yaml * add github actions job to verify yaml * fix instrumentations * fix up aerospike * better version ranges for aerospike * fix ci script * make it pass hopefully * update license 3rdparty * fix it no longer assuming nodejs versions * fix aerospike * since node version is now ignored, run on only one version of node
* add script to verify plugin yaml * add github actions job to verify yaml * fix instrumentations * fix up aerospike * better version ranges for aerospike * fix ci script * make it pass hopefully * update license 3rdparty * fix it no longer assuming nodejs versions * fix aerospike * since node version is now ignored, run on only one version of node
* add script to verify plugin yaml * add github actions job to verify yaml * fix instrumentations * fix up aerospike * better version ranges for aerospike * fix ci script * make it pass hopefully * update license 3rdparty * fix it no longer assuming nodejs versions * fix aerospike * since node version is now ignored, run on only one version of node
Ensures that plugins are tested with the same ranges that they support.