6 ms·

My group makes a custom executable to reflash a hardware device we produce. We build it for Linux and Darwin. Trying to get the program to work with our Mac us

My group makes a custom executable to reflash a hardware device we produce. We build it for Linux and Darwin. Trying to get the program to work with our Mac users has become harder and harder. These are all internal developers. Enabling developer mode and allowing Terminal execution isn't enough. Disabling the quarantine bit works - sometimes - but now we're getting automated nastygrams from corporate IT threatening to kick the laptops off the network. I'm exhausted. The emergency workaround, which I tell nobody about, is way less secure than if they just let us run our own software on our own computer.

hkpack 2y ago
I understand that you're doing it on principle, but for a software development team, 99$/year is a really minuscule price to pay to be able to build / notarise / distribute software. Developers pay exorbitant amount of money for much lesser value, and the idea of putting your teammates at risk to stick it to apple is kind of sad bordering with negligence from a business POV.
- hamandcheese 2y ago
  Adding signing as a requirement can easily make what was once a very simple distribution mechanism into something much more complex - now you need manage signing certificates and keys to be able to build your thing. The cost is far far higher than the price.
  - hkpack 2y ago
    But it doesn't in practice. I develop and distribute few free apps for macOS, and building / notarising is never a problem.
    - makeitdouble 2y ago
      You seem to be comparing a single dev sending apps to the world vs a corporate team pushing to employees (if I get parent's case right). In most cases, just involving account management makes the corporate case 10x more of a PITA. Doing things in a corporate environment is a different game altogether.
    - JamesonNetworks 2y ago
      In contrast to this point, as long as I use Xcode and do the same thing I've always done allowing it to manage provisioning and everything else, I don't have a problem. However, I want to use CI/CD. Have you seen what kind of access you have to give fastlane? It's pretty wild. And even after giving it the keys to the kingdom, it still didn't work. Integrating apple code signing with CI/CD is really hard, full of very strange error messages and incantations to make it "work".
      - hkpack 2y ago
        I don't know about fastlane, since my CI/CD is just a shell script, and signing and notarising is as hard as (checking the script) running `codesign ...` followed by `notarytool submit ... --wait` Yes, you need to put keys on the build server for the "Developer ID Application" (which is what you need to distribute apps outside of AppStore) signature to work. You do not need to give any special access to anything else beyond that. Anyway, it is indeed more difficult than cross-build for Darwin from linux and call it a day.
    - mvdtnz 2y ago
      [flagged]
    - 0xCE0 2y ago
      Code signing is absolutely disgusting practically and philosophically. It has very reasonable and good intent behind it, but the practical implementations cause great suffering and sadness both for developers (cert management, cost, tools) and end-users (freedom of computing). It is ugly: https://hearsum.ca/posts/history-of-code-signing-at-mozilla/ https://hearsum.ca/posts/history-of-code-signing-at-mozilla/
    - bshacklett 2y ago
      Do you distribute OSS software which requires notarizing? If so, have you found a way to let the community build the software without a paid developer account? I would be very interested in a solution which allows OSS development, relying on protected APIs without requiring that anyone who builds the app to have a paid developer account.
  - ehutch79 2y ago
    I take it you feel the trade off for dev team inconvenience, vs end user security, is not worth it?
    - hamandcheese 2y ago
      I'm just observing that the cost is a lot higher than $99/year. I do this professionally, I maintain macOS CI workers for my employer. Apple doesn't make it easy.
    - makeitdouble 2y ago
      They're talking about internal software for internal users. It can be made insanely secure, but that surely isn't the primary concern in this case.
- ryandrake 2y ago
  The principle is what matters. The amount is not the issue. The issue is that there is a cost at all. "It's so cheap" is never an excuse for charging for something that should be free. In this case, running software you have no intent to charge for, on your computer. It's as if someone started charging $0.01/month for breathable air. "But $0.01 is trivial," would not excuse it.
  - hkpack 2y ago
    The commenter I replied to employed by a business, develops software and distributes it within a team of engineers with Macs. For your personal needs, you do not need to pay anything for building and using apps locally.
    - bshacklett 2y ago
      Untrue. There are specific APIs which require notarization , regardless of usage. Credential autofill is one such API.
  - ethersteeds 2y ago
    It costs money, and isn't free, for a reason you're not acknowledging. I don't think it's a major profit center for Apple. It's about setting a higher floor for malicious actors than "random botnet residential IP + a captcha solving service". It's about proving some semblance of identity through a card number and a transaction that goes through without a chargeback. As the case upthread shows, there's plenty to dislike about a system that inhibits running code built for personal use. And it's obviously neither foolproof nor without collateral damage. Reasonable people can debate if it's worth it. But it still ought be acknowledged that the motivations are closer to the reason you have to identify yourself and pay a nominal fee to drive a vehicle on public roads.
    - eviks 2y ago
      > But it still ought be acknowledged that the motivations are closer to the reason Since this isn't true, no acknowledgement required, it doesn't need to be a "major" profit center to magically become a benevolent feature
- joezydeco 2y ago
  The tool is built deep in our CI/CD chain. The whole thing is a house of cards built on a massive pile of tinder next to an open drum of kerosene. You want me to integrate XCode into that? Last time I tried setting up an Apple developer license inside a large corporation, one that they paid for and not tied to me or my credit card, it was also a nightmare. And yes, it's also on principle.
  - plorkyeran 2y ago
    Who said anything about Xcode? The codesign tool is part of macOS, not Xcode. The CLI tool for notarization is bundled with Xcode, but you don't have to use it; they have an official REST API that you can use directly.
    - deleted 2y ago
      [deleted]
    - joezydeco 2y ago
      Do you have any notes on how to run it inside a Gitlab pipeline via a Linux Docker instance? I'd love to learn how to do this, then.
- jasonjayr 2y ago
  Sure it's trivial, but it is tacit acceptance that you need permission to make a program on their platform. Permission that needs to be renewed year over year. Permission to earn a living on this platform. Permission that can be revoked for any reason, including being compelled by someone with more power than Apple.
  - hkpack 2y ago
    It is permission to _distribute to others_, you can build and run on your own computer without a problem. Once signed, binary will work forever, you only need active subscription when you need to re-sign / re-notarise.
    - jasonjayr 2y ago
      They can revoke a signature too.
      - hkpack 2y ago
        If your signature is compromised and you start signing malware then yes. That's the whole purpose of it. Do you have any evidence that it happened in any different circumstances at least once?
- NegativeK 2y ago
  $99/year for one of the basic uses of a computer isn't okay.
  - dwaite 2y ago
    Distributing software is not what I would call one of the basic uses of a computer.
KennyBlanken 2y ago
There's extensive documentation. Examples: https://developer.apple.com/documentation/security/code-signing-services https://developer.apple.com/documentation/security/code-sign... https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution https://developer.apple.com/documentation/security/notarizin... There are dedicated sections of the developer web forums: https://developer.apple.com/forums/topics/code-signing-topic https://developer.apple.com/forums/topics/code-signing-topic https://developer.apple.com/forums/topics/code-signing-topic/code-signing-topic-notarization https://developer.apple.com/forums/topics/code-signing-topic... ...and there's an apple developer support person, Quinn, who appears to be heavily if not solely dedicated to helping developers do binary signing/notarization/stapling correctly. They have written a slew of Tech Notes about signing and notarization. Main TN is at https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles https://developer.apple.com/documentation/technotes/tn3125-i... Quinn also has their email address in their sig so people can just reach out via email without even needing an Apple account, or if they prefer more confidentiality. I mean, come on.
- paradite 2y ago
  As someone who actually signs, notorizes and distributes desktop apps for macOS, I can safely say their documentation is less than ideal. Maybe because I'm using Electron framework which makes things more complicated, but I don't really understand why there's is a difference between different types of certificates (Developer ID, Apple distribution, macOS distribution) and I had to guess which one to use everytime I set it up. Also why is notorization a completely different process from code signing, and requires completely different set of credentials from it. Seems odd to me.
  - latexr 2y ago
    > Also why is notorization a completely different process from code signing Because they do completely different things. Signing is a proof that you were the one to write and package that software; notarisation is an online security check for malware. If I recall, you still sign but do not notarise when distributing to the Mac App Store.
mystifyingpoi 2y ago
> emergency workaround I once really urgently needed `nmap` to do some production debugging ASAP. Unfortunately, the security tools would flag this immediately on my machine, as I knew this from previous experiments. Solution - compile my own binary from sources, then quickly rename it. I assume that this "workaround" was totally fine for sec department. At least production got fixed and money kept flowing.
- rollcat 2y ago
  > At least production got fixed and money kept flowing. You were denied the tools to get your job done. You've put yourself at risk by applying an unapproved workaround. Never ever do this (unless you hold substantial shares). Let the company's bottom line take the fall. If that's the only thing they care about, that's your only way to make the problem visible.
  - mystifyingpoi 2y ago
    Unfortunately the real world isn't black and white. Yes, according to the company policies, I should watch the world burn and do nothing, while looking at the company bleeding money due to customers SLA being broken. Of course, after submitting a ticket to get nmap approved, which takes days. Extra points if I'm on oncall, then racking that sweet incident money is great. But the underlying SRE culture here is that, if you know what you are doing and have a functioning brain of a responsible person, you'd be forgiven a jump over the fence, if it means putting out a fire on the other side of it. We aren't kids.
    - bshacklett 2y ago
      There’s a middle ground. Get the appropriate stakeholders involved in the decision, including security. Let security be the ones to keep the system down, if it cones to that. Or, let the business operations folks make the decision to go over security’s head. Either way, this is not something an engineer tasked with fixing an outage should be making the decision on.
TuxSH 2y ago
xattr -cr <file> should clear the "download" extended attribute and make it as if the software was compiled on the machine itself, bypassing the ever-so-annoying Gatekeeper. For binary patching: codesign --force --deep -s - <file> (no developer ID required, "ad-hoc signing" is just updating a few hashes here and there). Note that you should otherwise not use codesign as it is the job of the linker to do it.
- joezydeco 2y ago
  Very aware of the attributes, unfortunately these machines are on a global corporate network so there are layers and layers of monitoring software to prevent internal and external attacks. Changing perm bits on an OSX executable is instantly noted and sent upwards as a possible security breach. Last time we did this I had to spend a week explaining to management that Macs could actually run software other than PowerPoint and it was necessary for our job. The local workaround that we use is to just spin up a Linux VM and program devices from there. The less legal workaround is using WebUSB and I'm afraid to even tell the necessary people how I did it, because it's sitting out on a public-facing server.

hkpack 2y ago

I understand that you're doing it on principle, but for a software development team, 99$/year is a really minuscule price to pay to be able to build / notarise / distribute software. Developers pay exorbitant amount of money for much lesser value, and the idea of putting your teammates at risk to stick it to apple is kind of sad bordering with negligence from a business POV.

hamandcheese 2y ago
Adding signing as a requirement can easily make what was once a very simple distribution mechanism into something much more complex - now you need manage signing certificates and keys to be able to build your thing. The cost is far far higher than the price.
- hkpack 2y ago
  But it doesn't in practice. I develop and distribute few free apps for macOS, and building / notarising is never a problem.
  - makeitdouble 2y ago
    You seem to be comparing a single dev sending apps to the world vs a corporate team pushing to employees (if I get parent's case right). In most cases, just involving account management makes the corporate case 10x more of a PITA. Doing things in a corporate environment is a different game altogether.
  - JamesonNetworks 2y ago
    In contrast to this point, as long as I use Xcode and do the same thing I've always done allowing it to manage provisioning and everything else, I don't have a problem. However, I want to use CI/CD. Have you seen what kind of access you have to give fastlane? It's pretty wild. And even after giving it the keys to the kingdom, it still didn't work. Integrating apple code signing with CI/CD is really hard, full of very strange error messages and incantations to make it "work".
    - hkpack 2y ago
      I don't know about fastlane, since my CI/CD is just a shell script, and signing and notarising is as hard as (checking the script) running `codesign ...` followed by `notarytool submit ... --wait` Yes, you need to put keys on the build server for the "Developer ID Application" (which is what you need to distribute apps outside of AppStore) signature to work. You do not need to give any special access to anything else beyond that. Anyway, it is indeed more difficult than cross-build for Darwin from linux and call it a day.
  - mvdtnz 2y ago
    [flagged]
  - 0xCE0 2y ago
    Code signing is absolutely disgusting practically and philosophically. It has very reasonable and good intent behind it, but the practical implementations cause great suffering and sadness both for developers (cert management, cost, tools) and end-users (freedom of computing). It is ugly: https://hearsum.ca/posts/history-of-code-signing-at-mozilla/ https://hearsum.ca/posts/history-of-code-signing-at-mozilla/
  - bshacklett 2y ago
    Do you distribute OSS software which requires notarizing? If so, have you found a way to let the community build the software without a paid developer account? I would be very interested in a solution which allows OSS development, relying on protected APIs without requiring that anyone who builds the app to have a paid developer account.
- ehutch79 2y ago
  I take it you feel the trade off for dev team inconvenience, vs end user security, is not worth it?
  - hamandcheese 2y ago
    I'm just observing that the cost is a lot higher than $99/year. I do this professionally, I maintain macOS CI workers for my employer. Apple doesn't make it easy.
  - makeitdouble 2y ago
    They're talking about internal software for internal users. It can be made insanely secure, but that surely isn't the primary concern in this case.
ryandrake 2y ago
The principle is what matters. The amount is not the issue. The issue is that there is a cost at all. "It's so cheap" is never an excuse for charging for something that should be free. In this case, running software you have no intent to charge for, on your computer. It's as if someone started charging $0.01/month for breathable air. "But $0.01 is trivial," would not excuse it.
- hkpack 2y ago
  The commenter I replied to employed by a business, develops software and distributes it within a team of engineers with Macs. For your personal needs, you do not need to pay anything for building and using apps locally.
  - bshacklett 2y ago
    Untrue. There are specific APIs which require notarization , regardless of usage. Credential autofill is one such API.
- ethersteeds 2y ago
  It costs money, and isn't free, for a reason you're not acknowledging. I don't think it's a major profit center for Apple. It's about setting a higher floor for malicious actors than "random botnet residential IP + a captcha solving service". It's about proving some semblance of identity through a card number and a transaction that goes through without a chargeback. As the case upthread shows, there's plenty to dislike about a system that inhibits running code built for personal use. And it's obviously neither foolproof nor without collateral damage. Reasonable people can debate if it's worth it. But it still ought be acknowledged that the motivations are closer to the reason you have to identify yourself and pay a nominal fee to drive a vehicle on public roads.
  - eviks 2y ago
    > But it still ought be acknowledged that the motivations are closer to the reason Since this isn't true, no acknowledgement required, it doesn't need to be a "major" profit center to magically become a benevolent feature
joezydeco 2y ago
The tool is built deep in our CI/CD chain. The whole thing is a house of cards built on a massive pile of tinder next to an open drum of kerosene. You want me to integrate XCode into that? Last time I tried setting up an Apple developer license inside a large corporation, one that they paid for and not tied to me or my credit card, it was also a nightmare. And yes, it's also on principle.
- plorkyeran 2y ago
  Who said anything about Xcode? The codesign tool is part of macOS, not Xcode. The CLI tool for notarization is bundled with Xcode, but you don't have to use it; they have an official REST API that you can use directly.
  - deleted 2y ago
    [deleted]
  - joezydeco 2y ago
    Do you have any notes on how to run it inside a Gitlab pipeline via a Linux Docker instance? I'd love to learn how to do this, then.
jasonjayr 2y ago
Sure it's trivial, but it is tacit acceptance that you need permission to make a program on their platform. Permission that needs to be renewed year over year. Permission to earn a living on this platform. Permission that can be revoked for any reason, including being compelled by someone with more power than Apple.
- hkpack 2y ago
  It is permission to _distribute to others_, you can build and run on your own computer without a problem. Once signed, binary will work forever, you only need active subscription when you need to re-sign / re-notarise.
  - jasonjayr 2y ago
    They can revoke a signature too.
    - hkpack 2y ago
      If your signature is compromised and you start signing malware then yes. That's the whole purpose of it. Do you have any evidence that it happened in any different circumstances at least once?
NegativeK 2y ago
$99/year for one of the basic uses of a computer isn't okay.
- dwaite 2y ago
  Distributing software is not what I would call one of the basic uses of a computer.

KennyBlanken 2y ago

There's extensive documentation. Examples: https://developer.apple.com/documentation/security/code-signing-services https://developer.apple.com/documentation/security/code-sign... https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution https://developer.apple.com/documentation/security/notarizin... There are dedicated sections of the developer web forums: https://developer.apple.com/forums/topics/code-signing-topic https://developer.apple.com/forums/topics/code-signing-topic https://developer.apple.com/forums/topics/code-signing-topic/code-signing-topic-notarization https://developer.apple.com/forums/topics/code-signing-topic... ...and there's an apple developer support person, Quinn, who appears to be heavily if not solely dedicated to helping developers do binary signing/notarization/stapling correctly. They have written a slew of Tech Notes about signing and notarization. Main TN is at https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles https://developer.apple.com/documentation/technotes/tn3125-i... Quinn also has their email address in their sig so people can just reach out via email without even needing an Apple account, or if they prefer more confidentiality. I mean, come on.

paradite 2y ago
As someone who actually signs, notorizes and distributes desktop apps for macOS, I can safely say their documentation is less than ideal. Maybe because I'm using Electron framework which makes things more complicated, but I don't really understand why there's is a difference between different types of certificates (Developer ID, Apple distribution, macOS distribution) and I had to guess which one to use everytime I set it up. Also why is notorization a completely different process from code signing, and requires completely different set of credentials from it. Seems odd to me.
- latexr 2y ago
  > Also why is notorization a completely different process from code signing Because they do completely different things. Signing is a proof that you were the one to write and package that software; notarisation is an online security check for malware. If I recall, you still sign but do not notarise when distributing to the Mac App Store.

mystifyingpoi 2y ago

> emergency workaround I once really urgently needed `nmap` to do some production debugging ASAP. Unfortunately, the security tools would flag this immediately on my machine, as I knew this from previous experiments. Solution - compile my own binary from sources, then quickly rename it. I assume that this "workaround" was totally fine for sec department. At least production got fixed and money kept flowing.

rollcat 2y ago
> At least production got fixed and money kept flowing. You were denied the tools to get your job done. You've put yourself at risk by applying an unapproved workaround. Never ever do this (unless you hold substantial shares). Let the company's bottom line take the fall. If that's the only thing they care about, that's your only way to make the problem visible.
- mystifyingpoi 2y ago
  Unfortunately the real world isn't black and white. Yes, according to the company policies, I should watch the world burn and do nothing, while looking at the company bleeding money due to customers SLA being broken. Of course, after submitting a ticket to get nmap approved, which takes days. Extra points if I'm on oncall, then racking that sweet incident money is great. But the underlying SRE culture here is that, if you know what you are doing and have a functioning brain of a responsible person, you'd be forgiven a jump over the fence, if it means putting out a fire on the other side of it. We aren't kids.
  - bshacklett 2y ago
    There’s a middle ground. Get the appropriate stakeholders involved in the decision, including security. Let security be the ones to keep the system down, if it cones to that. Or, let the business operations folks make the decision to go over security’s head. Either way, this is not something an engineer tasked with fixing an outage should be making the decision on.

TuxSH 2y ago

xattr -cr <file> should clear the "download" extended attribute and make it as if the software was compiled on the machine itself, bypassing the ever-so-annoying Gatekeeper. For binary patching: codesign --force --deep -s - <file> (no developer ID required, "ad-hoc signing" is just updating a few hashes here and there). Note that you should otherwise not use codesign as it is the job of the linker to do it.

joezydeco 2y ago
Very aware of the attributes, unfortunately these machines are on a global corporate network so there are layers and layers of monitoring software to prevent internal and external attacks. Changing perm bits on an OSX executable is instantly noted and sent upwards as a possible security breach. Last time we did this I had to spend a week explaining to management that Macs could actually run software other than PowerPoint and it was necessary for our job. The local workaround that we use is to just spin up a Linux VM and program devices from there. The less legal workaround is using WebUSB and I'm afraid to even tell the necessary people how I did it, because it's sitting out on a public-facing server.