배포 프로세스를 자동화해야하며 도구가 릴리스 아티팩트에 자동으로 서명합니다. 내 키 링에는 하위 키를 만드는 데만 사용되는 기본 키와 두 개의 하위 키가 있습니다. 서명을위한 하나의 하위 키와 암호화를위한 하나의 하위 키.
현재 모든 키에 단일 패스 문구가 있습니다. 기본 키를 위험에 빠뜨리므로 구성 파일에이 암호 문구를 지정하고 싶지 않습니다.
그래서 다음을 수행하여 하위 키에 다른 암호 문구를 설정한다고 생각했습니다.
$ gpg --edit-key [subkey-id]
gpg> passwd
gpg> save
그러나 이것은 다른 키의 암호 문구도 변경했습니다.
개별 키에 대해 별도의 암호 문구를 설정하려면 어떻게해야합니까?
답변:
GnuPG에서는 하위 키에 대한 개별 비밀번호 문구를 설정할 수 없습니다. 그러나이 경우에는 좋은 연습 아이디어처럼 보이는 해결 방법이 있습니다.
선택한 하위 키를 내 보냅니다 (이 예에서 하위 키의 ID는 0xDEADBEEF). 느낌표를 잊지 마십시오. GnuPG는 실제로 기본 키가 아닌 하위 키 자체에서 작동합니다.
gpg --export-secret-subkeys 0xDEADBEEF! >subkeys.pgp
하위 키에는 공개 기본 키와 개인 기본 "키 스텁"이 연결되어 있지만 개인 기본 키 자체는 포함되지 않습니다.
하위 키를 다른 GnuPG 홈 디렉토리로 가져옵니다. 이 예제에서는 프로젝트 루트 디렉토리에 있고 etc키 링과 같은 폴더가있을 것으로 예상합니다 .
gpg --homedir ./etc/gnupg --import subkeys.pgp
분리 된 하위 키의 암호를 변경하십시오.
gpg --homedir ./etc/gnupg --edit-key 0xDEADBEEF
"일반적인"키링을 사용하는 대신 위에 언급 된대로 항상 별도의 GnuPG 디렉토리를 참조하십시오.
대안으로, 자신의 키로 서명 한 프로젝트 키를 만드는 것을 고려할 수 있습니다. 이는 다른 기고자 / 사용자가 키에 서명 할 수 있다는 장점이 있으며 (따라서 이것이 실제로 프로젝트에 사용 된 키임을 증명할 수 있음) 다른 사람이 유지 보수를 인수 할 경우 프로젝트를 넘겨주는 것이 더 쉬울 수 있습니다.
gpg-agent. 를보십시오 gpg-preset-passphrase.
매우 오래된 (2013) gnupg.org 메일 아카이브는 하위 키에 대해 별도의 암호를 만드는 어색한 해결 방법을 설명 합니다 .
이는 제약 조건이 키 세트의 데이터 구조 (예 : 마스터 서브 키 그룹화) 내에 있지 않고 키 세트를 구성하고 수정하기위한 소프트웨어 인터페이스에만 있음을 의미합니다.
참조에서 인용 :
안녕하세요,
마스터 키와 하위 키가 마스터 키와 다른 (예 : 더 짧은) 암호 구를 갖는 여러 하위 키를 가질 수 있습니까?
아마도 찾고있는 것은 오프라인 메인 키입니다 (--export-secret- 하위 키 참조). 그러나 대답은 그렇습니다. gpg-agent는 키 연결에 신경 쓰지 않습니다. 동일한 암호문을 여러 번 요청합니다 (같은 키의 다른 구성 요소에 대해).
그러나 GnuPG는 이것을 직접 지원하지 않습니다.
1) 비밀 키 내보내기 (--armor가없는 --export-secret-keys)
2) 암호 변경
3) 다시 다른 파일로 내보내기
4) 두 파일 모두 다른 디렉토리에있는 gpgsplit을 사용하십시오. 결과는 다음과 같습니다.
000001-005.secret_key 000002-013.user_id 000003-002.sig 000004-007.secret_subkey 000005-002.sig
5) 이제 두 그룹의 구성 요소를 혼합하십시오.
6) 다음 키를 삭제에서 삭제하십시오. --delete-secret-key
7) 새로운 것을 가져옵니다 : gpg --import different_passphrases.gpg
하우 크 레이 징
본인은이 작업을 개인적으로 확인하지 않았습니다. 읽은 내용 만보고하면됩니다.
이 중요한 주제에 관한 GnuPG 문서에서 사양과 논의가 부족하다는 것은 실망스러운 일입니다.