As I said, I think there are enough downsides to the “exe plus Python script” approach that it’s not going to work. If there was a way for a signed executable to re-sign itself when data was added to it, that might work - but I’ve no idea if that’s possible.
For me, the key features we need are:
- A single executable that can be copied, symlinked, etc., and still work.
- We don’t require every application developer publishing Python applications to own a signing key.
How do languages like rust and go handle this? They produce executables, and presumably the average open source rust/go project doesn’t sign those executables. Why is Python any different here?
The only difference I can see is that for a developer who has got a signing key and wants to sign their Python application, entry point scripts aren’t a good match because the executable is constructed at install time rather than at build time. In that case, properly embedding Python in the application, as Steve described here is probably a much better approach anyway.