4 ms·

> 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

> 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.
      - supermatt 6y ago
        And, as a user, what is the mechanism for ad-hoc signing an unsigned binary on silicon? :) You can’t distribute ad-hoc signed binaries. You can’t disable/bypass the gatekeeper on silicon. If you have access to a transition kit you can see this for yourself.
        comex 6y ago
        > And, as a user, what is the mechanism for ad-hoc signing an unsigned binary on silicon? :) `codesign -s - my_binary`, though that would rarely be necessary unless you patched it in a hex editor or something, since otherwise it would have been automatically ad-hoc signed when it was linked. > You can’t distribute ad-hoc signed binaries. They have the same distribution restrictions on Apple silicon as on Intel. You can, but it requires the person running the binary to either (a) run it in a terminal, (b) right-click Open, or (c) use spctl --master-disable to disable Gatekeeper entirely.
        supermatt 6y ago
        Good luck expecting a user to do that! As I already said, you cant distribute an ad-hoc app, so this is exactly what they would have to do - hence my smiley face! You CANNOT bypass gatekeeper on silicon - that is the whole point - otherwise there is no difference to the current behaviour.
- deleted 6y ago
  [deleted]

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.
    - supermatt 6y ago
      And, as a user, what is the mechanism for ad-hoc signing an unsigned binary on silicon? :) You can’t distribute ad-hoc signed binaries. You can’t disable/bypass the gatekeeper on silicon. If you have access to a transition kit you can see this for yourself.
      - comex 6y ago
        > And, as a user, what is the mechanism for ad-hoc signing an unsigned binary on silicon? :) `codesign -s - my_binary`, though that would rarely be necessary unless you patched it in a hex editor or something, since otherwise it would have been automatically ad-hoc signed when it was linked. > You can’t distribute ad-hoc signed binaries. They have the same distribution restrictions on Apple silicon as on Intel. You can, but it requires the person running the binary to either (a) run it in a terminal, (b) right-click Open, or (c) use spctl --master-disable to disable Gatekeeper entirely.
        supermatt 6y ago
        Good luck expecting a user to do that! As I already said, you cant distribute an ad-hoc app, so this is exactly what they would have to do - hence my smiley face! You CANNOT bypass gatekeeper on silicon - that is the whole point - otherwise there is no difference to the current behaviour.
deleted 6y ago
[deleted]