Re: [patch] PE and Mach-O format for code signing

(I missed this, because some authority in the sky?  cloud?  decided that
your initial message was spam.  Sorry about that.)

I think that an existing use case strongly suggests that we should be
working with you to make this supported.

I think tools-for-build/ is not an unreasonable place for
make-embedded-core-executable.lisp, given the similar nature of the
elfcore related utilities there.  On the ergonomics, I think it would be
OK to initially redefine SAVE-LISP-AND-DIE to not allow executable
cores, if that's easier to get started.  (I think the thing I am most
interested in to start with if you're willing to work on this is some
highish-level documentation).

Christophe

Robert Smith <[email protected]> writes:

> Two issues/gotchas with this:
>
> 1. If an executable is saved and modified in the way described, then S-L-A-D won't work with that executable on Windows. (It produces an executable, but it's invalid.)
>
> 2. If a signature is added, S-L-A-D will happily carry that signature over, and the resulting executable won't run due to an invalid signature.
>
> These are tangential to the feature of *reading* the core, but would be necessary considerations if *writing* became first-class and supported.
>
> If maintainers are interested in this feature and they want me to try my hand at building it, I can. It would convenience me, because my users will want to call S-L-A-D and have it work. :)
>
> Robert
>
>
> On Friday, April 17th, 2026 at 7:02 PM, Robert Smith <[email protected]> wrote:
>
>> Hello SBCL friends:
>> 
>> I've been building an app that I want to actually distribute to
>> real, human people on the internet for Windows, Mac, and Linux. In
>> order to make the experience seamless, the app should be
>> code-signed. As you may know, code-signing does not work
>> out-of-the-box on Windows and Mac with SBCL-produced executables,
>> because either (a) signing clobbers the executable in some way, or
>> (b) signing tools reject it as an executable with an invalid format.
>> 
>> There are various workarounds with different trade-offs, but in my
>> limited experience with code signing so far, the right answer is to
>> just make executables that are of a valid structured format. It
>> seems there was some work to do this with ELF in the tree already,
>> but I'm not sure people on Linux care about code signing. (?)
>> 
>> As such, please take a look at this patch:
>> 
>> https://github.com/sbcl/sbcl/compare/master...stylewarning:sbcl:signable-executables
>> 
>> The commit message describes everything which I won't recap here. The TL;DR for posterity:
>> 
>> - It allows coreparse to understand when cores are located in an executable section on Windows and 64-bit Mac, while maintaining backward compatibility with the concatenated core.
>> 
>> - It adds a utility script that allows taking a core + a runtime and creating a proper, signable executable.
>> 
>> I don't really know the right place for the
>> 
>>   tools-for-build/make-embedded-core-executable.lisp
>> 
>> file. It's not really a "tool for building".
>> 
>> I originally extended S-L-A-D with additional options, but the code
>> became a bloated mess of over 1000 lines of reading environment
>> variables, parsing them, trying to find a working $CC, invoking
>> linkers from the SBCL process, etc. I decided that if we want this
>> to be "built-in" in the future, we can, but to start with the
>> minimum useful surface area first.
>> 
>> I also originally added the make-embedded...lisp file to install.sh, but removed it, since it might be confusing to users since it's not in the documentation anywhere.
>> 
>> Perhaps most importantly, I am actively using this branch to produce valid, code-signed artifacts for Windows and Mac that "just work".
>> 
>> Please let me know if you have any comments.
>> 
>> Robert
>> 
>> 
>> 
>> _______________________________________________
>> Sbcl-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>> 
>
>
> _______________________________________________
> Sbcl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel