npm v12의 예정된 호환성 깨짐 변경

 (github.blog)
1P by GN⁺ | ★ favorite | 댓글 1개
  • npm v12에서 npm install의 보안 관련 기본값이 자동 실행·해석에서 명시적 허용 방식으로 바뀌며, npm 11.16.0 이상에서 경고로 사전 확인 가능
  • allowScripts 기본값이 꺼짐으로 바뀌어, 명시적으로 허용하지 않은 의존성의 preinstall, install, postinstall 스크립트와 암묵적 node-gyp rebuild, git·file·link 의존성의 prepare 스크립트 실행 차단
  • npm approve-scripts --allow-scripts-pending로 차단될 패키지를 확인하고, npm approve-scripts와 npm deny-scripts로 허용·차단을 정한 뒤 생성된 allowlist를 package.json에 커밋해야 함
  • --allow-git 기본값이 none으로 바뀌어, --allow-git로 명시적으로 허용하지 않은 직접·전이 Git 의존성 해석 중단
  • Git 의존성의 .npmrc가 --ignore-scripts 사용 중에도 Git 실행 파일을 덮어쓸 수 있는 코드 실행 경로 차단
  • --allow-remote 기본값이 none으로 바뀌어, --allow-remote로 명시적으로 허용하지 않은 https tarball 같은 원격 URL 의존성 해석 중단
  • --allow-file과 --allow-directory의 기본값은 npm v12에서 변경 없음
  • 준비 절차는 npm 11.16.0 이상으로 업그레이드한 뒤 일반 설치를 실행해 경고를 검토하고, 신뢰하는 패키지만 승인하며, 업그레이드 후 승인된 스크립트만 계속 실행되는 방식
  • 관련 문서: npm approve-scripts, npm deny-scripts, allow-scripts config

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • npm이 GitHub에 인수된 걸 어떻게 놓쳤는지 모르겠지만, 갑자기 많은 일이 이해되기 시작함
    Node 생태계의 이렇게 중요한 부분이 들어갈 곳으로 이보다 더 나쁜 집은 잘 떠오르지 않음

  • postinstall 스크립트는 오래전에 제거됐어야 했고, NPM 패키지의 암 같은 존재임
    뭔가를 가져올 때 깊게 중첩된, 통제되지 않는 postinstall들이 무작위로 실행되는 게 너무 많음
    누가 어느 시점에 이걸 좋은 생각이라고 봤는지 모르겠음

    • post-install 스크립트 우려의 핵심을 잘 이해하지 못하겠음
      보통은 패키지된 의존성 코드를 어차피 어느 시점엔 실행하고, 대개 설치 과정과 같은 권한으로 실행함
      그러면 이런 설정 스크립트들은 좋든 나쁘든 진입점을 npm에서 import나 require가 일어나는 곳으로 옮기면 됨
      전체 생태계가 Deno 같은 샌드박스 환경으로 옮겨가지 않는 한, 기껏해야 작은 걸림돌처럼 보임. 그게 계획일 수도 있겠지만
    • 절대 그렇게 하면 안 되고, 쓸 만한 사례가 많음
      당장 떠오르는 예로 https://www.npmjs.com/package/patch-package가 있음
      지금의 히스테리가 이런 식의 헛된 결정으로 이어지지 않길 바람

  • 이 내용은 10년 전에 공개된 뒤로 NPM 내부에서 수백 번은 논의됐을 것 같음
    Shai Halud 때문에 이제는 무시하기엔 너무 커졌음

    • JavaScript의 역사는 사실상 개발자식 사고방식을 농축한 것 같아서 좋음
      “곧 고칠게요”는 거의 항상 “젠장, 이제 고쳐야 하네”가 됨
    • 좋음, 이제 다음은 Python 차례임

  • 현재 LTS Node 버전들, 기억상 22, 24, 26이 이 보안 수정의 혜택을 받도록 번들 npm을 v12로 올릴 예정인지 궁금함
    지금은 모두 npm v11을 포함하고 있음

    • 과거에도 Node 중간 릴리스에서 npm 메이저 버전 업그레이드가 들어간 적 있음
      v18.19.0[1]과 v20.10.0[2]에서 npm 9를 10으로 올렸음
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • 기본값 변경이라 보안 태세 변화로 볼 수는 있지만, 보안 수정 자체는 모두가 이미 적용 가능함
      글에 나온 대로 적절한 기본값을 설정하면 끝임
      이 변화의 가장 좋은 점은, 기본값이 바뀌면서 새 개발자들이 그냥 install을 실행했을 때 이런 설정이 켜져 있다고 가정하는 성가신 패키지들이 즉시 깨지는 걸 보게 된다는 것임
      예를 들어 스크립트가 실행 가능하다고 기대하는 관행을 멈추게 만들 수 있음

  • 글만 봐서는 명확하지 않지만, 스크립트 허용 목록이 전역 설정이 아니라 패키지별 허용을 지원하는 것 같음
    특정 패키지에만 스크립트를 허용하는 조직 단위 규칙을 유지하기 쉬워질 듯함
    이런 식으로 패키지 관리자 설정에서 안전하지 않은 기본값을 막는 데 쓸 수 있는 린터가 있는지 궁금함

    • grep이면 되지 않나?

  • 아직도 Yarn을 쓸 이유가 있는지 궁금함
    Yarn도 공급망 공격을 막는 보호 장치를 구현했는지 모르겠음
    지금까지는 pnpm만 알고 있었는데, npm도 따라온 건 좋음

    • 당연히 있음
      최신 Yarn 릴리스인 4.x는 지나칠 정도로 결정적 동작을 보장하고, 팀 전체에서 일관된 동작을 기대할 수 있음
      기능 면에서는 작은 디테일들이 많고, 익숙해지면 합쳐져서 차이가 커짐
      다음 메이저 릴리스도 더 나은 성능과, 그 성능 개선에 의존해서 지금까지 구현하지 못했던 기능들로 같은 방향을 계속 밀고 갈 예정임
      참고로 Yarn의 리드 메인테이너임
    • 초기부터 v3까지 Yarn을 쓰던 프로젝트에서 일했는데, 엄청 느리지만 동작은 함
      공급망 보호 기능도 있음
      결국 참지 못하고 pnpm으로 옮겼고, CI와 로컬 개발 머신 모두에서 설치가 훨씬 빨라졌음
      LLM의 도움을 받아 마이그레이션하는 데 하루 정도 걸렸음
    • 차별점 중 하나는 선택 가능한 설치 전략으로, 패키지를 node_modules에 풀지 않고 압축 아카이브에서 직접 실행하는 방식임
      https://yarnpkg.com/features/pnp
      Java에서 .class 파일 디렉터리 트리 대신 .jar를 쓰는 것과 꽤 비슷함
      다만 약간 해키하고, 편집기와 도구 지원은 제각각임
      작은 파일 수가 훨씬 적어서, 어쩔 수 없이 Windows에서 작업해야 한다면 특히 더 빠를 수 있음
      아카이브를 git 저장소에 넣을 수도 있어서, 인터넷과 패키지 레지스트리에 대한 의존을 제거할 수 있음
    • NPM이 뭘 하는지는 모르겠지만, Yarn은 NPM보다 의존성 설치가 훨씬 빠름
    • 내 댓글에 반대표를 누르는 사람들은 질문에 답해줘도 됨
      정말 답을 모름

  • npm이 GitHub 소유인 줄 몰랐음
    그럼 여러 가지가 설명됨

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (2020년 3월 16일, 댓글 571개, 1829점) - https://github.blog/news-insights/company-news/npm-is-joinin...
      일부는 시간이 지나고 보니 흥미롭게 읽힘
      최상단 댓글은 “Microsoft가 모든 걸 잘하는 건 아니지만 GitHub 인수는 솔직히 예상보다 훨씬 잘 흘러갔다. GitHub에 Microsoft 중심 정책을 강요하기보다 Microsoft가 제품 관점에서 GitHub의 것들을 더 많이 받아들였다. GitHub는 여전히 별도 회사처럼 운영된다”는 내용이었음
    • NPM 회사는 2020년에 거의 망하기 직전이었음
      벤처 투자를 받았지만 지속 가능한 사업 모델을 찾지 못했음
      GitHub가 생태계를 살리려고 인수했고, 이 인수가 GitHub에 큰 이득을 준 것도 거의 없음
    • 대부분은 이걸 알지만, 진짜로 많은 걸 설명해주는 이유는 GitHub가 Microsoft 소유라는 점임
      그리고 Microsoft는 GitHub를 Azure로 옮겼음
    • GitHub 소유인 건 알고 있었지만, npm 블로그가 아니라 GitHub 블로그의 릴리스 노트를 직접 본 건 이번이 처음임

  • package.json의 허용 목록은 패키지 버전까지 고정하는 건지, 아니면 패키지 이름만 고정하는 건지 궁금함

  • allowScripts 기본값이 꺼짐이라니 좋음
    [시계 확인] 18개월 만에 pnpm을 따라가는 셈인가?

    • Java의 Maven에는 그런 게 없었고, 필요하다고 느낀 적도 없음
      JavaScript 쪽에서는 이게 무슨 목적임?
답변달기