gnupg 2.1.16 khối đang chờ entropy

Các bản phát hành của gnupg từ khối 2.1.16 (hiện tại là 2.1,17) chỉ chờ entropy trong lần gọi đầu tiên .

Lưu ý: đây không phải là một nỗ lực để tạo khóa, chỉ để giải mã một tệp và khởi động tác nhân.

Lần đầu tiên gpg-agent được khởi động, trực tiếp với gpg2 file.gpghoặc sử dụng một ứng dụng như pass, pinentry xuất hiện và một khi tôi nhập cụm mật khẩu của mình và nhấn Enternó trong khoảng 15 giây.

Tất cả các cuộc gọi tiếp theo, trong cửa sổ của cache-ttl mặc định, được thực hiện ngay lập tức.

Chạy ở --debug-allchế độ, khoảng thời gian treo xảy ra in ¹ :

gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 120 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 120 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
...

Tôi đã cài đặt các công cụ rng để bổ sung cho nhóm entropy:

cat /proc/sys/kernel/random/entropy_avail 
4094

và so sánh với một máy tính với cùng một phiên bản của gnupg mà không có RNG-tools, hoặc haveged cài đặt, mà triển lãm không chậm trễ:

cat /proc/sys/kernel/random/entropy_avail
3783

Vì vậy, dường như có đủ entropy trong hồ bơi. Điều này đã được thử nghiệm trên hạt nhân 4.8.13 và 4.9.

Có gpg sử dụng một hồ bơi khác nhau? Làm cách nào tôi có thể cung cấp đủ entropy hoặc loại bỏ độ trễ 15 giây khi bắt đầu tác nhân?

Tôi nghĩ rằng tôi biết những gì đang xảy ra. Trong tác nhân / gpg-agent.c của gnupg, hàm này xử lý các thông báo từ libgcrypt.

/* This is our callback function for gcrypt progress messages.  It is
   set once at startup and dispatches progress messages to the
   corresponding threads of the agent.  */
static void 
agent_libgcrypt_progress_cb (void *data, const char *what, int printchar,
                             int current, int total)
{
  struct progress_dispatch_s *dispatch;
  npth_t mytid = npth_self ();

  (void)data;

  for (dispatch = progress_dispatch_list; dispatch; dispatch = dispatch->next)
    if (dispatch->ctrl && dispatch->tid == mytid)
      break;
  if (dispatch && dispatch->cb)
    dispatch->cb (dispatch->ctrl, what, printchar, current, total);

  /* Libgcrypt < 1.8 does not know about nPth and thus when it reads
   * from /dev/random this will block the process.  To mitigate this
   * problem we take a short nap when Libgcrypt tells us that it needs
   * more entropy.  This way other threads have chance to run.  */
#if GCRYPT_VERSION_NUMBER < 0x010800 /* 1.8.0 */
  if (what && !strcmp (what, "need_entropy"))
    npth_usleep (100000); /* 100ms */
#endif
}

Phần cuối cùng với npth_us ngủ đã được thêm vào giữa 2.1.15 và 2.1.17. Vì điều này được biên dịch có điều kiện nếu libgcrypt cũ hơn 1.8.0, nên cách khắc phục đơn giản sẽ được biên dịch lại gnupg so với libgcrypt 1.8.0 hoặc sau đó không may là phiên bản đó dường như chưa tồn tại.

Điều kỳ lạ là, nhận xét về việc đọc libgcrypt / dev / ngẫu nhiên là không đúng. Stracing tác nhân tiết lộ nó đọc từ / dev / urandom và sử dụng tòa nhà getrandom (2) mới, mà không chặn. Tuy nhiên, nó sẽ gửi nhiều tin nhắn Need_entropy, khiến npth_us ngủ bị chặn. Xóa những dòng đó khắc phục vấn đề.

Tôi nên đề cập rằng npth dường như là một loại thư viện đa nhiệm hợp tác và npth_us ngủ có lẽ là cách mang lại, vì vậy có lẽ tốt hơn là giảm đáng kể sự chậm trễ đó, chỉ trong trường hợp libgcrypt quyết định chặn một ngày nào đó. (1ms là không đáng chú ý)