5 ms·

The problem is there’s no way to truely publish OSS on the iOS App Store (or Play store) you submit a binary to Apple and you can publish a repo to GitHub but A

The problem is there’s no way to truely publish OSS on the iOS App Store (or Play store) you submit a binary to Apple and you can publish a repo to GitHub but AFAIK there’s no way to correlate that those two things are the same. So unless you build the app from source yourself there could be anything in the binary.

emsy 3y ago
You just made the case for how sideloading can be more secure than a centralized App Store.
- 2muchcoffeeman 3y ago
  That’s not really a solution to this either, because security can’t just be for people who know how to compile and side load apps.
  - zouhair 3y ago
    So everyone's safe or no one is safe?
    - 2muchcoffeeman 3y ago
      That could be the case. I’m not arguing that you shouldn’t allow side loading. But let’s say this is what developers start doing. We compile our own code and side load. Great for us. How many people can each individual support? Immediate family and close friends? Are most people on their own? Now say your immediate contacts are compromised. That exposes some of your details as well would it not? At least you’d be more vulnerable to social engineering. So maybe you have to work towards a system where everyone is safe.
  - redeeman 3y ago
    theres no other way in general, those who have no clue about things will be doomed to not know how to conduct themselves in a secure manner
  - prophesi 3y ago
    I think a good middle-ground would be having the default store have the functionality for verifiable builds like F-Droid. Add a banner/badge that the app you're looking at is open source, a red flag if it's closed source, a link to the release page in their code repository for that specific release, so that techie-people can verify the hashsum themselves and look at the code. Of course, there's still plenty of possible supply-chain attacks and the like. Closed source app store, git repositories taken over or sneaking in malicious commits, binary blobs required to run your device, and so on. But we should encourage any progression in security, and turn good security practices into common sense.
    - alwaysbeconsing 3y ago
      It's possible that Apple's new Xcode Cloud service could support this at some point, providing a continuous pipeline from source to release. Though I doubt it is a high priority for them.
- NovemberWhiskey 3y ago
  How so? Side-loading an arbitrary binary is no safer (arguably less safe) than downloading a binary from the App Store.
  - m-p-3 3y ago
    A good middle ground would be an equivalent to F-Droid, where the developer can only submit the source code and the code is either compiled by F-Droid, or it is verified as a reproducible build. https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/
  - emsy 3y ago
    What arbitrary binary are you talking about? This is about an open source project.
- deleted 3y ago
  [deleted]
- concinds 3y ago
  This increases verifiability. Not security. And it's not the real issue. On Linux, many apps are open-source yet users don't compile them themselves; they trust that their distro vets packages properly before making them available in official repositories. In this situation, the problem isn't the lack of reproducible builds, but insufficient oversight by Apple that led to an untrustworthy package being made available in their "repository" (App Store).
  - Osiris 3y ago
    Security is provided by the OS. A side loaded app has no more access to the device than an AppStore app. I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app.
    - novok 3y ago
      I %100 agree about the OS part. With verifiability although, a side loaded store gives better nerd-level verification ability that the vast majority of nerds wont even bother with, while a trusted app store gives more low skill masses verification higher success rates in a practical manner. Facebook is going to be facebook on the apple app store, not fake facebook, and by breaking the app store only world, your going to get a lot of old people and other vulnerable people be scammed more on their phones.
      - flangola7 3y ago
        >your going to get a lot of old people and other vulnerable people be scammed more on their phones. This hasn't happened on Android. The fears about evil apps and developers insisting on their own app stores are fabricated FUD by Apple. The simple truth is 99.9% of regular users will never install an app outside the official store. Most will never know it is even an option.
    - xoa 3y ago
      >I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app. What on Earth are you talking about? The OS can provide certain boundaries in terms of "this software can do X and only X kinds of permissions" but short of a full general AI how would you expect it to tell between two pieces of software with user file access and network access permission, both of which accept banking credentials and allow you to see and manipulate your money but one of which doesn't also direct all your money elsewhere after awhile and the other does. For example. Or two password manager apps, both of which send encrypted data to a remote location, one of which does so with zero knowledge the other that has baked in a secondary key or subtle flaw in the encryption. Or a million other things. What you're talking about is, at best, an 80s or 90s view on security where it's purely about one "user" messing with another or gaining root or that sort of thing. But we've long since passed the point where it's possible for users to suffer enormous harm purely within a constricted limited set of non-admin permissions that they have over only their data, which are needed merely to do general productive work with it at all. That's a much harder problem, and involves trust relationships with other humans and organizations. There are technical efforts that can make pieces of it better or more recoverable, but particularly given the need to interact with existing real world stuff even what can be done on that front is further limited. Claiming all potential malicious software is just a "problem with the operating system" is kind of wild to see someone write apparently unironically in 2023. I mean, there are entire classes of software where "malicious" is going to come down pretty purely to consent for otherwise identical function. If someone accepts an advertising supported software experience and consents to their data being used in certain ways (on another system at that), that's not malicious, whereas the same thing stealthily snuck in would be. Or if their data is then used in ways that were contrary to what the software claimed, now what? How is the OS on their client supposed to police that? That's a relative power problem as well as a vetting one.
djxfade 3y ago
But that point applies to binary distribution outside an app store as well. How can you know that the binary linked from a GitHub repository is built from the same source?
- haliskerbas 3y ago
  The os can tell you a checksum in the settings page or before installing. Or you can build from source and confirm on your own.
  - brookst 3y ago
    How do you know the source hasn’t been tampered with, or outright backfired by the author? I don’t think any distribution mechanism will solve the “how can I trust these bytes I got from the internet” problem.
    - r3trohack3r 3y ago
      Ideally the source is readable, though reality falls short of that for most projects. For example, I didn’t realize I liked C until Redis. Now I’ve found a handful of C programs that I’d put into the “readable by non-C devs” bucket, like i3 and the suckless collection. Most build tools also are a disaster from the perspective of giving end users agency over their software. Automake, make, etc are often cryptic magic to non-practitioners. Like C, they can be made readable but most aren’t. KISS Linux falls into this bucket of “grokable” as well, it’s minimal and the process of going from source to distribution is easy to understand. Many stock distributions are so complicated I don’t think the average tech-savvy human has any hope of truly understanding what their system is doing in a single lifetime.
  - r3trohack3r 3y ago
    What’s the point of downloading the binary if you’re going to compile from source yourself anyways? Is the expectation that only a few users (watchdogs) do this and everyone else benefits from the extra validation?
mch82 3y ago
Can the binary be attached to the GitHub repo as a release so that the binaries can be compared?
- lxgr 3y ago
  The problem is that the App Store encrypts each binary to a device-specific key for DRM purposes, and it's not possible to disable that. Additionally, how would you even calculate a binary hash of an iOS app? The filesystem is locked down. I suppose the OS could provide a way to list binary hashes (either after DRM decryption or for non-DRM-ed binaries, if that ever becomes an option), which would be slightly better if you trust the OS more than the app store, which I personally do (it's much riskier to compromise all devices than to target a single device with modified app binaries).
tetrep 3y ago
It'd be cool if you could submit a specific Github commit (or similar) and then have the app store build it and distribute it. Then the user only needs to trust Apple or Google to not be malicious, which they kinda already need to do if they're using both an OS and app store from them.
- dingledork69 3y ago
  But then apple couldn't gouge every app developer for an additional 2k. Right now you must buy a Mac to have the privilege of building and uploading iOS apps.
dingledork69 3y ago
I thought the approved by apple line of thinking was that the app store is a mecca of safe and trustworthy apps?

emsy 3y ago

You just made the case for how sideloading can be more secure than a centralized App Store.

2muchcoffeeman 3y ago
That’s not really a solution to this either, because security can’t just be for people who know how to compile and side load apps.
- zouhair 3y ago
  So everyone's safe or no one is safe?
  - 2muchcoffeeman 3y ago
    That could be the case. I’m not arguing that you shouldn’t allow side loading. But let’s say this is what developers start doing. We compile our own code and side load. Great for us. How many people can each individual support? Immediate family and close friends? Are most people on their own? Now say your immediate contacts are compromised. That exposes some of your details as well would it not? At least you’d be more vulnerable to social engineering. So maybe you have to work towards a system where everyone is safe.
- redeeman 3y ago
  theres no other way in general, those who have no clue about things will be doomed to not know how to conduct themselves in a secure manner
- prophesi 3y ago
  I think a good middle-ground would be having the default store have the functionality for verifiable builds like F-Droid. Add a banner/badge that the app you're looking at is open source, a red flag if it's closed source, a link to the release page in their code repository for that specific release, so that techie-people can verify the hashsum themselves and look at the code. Of course, there's still plenty of possible supply-chain attacks and the like. Closed source app store, git repositories taken over or sneaking in malicious commits, binary blobs required to run your device, and so on. But we should encourage any progression in security, and turn good security practices into common sense.
  - alwaysbeconsing 3y ago
    It's possible that Apple's new Xcode Cloud service could support this at some point, providing a continuous pipeline from source to release. Though I doubt it is a high priority for them.
NovemberWhiskey 3y ago
How so? Side-loading an arbitrary binary is no safer (arguably less safe) than downloading a binary from the App Store.
- m-p-3 3y ago
  A good middle ground would be an equivalent to F-Droid, where the developer can only submit the source code and the code is either compiled by F-Droid, or it is verified as a reproducible build. https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/
- emsy 3y ago
  What arbitrary binary are you talking about? This is about an open source project.
deleted 3y ago
[deleted]
concinds 3y ago
This increases verifiability. Not security. And it's not the real issue. On Linux, many apps are open-source yet users don't compile them themselves; they trust that their distro vets packages properly before making them available in official repositories. In this situation, the problem isn't the lack of reproducible builds, but insufficient oversight by Apple that led to an untrustworthy package being made available in their "repository" (App Store).
- Osiris 3y ago
  Security is provided by the OS. A side loaded app has no more access to the device than an AppStore app. I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app.
  - novok 3y ago
    I %100 agree about the OS part. With verifiability although, a side loaded store gives better nerd-level verification ability that the vast majority of nerds wont even bother with, while a trusted app store gives more low skill masses verification higher success rates in a practical manner. Facebook is going to be facebook on the apple app store, not fake facebook, and by breaking the app store only world, your going to get a lot of old people and other vulnerable people be scammed more on their phones.
    - flangola7 3y ago
      >your going to get a lot of old people and other vulnerable people be scammed more on their phones. This hasn't happened on Android. The fears about evil apps and developers insisting on their own app stores are fabricated FUD by Apple. The simple truth is 99.9% of regular users will never install an app outside the official store. Most will never know it is even an option.
  - xoa 3y ago
    >I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app. What on Earth are you talking about? The OS can provide certain boundaries in terms of "this software can do X and only X kinds of permissions" but short of a full general AI how would you expect it to tell between two pieces of software with user file access and network access permission, both of which accept banking credentials and allow you to see and manipulate your money but one of which doesn't also direct all your money elsewhere after awhile and the other does. For example. Or two password manager apps, both of which send encrypted data to a remote location, one of which does so with zero knowledge the other that has baked in a secondary key or subtle flaw in the encryption. Or a million other things. What you're talking about is, at best, an 80s or 90s view on security where it's purely about one "user" messing with another or gaining root or that sort of thing. But we've long since passed the point where it's possible for users to suffer enormous harm purely within a constricted limited set of non-admin permissions that they have over only their data, which are needed merely to do general productive work with it at all. That's a much harder problem, and involves trust relationships with other humans and organizations. There are technical efforts that can make pieces of it better or more recoverable, but particularly given the need to interact with existing real world stuff even what can be done on that front is further limited. Claiming all potential malicious software is just a "problem with the operating system" is kind of wild to see someone write apparently unironically in 2023. I mean, there are entire classes of software where "malicious" is going to come down pretty purely to consent for otherwise identical function. If someone accepts an advertising supported software experience and consents to their data being used in certain ways (on another system at that), that's not malicious, whereas the same thing stealthily snuck in would be. Or if their data is then used in ways that were contrary to what the software claimed, now what? How is the OS on their client supposed to police that? That's a relative power problem as well as a vetting one.

djxfade 3y ago

But that point applies to binary distribution outside an app store as well. How can you know that the binary linked from a GitHub repository is built from the same source?

haliskerbas 3y ago
The os can tell you a checksum in the settings page or before installing. Or you can build from source and confirm on your own.
- brookst 3y ago
  How do you know the source hasn’t been tampered with, or outright backfired by the author? I don’t think any distribution mechanism will solve the “how can I trust these bytes I got from the internet” problem.
  - r3trohack3r 3y ago
    Ideally the source is readable, though reality falls short of that for most projects. For example, I didn’t realize I liked C until Redis. Now I’ve found a handful of C programs that I’d put into the “readable by non-C devs” bucket, like i3 and the suckless collection. Most build tools also are a disaster from the perspective of giving end users agency over their software. Automake, make, etc are often cryptic magic to non-practitioners. Like C, they can be made readable but most aren’t. KISS Linux falls into this bucket of “grokable” as well, it’s minimal and the process of going from source to distribution is easy to understand. Many stock distributions are so complicated I don’t think the average tech-savvy human has any hope of truly understanding what their system is doing in a single lifetime.
- r3trohack3r 3y ago
  What’s the point of downloading the binary if you’re going to compile from source yourself anyways? Is the expectation that only a few users (watchdogs) do this and everyone else benefits from the extra validation?

mch82 3y ago

Can the binary be attached to the GitHub repo as a release so that the binaries can be compared?

lxgr 3y ago
The problem is that the App Store encrypts each binary to a device-specific key for DRM purposes, and it's not possible to disable that. Additionally, how would you even calculate a binary hash of an iOS app? The filesystem is locked down. I suppose the OS could provide a way to list binary hashes (either after DRM decryption or for non-DRM-ed binaries, if that ever becomes an option), which would be slightly better if you trust the OS more than the app store, which I personally do (it's much riskier to compromise all devices than to target a single device with modified app binaries).

tetrep 3y ago

It'd be cool if you could submit a specific Github commit (or similar) and then have the app store build it and distribute it. Then the user only needs to trust Apple or Google to not be malicious, which they kinda already need to do if they're using both an OS and app store from them.

dingledork69 3y ago
But then apple couldn't gouge every app developer for an additional 2k. Right now you must buy a Mac to have the privilege of building and uploading iOS apps.

dingledork69 3y ago

I thought the approved by apple line of thinking was that the app store is a mecca of safe and trustworthy apps?