Native code script #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shc creates code that makes corporate antivirus (or at least SentinelOne) very angry, for reasonably understandable reasons.
|
We have been using this in a distributed application for over a year now without issue, so I am going to mark this PR as ready for review |
5 tasks
|
Wow! Sorry ... I missed this PR 😞 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Second copy of the launcher rewritten in objective-c
What is the current behavior?
The existing script as a shell script is fine. However, when compiled into a binary script with SHC it sets off my corporate antivirus (SentinelONE) (anything compiled with SHC, along with SHC itself, does). This is likely because SHC stuffs the shell script into an encrypted blob in the file and then the surrounding code is decrypting the script and running it through a shell, which is the kind of thing that malware commonly does to try to obfuscate its real purpose.
What is the new behavior?
This introduces an objective-c implementation of the script which should behave identically (other than some slightly differences in the presentation of logging/dialogs) to the shell script but is compiled as conventional native code. This creates a functionally equivalent drop-in binary, which I have tested works correctly in basic use cases with JavaPackager. (I did not port over the translations, though it wouldn't be hard to port if over if desired). It should have more guaranteed correct plist handling since it is actually parsing the plists through Apple's plist deserialization code rather than trying to string-parse the output of PlistBuddy.
Does this PR introduce a breaking change?
No breaking change since this is purely additive.
Other information:
This is definitely not 100% tested, and could very well be broken in various edge cases. In particular I have not tested JVMOptionsFile, BootstrapScript, or
sdkman, though I did add and testasdfsupport, which functions very similarly to thesdkmansupport.I don't know if this is actually worth adding to this project or if I should just maintain this independently, but I figured it was worth at least sharing and opening up the conversation.