If your macOS app is in a sandbox, you’ll be using the version that relies on XPC services to perform the update. Like everything else in your application package, these will need to be signed correctly before you can submit your app for notarization.
The “Sign Frameworks” build phase should look like this[…]
[…]
You’ll also add a new Run Script build phase just before the XPC Services are embedded in your application package.
Previously:
I had been thinking about ways to improve my summertime beta setup when Other World Computing offered to send me its OWC Thunderbolt 3 Dock to test. I took them up on the offer, and having used it for a while now, I love the convenience of being able to connect everything to my MacBook Pro with a single Thunderbolt 3 cable. It’s not an inexpensive solution, but compared to the cost of purchasing multiple over-priced dongles, it’s not as extravagant as it might seem at first.
[…]
One especially nice touch that I appreciate is a free menu bar utility OWC offers called OWC Dock Ejector. If you have multiple drives attached to a dock, the process of ejecting each one before disconnecting the dock defeats some of the convenience of having a single Thunderbolt cable connected to your Mac. With OWC Dock Ejector, a single click safely ejects every external drive attached to my dock, so I can yank out the Thunderbolt cable and be on my way.
Another $300+ dock. This one gives you a passthrough Thunderbolt port, a Mini DisplayPort, and a single USB-C port. How about just putting more ports on the computer?
Previously:
Update (2019-08-20): See also: Jon Alper and my reply.
Update (2019-08-23): Howard Oakley :
The same happened with good old USB-A: even when your Mac has four, you quickly accumulate more USB-C devices than you’ve got ports. Yet no one seems to be offering a ‘port expander’ to turn a single USB-C port into several. In particular, I’m now accumulating several external SSDs in compact cases. One obvious step forward would be to mount two or more in a single housing, which is the aim of this article.
The
curl --libcurloption generates a C file that mimics the used command line! #awesome
I’m a fan of this pattern. Some other examples:
Update (2019-08-20): Michael Tofias:
I don’t use it often these days, but one of things that made me fall in love with Stata was being able to copy the code generated by using the GUI. Super helpful when building graphs and such with non-intuitive APIs.
WebKit (via Jon Davis, Hacker News):
This document describes the web tracking practices that WebKit believes, as a matter of policy, should be prevented by default by web browsers. These practices are harmful to users because they infringe on a user’s privacy without giving users the ability to identify, understand, consent to, or control them.
[…]
WebKit will do its best to prevent all covert tracking, and all cross-site tracking (even when it’s not covert). These goals apply to all types of tracking listed above, as well as tracking techniques currently unknown to us.
[…]
We do not grant exceptions to our tracking prevention technologies to specific parties. Some parties might have valid uses for techniques that are also used for tracking. But WebKit often has no technical means to distinguish valid uses from tracking, and doesn’t know what the parties involved will do with the collected data, either now or in the future.
It’s good to have this all summarized in one place.
There are practices on the web that we do not intend to disrupt, but which may be inadvertently affected because they rely on techniques that can also be used for tracking. […] When faced with a tradeoff, we will typically prioritize user benefits over preserving current website practices. […] However, we will try to limit unintended impact. We may alter tracking prevention methods to permit certain use cases, particularly when greater strictness would harm the user experience.
I can’t tell from this whether they intend to prioritize the “user benefit” of not being tracked above the benefit of being able to use the site. It sounds like the policy is to decide case-by-case.
Previously:
Key Negotiation of Bluetooth Attack (via Luis Grangeia, Hacker News):
The specification of Bluetooth includes an encryption key negotiation protocol that allows to negotiate encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process. A remote attacker can manipulate the entropy negotiation to let any standard compliant Bluetooth device negotiate encryption keys with 1 byte of entropy and then brute force the low entropy keys in real time.
[…]
The KNOB attack is possible due to flaws in the Bluetooth specification. As such, any standard-compliant Bluetooth device can be expected to be vulnerable. We conducted KNOB attacks on more than 17 unique Bluetooth chips (by attacking 24 different devices). At the time of writing, we were able to test chips from Broadcom, Qualcomm, Apple, Intel, and Chicony manufacturers. All devices that we tested were vulnerable to the KNOB attack.
After we disclosed our attack to industry in late 2018, some vendors might have implemented workarounds for the vulnerability on their devices. So the short answer is: if your device was not updated after late 2018, it is likely vulnerable. Devices updated afterwards might be fixed.
What is even more bananas than the mere existence of this attack is the statement of the bluetooth standardization group.
Here’s their plan to fix this:
To remedy the vulnerability, the Bluetooth SIG has updated the Bluetooth Core Specification to recommend a minimum encryption key length of 7 octets for BR/EDR connections
7 octets, aka… 56 bit. So it looks like this vulnerability is here to stay. They just raise the bar from “trivially breakable” to “you need a bit of cloudcomputing effort to break a connection”.
For an attack to be successful, an attacking device would need to be within wireless range of two vulnerable Bluetooth devices that were establishing a BR/EDR connection. If one of the devices did not have the vulnerability, then the attack would not be successful. The attacking device would need to intercept, manipulate, and retransmit key length negotiation messages between the two devices while also blocking transmissions from both, all within a narrow time window.
So it sounds like the good news is that this could potentially be fixed at the OS level, i.e. updating half of each pair. You wouldn’t have to replace all your Bluetooth devices.
Update (2019-08-29): Josh Centers:
Apple has already mitigated this vulnerability in macOS 10.14.6 Mojave, Security Update 2019-004 for Sierra and High Sierra, iOS 12.4, watchOS 5.3, and tvOS 12.4.
