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

I am very happy to work on documentation.

I've also been running with this for a little bit now, making tweaks to some of the commits as users find issues.

The recently announced `mine` software is being compiled with this SBCL branch to (a) allow the executable to be signed, and (b) to allow executables dumped with S-L-A-D to be runnable. (They now are on both macOS and Windows, including x64/ARM and x64-on-ARM-with-Prism.)

https://coalton-lang.github.io/mine/

I'll write up some docs and ping again for discussion or review.

Robert



On Wednesday, April 29th, 2026 at 3:49 PM, Christophe Rhodes <[email protected]> wrote:

> (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
>