we have developed a kernel extension (KEXT) for a virtual file system (VFS) on macOS to integrate our software with external programs like Adobe InDesign or Microsoft Word. Our software and the KEXT are used by many of our customers.
As it looks like KEXTs are deprecated and may be removed completely in future versions of macOS, particularly on Apple Silicon based computers. See e.g. Apple's announcement in its security guide:
"This is why developers are being strongly encouraged to adopt system extensions before kext support is removed from macOS for future Mac computers with Apple silicon"
Therefore we are currently investigating in possible alternatives.
Apple suggests to migrate to System Extensions instead of KEXTs. However, the only VFS related API we found is to implement a File Provider that is based on an NSFileProviderReplicatedExtension.
Unfortunately that NSFileProviderReplicatedExtension has several flaws:
Files can either be in the cloud or downloaded. It is not possible to download/read only a portion of a file. This is a big performance problem for us, since we work with large images (> 1GB). The programs we integrate with typically only read a part of the image, e.g. the embedded preview. The API does not offer a way to access selected blocks of a file (random access file).
The File Provider learns about the file system content via enumerators. So everything that is inside a folder must be enumerated (listed) first. Otherwise it cannot be accessed. However, we cannot enumerate our VFS. Most of the content of our VFS is fully dynamic. It only exists when it is accessed by a client the first time. Such dynamic content also includes dynamic parameters like the client's locale or the size of a box where the image will be placed. Since we do not know those parameters in advance, we cannot enumerate the VFS's content in advance.
This means, an NSFileProviderReplicatedExtension in its current state isn't a replacement for a "real" VFS and therefore cannot be used by us as a replacement for our current VFS KEXT.
My questions:
Will Apple allow kernel extensions also in future versions of (Apple Silicon/M1 based) operating systems? Or is there at least a clear deadline?
If not, what is Apple's officially suggested replacement for KEXT based VFS solutions?
Will the API of an NSFileProviderReplicatedExtension be improved to behave like a "real" file system so that above mentioned flaws will no longer be an issue?
Many thanks for any answers or comments!
Best regards,
Michael
Will Apple allow kernel extensions also in future versions of (Apple Silicon/M1 based) operating systems? Or is there at least a clear deadline?
Apple doesn't really give timelines, and they also occasionally break promises of support.
However, this sort of hard API deprecation and removal usually is done as part of a major release, so you will typically get deprecation notice for it at WWDC one year, users might start seeing deprecation notices when the .0 of the OS release ships at the earliest, and sometimes the .3 or .4 revision. Then you'll typically be told at the next WWDC that the API is blocked in the upcoming release, so by that point you should have implemented a replacement.
If not, what is Apple's officially suggested replacement for KEXT based VFS solutions?
As far as I'm aware, NSFileProviderReplicatedExtension is currently the only one.
Will the API of an NSFileProviderReplicatedExtension be improved to behave like a "real" file system so that above mentioned flaws will no longer be an issue?
Other than via beta SDKs, Apple generally doesn't pre-announce future APIs.
My advice:
File issues for each of the file provider shortcomings you are hitting using Feedback Assistant. (Radar)
File an "enhancement request" feedback issue with Apple for a "real" file system API replacement for the VFS KPI.
If your vfs kext is critical to your business/product, I suggest additionally asking Apple's DTS via a TSI what they recommend for your situation. Reference the feedback IDs of the issues filed, otherwise they will recommend that you file issues.
Related
I was wondering if it's possible to build a Mach-O file, or modify an existing one and then re-sign it so that the code sections will be encrypted.
I know that there's a flag called cryptid that represent the encryption type (by values `EncryptionInfo32/64 for load commands LC_ENCRYPTION_INFO_32/64 respectively)
However, I couldn't find anywhere in Xcode for how it's done.
EDIT : I'm well aware that it can be done in iOS, but my question relate to macOS, does the platform support this encryption feature in Mach-O file ?
EDIT2: So after reading the other question I understood that the whole encryption thing can only be done by appStore which is after the Mach-O file is already left the developer side. So in this case, Apple actually controlled the encryption/decryption algo+key and it's completely outside the developer hand, right ?
Also, since the Mach-O is being changed during the encryption, so who's in charge to re-sign the application ?
Thanks
No, you cannot do this.
The only "supported" way of getting LC_ENCRYPTION_INFO added to your binary is by distributing through the iOS App Store. It is Apple who checks your binary for compliance with their rules, then encrypts the binary and re-signs it.
This is all backed by "FairPlay", Apple's proprietary DRM stack. Not much is known about it since the code is heavily obfuscated, but it is widely believed that it's built on features of Apple's custom hardware AES engine. Given this, it may or may not be possible to create an encryptor yourself, but it would require immense reverse engineering efforts to even find out.
Further, the entire FairPlay stack is only present on Apple's own chips. It is indeed available on M1 Macs, as you can install iOS apps off the shelf (so long as you leave SIP enabled), but it is not available at all on Intel Macs (the relevant kexts are IOTextEncryptionFamily.kext and FairPlayIOKit.kext, the latter of which is obfuscated).
I have advised of a security issue found on the software GIMP 2.8.14. The vulnerability description can be found here: Vulnerability Description
And the CVE here: CVE-2016-4994
When I was advised of the vulnerability, I also was advised about a solution, which is update the software with a particular version sent to me in that advise. The thing is that the upgrade is available only for linux, and we have GIMP on Windows.
Do you know something about the risks of this vulnerability on 2.8.16 version (which is the one that we have)? And if there are risks, do you know the proper actions to avoid that?
I haven't found anything about GIMP on Windows, all the solutions are set for Linux.
Thanks beforehand.
The new version 2.8.18 of GIMP fixes this vulnerability. Check the releaase notes at: http://www.gimp.org/news/2016/07/14/gimp-2-8-18-released/
However, I don'think that is a big issue at all.
GIMP is not meant to be "secure software" - it runs as a user processor, and have to deal with tens of file formats, each one able to have up to hundreds of different data structures. It uses third-party libraries to handle some of those data formats.
One can't expect any version of GIMP to be secure against opening a file and have that file execute arbitrary code, with the same privileges the program itself has. While this particular vulnerability tells about GIMP's native XCF files, which may be fixed in that respect, one can simply open a postscript file, which is by definition a complete program - and will run arbitrary code, even for well-formed images. In most cases, the postcript libraries in use should sandbox the running program and prevent it from accessing, say, the filesystem, but it will be able to use CPU as a DoS attack nevertheless.
It is up to your OS to control what resources an user application can access. Vulnerabilities in GIMP won't offer privilege escalation, if the OS is tight. And one could even use finer grained security features (e.g. SELinux) to further restrict application access.
As for GIMP, the 2.8.18 version is out as of yesterday - if this particular issue is marked as fixed, you should try to grab that one.
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
Does anyone know library to browse (and upload/download/stream) on smb shares (SMB/CIFS protocol) from iOS. This must be support for all the Windows OS. This is grade help for me.
Not quite an answer to your question, but I have some tips:
If you write your own client, don't trust the IETF RFC. Microsoft
hasn't been scrupulous in its adherence to the spec. And be sure to
test with Unicode file/folder names, all major versions of Windows,
and so on.
Don't write your own client. :-)
If you use an open-source library, make sure it's not GPL or LGPL,
unless you plan to open-source your entire project. LGPL almost
works—it does on Mac OS X—but it requires dynamic linking, which
isn't supported on iOS.
You may see apps in the app store that use GPL or LGPL libraries,
but don't assume that it is safe to use them yourself. Those apps
are often blatantly abusing the license.
opensource.apple.com has an smb client that's a great reference but
it's a file system kernel extension, so you can't use it directly.
I am wondering what technologies are used by the new Mac OS AirDrop and if there is a way to use it on windows.
You know that AirDrop is a feature that will be introduced as part of Mac OS X Lion (version 10.7), right? That version of the OS is not even out yet, and it won't be until later this summer.
Furthermore, I assume that the handful of lucky developers who have a pre-release copy are under a strict non-disclosure agreement (this is Apple, and that's pretty standard policy in the industry anyway), which would keep them from giving any details about the feature in a public forum such as this one.
But, since I am not one of those lucky developers, I suppose I'm free to do a little speculating about how it might work. Presumably, it takes advantage of Apple's existing Bonjour network service discovery protocol (formerly known as Rendezvous) to locate other users nearby whose devices support AirDrop. The rest of the pieces have been part of Mac OS X for years, they just haven't been wrapped up in a fancy, easy to use interface (really, that's about all that software development is about nowadays). There's always been rich support for peer-to-peer networking, you've always been able to share files with other users, users have always had a public folder, etc. (This is UNIX we're talking about, after all.)
Will it work on Windows? Maybe. Apple has been surprisingly good in recent history about including its Windows brethren in on the fun—iTunes, Safari, MobileMe, etc. But it doesn't always happen right away. Rolling your own solution for Windows (or any other platform) would be pretty simple, but there's no guarantee that it will be compatible with Apple's.
Bonjour happens at layer 3, so it may be a small part of it.
The real question is how does AirDrop work at layer 2.
Airdrop was reverse-engineerd by the https://owlink.org/ folks. They implemented a free Python version called opendrop as well. The implementation is (unsurprisingly) quite hairy as you need to setup a special Wi-Fi link alongside some bluetooth voodoo, but it apparently works. Or at least it works better than whatever we had before, which was those few question around SE:
Implementing the AirDrop protocol
Is it possible to listen on the Airdrop protocol with my Ubuntu machine?