Patrick Wardle:
So, now imagine an attacker has found an legitimate signed application that attempts to load or execute some relatively external content (i.e outside it’s app bundle, but within the same download package). In the past, they could use this to bypass Gatekeeper as such external content was not verified. Now however, when the user double-clicks the application to execute it, the OS intercepts this, and will create a read-only DMG image on the fly for the application bundle, and only the application bundle. This translocated copy is then executed. Here in this new location, it will not be able find the unverified external content (as it was not copied over), and thus the attack fails.
[…]
As a security researcher/hacker, I must give a lot of kudos to Apple for (finally) fixing the underlying issue in comprehensive manner. However as developer, f**kkkkk this broke a lot of stuff.
[…]
With this information the translocated application can programmatically both remove the quarantine attribute and then re-execute the original instance of the application (e.g. in ~/Downloads). The net result of this is that the App Translocation is ‘undone’ and the application is transparently executed from its original location on a writeable filesystem.
However, this is not safe for apps that actually use external resources because it undoes the protection that App Translocation provides.
Previously: Gatekeeper Path Randomization.
Update (2016-12-19): Despite finding Wardle’s technique interesting, I should note that I agree with Apple’s recommendation to use signed disk images, which DropDMG can help you create.
Gatekeeper Mac macOS 10.12 Sierra Security
Eric Newcomer (Hacker News):
Though the name GitHub is practically unknown outside technology circles, coders around the world have embraced the software. The startup operates a sort of Google Docs for programmers, giving them a place to store, share and collaborate on their work. But GitHub Inc. is losing money through profligate spending and has stood by as new entrants emerged in a software category it essentially gave birth to, according to people familiar with the business and financial paperwork reviewed by Bloomberg.
[…]
The issue took on a new sense of urgency in 2014 with the formation of a rival startup with a similar name. GitLab Inc. went after large businesses from the start, offering them a cheaper alternative to GitHub. “The big differentiator for GitLab is that it was designed for the enterprise, and GitHub was not,” says GitLab CEO Sid Sijbrandij. “One of the values is frugality, and this is something very close to our heart. We want to treat our team members really well, but we don’t want to waste any money where it’s not needed. So we don’t have a big fancy office because we can be effective without it.”
Almost nine years old, revenue of almost $100 million per year, but losing money—I guess because they have 600 employees.
Previously: What It’s Like to Take on Venture Capital Investment.
Update (2016-12-20): Manton Reece:
These numbers seem fantastic except that GitHub is losing money overall. GitHub has transformed from a small profitable company to a large unprofitable VC-backed company.
Update (2016-12-21): Moritz Plassnig (via Hacker News):
Despite all the adoption and great numbers that I mentioned, GitHub is seeing more competition recently. GitLab is doing a wonderful job in challenging them on a product level. For many years, GitHub didn’t have any competition which naturally led to less pressure and a slower pace for releasing product improvements. This development combined with some troubling cultural issues, multiple changes in the leadership team, and an influx of cash from huge financing rounds caused a lot of employee turnover. Changing your company culture from bootstrapping, no managers, and “Optimizing for Happiness“ to being a VC-backed startup with a lot of money, directly translating into more employees, is hard - very hard.
[…]
It’s hard to analyze GitHub’s financials and metrics without having direct access to the data. With what we know from Bloomberg, GitHub is to be doing very well financially. $140M in ARR with roughly 62% YoY growth makes them an IPO candidate. GitHub historically generated the majority of their revenue without Sales and outside of the enterprise market. Their ability to move up-market, close large deals and generating more than 50% of their revenue with their enterprise product is very promising and will allow them to maintain a high revenue growth rate.
Business Git GitHub Web
Nick Snyder (via Dave Verwer):
Here’s an example of a layout in the LinkedIn app. It has two labels: there’s a multi-line label on the left, and a single line label on the right. For the right label, we just want it to be as big as it needs to be to display the content. Think of it as a badge with a number. Then the left label just has some arbitrary amount of text that we want to wrap to up to two lines.
To accomplish this using Auto Layout, on the right label we give it required content hugging and required content compression resistance, so that it’s exactly the width that it needs to be. This worked fine in iOS 8, and it worked fine with all the sample data that we tested this layout with during development. But when iOS 9 launched, this caused a huge performance problem for some of our users that we didn’t know about until they started complaining.
[…]
We have Auto Layout as our baseline, 1x. You can see that if you use UIStackView, it’s actually slower than Auto Layout because it’s built on top of Auto Layout. On the right, we have manual layout. Manual layout is 9.4 times faster than Auto Layout. On the green we have LayoutKit, and LayoutKit is about 7.7 times faster than Auto Layout. Not as fast as doing manual layout, but you get a lot of nice things without having to write a lot of code.
Auto Layout Cocoa iOS iOS 10 iOS App LinkedIn Open Source Optimization Programming Swift Programming Language
Daniel Jalkut:
I wrote previously about crashes related to Apple’s Touch Bar. These crashes seem to affect all apps that were built with a certain toolchain. Most likely it affects all apps that were built against an SDK of a certain vintage. For example, some of my apps that are still built against a 10.6 SDK crash on Touch Bar Macs, either frequently or infrequently, depending upon the user.
I had hoped that we might see a fix from Apple in macOS 10.12.2, but alas the issue is still there.
[…]
Poking around the AppKit infrastructure supporting the Touch Bar, I discovered a secret NSUserDefaults setting, NSFunctionBarAPIEnabled, which seems to determine whether the system exposes an app to the Touch Bar at all. It defaults to YES, but if it’s set to NO for an app, I think the app remains more or less invisible to the Touch Bar.
Worth a try if, like me, you are getting crashes in DFRFoundation/DFRElement/CALayer.
Update (2017-01-13): Instead of using NSFunctionBarAPIEnabled, you can set NSLayerPerformanceUpdates to YES. This works around the memory management bug that causes the crash without having to turn off the Touch Bar.
Bug Esoteric Preferences Mac macOS 10.12 Sierra Touch Bar
