GitHub Actions 워크플로 잠금 파일 공개, SHA 핀 대신 태그로 의존성 고정

다른 사람 블로그에서 본 건데, 태그를 안 옮기는 저장소 주인을 믿는 대신 커밋 해시를 머지한 사람이 그게 진짜 원본 저장소 릴리스인지 확인했다고 믿는 거래. 포크도 같은 저장소라서 아무 커밋이나 핀할 수 있음. 깃허브가 마켓플레이스에 불변 태그를 강제했으면 좋겠음.

잠금 파일이 바로 그걸 막아줌. 가짜 커밋은 잠글 수 없게 되어 있고 그게 맞는 기본값임. 기존 해시 핀 방식은 이 구멍이 있어서 추가 검사가 필요했고.

근데 액션이 셸 스크립트를 돌려서 docker pull abc:latest 하는 건 못 막음. 소비자 입장에서는 코드 전체를 뜯어보기 전엔 알 수가 없더라.

포크에 대한 그 황당한 취급은 진짜 잊고 있었음. 그냥 마켓플레이스 태그를 다른 데처럼 불변으로 만들면 안 되나?

사람들이 깃 액션을 임포트해서 업데이트할 일이 실제로 있나? 보통 한 줄짜리 bash인데. 그냥 설정에 복붙해서 완전히 통제하는 게 낫지 않나.

깃허브 액션이 그렇게 단순하지가 않음. 한 줄 bash로 끝나야 할 일이 수십 줄 주문과 엣지 케이스 처리가 되는 경우가 많아서 액션이 도움이 됨.

잠근 의존성이 자기 의존성은 안 잠그고 악성 태그를 끌어오는 건 막아주나?

못 막음. foo/setup-latest-go를 잠가도 최신 go를 끌어오는 건 그대로고, 액션 엔트리포인트가 무슨 짓이든 할 수 있음.

zizmor 관리자로서 현재 잠금 파일의 한계를 짚자면, 재사용 워크플로 호출은 잠그지 못해서 직접 해시 핀을 유지해야 하고 컴포지트 액션은 호출 지점을 통해서만 간접적으로 잠김. 그래서 기본 gh actions-lock이 컴포지트 액션 자체의 해시 핀을 지워버리는 게 위험하고, 도커 이미지나 npx 같은 내부 변경도 못 잠금.

runs-on도 이미지인데 다들 ubuntu-latest로 두고 그날 깃허브가 넣은 걸 그대로 받아들임. 러너 이미지 리비전을 다이제스트로 지정하는 건 아예 불가능한 것 같고.

커밋 SHA 핀 대신 이걸 쓸 이유가 뭐임?

간접 의존성 때문일 거임. 액션 X를 핀해도 그 액션이 Y의 SHA를 제대로 안 잠그면 태그가 옮겨질 때 털리는데, 잠금 파일은 직접 의존성과 간접 의존성을 다 잠금. 버전 번호 정보도 남고 SemVer면 업그레이드도 쉬움.

결국 SHA 핀에 버전 주석 붙이던 걸 단계만 늘린 거 아님? 태그를 다시 쓰고 SHA는 별도 파일로 옮겨서 검증해야 하는데 뭐가 나아진 건지 모르겠음.

잠금 파일을 워크플로에서 검증 안 하면 act로 로컬 실행하거나 수동으로 돌릴 때 여전히 위험함. 러너가 플랫폼 차원에서 처리해야 할 일이고 이건 SHA 핀처럼 우회일 뿐임.

SHA 핀 써도 액션 자체 의존성이 SHA로 안 잠겨 있으면 소용없다는 얘기를 봤는데 이 잠금 파일도 그건 못 막는 것 같음. 난 아예 서드파티 액션을 안 씀.

블로그 글과 깃허브 릴리스 공지를 아무도 안 읽나? 이건 간접 의존성까지 잠그는 깃허브 1st party 기능임.

액션 자체를 피하는 게 낫다고 봄. 여기 안 좋은 역사가 길어서.

액션 대신 뭘 쓰라는 거임? 빌드 오케스트레이터에 제대로 세팅하면 요즘은 더 싸고 쉽고 UI 편의만 조금 잃음.