For every new release of android there is only one thing I care about, how will this affect termux?
So I did a google and looks promising ( https://www.reddit.com/r/termux/comments/nyayhq/comment/h1j9... ).
So I did a google and looks promising ( https://www.reddit.com/r/termux/comments/nyayhq/comment/h1j9... ).
https://developer.android.com/ndk/guides/stable_apis
Whatever cannot be done with ISO C and ISO C++ standard libraries, GL ES or Vulkan for the UI, needs to drop into JNI or Android IPC, period.
You can enjoy PyDroid for the time being,
https://play.google.com/store/apps/details?id=ru.iiec.pydroi...
But it might not be around for long,
https://www.theregister.com/2021/07/29/google_play_python_ja...
I'm aware. The difficulty in this process would act as a filter ensuring only powerusers can do it. It would certainly not be ideal to have to do this just to use Termux, but if Google wants to eventually enforce W^X exec(), it would be better than nothing.
I'm honestly curious as to what the security implications of allowing exec() in writable directories really is. For example, GrapheneOS' top priority is security and it hardens the Android sandbox even beyond AOSP, and yet it still supports Termux (and I doubt its users would accept if it dropped support for this, even if in exchange for a little extra security).
If anyone knows about this, I would appreciate your input.
W^X is what Android is pushing people towards, there's no reason for a permission to guard what's recommended.
And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do. But eg Chrome & Firefox have no issues with their JavaScript JITs that still comply with W^X.
> And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do.
Do you know of any alternative approach to the gross APK packaging one? I would say it definitely restricts "useful behavior", unless you think Termux would be just as useful after API 29 compatibility were implemented (and I would disagree).
Besides, when thinking about implementing a security feature, the question "does this restrict behavior?" is important (and I think it does in this case), but not quite as relevant as the question "what actual extra security does this provide?", and I'm not quite sure how much extra security this provides.
Could someone provide a realistic attack scenario?
By the way, as far as I know, Termux (at least as we know it) is for sure eventually doomed, which is really sad. Here's a brief explanation for those uninitiated:
* Android 10 introduced a restriction that apps targeting API version 29+ can no longer invoke exec() on files within the app's home directory, which breaks Termux [1].
* An app can target any API version. There is a hardcoded "min_supported_target_sdk" in the Android source code (23 as of Android 12) [2], but as of now targeting a lower version only produces a warning, and it will likely take quite a long time before it reaches 29 anyway [3]. The main problem is that the Play Store won't allow new app updates targeting <29. For now, the Play Store Termux build is very out of date and it's recommended to get Termux from F-Droid. But for some reason, the developer of Termux has decided that they want to make Termux API 29 compatible [4]. (Perhaps to ensure long-term compatibility if the "min_supported_target_sdk" ever increases past 28 AND starts to actually be enforced, or maybe just because they want to distribute Termux in the Play Store, even though most of its users would be perfectly comfortable getting it from F-Droid?)
* Making Termux API 29 compatible will make it a lot less fun and a lot less practical to use. All executables will have to be distributed inside separate APK files which must be individually installed, since exec() can now only be called on files in the read-only /data/app directory [5]. Say goodbye to `apt install <name>`.
* Google continues to further restrict the OS in ways that break certain functionality within Termux.
* Termux still works mostly normally for now in Android 10 and 11 (and 12, it seems), but its developer is already at work on the weird APK packaging system.
[1] https://github.com/termux/termux-packages/wiki/Termux-and-An...
[2] https://android.googlesource.com/platform/prebuilts/fullsdk/...
[3] https://github.com/termux/termux-app/issues/1072#issuecommen...
[4] https://github.com/termux/termux-app/issues/1072#issuecommen...
[5] https://github.com/termux/termux-app/issues/1072#issuecommen...
=== EDIT ===
According to the README, the current plan is actually to continue targeting API 28 for now:
> There is currently no work being done to solve android 10 issues and working updates will not be resumed on Google Play Store any time soon. We will continue targeting sdk 28 for now.
They are looking for contributors to help make an API 29 compatible version though:
> @termux is looking for Termux Application maintainers for implementing new features, fixing bugs and reviewing pull requests since the current one (@fornwall) is inactive. Issue https://github.com/termux/termux-app/issues/1072 needs extra attention.
https://github.com/termux/termux-app/blob/master/README.md#g...
https://developer.android.com/distribute/best-practices/deve...
> Starting in November 2021, app updates will be required to target API level 30 or above and adjust for behavioral changes in Android 11. Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Wear OS apps must continue to target API level 28 or higher.
Android is not a POSIX OS, apis like exec() where never part of the public APIs, time to embrace the Java ways of the platform.
https://developer.android.com/ndk/guides/stable_apis#c_libra...