Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

ci: a publish_snapshot.yml dry run still passes the Nexus secrets to the build

Aperta Adatta ai principianti
  • Qualcosa non va?
#7,319 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, scala, yaml
Ambito
ci-cd, security

Direzione di ricerca

Leggi publish_snapshot.yml e controlla l’ambiente dello step Build and install e le condizioni dry_run descritte nell’issue. Verifica come il workflow gestisce le credenziali sia nelle esecuzioni a secco sia in quelle di pubblicazione, quindi assicurati che un’esecuzione a secco non esponga i segreti Nexus, mentre una pubblicazione normale possa ancora eseguire il deployment; controlla il diff del workflow per entrambi i casi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area:ci enhancement priority:low requires-triage

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.

Lingua principale
Scala
Stelle
1.3k
Fork
398
Merge medio
3g 4h
PR unite (30g)
363

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/datafusion-comet

Tutte le issue di apache/datafusion-comet

Issue simili

Altre issue su Scala

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.