코드 서명 & Notarization

"서명 안 한 앱은 '덜 다듬어진' 게 아냐 — 요즘 OS한텐 '악성코드일지도 모르는 것'이고, 딱 그렇게 대접받아."

서명이 선택이 아닌 이유

요즘 운영체제는 서명 안 된 코드를 경계해. macOS에선 Gatekeeper가 서명 없는 앱을 무서운 다이얼로그로 막거나 아예 열기를 거부하고, Windows에선 SmartScreen이 사용자한테 경고해서 발길을 돌리게 해. 코드 서명은 이 앱을 누가 냈는지 증명하는 암호학적 신원을 붙여서, OS도 사용자도 믿을 수 있게 해줘. 앱 스토어 밖으로 배포하는 거라면 서명은 있으면 좋은 게 아니라 사실상 필수야.

macOS는 두 단계: 서명하고 notarize하고

macOS가 제일 깐깐해. 먼저 Developer ID 인증서로 서명해(Apple Developer 계정이 필요하고, 연 ~$99). 그다음 notarize해. 서명한 앱을 Apple에 올리면 악성코드를 검사하고 앱에 'staple'할 티켓을 발급해줘. notarization 없이는 서명한 앱도 요즘 macOS에선 기본적으로 막혀. Apple 자격증명을 환경 변수로 주면 Tauri가 notarization까지 대신 돌려줘 — 보통은 CI에서, 절대 코드에 박아넣지 말고.

Windows랑 CI의 현실

Windows 서명은 코드 서명 인증서를 써(점점 EV나 클라우드 HSM 기반으로 가고 있어). Linux는 AppImage나 deb에 보통 서명이 필요 없지만, 저장소는 저마다 자기 서명 체계가 있고. 이 모든 걸 실제로 굴리는 방식은 이래. 서명 신원이랑 Apple 자격증명은 CI 시크릿에 두고, 릴리스 워크플로가 알아서 서명하고 notarize하게 해. 릴리스가 서명 신원의 유일한 사본을 가진 개발자 한 명의 노트북에 매달리는 상황은 절대 만들고 싶지 않을 거야.

Code

환경 변수로 macOS 서명이랑 notarization (CI 시크릿에)·bash

# macOS: Tauri가 서명 + notarize에 쓰는 자격증명 (코드 아니라 CI에 설정).
export APPLE_CERTIFICATE="<네 .p12의 base64>"
export APPLE_CERTIFICATE_PASSWORD="<비밀번호>"
export APPLE_SIGNING_IDENTITY="Developer ID Application: Your Name (TEAMID)"
export APPLE_ID="you@example.com"
export APPLE_PASSWORD="<앱 전용 비밀번호>"   # notarization용
export APPLE_TEAM_ID="TEAMID"

npm run tauri build   # 이것들 있으면 서명하고 notarize해

Exercise

먼저 내보낼 OS의 서명 계획을 써봐. macOS면 어떤 계정, 어떤 인증서, 그리고 두 단계(서명하고 notarize하기). Windows면 어떤 종류 인증서고 그게 없으면 SmartScreen이 뭘 하는지. 그다음 시크릿이 각각 어디 있어야 하는지 말해(힌트: 네 레포는 아냐). 바이너리를 사용자가 겁 없이 열 수 있는 물건으로 바꿔주는 신뢰의 층을 지도로 그리는 거야.

Hint

macOS는 Apple Developer 계정 → Developer ID 인증서 → 서명 → notarize(Apple에 업로드) → staple. Windows는 코드 서명 인증서(EV가 평판을 더 빨리 쌓아). 시크릿은 CI의 암호화 저장소에 두고 빌드할 때 환경 변수로 불러와.