I've managed to make a fork with support for teensy_secure but I can't manage to figure out how to add a config option to the ini and not require the "custom_" prefix.

What about testing for the existence of the key at ~/Documents/Arduino/key.pem? That's the default path on the Mac.

Or, could always use these configuration options, something like:

1. key_location
2. do_encrypt_hex

Cases:

1. Both missing: Look for key at default location and, if exists, encrypt
2. Invalid key_location (file doesn't exist): Don't encrypt
3. Valid key_location (file exists) and missing do_encrypt_hex or do_encrypt_hex is true: Encrypt
4. do_encrypt_hex is false or invalid: Don't encrypt

Why would anyone need "do_encrypt_hex"? If the key exists, always use it to create a .ehex file from the .hex file. The operation is so fast and consumes little memory, it costs pretty much nothing on any modern PC. The original .hex file is not modified.

I don’t disagree with you there. I always err on the side of “more knobs”, but you’re right. I think the main place where that kind of option might be necessary, though, is the upload step.

I was thinking about this some more. @PaulStoffregen how does Teensyduino 1.57 know which of the hex or ehex to give to the loader? Or does it just try to load the ehex, and, if there’s a certain error code, it tries the hex?

The compile process doesn't know which file will be used. It first builds the .hex file, and if a key is available it builds the .ehex file. Then it's up to Teensy Loader to decide which file to actually use.

Teensy Loader detects whether a .ehex file exists in the same folder as the .hex file. It also detects whether the Teensy hardware supports .ehex. It checks whether the hardware and .ehex have matching key fingerprint. If all checks pass, .ehex is used automatically. Otherwise, the .hex file is used.

Thanks, @PaulStoffregen, for the guidance.

I was playing with this and it looks like one can always call the teensy_secure program because it will automatically look for a key in the default place. Also, if there's no key, it will fail with a message, but with a zero exit code. Not knowing SCons that well, I don't know how it handles Builder programs if they return a non-zero exit code, but thankfully we don't have to worry about it.

It appears you can remove the custom_secure check in your code and just run teensy_secure by default and things should "just work". (I'll try your changes when I have a chance.)
See: https://github.com/GoobyCorp/platform-teensy/blob/4a806aa7ec12fda4cb22cbcbea82fa0119508eee/builder/main.py#L195

Update: That is, if it's on a Teensy 4.x. Or... maybe make the "HexToEhex" Builder a no-op when not running on a Teensy 4.x.
Update 2: I suppose there might have to be a check that the ehex file exists, otherwise I'm not sure how SCons treats a Builder that doesn't create the file it's supposed to. I need to experiment...

I tried the original and it didn't work on my Teensy 4.1 so I'm going to continue using my fork.

Please add support for TeensyMM to this as well!