Hacker News 의견들

• GNOME의 비밀 저장소 접근 취약점 논란을 보며, GNOME 팀이 “신뢰되지 않은 앱은 비밀 서비스와 통신할 수 없다”는 보안 모델을 근거로 문제를 부정한 게 웃김
  GNOME은 정말 광대단이 운영하는 프로젝트 같음

  • Wayland는 보안을 이유로 입력 이벤트 가로채기를 막으면서, 정작 이런 문제는 그대로 두는 게 아이러니함
  • 나는 비밀 저장소를 “디스크에 평문으로 저장하면 안 되는 데이터” 정도로 생각했음. 앱 간 격리를 원한다면 가상머신을 쓰는 게 맞음
  • 사용자 권한으로 실행되는 프로그램이 같은 사용자 데이터에 접근할 수 있는 건 당연한 일임. 만약 그게 취약점이라면 리눅스 전체가 뚫린 셈임. 관련해서 xkcd 1200이 딱 맞는 비유임
  • 결국 “의도된 동작, 수정 안 함, 토론 잠금”으로 끝날 문제 같음
  • 요즘은 AI 덕분에 모든 코드를 클라우드에 던져서 직접 감사(audit) 할 수 있으니, 이제 모두가 신뢰할 수 있는 소프트웨어만 쓸 수 있게 되었음 /s

• 누군가 “새로운 버스를 직접 만들겠다”고 하길래, 이미 수십억 대 기기에 배포된 Binder를 재활용하면 어떨까 제안함
  Binder는 안드로이드의 핵심 IPC로, 훨씬 많은 개발자와 검증된 코드가 있음

  • Binder 위에 새 시스템을 만들면 훨씬 견고한 기반을 얻을 수 있음. 게다가 Google이 최근 Rust로 커널용 Binder를 구현해 머지시켰음
    관련 기사: LWN, Rust-for-Linux 메일링
  • 다만 안드로이드 외의 Binder 사용자 공간 구현체는 거의 없음
  • “BSD Binder”나 “Windows Binder”를 검색해봤지만 결과가 없었음. 아마 “serious OS”라는 표현은 농담이었을 듯함
  • Binder가 D-Bus보다 나은지 궁금함. 어떤 점에서 더 좋은지 알고 싶음
  • 언젠가 리눅스 데스크탑에도 Binder가 들어올지도 모름. 안드로이드와 함께

• Hyprwire와 Hyprtavern을 기대했는데, 문서나 테스트가 거의 없음
  이런 프로젝트들이 좋은 출발점이 될 수 있었을 텐데 아쉬움

  • 개발자가 지금 대학교 졸업 시험 기간이라 그런 듯함
  • 글에서도 “아직 준비 중”이라고 여러 번 언급했으니, 완성 후를 기다려볼 생각임

• OpenWrt 개발자들은 이미 오래전에 ubus라는 대안을 만들었음
  참고: ubus 문서, ubus vs dbus 비교
  다만 보안 모델은 거의 없고, OpenWrt 특성상 그럴 만한 이유가 있음

• D-Bus의 문제 중 하나는 브라우저 확장 기능들이 GNOME/KDE와 통신하면서 발생하는 취약점임
  웹사이트 방문만으로도 D-Bus API를 폭주시켜 데스크탑이 멈출 수 있었음
  보안 연구자라면 D-Bus는 정말 탐구할 가치가 있는 영역임

  • “웹사이트가 GNOME이나 KDE와 통합된다”는 게 무슨 의미인지 궁금함
  • 이런 문제는 독립 VM 환경에서는 발생하지 않음

• D-Bus는 리눅스 데스크탑에서 XPC, COM, Android IPC에 가장 가까운 존재임
  하지만 데스크탑 단편화 때문에 통합된 개발 스택을 만들기 어려움
  GNOME용으로 만든 게 KDE에서는 쓸모없고, XFCE나 Sway는 또 따로 놀음

  • KDE는 예전에 DCOP이라는 자체 IPC를 썼지만 지금은 D-Bus로 교체됨
  • D-Bus는 20년이 넘었으니 이제 리부트가 필요함. 하지만 새로운 IPC가 성공하려면 기술보다 사회적 영향력이 더 중요함
  • KDE에는 COM과 비슷한 KParts도 있었음
  • 단편화는 결국 다양한 사용 사례가 존재하기 때문에 생기는 자연스러운 결과임

• KWallet이나 GNOME Keyring 같은 비밀 저장소가 사실상 잠금 해제 상태에서는 모든 앱이 접근 가능하다는 걸 처음 알게 됨
  seahorse GUI로 확인해보니 대부분 Chromium 관련 키나 JetBrains 계정 토큰 정도였음
  평문 비밀번호는 없지만, 악성 앱이 Chromium 데이터를 파고들면 뭔가 더 나올 수도 있겠다는 생각이 듦

  • 어차피 비밀번호를 입력하지 않는다면 메모리에 평문으로 존재할 수밖에 없음
    시스템이 접근 시 알림을 주지 않는다면, 어떤 소프트웨어가 관리하든 큰 차이는 없음

• “왜 굳이 범용 버스 프로토콜이 필요한가?”라는 의문이 있음
  Unix domain socket 위에서 HTTP나 간단한 JSON 프로토콜을 쓰면 충분함
  권한 관리, SSH 포워딩, 컨테이너 마운트 등도 다 지원됨
  D-Bus는 서비스, 인터페이스, 경로, 메서드 등 구조가 복잡한데도 메시지 식별이 불완전하고, 앱별 프로토콜 세부사항을 알아야 함
  결국 프록시 처리도 어렵고, 과도하게 복잡한 시스템임

• D-Bus의 설계가 “가장 뛰어난 솔루션이 꼭 선택되지 않는다”는 무작위성의 법칙을 보여주는 예 같음
  React보다 나은 프레임워크가 수없이 존재하지만, 알려지지 않아 묻히는 것처럼

  • 이런 현상은 종종 사람들이 문제를 완전히 이해하지 못한 채 평가하기 때문임
  • D-Bus가 뜬 건 GNOME과 Red Hat의 연관성 덕분임
  • 사실 “가장 뛰어난” 해법은 존재하지 않고, 각자 다른 트레이드오프 공간에 있을 뿐임. 다른 사람의 노력을 무시하는 태도는 경계해야 함
  • 오픈소스는 대부분 자원봉사자가 만든다. 몇 명이 수천 시간을 투자해 개발하니, 그들이 방향을 결정하는 건 자연스러움. 이런 구조에서는 이상한 결정도 생길 수밖에 없음
  • “더 나쁠수록 낫다”는 말처럼, 선택 과정 자체가 가장 비효율적인 방식으로 이뤄지는 게 현실임

• GNOME이 취약점 보고를 반박하며 Flatpak 샌드박스 접근 제한을 언급한 게, 예전 Microsoft 블로그 글을 떠올리게 함
  게다가 인용문을 스크린샷으로만 올려 복사도 안 되게 한 건 정말 이해할 수 없음

  • Wayland는 루트 권한 없이는 스크린샷을 막지만, D-Bus는 YOLO 정신으로 열려 있음