bug#28202: 26.0.50; Loading package.el should not start a subprocess

bug#28202: 26.0.50; Loading package.el should not start a subprocess

[Philipp]

Loading package.el initializes the variable `package-check-signature',
which starts a GnuPG subprocess.  This process might then be affected by
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1285390, causing
infinite hangs that can only be worked around by restarting the
machine.  I think that in general loading packages should not start
subprocesses to increase robustness.  Possible the initialization of
`package-check-signature' should be delayed until signature checks are
actually attempted.


In GNU Emacs 26.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.10.8)
 of 2017-08-22 built on localhost
Repository revision: 4309d1574ae86244751600171b605b2b2eca4697
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Ubuntu 14.04.5 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --without-pop --with-mailutils
 --enable-checking --enable-check-lisp-object-type --enable-gcc-warnings
 'CFLAGS=-ggdb3 -O0''

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 94626 11502)
 (symbols 48 20136 1)
 (miscs 40 38 119)
 (strings 32 28609 1399)
 (string-bytes 1 762320)
 (vectors 16 13991)
 (vector-slots 8 488284 14635)
 (floats 8 48 68)
 (intervals 56 205 0)
 (buffers 992 11)
 (heap 1024 39482 995))

bug#28202: 26.0.50; Loading package.el should not start a subprocess

[Lars Ingebrigtsen]

Philipp <p.stephani2@gmail.com> writes:

> Loading package.el initializes the variable `package-check-signature',
> which starts a GnuPG subprocess.  This process might then be affected by
> https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1285390, causing
> infinite hangs that can only be worked around by restarting the
> machine.  I think that in general loading packages should not start
> subprocesses to increase robustness.  Possible the initialization of
> `package-check-signature' should be delayed until signature checks are
> actually attempted.

Yes, definitely.  Packages should never execute anything when loaded --
and especially not something as complicated as gpg.

Does the following patch make sense?  It defaults the value to
allow-unsigned, which will then lead to the epg checking being run
(which will execute gpg).  The execution is cached in epg, though, so
it'll just be run once anyway.

This does mean though, that if you don't have gpg installed, the
`package-check-signature' value will still be `allow-signature', but
it'll act as if it's nil.  Currently, it would default to nil, and that
may be confusing.

Perhaps I could change the default to 'check-available or something and
then actually set the variable if it is that?  Opinions?

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 9a350aadac..c4309b700e 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -331,10 +331,7 @@ package-gnupghome-dir
   :risky t
   :version "26.1")
 
-(defcustom package-check-signature
-  (if (and (require 'epg-config)
-           (epg-find-configuration 'OpenPGP))
-      'allow-unsigned)
+(defcustom package-check-signature 'allow-unsigned
   "Non-nil means to check package signatures when installing.
 More specifically the value can be:
 - nil: package signatures are ignored.
@@ -353,6 +350,14 @@ package-check-signature
   :risky t
   :version "27.1")
 
+(defun package-check-signature ()
+  (if (eq package-check-signature 'allow-unsigned)
+      (progn
+        (require 'epg-config)
+        (and (epg-find-configuration 'OpenPGP)
+             'allow-unsigned))
+    package-check-signature))
+
 (defcustom package-unsigned-archives nil
   "List of archives where we do not check for package signatures."
   :type '(repeat (string :tag "Archive name"))
@@ -1279,15 +1284,15 @@ package--check-signature-content
       (dolist (sig (epg-context-result-for context 'verify))
         (if (eq (epg-signature-status sig) 'good)
             (push sig good-signatures)
-          ;; If package-check-signature is allow-unsigned, don't
+          ;; If `package-check-signature' is allow-unsigned, don't
           ;; signal error when we can't verify signature because of
           ;; missing public key.  Other errors are still treated as
           ;; fatal (bug#17625).
-          (unless (and (eq package-check-signature 'allow-unsigned)
+          (unless (and (eq (package-check-signature) 'allow-unsigned)
                        (eq (epg-signature-status sig) 'no-pubkey))
             (setq had-fatal-error t))))
       (when (or (null good-signatures)
-                (and (eq package-check-signature 'all)
+                (and (eq (package-check-signature) 'all)
                      had-fatal-error))
         (package--display-verify-error context sig-file)
         (signal 'bad-signature (list sig-file)))
@@ -1318,7 +1323,7 @@ package--check-signature
       :async async :noerror t
       ;; Connection error is assumed to mean "no sig-file".
       :error-form (let ((allow-unsigned
-                         (eq package-check-signature 'allow-unsigned)))
+                         (eq (package-check-signature) 'allow-unsigned)))
                     (when (and callback allow-unsigned)
                       (funcall callback nil))
                     (when unwind (funcall unwind))
@@ -1602,7 +1607,7 @@ package--download-one-archive
            (local-file (expand-file-name file dir)))
       (when (listp (read content))
         (make-directory dir t)
-        (if (or (not package-check-signature)
+        (if (or (not (package-check-signature))
                 (member name package-unsigned-archives))
             ;; If we don't care about the signature, save the file and
             ;; we're done.
@@ -1654,7 +1659,7 @@ package-refresh-contents
   (let ((default-keyring (expand-file-name "package-keyring.gpg"
                                            data-directory))
         (inhibit-message (or inhibit-message async)))
-    (when (and package-check-signature (file-exists-p default-keyring))
+    (when (and (package-check-signature) (file-exists-p default-keyring))
       (condition-case-unless-debug error
           (package-import-keyring default-keyring)
         (error (message "Cannot import default keyring: %S" (cdr error))))))
@@ -1901,7 +1906,7 @@ package-install-from-archive
          (file (concat (package-desc-full-name pkg-desc)
                        (package-desc-suffix pkg-desc))))
     (package--with-response-buffer location :file file
-      (if (or (not package-check-signature)
+      (if (or (not (package-check-signature))
               (member (package-desc-archive pkg-desc)
                       package-unsigned-archives))
           ;; If we don't care about the signature, unpack and we're

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28202: 26.0.50; Loading package.el should not start a subprocess

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This does mean though, that if you don't have gpg installed, the
> `package-check-signature' value will still be `allow-signature', but
> it'll act as if it's nil.  Currently, it would default to nil, and that
> may be confusing.
>
> Perhaps I could change the default to 'check-available or something and
> then actually set the variable if it is that?  Opinions?

There weren't any, so I've applied a tweaked version of this to the
trunk, including a NEWS item that calls out this change.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28202: 26.0.50; Loading package.el should not start a subprocess

[Philipp Stephani]

Am Fr., 26. Juli 2019 um 08:28 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > This does mean though, that if you don't have gpg installed, the
> > `package-check-signature' value will still be `allow-signature', but
> > it'll act as if it's nil.  Currently, it would default to nil, and that
> > may be confusing.
> >
> > Perhaps I could change the default to 'check-available or something and
> > then actually set the variable if it is that?  Opinions?
>
> There weren't any, so I've applied a tweaked version of this to the
> trunk, including a NEWS item that calls out this change.
>

Thanks.