fly: remove removal of quarantine #98525
Conversation
|
@vitorgalvao Requiring this to be done through the GUI is very much an anti-pattern. While I respect the decision to avoid automatically untainting it, the xattr instructions should be provided as caveats during install, rather than forcing the user to use the GUI. My problem isn't with the security considerations here, it's with enforcing a multi-click, GUI approach to solving a known issue with a specific binary when a command-line alternative with no root privileges required can be presented to the user during cask installation. |
Nobody is requiring you to go through the GUI. I’ve pointed out above how to it at install time: |
The point is that it's non-intuitive for users who may not realize that they need to install it with different arguments. That's why I'm suggesting putting the solution into the caveats displayed to the user, rather than being something they need to know before attempting the installation. |
Which is the case for literally every cask with signed software. There’s nothing special about this one. You’re arguing for it because you use it. |
|
Apologies for all the trouble I caused with this @vitorgalvao. |
Not at all! It’s two minor casks; no big deal in the slightest. By now I’ve said it multiple times and it continues to hold: in my book, you’re a fantastic maintainer. |
We (HBC) are the ones who add the quarantine, so we should never be the ones removing it. That breaks expectations. Removing quarantine ourselves in one cask means users who rely on it being active have to check every cask installation to see if it’s there.
We explain how to remove quarantine when needed and have
--no-quarantine, both of those need to be explicitly called by users thus indicating explicit consent. That’s the way it should be. Either that or we remove quarantining altogether, but we should never say we do something and then do the reverse (bugs excluded).Refs #98458.
cc @miccal @todd-a-jacobs.