infra: fait confiance au CA local de Caddy pour l'envoi des artefacts SBOM #78
No reviewers
Labels
No labels
Compat/Breaking
EC01
EC02
EC03
EC04
EC05
EC06
Kind/BDD
Kind/Back
Kind/Bug
Kind/CICD
Kind/Cloud
Kind/Contenu
Kind/Data
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Front
Kind/IA
Kind/Infra
Kind/Monitoring
Kind/Security
Kind/Testing
Portée/Post-jury
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
ops/alerte
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
g2/enervision!78
Loading…
Reference in a new issue
No description provided.
Delete branch "gabriel/77-confiance-caddy-ci"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce que ça change
L'envoi des trois artefacts SBOM échouait systématiquement en CI (« unable to get local issuer certificate » contre le CA auto-signé de Caddy), masqué par
continue-on-error. Comme le projet n'aura pas de nom de domaine public d'ici la fin, jamais de certificat ACME reconnu par un magasin de confiance standard : la chaîne récupère désormais le certificat de la forge à chaque exécution (poignée de main TLS, rien de figé dans le dépôt) et le passe àactions/upload-artifactviaNODE_EXTRA_CA_CERTS.Closes #77
Preuve
Non-régression du script de récupération, rejouée en local (serveur TLS jetable, ne dépend jamais de la forge) :
Sur cette PR (commit
2a9ea0c), la première version cassaitdependances-python(échec à 42s) etdependances-dashboard(échec à 11s) — trop rapide pour un blocage réseau, ce n'était pas le certificat mais${{ github.server_url }}, un contexte jamais utilisé ailleurs dans ce dépôt et que rien ne garantissait peuplé par ce runner. Corrigé (e79bbb0) en adressant la forge en dur, comme partout ailleurs dans le dépôt (bin/fj, ce manuel).Après correction, les 6 tâches de la chaîne sont vertes sur
e79bbb0:dependances-pythontermine en 3m32s — comparable à la durée constatée quand l'envoi allait jusqu'au bout de la poignée de main TLS avant d'échouer sur le certificat (~3m35s sur la PR #56), cohérent avec un envoi qui va cette fois à son terme plutôt qu'un échec instantané. Je n'ai pas pu inspecter le journal détaillé de l'étape elle-même (API de la forge sans endpoint de logs exposé pour ce test) : un pair qui ouvre la page d'exécution peut confirmer l'absence deunable to get local issuer certificateet que les 3 artefacts sont bien listés en pièces jointes — à cocher dans la relecture.Relecture
sbom-applicatif,sbom-outillage,sbom-dashboard) sont bien téléchargeables depuis la page d'exécution de cette PRCe qui suit le code
docs/runbooks/mis à jour, un geste d'exploitation a changéOù regarder en priorité
.forgejo/scripts/confiance-caddy.mjs: première utilisation sans épinglage d'empreinte (confiance à la première connexion). Accepté parce que c'est le même réseau non chiffré que le runner utilise déjà pour joindre la forge — mérite un second avis si quelqu'un voit ça autrement.continue-on-error: trueest conservé sur les trois envois d'artefact, mais son commentaire change de sens : garde-fou général désormais, plus correctif du certificat.https://10.105.200.41est en dur dansci.yml(deux occurrences) plutôt que tirée d'un contexte Actions :${{ github.server_url }}a cassé la première version de cette PR, voir « Preuve ».ci.yml,docs/runbooks/ci.md) — je m'y suis aligné dans le nouveau texte plutôt que d'introduire une troisième numérotation.