Can't use Process Substitution for generate_appcast --ed-key-file

[kevincox]

Summary

% generate_appcast --ed-key-file <(echo mysecretkey) example/
Unable to load EdDSA private key from /dev/fd/11 
 Error Domain=NSCocoaErrorDomain Code=257 "The file “11” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/dev/fd/11, NSUnderlyingError=0x6000002404e0 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}}

You can work around this by using stdin. (Example doesn't have a real key, but with a real key everything works perfectly.)

% echo mysecretkey | generate_appcast --ed-key-file - example/
Error: Private key not found in the argument. Please provide a valid key.

This is very surprising as it should just be reading from the passed in path. For some reason it doesn't work properly. Not only is this surprising and leads to requiring a different approach but in many cases the stdin approach results in scripts that are harder to read and maintian.

Version

2.6.4

[zorgiepoo]

--ed-key-file expects a file path. The first example doesn't make sense in context of what generate_appcast and sign_update supports today.

The option to pass a string as a command line argument, which I think is what you would need here for process substitution (correct me if wrong) is insecure/deprecated/onwards removal.

Programmatically speaking, using standard input (or a real file) should be often easier if you're using a language with a sort of subprocess/task API, whereas using a system() like API is discouraged.

I don't think this is going to change. Related: #2168

[zorgiepoo]

Alright I read up more on process substation. Indeed, you are right, it should work but doesn't. generate_appcast uses this API https://developer.apple.com/documentation/swift/string/init(contentsof:) and the error is coming from Swift/Foundation, however it's. getting a POSIX error 13 (Permission Denied). This would require more investigation to figure out why that doesn't work.

[kevincox]

Yeah, it seems strange. Maybe that constructor is trying to seek the file to get its length. This wouldn't be supported with a FIFO. If the code doesn't have a fallback path it may raise an error. I would expect some sort of not supported error rather than permission denied though.

[kevincox]

It is worth noting that with zsh you can use =(echo foo) which will create a temporary file rather than a FIFO. This works but many shells don't support a feature like this.

[zorgiepoo]

Converted back to issue #2605. Need to use FIleHandle to read the file contents to support this use case.