Medium - The biggest scandals of NPM Statements

in Trend

원문 - Louis Petrik

Trend 파악을 위한 Medium 기고문 포스팅 - NPM의 가장 큰 스캔들; 자바스크립트 환경의 엄청나게 많은 패키지 모듈들은 개발에 있어서 도움이 됩니다. 그러나 가끔 커뮤니티 전체에 문제를 만들기도 합니다.

left-pad: How the internet was “broken”

Left-pad는 아주 간단한 자바스크립트 라이브러리로 그냥 몇줄의 코드를 포함하고 있을 뿐입니다.

이 라이브러리의 묵적은 문자열의 왼쪽에 공백을 채워넣는 것으로 문자열을 leftPad()함수에 전달하고 공백을 포함하여 전체 문자열의 길이를 숫자로 전달하면 그만큼 왼쪽에 공백을 채워넣어줍니다.

leftPad("foo", 5)
=> "  foo"

leftPad("foo", 7)
=> "    foo"

leftPad("foooo", 5)
=> "foooo"

대단한 일을 하는 라이브러리는 아니지만 매우 인기가 많았고 현재는 자바스크립트에 자체 함수가 있어서 디프리케이티드가 되었습니다.

그러나 left-pad가 엄청 인기 있었을 때 그 때문에 엄청 문제가 된 적이 있었습니다. 2016년 3월 22일에 일어난 일로 273개의 라이브러리를 가진 소유자가 그의 트레이드 마크인 메신저 킥때문에 발생한 논쟁때문에 자신의 모든 패키지를 내려버린 것이죠.

NPM에서 Messenger Kik의 오픈소스 프로젝트에 kik이라는 패키지 이름을 부여하였는데 이는 단순히 NPM에게 저항하기 때문이었습니다. 그 프로젝트의 소유주는 Azer Koçulu 였는데 left-pad를 비롯하여 아주 많은 패키지를 출시했죠.

NPM의 작명 결과 때문에 Koçulu는 매우 기분이 상했고 그의 모든 패키지들을 NPM에서 내려버렸습니다. 거기에 left-pad도 있었죠. 문제는 NPM의 엄청나게 많은 패키지들이 left-pad에 대한 의존성이 있었기 때문에 일반 JS 개발자가 node_module을 설치할 때 동작이 제대로 되지 않았습니다. Left-pad가 영원히 사라졌기 때문에 React, Babel, 기타 등등 패키지 들이 마비되었죠.

event-stream

수많은 패키지들이 연관되어 문제가 되는 것을 봤기 때문에 NPM은 존재하는 패키지를 간단히 제거할 수 없도록 만들었습니다. 하지만 패키지에 권한을 다른 사람에게 쉽게 옮길 수 있닫면 어떤 일이 발생할까요? 이것이 다음 케이스인 ** event-stream ** 입니다. 매주 200만 다운로드를 기록하던 인기 패키지인 event-stream 주인이 관심이 없어져서 right9ctrl이라는 유저에게 메일로 연락을 주고받고 권한을 모두 줘버렸습니다.

이 새로운 패키지 주인이 한 것은 flatmap-stream 이라는 의존성을 추가한 것입니다. 해당 의존성은 올바른 것이 아니며 아직 NPM 공식 페이지에서 볼 수 있습니다. 이 새로운 의존성은 악성 코드를 가지고 있었고 비트코인 지갑인 Copay 앱이 패키지에 포함이 되면 동작을 하는 것이었습니다. 악성코드가 하는 것은 지갑 소유자의 비공개 키를 훔치는 시도를 하고 해커의 서버로 전송하는 것이죠. 이것은 GitHub 유저가 새로운 의존성을 발견하면서 표면에 드러나게 되었습니다.

right9ctrl 이라는 유저의 실수인지 아니면 고의로 한 것인지는 명확하지 않습니다. 그러나 이 사건은 우리에게 교훈을 주죠. Node.js의 환경에서는 NPM 패키지가 쉽게 엔드 유저의 파일 시스템과 네트워크에 접근할 수 있습니다. 쉘 커맨드 또한 아무 문제없이 동작합니다.

그리고 문제는 NPM 환경에서 수백개나 되는 의존성을 사용하는 것이 일반적인 것이라는 겁니다. event-stream이 단독으로 1795의 의존성을 가지고 있으니 훨씬 더 많은 패키지들이 event-stream을 사용하는 것입니다.

is-promise: Is there an error?

네 문제가 있었습니다.

얼마 되지도 않았습니다. 불과 몇주전에 one-liner 라이브러리가 ES6 모듈에서 동작하기 위해 업데이트가 되었습니다. 그러나 새로운 버전은 버그가 있었고 해당 문제가 커져서 create-react-app 까지 영향을 미쳤죠. GitHub에서도 같은 문제가 발견되었습니다.

Must use import to load ES Moudle

이번에도 마찬가지로 사용자들은 분노가 일었죠.

What we could learn from this

NPM같은 패키지 매니저들이 우리에게 업무 효율을 가져다 주지만 우리를 너무 지나치게 편하게 만듭니다. 수많은 패키지들이 매주 수백만 다운로드가 되며 대분은 한줄짜리 코드나 더 짧은 코드로 되어 있습니다. 패키지들이 버그를 포함하거나 혹은 악용되는 것과 같은 위험은 절대로 완벽히 잡히지 않을 겁니다. 그러나 이것을 해결할 수 있는 대안이 하나 있긴 합니다. 크고 중요한 프로젝트의 경우 작은 패키지들을 사용하지 않는 것입니다. 여러분의 프로젝트에 패키지의 코드를 직접 구현하는 것이죠 ( 복사 붙여넣기를 통해서 말이죠 )

그러나 이것은 보안 이슈가 있을 때 해당되는 것이며 코드가 많을 수록 유지보수가 더욱 필요하며 패키지 주인이 그의 코드에 대한 책임이 없게 되는 것이죠. 따라서 위의 제안도 깔끔한 것은 아닙니다.

Summary

  • NPM의 의존성 문제;
  • 버그가 있는 패키지가 있는 경우 연결된 다른 패키지들이 마비가 될 수 있다
  • 특정 패키지에서 비트코인 지갑의 프라이빗 키를 탈취하는 악성코드를 실행할 수 있다
  • 의존성이 너무 많다보니 이런 것이 관리가 안된다
  • Node.js 환경상 패키지에서 너무나 쉽게 엔드 유저의 파일시스템/네트워크에 접근할 수 있다.
  • 이 때문에 디노에서는 위의 문제를 탈피하고자 package.json 을 없앴다.

© 2019. All rights reserved.

Powered by Hydejack v8.1.1