GNU bug report logs - #45552
28.0.50; bootstrap-emacs apparently not correctly codesigned

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45552 in the body.
You can then email your comments to 45552 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; bootstrap-emacs apparently not correctly codesigned
Date: Wed, 30 Dec 2020 14:10:46 +0100

The following happens for me (on macOS Big Sur on ARM 64, which needs
codesigning) pretty frequently: every time Emacs needs to re-dump as
part of `make', the code signature for bootstrap-emacs is somehow
invalid.  For example:

$ ./config.status
[...]
$ gmake
[...]
/bin/sh: line 3: 18759 Killed: 9               EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l autoload --eval "(setq generate-autoload-cookie \";;;###diary-autoload\")" --eval "(setq generated-autoload-file (expand-file-name (unmsys--file-name \"calendar/diary-loaddefs.el\")))" -f batch-update-autoloads ./calendar
[...]
$ src/bootstrap-emacs 
Killed: 9

The crash reports for these crashes say

Exception Type:        EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes:       0x0000000000000032, 0x0000000104098000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x2

However, `codesign' thinks the signature is valid:

$ codesign -v -v src/bootstrap-emacs
src/bootstrap-emacs: valid on disk
src/bootstrap-emacs: satisfies its Designated Requirement

Removing src/bootstrap-emacs and running `gmake' again fixes the issue
(until the next re-dump).



In GNU Emacs 28.0.50 (build 28, aarch64-apple-darwin20.2.0, NS appkit-2022.20 Version 11.1 (Build 20C69))
 of 2020-12-29
Repository revision: 90bd3b3d69d40339127b4744c459cedb7eb962b0
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.1

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

Configured features:
PNG NOTIFY KQUEUE ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS XIM NS MODULES
THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LANG: de_DE.UTF-8
  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 rmc dired dired-loaddefs rfc822
mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils phst skeleton derived edmacro kmacro pcase ffap
thingatpt url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map url-vars
mailcap rx gnutls puny dbus xml subr-x seq byte-opt gv bytecomp
byte-compile cconv compile text-property-search comint ansi-color ring
cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 70992 6262)
 (symbols 48 8581 1)
 (strings 32 24358 1310)
 (string-bytes 1 794668)
 (vectors 16 14985)
 (vector-slots 8 206069 5818)
 (floats 8 26 28)
 (intervals 56 209 0)
 (buffers 984 10))

Message #8 received at 45552 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 45552 <at> debbugs.gnu.org
Subject: Re: bug#45552: 28.0.50; bootstrap-emacs apparently not correctly
 codesigned
Date: Tue, 31 Aug 2021 20:28:23 +0100

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

> The following happens for me (on macOS Big Sur on ARM 64, which needs
> codesigning) pretty frequently: every time Emacs needs to re-dump as
> part of `make', the code signature for bootstrap-emacs is somehow
> invalid.  For example:
>
> $ ./config.status
> [...]
> $ gmake
> [...]
> /bin/sh: line 3: 18759 Killed: 9               EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l autoload --eval "(setq generate-autoload-cookie \";;;###diary-autoload\")" --eval "(setq generated-autoload-file (expand-file-name (unmsys--file-name \"calendar/diary-loaddefs.el\")))" -f batch-update-autoloads ./calendar
> [...]
> $ src/bootstrap-emacs 
> Killed: 9
>
> The crash reports for these crashes say
>
> Exception Type:        EXC_BAD_ACCESS (Code Signature Invalid)
> Exception Codes:       0x0000000000000032, 0x0000000104098000
> Exception Note:        EXC_CORPSE_NOTIFY
>
> Termination Reason:    Namespace CODESIGNING, Code 0x2
>
> However, `codesign' thinks the signature is valid:
>
> $ codesign -v -v src/bootstrap-emacs
> src/bootstrap-emacs: valid on disk
> src/bootstrap-emacs: satisfies its Designated Requirement
>
> Removing src/bootstrap-emacs and running `gmake' again fixes the issue
> (until the next re-dump).

I think we fixed some problems around code signing recently. Is this
still an issue?
-- 
Alan Third

Message #11 received at 45552 <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 45552 <at> debbugs.gnu.org
Subject: Re: bug#45552: 28.0.50; bootstrap-emacs apparently not correctly
 codesigned
Date: Sat, 4 Sep 2021 18:55:21 +0200

> Am 31.08.2021 um 21:28 schrieb Alan Third <alan <at> idiocy.org>:
> 
> Philipp <p.stephani2 <at> gmail.com> writes:
> 
>> The following happens for me (on macOS Big Sur on ARM 64, which needs
>> codesigning) pretty frequently: every time Emacs needs to re-dump as
>> part of `make', the code signature for bootstrap-emacs is somehow
>> invalid.  For example:
>> 
>> $ ./config.status
>> [...]
>> $ gmake
>> [...]
>> /bin/sh: line 3: 18759 Killed: 9               EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l autoload --eval "(setq generate-autoload-cookie \";;;###diary-autoload\")" --eval "(setq generated-autoload-file (expand-file-name (unmsys--file-name \"calendar/diary-loaddefs.el\")))" -f batch-update-autoloads ./calendar
>> [...]
>> $ src/bootstrap-emacs 
>> Killed: 9
>> 
>> The crash reports for these crashes say
>> 
>> Exception Type:        EXC_BAD_ACCESS (Code Signature Invalid)
>> Exception Codes:       0x0000000000000032, 0x0000000104098000
>> Exception Note:        EXC_CORPSE_NOTIFY
>> 
>> Termination Reason:    Namespace CODESIGNING, Code 0x2
>> 
>> However, `codesign' thinks the signature is valid:
>> 
>> $ codesign -v -v src/bootstrap-emacs
>> src/bootstrap-emacs: valid on disk
>> src/bootstrap-emacs: satisfies its Designated Requirement
>> 
>> Removing src/bootstrap-emacs and running `gmake' again fixes the issue
>> (until the next re-dump).
> 
> I think we fixed some problems around code signing recently. Is this
> still an issue?

Right now `gmake' appears to work, but I've only tried it once so far, so I'm far from certain.

Message #14 received at 45552 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 45552 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#45552: 28.0.50; bootstrap-emacs apparently not correctly
 codesigned
Date: Tue, 07 Jun 2022 14:20:28 +0200

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

>> I think we fixed some problems around code signing recently. Is this
>> still an issue?
>
> Right now `gmake' appears to work, but I've only tried it once so far,
> so I'm far from certain.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

It seems to work fine for me, at least, and I haven't seen any reports
about this, so I'm closing this bug report.  If it's still an issue,
please respond to the debbugs address and we'll reopen.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.