3 ms·

There is no reason for "root access". An API call to install a packaged app in a sandbox, and update apps that are installed is all that you would require. App

There is no reason for "root access". An API call to install a packaged app in a sandbox, and update apps that are installed is all that you would require. Apps would be consistently installed to a sandbox identified by their bundle identifier (which is typically domain-based). This is effectively what already happens on iOS. App certification/verification would be done using exactly the same certs we use for domains (possibly co-signed by the store as part of their curation/verification/drm process) to ensure the store can only install what the developer provides, and what the store curators permit to be distributed through their store. I don't think changing 30% to some other arbitrary figure solves anything. For me the biggest problem is Apple deciding what/whose apps ios (and macos, given the recent code signing requirements coming with mac silicon...) users are permitted to use.

rarepostinlurkr 6y ago
> For me the biggest problem is Apple deciding what/whose apps ios (and macos, given the recent code signing requirements coming with mac silicon...) users are permitted to use. Thats FUD. The release notes even address it "This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs, and is designed to simplify the execution policies on Apple silicon Mac computers and enable the system to better detect code modifications."
- supermatt 6y ago
  Arbitrary code, not binaries. You can run arbitrary code through a compiler (which gets signed automatically when it gets linked) and then run it, or you can run arbitrary code through an (already signed) interpreter. You CANNOT run an unsigned binary on silicon, but I totally understand your confusion given their statement. Edit: To clarify further, you cant run an ARM binary - x86 apps going through rosetta (currently) work as they used to (right click and you can open).
  - comex 6y ago
    Why do you care about unsigned binaries when self-signed binaries work fine and the linker produces signatures automatically? It's just a technical change in the required format for executables, not a substantive change in what you're able to do. You may as well complain that macOS doesn't support ELF binaries.
    - supermatt 6y ago
      Not self signed. Signed by an Apple issued cert. This entire thread is about control of distribution. You absolutely will not be able to distribute a Mac app without an Apple dev subscription in order to have your app notarised, agreeing to everything that comes with that. At the moment you can. This is clearly a “substantive change”. I am a proponent for code-signing, I just don't see why I cant use my own cert (such as that issued for a domain name) instead of an apple issued one - if it is solely about preventing code tampering, as they state... The actual reason behind a central issuance of certs is DRM. If apps NEED to run through this gatekeeper, then the gatekeeper can phone home to get a license for you to run the app (or not). This will enable the revocation of a cert for distribution of malware, but will also enable revocation for other reasons - like a dev breaching the terms of their agreement with apple (whatever those may be). That is what the issue is. There is literally no benefit in this unless apple can revoke certs, because there is nothing to stop a dev signing a malicious app! I don’t see what this has to do with elf binaries. I mentioned arm binaries because that is what all upcoming apple “computers” will be.
      - comex 6y ago
        That's not correct. To quote Apple: > New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature issued locally is sufficient, which includes signatures which are now generated automatically by the linker. An "ad-hoc signature" is Apple jargon for a code signature without a certificate (so really just a set of hashes, no actual public-key signature); I called it self-signed since it's a more familiar term. By "there isn't a specific identity requirement" they mean it's not required to be Apple-signed. Of course, macOS on Apple silicon will still require an Apple signature by default like it does on Intel, but you'll be able to disable that like you can on Intel.

rarepostinlurkr 6y ago

> For me the biggest problem is Apple deciding what/whose apps ios (and macos, given the recent code signing requirements coming with mac silicon...) users are permitted to use. Thats FUD. The release notes even address it "This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs, and is designed to simplify the execution policies on Apple silicon Mac computers and enable the system to better detect code modifications."

supermatt 6y ago
Arbitrary code, not binaries. You can run arbitrary code through a compiler (which gets signed automatically when it gets linked) and then run it, or you can run arbitrary code through an (already signed) interpreter. You CANNOT run an unsigned binary on silicon, but I totally understand your confusion given their statement. Edit: To clarify further, you cant run an ARM binary - x86 apps going through rosetta (currently) work as they used to (right click and you can open).
- comex 6y ago
  Why do you care about unsigned binaries when self-signed binaries work fine and the linker produces signatures automatically? It's just a technical change in the required format for executables, not a substantive change in what you're able to do. You may as well complain that macOS doesn't support ELF binaries.
  - supermatt 6y ago
    Not self signed. Signed by an Apple issued cert. This entire thread is about control of distribution. You absolutely will not be able to distribute a Mac app without an Apple dev subscription in order to have your app notarised, agreeing to everything that comes with that. At the moment you can. This is clearly a “substantive change”. I am a proponent for code-signing, I just don't see why I cant use my own cert (such as that issued for a domain name) instead of an apple issued one - if it is solely about preventing code tampering, as they state... The actual reason behind a central issuance of certs is DRM. If apps NEED to run through this gatekeeper, then the gatekeeper can phone home to get a license for you to run the app (or not). This will enable the revocation of a cert for distribution of malware, but will also enable revocation for other reasons - like a dev breaching the terms of their agreement with apple (whatever those may be). That is what the issue is. There is literally no benefit in this unless apple can revoke certs, because there is nothing to stop a dev signing a malicious app! I don’t see what this has to do with elf binaries. I mentioned arm binaries because that is what all upcoming apple “computers” will be.
    - comex 6y ago
      That's not correct. To quote Apple: > New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature issued locally is sufficient, which includes signatures which are now generated automatically by the linker. An "ad-hoc signature" is Apple jargon for a code signature without a certificate (so really just a set of hashes, no actual public-key signature); I called it self-signed since it's a more familiar term. By "there isn't a specific identity requirement" they mean it's not required to be Apple-signed. Of course, macOS on Apple silicon will still require an Apple signature by default like it does on Intel, but you'll be able to disable that like you can on Intel.