intial commit

archetypes/default.md

@@ -0,0 +1,6 @@
+---
+title: "{{ replace .Name "-" " " | title }}"
+date: {{ .Date }}
+draft: true
+---
+

config.yml

@@ -0,0 +1,73 @@
+baseURL: "https://wonderfall.github.io/"
+languageCode: en-us
+title: "Wonder's Lab"
+theme: PaperMod
+
+enableRobotsTXT: true
+buildDrafts: false
+buildFuture: false
+buildExpired: false
+
+minify:
+  disableXML: true
+  minifyOutput: true
+
+params:
+  env: production
+  title: "Wonder's Lab"
+  description: "Thoughts and research on security, privacy and pharmacology."
+  keywords: [Blog, Research, Security, Privacy]
+  author: Wonderfall
+  DateFormat: "January 2, 2006"
+  defaultTheme: auto # dark, light
+  disableThemeToggle: false
+
+  ShowReadingTime: true
+  ShowShareButtons: true
+  ShowPostNavLinks: true
+  ShowBreadCrumbs: true
+  ShowCodeCopyButtons: false
+  disableSpecial1stPost: false
+  disableScrollToTop: false
+  comments: false
+  hidemeta: false
+  hideSummary: false
+  showtoc: false
+  tocopen: false
+
+  homeInfoParams:
+    Title: "Hi there. I'm a bug on the Internet."
+    Content: Thoughts and research on security, privacy, and pharmacology.
+
+  socialIcons:
+    - name: twitter
+      url: "https://twitter.com/w0nderfall"
+    - name: mastodon
+      url: "https://sheikah.online"
+    - name: matrix
+      url: "https://matrix.to/#/@wonderfall:targaryen.house"
+    - name: github
+      url: "https://github.com/Wonderfall"
+    - name: rss
+      url: /index.xml
+
+  cover:
+    hidden: true # hide everywhere but not in structured data
+    hiddenInList: true # hide on list pages and home
+    hiddenInSingle: true # hide on single page
+
+  editPost:
+    URL: "https://github.com/Wonderfall/wonderfall.github.io/content"
+    Text: "Suggest Changes" # edit text
+    appendFilePath: true # to append file path to Edit link
+
+menu:
+  main:
+    - identifier: tags
+      name: tags
+      url: /tags/
+      weight: 10
+    - identifier: french
+      name: french blog
+      url: https://wonderfall.space
+      weight: 99

content/posts/fdroid-issues.md

@@ -0,0 +1,72 @@
+---
+title: "F-Droid: how is it weakening the Android security model?"
+date: 2022-01-02T21:28:31Z
+draft: false
+tags: ['security', 'android']
+---
+
+Many of us in GrapheneOS community channels suggest avoiding F-Droid, the alternative app repository dedicated to free and open-source software. We don't strictly oppose its use nor are we against the usage of free software, but we often emphasize major issues specifically with F-Droid that can harm the security of your device and the FOSS app ecosystem.
+
+Before we start, a few things to keep in mind:
+
+- The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else's work. Please don't misinterpret this article's intention.
+- You have your own reasons for using open-source software which won't be discussed here. Beware though that open-source does not equal security and may sometimes be the perfect Trojan Horse for exploits. It's just a development model like any other.
+- A lot of information in this article is sourced from official and trusted sources, but you're welcome to do your own research. As the author of this article, I'm only interested in facts and not ideologies.
+
+## 1. The trusted party problem
+To understand why this is a problem, you'll have to understand a bit about F-Droid's architecture, the things it does very differently from other app repositories, and the [Android platform security model](https://arxiv.org/pdf/1904.05572.pdf).
+
+Unlike other repositories, F-Droid signs all the apps (at least in its main repository, we'll get back to it later) with app keys it always owns. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that's what we call a trust-on-first-use model since all subsequent updates of the app must have the corresponding signature to be installed.
+
+Normally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don't have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You're now adding another party you'll have to trust, which isn't ideal: the fewer parties, the better.
+
+F-Droid also requires that the source code of the app is exempt from any proprietary library or ad service, according to their [inclusion policy](https://f-droid.org/en/docs/Inclusion_Policy/). Usually, that means that some developers will have to maintain a slightly different version of their codebase that should comply with F-Droid's requirements.
+
+## 2. Slow and irregular updates
+Since you're adding one more party to the mix, that party is now responsible for delivering proper builds of the app: it's a common thing among traditional Linux distributions and their packaging system. They have to catch up with *upstream* on a regular basis, but very few do it well (Arch Linux comes to my mind). Others, like Debian, prefer making extensive *downstream* changes and delivering security fixes for a subset of vulnerabilities assigned to a CVE (yeah, it's as bad as it sounds, but that's another topic).
+
+Not only do F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, they also have a rather strange way of triggering new builds. Part of their build process seems to be [automated](https://f-droid.org/en/docs/FAQ_-_App_Developers/), which is the least you could expect. Now here's the thing: app signing keys are on an **air-gapped system** (meaning it's disconnected from any network), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it's the least to be expected since by entrusting all the singing keys to one party, you could also introduce a single point of failure. Should their system be compromised, it could lead to serious security issues affecting plenty of users.
+
+Considering all this, and the fact that their build process is often broken using outdated tools, you have to expect **far slower updates** compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should've been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance.
+
+## 3. Low target API level (SDK) for client & apps
+SDK stands for Software Development Kit and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you'll be able to make use of modern APIs, whose iterations bring **security and privacy improvements**. For instance, API level 31 makes use of all these improvements on Android 12.
+
+As you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox; as opposed to outdated apps with older API levels, which have a weaker sandbox.
+
+```
+# b/35917228 - /proc/misc access
+# This will go away in a future Android release
+allow untrusted_app_25 proc_misc:file r_file_perms;
+
+# Access to /proc/tty/drivers, to allow apps to determine if they
+# are running in an emulated environment.
+# b/33214085 b/33814662 b/33791054 b/33211769
+# https://github.com/strazzere/anti-emulator/blob/master/AntiEmulator/src/diff/strazzere/anti/emulator/FindEmulator.java
+# This will go away in a future Android release
+allow untrusted_app_25 proc_tty_drivers:file r_file_perms;
+```
+
+This is a mere sample of the SELinux exceptions that have to be made on older API levels so that you can understand why it matters.
+
+It turns out the official F-Droid client doesn't care much about this since it lags behind quite a bit, targeting the API level 25 (of which some SELinux exceptions were shown above). As a workaround, some users recommended third-party clients such as Foxy Droid or Aurora Droid. While these clients might be technically better, they're poorly maintained for some, and they also introduce yet another party to the mix.
+
+F-Droid also doesn't enforce a minimum target SDK for the official repository. Play Store does that quite aggressively for new app updates, and while it may seem bothersome, it's a necessity to keep the app ecosystem modern and thus healthy. F-Droid's approach sends the wrong message to developers (and even users) because they should care about it, and this is why many of us think it may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated.
+
+## 4. General lack of good practices
+The F-Droid client allows multiple repositories to coexist within the same app. Many of the issues highlighted above were focused on the main official repository which most of the F-Droid users will use anyway. However, having **other repositories in a single app also violates the security model of Android** which was not designed for this at all. As a matter of fact, the new unattended update API from Android 12 that allows seamless updates for third-party clients without privileged access to the system won't work with F-Droid.
+
+Their client also lacks **TLS certificate pinning**, unlike Play Store. Certificate pinning is a way for apps to increase the security of their connection to services by bundling known-good certificates for these services. This can avoid some cases where an interception (man-in-the-middle) could be possible and lead to various security issues considering you're trusting the app to deliver you other apps.
+
+F-Droid also has a problem regarding the adoption of **[new signature schemes](https://source.android.com/security/apksigning)** as they [held out on the v1 signature scheme](https://forum.f-droid.org/t/why-f-droid-is-still-using-apk-signature-scheme-v1/10602) (which was [horrible](https://www.xda-developers.com/janus-vulnerability-android-apps/) and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes. Quite frankly, this is straight-up bad.
+
+## Conclusion: what should you do?
+F-Droid **weakens the security model of Android substantially** for all of the reasons above. If security matters to you, it should not be used. If you don't care or if you'll use it knowingly, then it's up to you. While they could make some easy improvements, I don't think F-Droid is in an ideal situation to solve all of these issues because some of them are inherent flaws in their architecture.
+
+F-Droid is also not the only way to get and support open-source apps. Sure, it can help you in finding one that you wouldn't have known existed otherwise. Many developers also publish their FOSS apps on the **Play Store** or their website directly. Most of the time, releases are available on **GitHub**, which is great since each GitHub releases page has an atom feed. Nonetheless, I'd still recommend using **Play Store for top-notch security** as it does additional checks, and it is even perfectly usable on GrapheneOS with their [sandboxed Play services](https://grapheneos.org/usage#sandboxed-play-services) compatibility layer.
+
+> If you don't have Play services installed, you can use [Aurora Store](https://auroraoss.com/) instead which is a Play Store client. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid (one more party to trust, lack of good practices) - it should still be better than F-Droid though.
+
+You should also keep an eye on the great work **GrapheneOS** does on [their future app repository](https://github.com/GrapheneOS/Apps). It will be a simple, secure, modern app repository for a curated list of high-quality apps, some of which having their own builds (for instance, Signal still uses their [original 1024-bits RSA key](https://github.com/signalapp/Signal-Android/issues/9362) that has never been rotated since then). Inspired by this work, a GrapheneOS community member is developing a more generic app repository called [Accrescent](https://twitter.com/lberrymage/status/1475307653089792003).
+
+*Thanks to the GrapheneOS community for proofreading this article.*

themes/PaperMod

@@ -0,0 +1 @@
+Subproject commit c59193fc48c104389d8b3e9e6857c7aa46221a92