fixed(grammar): replace appropriate *its* with *it's* (#168)

Author: Benjamin-Loison

README.md

@@ -45,7 +45,7 @@ page_ref: /posts/<category_name>.html
 
 2. Add `[{%- include t.html root="posts" key="views.index.<category_name>" -%}](/{{- page.lang -}}/posts/<category_name>.html)` link for the category in [`_layouts/posts/index.md`](_layouts/posts/index.md) like `[{%- include t.html root="posts" key="views.index.general" -%}](/{{- page.lang -}}/posts/general.html)`. The translation for the category must be added to the `_data/posts/t/<language>/view.yml` file with the `index.<category_name>` key, like in [`_data/posts/t/en/view.yml`](_data/posts/t/en/view.yml). The `index.<category_name>_posts` key must also be added that is used by [`category.html`](_includes/posts/category.html).
 
-3. Add front matter default values for `category` for the `_posts/*/<category_name>` path scope in [`_config.yml`] file. This is required because otherwise jekyll will not assign the `category` automatically to the posts and posts will not be added to the `site.categories` used by [`category.html`](_includes/category.html) and so posts won't show for the category. Check [jekyll docs](https://jekyllrb.com/docs/configuration/front-matter-defaults) for more info. If we used the `<category_name>/_posts/` path for posts, then `<category_name>` would have been automatically assigned to the post since its exist above the `_posts` directory in the path (check [`page.categories` variable](https://jekyllrb.com/docs/variables)), but we can't use that since we need to maintain `_posts/<language>` directory structure and we don't want language to be added as the category and added after `/posts` in url. We can also add `category` to front matter of each post file but that just creates repeatability.
+3. Add front matter default values for `category` for the `_posts/*/<category_name>` path scope in [`_config.yml`] file. This is required because otherwise jekyll will not assign the `category` automatically to the posts and posts will not be added to the `site.categories` used by [`category.html`](_includes/category.html) and so posts won't show for the category. Check [jekyll docs](https://jekyllrb.com/docs/configuration/front-matter-defaults) for more info. If we used the `<category_name>/_posts/` path for posts, then `<category_name>` would have been automatically assigned to the post since it exists above the `_posts` directory in the path (check [`page.categories` variable](https://jekyllrb.com/docs/variables)), but we can't use that since we need to maintain `_posts/<language>` directory structure and we don't want language to be added as the category and added after `/posts` in url. We can also add `category` to front matter of each post file but that just creates repeatability.
 
 ```
 defaults:

_posts/en/apps/2022-02-25-termux-tasker-v0.6.0-release.md

@@ -75,7 +75,7 @@ You can check the release at github [here](https://github.com/termux/termux-task
 
 - Fix issue where log level was not being read from file, which has been fixed in `TermuxTaskerAppSharedPreferences` in upstream. ([`63e76458`](https://github.com/termux/termux-tasker/commit/63e76458))  
 
-- Previously working directory would only be created automatically if it was under `TermuxConstants.TERMUX_HOME_DIR_PATH` but now it will be created even if its under `TermuxConstants.TERMUX_FILES_DIR_PATH`. ([`63e76458`](https://github.com/termux/termux-tasker/commit/63e76458))  
+- Previously working directory would only be created automatically if it was under `TermuxConstants.TERMUX_HOME_DIR_PATH` but now it will be created even if it's under `TermuxConstants.TERMUX_FILES_DIR_PATH`. ([`63e76458`](https://github.com/termux/termux-tasker/commit/63e76458))  
 
 - Use `ExecutionCommand` class to handle intent extras in `FireReceiver` since they are consistent with that of `TermuxService` `ACTION_SERVICE_EXECUTE` intent. ([`63e76458`](https://github.com/termux/termux-tasker/commit/63e76458))  
 

_posts/en/general/2024-11-11-termux-selected-for-nlnet-ngi-mobifree-grant.md

@@ -43,7 +43,7 @@ Check the [App Data File Execute Restrictions](https://github.com/agnostic-apoll
 
 Check the [`APK Native Library`](https://github.com/agnostic-apollo/Android-Docs/blob/master/site/pages/en/projects/docs/apps/processes/app-data-file-execute-restrictions.md#apk-native-library) docs for more info on the `APKLF` design, and the `Issues` sections for details on all its issues that need to be solved. A proper design doc and info on additional issues will be published in near future.
 
-`APKLF` design is very critical for long term functioning and stability of the Termux app, as the exemption allowed by Android for apps like Termux to execute downloaded files by using `targetSdkVersion` `= 28` (Android `9`) may end in some future Android version, which will break Termux completely. Android has already bumped `PLATFORM_MIN_SUPPORTED_TARGET_SDK_VERSION` to `28` in Android `14` and there are plans to bump it to `29` soon, which will then show a message when Termux app is launched to warn the users that app may not work properly as its targeting too old an sdk. ([1](https://cs.android.com/android/_/android/platform/build/+/67ebe09f86bf55b54731cfa99bbfbe90db7c850b), [2](https://cs.android.com/android/_/android/platform/build/release/+/abd2b8452b81f79722dffcd45a491473b2be91d6:flag_declarations/RELEASE_PLATFORM_MIN_SUPPORTED_TARGET_SDK_VERSION.textproto;l=1;bpv=1;bpt=0;drc=9f7ef8bd22b400ba7ca922eba1db83c6701d979c)) Additionally, this is required for [`temrux-core` library](#termux-core-library) as well as external apps, especially ones on Google PlayStore, cannot use older `targetSdkVersion` like Termux does to bypass restrictions.
+`APKLF` design is very critical for long term functioning and stability of the Termux app, as the exemption allowed by Android for apps like Termux to execute downloaded files by using `targetSdkVersion` `= 28` (Android `9`) may end in some future Android version, which will break Termux completely. Android has already bumped `PLATFORM_MIN_SUPPORTED_TARGET_SDK_VERSION` to `28` in Android `14` and there are plans to bump it to `29` soon, which will then show a message when Termux app is launched to warn the users that app may not work properly as it's targeting too old an sdk. ([1](https://cs.android.com/android/_/android/platform/build/+/67ebe09f86bf55b54731cfa99bbfbe90db7c850b), [2](https://cs.android.com/android/_/android/platform/build/release/+/abd2b8452b81f79722dffcd45a491473b2be91d6:flag_declarations/RELEASE_PLATFORM_MIN_SUPPORTED_TARGET_SDK_VERSION.textproto;l=1;bpv=1;bpt=0;drc=9f7ef8bd22b400ba7ca922eba1db83c6701d979c)) Additionally, this is required for [`temrux-core` library](#termux-core-library) as well as external apps, especially ones on Google PlayStore, cannot use older `targetSdkVersion` like Termux does to bypass restrictions.
 
 ### Context
 
@@ -67,7 +67,7 @@ Android restricts execution based on SeLinux policies and contexts assigned to a
 
 Termux package sources will be patched to read paths from environment variables exported by the app, or compiled package files will be patched at install time, rather than relying on hardcoded paths in the package files to Termux rootfs.
 
-Termux packages currently use hardcoded paths/variables that are added/replaced in package sources at build time for its Termux rootfs directory `/data/data/com.termux/files` under the app data directory that Android is expected to assign to the Termux app if its installed in the primary Android user `0`. This prevents Termux packages to run if Termux app is installed in secondary users/work profiles, or on external sdcards, or if packages are running in an external app with a different app data or rootfs directory, unless packages are compiled specifically for the different rootfs path.
+Termux packages currently use hardcoded paths/variables that are added/replaced in package sources at build time for its Termux rootfs directory `/data/data/com.termux/files` under the app data directory that Android is expected to assign to the Termux app if it's installed in the primary Android user `0`. This prevents Termux packages to run if Termux app is installed in secondary users/work profiles, or on external sdcards, or if packages are running in an external app with a different app data or rootfs directory, unless packages are compiled specifically for the different rootfs path.
 
 There are currently around `~4000` placeholders in package source/patch files that are replaced at build time with Termux variables. There are also additional variables passed as build time config to package source builder scripts. To solve the issues of hardcoded values, following will be done.
 - The sources of any executable files of the package will be patched at build time with package source language specific code to read environment variables at runtime that are exported by the Termux app.

_posts/en/security/2022-02-15-termux-apps-vulnerability-disclosures.md

@@ -122,7 +122,7 @@ The vulnerability existed since [`v0.47`](https://github.com/termux/termux-app/r
 
 The vulnerability existed in the [termux `ContentProvider` declaration](https://github.com/termux/termux-app/blob/v0.117/app/src/main/AndroidManifest.xml#L171) since it had set `android.permission.permRead` as [`readPermission`](https://developer.android.com/guide/topics/manifest/provider-element). Basically, termux [passes](https://github.com/termux/termux-app/blob/v0.117/app/src/main/java/com/termux/app/TermuxOpenReceiver.java#L77) the [`FLAG_GRANT_READ_URI_PERMISSION` flag](https://developer.android.com/guide/topics/providers/content-provider-basics#getting-access-with-temporary-permissions) when user requests to open a file with another app, like with `termux-open`, so the target app doesn't need to have the `android.permission.permRead` permission to be able to read the file, which also requires `grantUriPermissions="true"` in the `provider` element. However, if some app has the permission, it can **read** any files under `files` directory as [set by termux `TermuxOpenReceiver$ContentProvider.openFile()`](https://github.com/termux/termux-app/blob/v0.117/app/src/main/java/com/termux/app/TermuxOpenReceiver.java#L177).
 
-Issue was that termux did not declare/publish the  `android.permission.permRead` permission, like it does the `com.termux.permission.RUN_COMMAND` custom permission. Its a dummy permission, likely copied from some tutorial or stackoverflow answer when the `ContentProvider` was added, since internet searches reveal various random results from different sites for it. It was meant to be replaced with a custom permission published by the app, but it was not. That resulted in **any app** to just publish the permission in its own `AndroidManifest.xml` and grant itself the permission with `uses-permission` entry and then be able to **read** any files under `files` directory.
+Issue was that termux did not declare/publish the  `android.permission.permRead` permission, like it does the `com.termux.permission.RUN_COMMAND` custom permission. It's a dummy permission, likely copied from some tutorial or stackoverflow answer when the `ContentProvider` was added, since internet searches reveal various random results from different sites for it. It was meant to be replaced with a custom permission published by the app, but it was not. That resulted in **any app** to just publish the permission in its own `AndroidManifest.xml` and grant itself the permission with `uses-permission` entry and then be able to **read** any files under `files` directory.
 
 Note that other apps could only **read** the files, but not **write** to them since `TermuxOpenReceiver$ContentProvider.openFile()` returned the `ParcelFileDescriptor.MODE_READ_ONLY` file mode, so writing was not possible and caller would get `java.io.IOException: write failed: EBADF (Bad file descriptor)` errors if it tried to write, There was also no `writePermission` set in the `provider` element. This at least prevented arbitrary code execution and privilege escalation, which obviously would have been much worse for some cases.
 

en/security.md

@@ -49,7 +49,7 @@ A good quality report has all the relevant details for the security vulnerabilit
 - An analysis and demonstration of the impact of the vulnerability.
 
 Additionally:
-- If you have coding experience and want to help fix the vulnerability, then a proposed patch can be sent as well and it will be merged if its the ideal solution.
+- If you have coding experience and want to help fix the vulnerability, then a proposed patch can be sent as well and it will be merged if it's the ideal solution.
 - We also expect the reporter to be responsive when they are asked questions, and also accurately answer any queries about the vulnerability.
 - If you are using a fork of Termux, then you should ideally first verify that the issue is reproducible in the Termux releases we provide before reporting to us. This can also help verify whether the issue exists because of changes in the fork or its config.
 - See also [How to ask, report and request](https://github.com/termux/termux-community/blob/site/site/pages/en/rules/how-to-ask-report-and-request.md) for more info on what to normally include when reporting bugs to maintainers.