4 ms·

Please refrain from using titles that are more alarmist than the original title. If linking to something with an alarmist title (not the case here!), use a mor

by bla3 6y ago

Please refrain from using titles that are more alarmist than the original title. If linking to something with an alarmist title (not the case here!), use a more neutral headline for your submission.

adsenseclient 6y ago
Google employee reporting?
asveikau 6y ago
I don't think it's very alarmist or an overstatement though. An android 10 app is no longer allowed to do what termux does. I guess with more reading they are saying they need to declare themselves as targeting android 9 or lower until they find a solution. At some point, I imagine, that will not be an option. To some degree it should also be on Google to ensure that tightening security (or perceived tightening of security) doesn't break valid use cases. edit: Ok, for some reason I can't reply, but I see the workaround is to write to another directory.
- andybak 6y ago
  From my brief reading it sounds like they have a solution and there's no danger of it stopping working. In any case - don't editorialize in your titles.
  - cft 6y ago
    You might call this a solution, but I disagree: https://github.com/termux/termux-app/issues/1072#issuecomment-627983273 https://github.com/termux/termux-app/issues/1072#issuecommen... "As i said on another issue, you should really start communicating this to users now , via as many channels as you can. I understand why you are doing what you do, but it is a big change and will annoy and/or confuse users however will you implement it. so getting people prepared now (ie as soon as possible, and before they have to do anything) will avoid a lot of angst and be in your best interests." The "solution" is to publish 100s of different play store apps with Linux packages or to disable the ability to run installed programs.
- shockinglytrue 6y ago
  It's still possible, you just have to dance around a little more In one project we work around this by shipping a tiny wrapper in the APK to exec that then uses dlopen() on the target, which is now built as a library. Pretty sure a generic hack could be made to run unmodified executables this way. Certainly in the security community userland ELF loaders are very old news, even X11R6 had its own at one point
  - AshamedCaptain 6y ago
    And the next release Android uses noexec and therefore you can't even mmap(...PROT_EXEC) the binary. So you now have yo copy the binaries to RAM by yourself on exec(). And then at some point you realize that, like Cygwin, you have built a system where fork() fails randomly by design. And then Google blacklists both fork and exec.
    - shockinglytrue 6y ago
      Not sure why you're being downvoted, this unfortunately all makes sense
- dueF7un3 6y ago
  I'm confused, because I use termux on android-10 (on a pixel2) without any problem. I have a cron running on it that mails my notifications to me, a ssh server which my laptop use to send my backups on my phone, a go http server running a local app that I use in the mobile's browser, I'll often take screenshots on the phone, then scp them on the laptop, etc. Am I missing something? EDIT: I won't reply to each of you to not be floody, thanks everyone for the clarifications :)
  - deleted 6y ago
    [deleted]
  - gst 6y ago
    > I'm confused, because I use termux on android-10 (on a pixel2) without any problem. It's only an issue if applications target Android 10 APIs. Termux still targets an older API version and is thus not yet affected by this issue. Eventually they'll need to target a newer version because the Google Play store specifies a minimum API version that applications need to use.
  - tdeck 6y ago
    Android apps specify a target SDK version (essentially a kind of OS version) in their manifest alongside a min SDK version. The advantage of targeting a newer SDK than the oldest one you support is that you get access to new APIs, but it often comes with additional restrictions as well. Google Play periodically updates their policy to require that targetSdkVersion be above a certain value in order for an app to be published in the play store (currently that value corresponds to Android 9) [1]. What this means is that this policy is an optional trade-off today but likely to be a requirement in the future. [1]: https://developer.android.com/distribute/best-practices/develop/target-sdk https://developer.android.com/distribute/best-practices/deve...
  - asveikau 6y ago
    You are running in a compatibility mode. If they built it declaring support for Android 10 at build time it would be subject to the new rules and break. Long term, I can only assume targeting an old SDK will not be supported at some point.
- kllrnohj 6y ago
  The title is that Android 10 is killing Termux. But it's not, it's killing exec() on writable files. There's alternatives Termux could take, which the Google issue tracker already mentions such as bundling the executables in the APK & using extractNativeLibs=true so they can be exec'd ( https://issuetracker.google.com/issues/128554619#comment4 https://issuetracker.google.com/issues/128554619#comment4 ). They could use a loader that mmap's the code with PROT_EXEC but not PROT_WRITE, that also works (this is how JIT's work, and Android is obviously not breaking JITs anytime soon) It's not entirely clear why Termux hasn't seemingly made any move on the alternative approaches raised a year ago (that's how old the issue is: https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/1072 ), and there's a bunch of nonsensical alarmist bullshit muddying up the waters which isn't helping.
  - stonewareslord 6y ago
    Termux allows you to apt install thousands of packages. The options in that issue aren't nearly as good. Bundling every binary in the apk? That would be a breach of licenses, let alone the amount of storage that would take up to have gimp, libreoffice, Firefox, etc installed. As mentioned, proot is a temporary hack (why wouldn't any app just stick proot in their lib Dir?). Even if the workaround works, this would break apt install from non-termux repos, compiling and running with gcc, maybe Python packages installed with pip. Google's intent here is to block code execution in the app home Dir. Any workaround would be a security violation and eventually stopped. How is this not killing Termux?
    - kllrnohj 6y ago
      > Google's intent here is to block code execution in the app home Dir Google's actions are to block exec of writable code. What their _intentions_ are is pure speculation and detracts from the actual issue. Your claim is largely unsubstantiated & lacks evidence, particularly as Google recommended ways to continue to do exactly what you claim they are intending to block. > The options in that issue aren't nearly as good. How is using a PROT_EXEC mmap "not nearly as good"? It's the same end result. There's no technical banning of executing downloaded code. That's not what was done, and doing that would also break Chrome which should be glaringly obvious that Google isn't intending or going to do. It takes a bit more effort, and it's not as "simple" as just exec'ing random stuff, but it's not without its own upsides as well (like not violating W^X, which is a _well_ proven security design)
- on_and_off 6y ago
  Another title could be : "termux failed to update to Android changes for 2 years"

by bla3 6y ago

Please refrain from using titles that are more alarmist than the original title. If linking to something with an alarmist title (not the case here!), use a more neutral headline for your submission.

adsenseclient 6y ago

Google employee reporting?

asveikau 6y ago

I don't think it's very alarmist or an overstatement though. An android 10 app is no longer allowed to do what termux does. I guess with more reading they are saying they need to declare themselves as targeting android 9 or lower until they find a solution. At some point, I imagine, that will not be an option. To some degree it should also be on Google to ensure that tightening security (or perceived tightening of security) doesn't break valid use cases. edit: Ok, for some reason I can't reply, but I see the workaround is to write to another directory.

andybak 6y ago
From my brief reading it sounds like they have a solution and there's no danger of it stopping working. In any case - don't editorialize in your titles.
- cft 6y ago
  You might call this a solution, but I disagree: https://github.com/termux/termux-app/issues/1072#issuecomment-627983273 https://github.com/termux/termux-app/issues/1072#issuecommen... "As i said on another issue, you should really start communicating this to users now , via as many channels as you can. I understand why you are doing what you do, but it is a big change and will annoy and/or confuse users however will you implement it. so getting people prepared now (ie as soon as possible, and before they have to do anything) will avoid a lot of angst and be in your best interests." The "solution" is to publish 100s of different play store apps with Linux packages or to disable the ability to run installed programs.
shockinglytrue 6y ago
It's still possible, you just have to dance around a little more In one project we work around this by shipping a tiny wrapper in the APK to exec that then uses dlopen() on the target, which is now built as a library. Pretty sure a generic hack could be made to run unmodified executables this way. Certainly in the security community userland ELF loaders are very old news, even X11R6 had its own at one point
- AshamedCaptain 6y ago
  And the next release Android uses noexec and therefore you can't even mmap(...PROT_EXEC) the binary. So you now have yo copy the binaries to RAM by yourself on exec(). And then at some point you realize that, like Cygwin, you have built a system where fork() fails randomly by design. And then Google blacklists both fork and exec.
  - shockinglytrue 6y ago
    Not sure why you're being downvoted, this unfortunately all makes sense
dueF7un3 6y ago
I'm confused, because I use termux on android-10 (on a pixel2) without any problem. I have a cron running on it that mails my notifications to me, a ssh server which my laptop use to send my backups on my phone, a go http server running a local app that I use in the mobile's browser, I'll often take screenshots on the phone, then scp them on the laptop, etc. Am I missing something? EDIT: I won't reply to each of you to not be floody, thanks everyone for the clarifications :)
- deleted 6y ago
  [deleted]
- gst 6y ago
  > I'm confused, because I use termux on android-10 (on a pixel2) without any problem. It's only an issue if applications target Android 10 APIs. Termux still targets an older API version and is thus not yet affected by this issue. Eventually they'll need to target a newer version because the Google Play store specifies a minimum API version that applications need to use.
- tdeck 6y ago
  Android apps specify a target SDK version (essentially a kind of OS version) in their manifest alongside a min SDK version. The advantage of targeting a newer SDK than the oldest one you support is that you get access to new APIs, but it often comes with additional restrictions as well. Google Play periodically updates their policy to require that targetSdkVersion be above a certain value in order for an app to be published in the play store (currently that value corresponds to Android 9) [1]. What this means is that this policy is an optional trade-off today but likely to be a requirement in the future. [1]: https://developer.android.com/distribute/best-practices/develop/target-sdk https://developer.android.com/distribute/best-practices/deve...
- asveikau 6y ago
  You are running in a compatibility mode. If they built it declaring support for Android 10 at build time it would be subject to the new rules and break. Long term, I can only assume targeting an old SDK will not be supported at some point.
kllrnohj 6y ago
The title is that Android 10 is killing Termux. But it's not, it's killing exec() on writable files. There's alternatives Termux could take, which the Google issue tracker already mentions such as bundling the executables in the APK & using extractNativeLibs=true so they can be exec'd ( https://issuetracker.google.com/issues/128554619#comment4 https://issuetracker.google.com/issues/128554619#comment4 ). They could use a loader that mmap's the code with PROT_EXEC but not PROT_WRITE, that also works (this is how JIT's work, and Android is obviously not breaking JITs anytime soon) It's not entirely clear why Termux hasn't seemingly made any move on the alternative approaches raised a year ago (that's how old the issue is: https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/1072 ), and there's a bunch of nonsensical alarmist bullshit muddying up the waters which isn't helping.
- stonewareslord 6y ago
  Termux allows you to apt install thousands of packages. The options in that issue aren't nearly as good. Bundling every binary in the apk? That would be a breach of licenses, let alone the amount of storage that would take up to have gimp, libreoffice, Firefox, etc installed. As mentioned, proot is a temporary hack (why wouldn't any app just stick proot in their lib Dir?). Even if the workaround works, this would break apt install from non-termux repos, compiling and running with gcc, maybe Python packages installed with pip. Google's intent here is to block code execution in the app home Dir. Any workaround would be a security violation and eventually stopped. How is this not killing Termux?
  - kllrnohj 6y ago
    > Google's intent here is to block code execution in the app home Dir Google's actions are to block exec of writable code. What their _intentions_ are is pure speculation and detracts from the actual issue. Your claim is largely unsubstantiated & lacks evidence, particularly as Google recommended ways to continue to do exactly what you claim they are intending to block. > The options in that issue aren't nearly as good. How is using a PROT_EXEC mmap "not nearly as good"? It's the same end result. There's no technical banning of executing downloaded code. That's not what was done, and doing that would also break Chrome which should be glaringly obvious that Google isn't intending or going to do. It takes a bit more effort, and it's not as "simple" as just exec'ing random stuff, but it's not without its own upsides as well (like not violating W^X, which is a _well_ proven security design)
on_and_off 6y ago
Another title could be : "termux failed to update to Android changes for 2 years"