JayBrown
commented
3 years ago Can't comment on other operating systems, but macOS doesn't provide for code-signing (let alone notarizing) of script executables, and in the end youtube-dlc is just a /usr/bin/env python script—with binary data, of course, but still a script. Of course you can always code-sign youtube-dlc, but the code signature will not be embedded, but written as a bunch of extended attributes instead. To transport that signature (i.e. the XAs) to the destination OS, you'd have to tar youtube-dlc, but if the user runs xattr -c youtube-dlc or xattr -d com.apple.cs.CodeSignature youtube-dlc etc., the signature will be lost.
And macOS Gatekeeper doesn't care either… even though the spctl -a -vvv -t install youtube-dlc command will reject third-party signatures, will print a "code or signature modified" error, if the script was altered after signing, you can run a code-signed & modified script just fine, because it's just a script, and macOS doesn't care about scripts' signatures. Same with the codesign command (signed and unmodifed, then modified after signing):
You have a working signature, everything's fine. You change something, and codesign will print an error, like spctl. But (a) the script will run fine nonetheless, and (b) an attacker could, after modifying the script, just re-sign it, i.e. seal it with a new signature.
So for macOS, code signatures are of no use with regard to youtube-dlc, unless Apple changes the rules. (But requiring scripts to be code-signed would be a usability nightmare imho.)
ThatNerdyPikachu
diegorodriguezv
Checklist
Description
While code signing is not a panacea, it would reduce the possibility of maliciously modified copies of the binaries, as well as reduce the probability for anti-malware utilities reporting a false positive.