ci: a publish_snapshot.yml dry run still passes the Nexus secrets to the build
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
Research direction
Read publish_snapshot.yml and inspect the Build and install step’s environment and the dry_run conditions described in the issue. Confirm how the workflow handles credentials for both dry runs and publishing runs, then make sure a dry run does not expose the Nexus secrets while normal publishing still can deploy; review the workflow diff for both paths.
Written by the indexing model from the issue text.
Description
What is the problem?
publish_snapshot.yml has a dry_run input that builds and verifies the jars without deploying them. A dry run skips the "Configure Maven server credentials" step and uses the install goal, but the Build and install step still sets both Nexus secrets in its environment:
- name: Build and ${{ inputs.dry_run && 'install' || 'deploy' }}
env:
NEXUS_USER: ${{ secrets.NEXUS_USER }}
NEXUS_PW: ${{ secrets.NEXUS_PW }}
GOAL: ${{ inputs.dry_run && 'install' || 'deploy' }}
So a dry run is not credential-free. Maven, its plugins and the build scripts they run can all read NEXUS_USER and NEXUS_PW, though a dry run never needs them.
This is hardening, not a known leak. The secrets are repository Actions secrets, and anyone with write access can already run a modified workflow that uses them. The point is that a run advertised as safe to try, and one that changes allows in a fork (if: github.repository == 'apache/datafusion-comet' || inputs.dry_run), should not carry the publishing credentials at all.
Proposal
Make a dry run credential-free. The smallest change is to leave the variables empty when dry_run is set:
NEXUS_USER: ${{ inputs.dry_run && '' || secrets.NEXUS_USER }}
NEXUS_PW: ${{ inputs.dry_run && '' || secrets.NEXUS_PW }}
A stronger form builds and verifies the jars in one job with no secrets, uploads them, and deploys from a second job that has the secrets and runs only deploy on the verified output. That also keeps the credentials away from the five-variant clean and compile loop in a real run.
Raised in review of #7311, which does not touch this file.
- Dominant language
- Scala
- Stars
- 1.3k
- Forks
- 398
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 363
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/datafusion-comet
-
area:ci bug priority:low requires-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/datafusion-comet#7315 ·
Maintainers usually reply within 2 days
-
requires-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/datafusion-comet#7240 ·
Maintainers usually reply within 2 days
-
bug priority:low
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
apache/datafusion-comet#7176 ·
Maintainers usually reply within 2 days
-
docs: update Scala comments that reference the removed iceberg-writes.md pagePossibly taken A pull request linked to this issue is open or already merged. Openenhancement
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
apache/datafusion-comet#7101 ·
Maintainers usually reply within 2 days
-
requires-triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
apache/datafusion-comet#7001 ·
Maintainers usually reply within 2 days
All issues in apache/datafusion-comet
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
lichess-org/lila#22324 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
canton-network/splice#8087 ·
Maintainers usually reply within 1 day