☰

에이전트에 비밀번호가 캐시되지 않은 경우에만 gpg2가 비합리적으로 느리게 실행됩니다.

tag-icon • tag-icon encryption gnupg gpg-agent
에이전트에 비밀번호가 캐시되지 않은 경우에만 gpg2가 비합리적으로 느리게 실행됩니다.

최근에 내통과하다비밀번호 관리자가 내 마스터 비밀번호에 대한 gpg-agent 비밀번호 프롬프트를 표시하는 데 45초 이상이 걸리기 시작했는데, 이는 웹사이트에 로그인하려고 할 때 거기에 앉아 비밀번호 프롬프트를 1분 동안 쳐다보아야 할 때 매우 짜증나는 일입니다. .

몇 가지 테스트를 시작했는데 gpg2 에이전트에 문제가 있는 것 같습니다. 에이전트를 구성하지 않고 gpg1을 실행하면 매우 빠릅니다(여기에는 비밀번호를 입력하는 시간도 포함됩니다).

$ time gpg -vvv -d BitBucket.gpg
real    0m2.940s
user    0m0.024s
sys     0m0.004s

하지만 동일한 파일(gpg2를 사용해야 하는 에이전트)에 대해 gpg2를 실행하면 엄청나게 느립니다.

$ time gpg2 -vvv -d BitBucket.gpg
real    0m53.421s
user    0m0.000s
sys     0m0.004s

하지만 이제 에이전트에 내 비밀번호가 캐시되어 있으므로 속도가 다시 빨라졌습니다.

$ time gpg2 -vvv -d BitBucket.gpg
real    0m0.126s
user    0m0.004s
sys     0m0.000s

느린 것은 암호 해독이 아닙니다. 최종적으로 암호 프롬프트가 나타나면 어느 정도 정상적인 시간 내에 암호가 해독됩니다. 단지 에이전트가 비밀번호 프롬프트를 로드하고 표시하는 데 시간이 오래 걸리기 때문입니다.

자세한 로그는 유용한 정보를 제공하지 않습니다. 출력은 다음과 같습니다(관련이 없거나 민감한 정보는 다음으로 대체됨 <angle-bracketed text>).

$ gpg2 -vvv -d BitBucket.gpg
gpg: using character set 'utf-8'
<key parameters>
:pubkey enc packet: version 3, algo 1, keyid <X>
        data: [2048 bits]
gpg: public key is <Y>
gpg: using subkey <Y> instead of primary key <Z>
[...here it locks up for 45-ish seconds and then pops up the agent prompt]
gpg: public key encrypted data: good DEK
<key parameters>
:encrypted data packet:
        length: 200
        mdc_method: 2
gpg: using subkey <Y> instead of primary key <Z>
gpg: encrypted with 2048-bit RSA key, ID <Y>, created 2012-03-07
      <ME>
gpg: AES256 encrypted data
<key parameters>
:literal data packet:
        mode b (62), created 1525637737, name="",
        raw data: 151 bytes
gpg: original file name=''
<the content of the password file>
gpg: decryption okay

gpg-agent매뉴얼 페이지에 설명된 대로 옵션을 사용 하여 종료하고 수동으로 다시 로드해 보았습니다. --log-file무엇이 그렇게 오래 걸리는지에 대한 설명을 얻기를 바라면서 몇 번의 암호 해독 작업을 수행한 후에 인쇄된 유일한 줄은 다음과 같습니다.

2019-07-24 17:49:13 gpg-agent[19648] gpg-agent (GnuPG) 2.1.11 started

분명히 별로 도움이 되지 않습니다!

pinentry-program내 에서 변경을 시도했지만 ~/.gnupg/gpg-agent.conf다른 GUI도 비슷하게 작동했습니다.

나는 찾았다이 스레드, 그러나 그것은 암호화에 관한 것 같습니다(임의성이 부족하여 차단될 가능성이 있지만 gpg-agent를 시작할 때 진정한 무작위성은 필요하지 않은 것 같습니다).

나는 또한실속도 가 --check-trustdb느리고 때로는 모든 명령을 실행하는 경우도 있지만 --check-trustdb직접 실행해보니 눈에 띄는 지연 없이 완료되었습니다.

$ time gpg2 -vvv --check-trustdb
real    0m0.009s
user    0m0.008s
sys     0m0.000s

이 문제를 해결하기 위해 다음에 시도할 수 있는 아이디어가 있습니까?

답변1

이 문제는 실제로 와 관련이 있지만 pinentry간접적입니다. pinentry-*키링 데몬 쿼리를 시도하지 않는 구현 에서는 이런 일이 발생하지 않습니다 .

사용 중인 데몬이 gnome-keyring-daemon정지의 원인일 가능성이 높습니다(그런데 몇 가지 다른 키링 구현이 있습니다). 에서GPG 버그 보고서:

지연은 GNOME 키링을 쿼리하는 pinentry로 인해 발생합니다. no-allow-external-cachegpg-agent.conf에 추가 하거나, GNOME 설치를 수정하거나, GNOME 사람들에게 문제를 보고하십시오.

다른 가능한 해결 방법:

  • killall gnome-keyring-daemon(다음 사용 시 자동으로 시작되며 더 이상 중단되지 않을 수 있으므로 재부팅할 필요가 없습니다)
  • gnome-keyring패키지를 사용하지 않는 경우 제거

답변2

내 Debian 시스템에서는 GPG가 암호 문구 프롬프트를 표시하기까지 오랜 지연이 발생했는데 이는 프로그램 때문이었습니다 pinentry. 기본으로 설정되어 pinentry-gnome3있는데 로 변경하면 pinentry-curses문제가 해결된 것 같습니다.

귀하의 질문에서 귀하는 다른 GUI가 pinentry-program유사하게 작동한다고 말한 것으로 나타났습니다. 또한 재부팅 후 문제가 사라졌으므로 다른 문제에 직면했을 가능성이 높습니다. 지난 몇 년 동안 몇몇 시스템에서 이러한 긴 지연이 발생했으며 어떤 경우에는 재부팅해도 도움이 되지 않았으므로 다른 사람이 유용하다고 생각할 경우를 대비해 이 답변을 기록하겠습니다.

이 문제를 해결하기 위해 다음 명령을 실행하고 다음을 선택했습니다 pinentry-curses.

sudo update-alternatives --config pinentry

데비안이 아닌 시스템의 경우 어느 시스템에 심볼릭 링크되어 있는지 확인할 수 있습니다 /usr/bin/pinentry.

ls -l /usr/bin/pinentry

업데이트하면 다음과 같이 보일 수 있습니다.

sudo rm /usr/bin/pinentry
sudo ln -s /usr/bin/pinentry-curses /usr/bin/pinentry

/usr/bin/pinentry특히 심볼릭 링크가 아닌 경우에는 주의를 기울이십시오 . 귀하의 배포판에는 이를 수행하는 다른 방법이 있을 수 있습니다.

pinentry-curses(또는 ) 을 사용하도록 업데이트한 후에는 pinentry-tty긴 지연이 사라집니다.

답변3

당황해서 Windows 사용자 작업을 수행하고 PC를 재부팅했는데(여기서는 Linux를 실행하고 있음에도 불구하고) 놀랍게도 문제가 사라졌습니다. 다른 실행 중인 프로세스에 일종의 경합 문제가 있었던 것 같습니다.

이런 일이 다시 발생하면 돌아와서 업데이트하겠습니다. 그러면 구체적인 범인이 무엇인지 확인할 수 있습니다. gpg-agent에 대해 나열된 항목은 lsof가능한 문제를 암시하지 않는 것 같으며 실행 중인 다른 에이전트나 GPG 프로세스가 없는지 다시 확인했습니다.

관련 정보