AUR은 사용자들이 만든 PKGBUILD 모음일 뿐이라는 걸 받아들여야 함
AUR에서 설치하는 모든 PKGBUILD의 소스를 반드시 검토해야 하고, 업데이트도 예외가 아님. 이건 10년도 넘게 계속 논의돼 온 전제라서, yay 같은 공식 AUR 헬퍼가 없는 이유도 여기에 있음
Arch Linux가 엘리트주의적이라는 불평도 많지만, 현실적으로는 자신이 뭘 하는지 알고 매 단계에서 손잡아 주길 원하지 않는 사람들을 위한 배포판임. 무작위 AUR 패키지를 설치해서 시스템을 망가뜨리거나 침해당했다면 본인 책임이라는 뜻이기도 함
다만 누구나 AUR 패키지를 인수할 수 있게 두는 시대는 끝날 수도 있음. 매번 영향을 받은 패키지를 되돌리는 비용만 봐도 너무 큼. 대안으로 모든 인수 요청을 검토하는 건 너무 부담스럽고, 매번 도움이 된다는 보장도 없음

AUR에서 설치하는 모든 PKGBUILD 소스를 검토해야 한다면, 그건 브라우저 확장, VSCode 확장, NuGet 패키지, Cargo 크레이트, Python 패키지, npm 패키지 등에도 똑같이 적용되는 것 아닌가 싶음
인터넷 접근이 없거나 공개돼도 상관없는 것에만 접근하는 곳에서 실행하지 않는 한 그렇다고 봄
AUR은 아닐 수도 있지만, 다른 생태계는 권한 모델이나 샌드박싱으로 이론적으로 개선 가능함. 브라우저 확장은 그런 선택지가 이미 있지만 “일반” 사용자는 거의 쓰지 않음
안타깝게도 99.99%의 사람은 모든 걸 검토할 수 없거나 그럴 시간이 없음. 신뢰된 메인테이너가 있는 배포판 패키지나, 권한과 어느 정도의 심사가 있는 iOS App Store 같은 곳이 가장 안전해 보임

이게 실제 해결책이라고 보긴 어려움. 이런 공격의 일반적인 흐름은 의존성 어딘가에 페이로드를 숨기는 것이었음
이번 건 PKGBUILD 안에서 아주 성의 없이 npm install을 하는 경우라 좀 특이함. 이제는 AUR 밖의 거의 모든 패키지 저장소도 같은 문제를 갖고 있고, 전체 의존성 사슬을 손으로 감사하는 건 현실적이지 않음
물론 나도 해결책은 없음

사용자 중 아주 일부라도 실제로 이걸 한다고 믿는 건 현실과 심하게 동떨어진 생각임

AUR이 사용자 제작 PKGBUILD 모음이라는 게 PyPI 생태계, npm, Docker Hub 전체와 얼마나 다른가 싶음
사람들은 SELinux를 끄고, --privileged는 seccomp와 AppArmor를 꺼버리며, 샌드박스 탈출 CVE도 존재함

누구나 AUR 패키지를 인수할 수 있었던 건 애초에 있어서는 안 됐음
결국 username/packagename-bin|git 같은 구조가 됐으면 좋겠음. 그러면 사람들이 실제로 무엇을 누구에게서 설치하는지 훨씬 더 명확해질 것임

이쯤 되면 고아 패키지 인수라는 개념 자체가 망가진 건 아닌지, 아예 제거해야 하는 건 아닌지 궁금함
불편하긴 하겠지만, 다른 사람이 버린 패키지를 인수하게 하는 대신 AUR이 새 제출을 강제하고, 일정 기간이 지난 고아 패키지를 정기적으로 삭제하는 편이 나을 수도 있음

나도 방금 감시하던 AUR 패키지 하나가 고아 패키지였다는 이유로 모르는 사람에게 넘어갔다는 알림을 받음

AUR에서 뭔가를 설치할 때 조심해야 하는 건 당연하고, 예전에도 수상한 패키지, 즉 잘못 빌드되거나 잘못 패키징된 것들은 늘 있었지만, 능동적인 악성 삽입을 보는 건 우려됨
AUR에는 두 가지 큰 문제가 있다고 봄. 첫째, 제3자 코드를 대체로 신뢰할 수 있었던 조금 더 평등주의적이던 오픈소스 시대의 잔재라는 점. 둘째, 고아 패키지를 누구나 기존 기록과 검증 이력을 그대로 가진 채 인수할 수 있다는 점
첫 번째 시대는 이미 지났고, 두 번째는 AUR 계정에 더 엄격한 통제를 두거나 AUR 헬퍼 쪽에 추가 보호장치를 넣어 완화할 수 있음. 예를 들어 최근 소유자가 바뀐 패키지라면 크게 무서운 경고를 보여주는 식임. 그래도 그냥 y를 누르고 넘어갈 사람은 있겠지만 없는 것보다는 나음
아니면 AUR 헬퍼를 아예 피하고, 필요한 패키지를 PKGBUILD에서 직접 검토하고 빌드하는 방법도 있음

패키지 인수 정책은 합리적이었던 시대가 단 한 번도 없었음

AUR 헬퍼는 오히려 검토 단계를 작업 흐름에 통합하기 쉽게 해 준다고 봄
검토하라고 적극적으로 물어보고, 마지막으로 위험을 받아들인 뒤 변경이 있었는지도 알려줌
다만 “AUR은 해롭다”는 관점은 새롭지 않음. AUR을 쓰는 사람은 여기의 위험을 이해해야 하고, 사실상 StackOverflow에서 찾은 걸 curl | bash 하는 것보다 한 단계 나은 정도임

이 일이 7시간 넘게 지났는데도 archlinux.org나 aur.archlinux.org에 아직 아무 언급이 없음. 왜 그런지 모르겠음. 사용자가 이 일을 알고 있다는 걸 증명하는 조치를 하기 전까지는 AUR을 막았어야 함
예를 들어 AUR API URL을 살짝 바꿔서 yay/yaourt 사용자가 무슨 일이 있는지 찾아보게 만들 수 있음. 새 API에는 사용자에게 알리고, 진행 전에 메시지를 읽었는지 확인하는 인프라가 있어야 함. 특히 모든 악성코드를 찾았는지도 확실하지 않은 상황에서는 더더욱 필요함
또한 철회되거나 침해된 AUR 커밋 데이터베이스가 있어야 하고, 사용자가 해당 패키지를 설치한 적이 있으면 경고하는 메커니즘도 있어야 함

좋든 나쁘든, AUR에는 이 경고가 항상 존재함
이름 자체에도 들어 있고, 위키 자료에도 AUR은 사용자 저장소이며 맹목적으로 신뢰하면 안 된다고 명확히 안내돼 있음
바로 앞부분의 큰 빨간 상자에 그대로 적혀 있음: https://wiki.archlinux.org/title/Arch_User_Repository
AUR에는 절대 설치하지 않을 것들이 많고, 그 전부를 메일링 리스트에 뿌리는 게 최선이라고 보진 않음
악성 패키지를 설치한 사용자에게 경고하는 아이디어 자체는 싫지 않지만, 구현 가능성이 낮음. AUR에는 상용 도구에 있는 설치 추적이 없기 때문임. 누가 어떤 패키지를 설치했는지 어떻게 알 수 있겠음? AUR은 기본적으로 패키지 위치 전화번호부에 가깝고, 로그인이나 인증 정보를 요구하지도 않음
그래서 경고는 사용자가 주의를 기울이면 실행할 수 있는 도구에서 나와야 하고, 실제로 주의를 기울이라고 요구함. 예: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...

그러면 안 됨. 일부 사람이 기본적인 보안 조언을 진지하게 받아들이지 않는다고 해서 모두의 작업 흐름을 깨면 안 됨
새 API가 사용자에게 알리고 읽었는지 확인하게 한다는 건 대체 어떻게 동작해야 하나? AUR 패키지는 그냥 git 저장소이고, AUR 헬퍼가 무엇을 하거나 하지 않는지는 Arch 메인테이너가 통제할 수 없음

AUR 첫 페이지에는 공지가 올라가는 게 맞다고 봄. 개인적으로는 Arch 홈페이지에 짧은 안내와 AUR 페이지 공지 링크가 있어도 도움이 될 것 같음
알려진 영향 패키지를 전부 나열하고 싶지 않다면, 최소한 AUR 패키지를 쓰는 사람은 사용하는 모든 패키지의 모든 파일을 읽어야 한다는 공식 입장이라도 권고해야 함

Socket.dev의 수치를 신뢰할 수 있다면, 영향은 다행히 꽤 작아 보임
말이 되는 면도 있음. 영향 목록에 있는 패키지 일부는 알고 있는데, 심하게 오래됐고 상류 프로젝트도 더는 유지되지 않음
전체 피해자가 얼마나 되는지는 모르지만 AUR 팀은 정확한 숫자를 가지고 있을 가능성이 큼. 영향도에 맞게 최선을 다해 처리하고 있을 거라고 봄

이런 일은 결국 피할 수 없게 됐고, 변화가 없다면 더 자주 일어날 가능성이 큼. AUR PKGBUILD 시스템은 매우 좋아하고, 직접 작성할 때도 자주 활용함
가장 심각하면서도 고치기 쉬운 문제는, 고아 패키지를 누구나 인수할 수 있는데 그 사실이 최종 사용자에게 전혀 알려지지 않는다는 점임
패키지를 삭제시키는 건 들이는 수고에 비해 얻는 게 적어서, 통제권을 내려놓는 최적의 방법이 고아 패키지로 만드는 쪽이 됨. 이건 반대여야 한다고 봄. 적어도 사용자는 패키지가 고아가 됐다는 사실을 분명히 알아야 함
이 부담은 paru나 yay 같은 AUR 헬퍼 쪽에 더 있을 수도 있고, 그런 변경을 해 주길 권장함

이건 패키지가 설치됐는지만 확인하지, 설치된 버전이 감염됐는지는 확인하지 않음
아마도 나처럼 한동안, 몇 달 동안 yay -Syu를 실행하지 않았다면 괜찮은 거겠지? …그렇겠지?
젠장, Arch를 다시 설치하게 만들지 말아 줘. 지난번엔 일주일 걸렸음
업데이트: archinstall 좋음. 15분 정도 만에 다시 복구함

그 목록이 완전하다는 보장은 없음
항상 PKGBUILD와 소스를 확인해야 함. AUR은 대체로 신뢰할 대상이 아님. 오히려 이런 침해가 더 일찍 일어나지 않았다는 게 더 놀라움

pacman은 날짜 로캘을 지원하므로, 9 Jun을 검색하는 방식은 영어 로캘이나 비슷한 형식을 쓰는 로캘에서만 동작함
내 환경에 맞게 고친 뒤에는 jd-gui가 걸렸지만, 실제로는 침해 약 두 시간 전에 jd-gui-bin을 설치했음. 내가 그날 밤 게을러서 소스 컴파일을 기다리지 않고 -bin 패키지를 선택한 덕분에 운이 좋았던 것 같음

초보 질문인데, 이게 Arch나 공식 출처에서 나온 게 아닌데 어떻게 신뢰할 수 있는지 알 수 있나?
저 스크립트에는 이해하기 어려운 부분이 많아서, 코드를 읽는 것만으로 안전한지 쉽게 판단할 수 없음
공식 Arch 개발자 쪽의 반응이나 해결책을 기대하게 됨

저장소 README 아래쪽의 별 그래프가 마음에 듦
이런 대형 악성코드 공격에 얽힌 긴박감과 중요도를 잘 전달함

약 10년 전 Arch Linux에서 에뮬레이터인 Mednafen을 설치했던 기억이 있음. 프로그램이 실행되지 않았는데, 내 시스템에 없는 라이브러리에 링크돼 있었기 때문임
알고 보니 메인테이너가 자기 시스템에서 소프트웨어를 빌드했고, 그 시스템에 있던 라이브러리가 사용됐지만 의존성에는 적혀 있지 않았음
공식 유지 패키지였고, 이런 건 전용 빌드 서버에서 만들어진다고 늘 생각했지 임의의 자원봉사자나 집 컴퓨터에서 빌드된다고는 생각하지 않았음. Arch가 아직도 같은 방식으로 빌드하는지는 모르겠지만, 그 일이 충분히 무서워서 배포판을 바꾸게 됨

pkgctl build를 써도 이런 일은 생길 수 있음. makedepends=가 전이적으로 빌드 환경에 공유 라이브러리를 끌어왔지만, depends=에는 빠져 있는 경우임 .so 의존성이 감지되면 경고는 있지만, 그걸 보고 조치하는 건 메인테이너 몫임
안전성과 보안 측면에서 Arch Linux는 재현 가능한 빌드 프로젝트를 이끄는 축 중 하나였고, 운영체제의 상당 부분은 해당 바이너리가 실제로 소스 코드에서 빌드됐는지 독립적으로 검증할 수 있음. 공식 패키지의 감사 체계는 NixOS보다 강하고 Debian과 비슷한 수준임: https://reproducible.archlinux.org/
다만 이 모든 건 이번 AUR 사건과는 전혀 별개임

이런 일을 잡기 위해 깨끗한 이미지에서 패키지를 빌드하고 설치해 볼 수 있는 도구가 있음. 예를 들면 pkgctl임
메인테이너라면 게시 전에 이런 도구를 꼭 써야 함

비교적 최근까지는 이런 방식이 일반적이었음. Debian도 오랫동안 그렇게 운영했고, 2019년에야 완전히 금지했음

이 문제의 해결책은 뭘까? 이런 패키지는 네트워크 접근 없는 Docker 컨테이너 안에 설치해야 하나? 이게 AUR에만 한정된다고 가정하면 안 된다고 봄
2026년에는 모든 소프트웨어 출처를 의심해야 함. 특히 바이브 코딩이 확산된 상황에서는 더 그렇고, 폐쇄형 소프트웨어는 블랙박스라서 오픈소스보다 더 큰 난장판임

신뢰할 수 없는 “앱 스토어”는 AUR, Flatpak 등을 포함해 샌드박스 안에 있어야 함. 기본값이나 선택지로 최소한 가상 머신 정도는 필요해 보임

말하기 싫지만 Qubes OS 사람들이 맞았음. 해결책은 앱을 가상 머신으로 적극적으로 격리하는 것임
마음먹고 갈아타면 배터리 수명이 얼마나 나빠질지 아는 사람 있나?