libcups uses deprecated/private Security.framework APIs

[vkhorana]

I submitted App for Mac App Store review and had got the following reply:

Symbols: _SecCertificateIsValid, _cssmErrorString, _SecCertificateCreateWithBytes, _SecCertificateNotValidAfter
From framework: /System/Library/Frameworks/Security.framework/Versions/A/Security
In binary: Contents/Frameworks/QUtil.framework/Versions/A/Resources/libcups.dylib

The use of non-public APIs is not permitted on the App Store, because it can lead to a poor user experience should these APIs change.

Next Steps:
If you are using third-party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries' source, you may be able to search the compiled binary using the "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These tools can help you narrow down where the problematic code resides.

Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.

Any plans to remove these instances?

[vkhorana]

Instead of _SecCertificateCreateWithBytes we can use SecCertificateCreateWithData.
And instead of _SecCertificateIsValid and _SecCertificateNotValidAfter we can query the certificate with kSecOIDInvalidityDate and kSecOIDX509V1ValidityNotAfter.
Not sure about _cssmErrorString.

But I am still not sure that are there more instances of non-public APIs in cups library?

[michaelrsweet]

@vkhorana You should be using the macOS libcups and not your own compiled version of libcups.

[vkhorana]

@michaelrsweet I want to use pstops, but in sandboxed environment I am not able to use it. Thats why I bundled it.

[michaelrsweet]

Well, you can just bundle pstops and not all of the CUPS libraries - that will eliminate the direct references to those symbols while giving you access to pstops.

[vkhorana]

@michaelrsweet thank you so much. we will try that. and get back to you incase of any issues.

[michaelrsweet]

OK, we are revisiting this after reviewing the code in question. I can't say we'll have all of the private APIs eliminated in 2.3.x, but I've been able to clean out usage of cssmErrorString and switch to SecCertificateCreateWithData. I'll need to do more testing to see if we can eliminate the other calls.

[michaelrsweet]

kSecOIDInvalidityDate and kSecOIDX509V1ValidityNotAfter are not available on iOS... :/

Continuing my investigations...

[michaelrsweet]

Near as I can tell right now, we can't move off SecCertificateIsValid or SecCertificateNotValidAfter since iOS does not allow any certificate introspection... :/ It is possible that in the future we can move to using SecTrustEvaluate(), however that will require some significant changes that I am not comfortable with...

[vkhorana]

@michaelrsweet thanks for your efforts. We started bundling libcups because when I tried to build pstops then the libcups.dylib was also created in the build folder and I thought that pstops might be referencing this dylib. If that's not the case then we can try to bundle pstops only.

[vkhorana]

@michaelrsweet my app again got rejected. this time i only bundled pstops. and here is the comment i got:

Symbols: __cups_strcasecmp, __cupsLangPrintError, __cupsLangPrintf, __cupsLangPrintFilter
From framework: /usr/lib/libcups.dylib
In binary: Contents/Frameworks/QUtil.framework/Versions/A/Resources/pstops

The use of non-public APIs is not permitted on the App Store, because it can lead to a poor user experience should these APIs change.

We are constantly reevaluating and identifying non-public APIs that you may have been using for an extended period of time. You should always use public APIs and frameworks and ensure they are up-to-date to prevent this issue in the future.

[michaelrsweet]

pstops-standalone.tar.gz

Here is a version of the pstops sources that doesn't link against the CUPS string/localization functions.

[vkhorana]

@michaelrsweet i did changes locally and submitted a build again. I also removed the localized instances because these were mostly error logging functions. Shall I send you changed files for review?

[michaelrsweet]

@vkhorana No, that isn't necessary. I just wanted to make sure you would be able to submit without those issues.

[vkhorana]

@michaelrsweet thanks you so much for ur prompt action. Really appreciate!
😊

[IthacaRonD]

@michaelrsweet We had an iOS app approved 2 months ago that was based on Cups 2.1.2 with only SecCertificateCreateWithData used to replace SecCertificateCreateWithBytes (but no other changes to tls-darwin.c). Last night we had our newer app (based on CUPS 2.2.4) rejected with the following private symbols quoted: _SecCertificateCreateWithBytes, _SecCertificateIsValid, _SecCertificateNotValidAfter, _SecGenerateSelfSignedCertificate, _SecIdentityCreate, _kSecCSRBasicContraintsPathLen, _kSecCertificateKeyUsage, _kSecOidCommonName, _kSecOidOrganization, _kSecSubjectAltName. The person who updated the CUPS library (2.1.2 -> 2.2.4) wasn't aware of this issue which is why we were flagged for _SecCertificateCreateWithBytes again. Some of those 10 symbols were in 2.1.2 in an app that was approved 2 months ago. Did the scanning logic in the approval process change recently? If you can't get all of the private APIs out of CUPS for the 2.3 release, will the position be that we can't use the CUPS distribution in iOS apps? Thanks for any additional feedback you might have.

[michaelrsweet]

@IthacaRonD I'm not able to say whether or why things have changed WRT iOS application screening. I do know that the SecureTransport APIs are slowly being deprecated, so perhaps that is the cause...

As for how to use CUPS on iOS, keep in mind that libcups.2.dylib has been distributed with iOS since iOS 8, so you should be able to just use the open source headers with the shipped libcups.

[IthacaRonD]

@michaelrsweet Thanks for the quick reply! At one point in the history of this app we needed to make a small tweak in the cups code to ensure we'd work with all the printers we wanted to work with, but I believe we no longer need to and would welcome being able to take advantage of what is already in iOS. I'll certainly investigate. Thanks again!

[IthacaRonD]

@michaelrsweet One quick followup. I've made the switch to utilizing the built in CUPS. I took the public headers from the 2.2.11 distribution and made a Xcode project for CUPS that is embedded in my main Xcode Workspace for our product. The public headers have been added to that embedded project file and this allows me to access CUPS from both Objective-C and Swift. Only problem is that the public headers say that CUPS is only available in iOS 11 and later and that is enforced with the use of @available macros. I removed the @available macros and confirmed that the app crashes on iOS 10. Is there any way to access built-in CUPS on iOS 10? Thanks again!

[michaelrsweet]

@IthacaRonD OK, I did some more digging and it looks like the libcups.2.dylib file wasn't included until iOS 11 (previous to that we linked it statically into another framework). How far back do you need to support?

[IthacaRonD]

@michaelrsweet We need to support back to iOS 10 for now. In future releases (after iOS 13 is out) we will probably only support back to iOS 11 at which point your previous suggestion will work. But the release we are trying to get out now still needs to support iOS 10. While it is easy to substitute SecCertificateCreateWithData for SecCertificateCreateWithBytes, and I could, in theory, just hard-code the constants (assuming they aren't going to change between now and our next release in the fall), are there any substitution patterns for the remaining 4 API calls (_SecCertificateIsValid, _SecCertificateNotValidAfter, _SecGenerateSelfSignedCertificate, _SecIdentityCreate) with Public APIs? Thanks again for your time, very much appreciate it!

[michaelrsweet]

@IthacaRonD I'm playing around with a potential solution now - basically use the IPP stack in libcups but use NSURLSession to actually send the IPP request and parse the response. That will avoid the problematic bits of libcups, but there might be issues with the self-signed certificates used for IPPS with most printer (we'll see...)

Tracking with Issue #5607...

[IthacaRonD]

@michaelrsweet Thanks for taking the time to look into this. For the immediate release I've run a bunch of workflows through our code with breakpoints at the problematic parts of CUPS and have discovered that we do not appear to utilize CUPS in a way that triggered the breakpoints. For now now, I've commented out the private symbols (after replacing SecCertificateCreateWithBytes with SecCeftificateCreateWithData) and all seems to be working. I'd obviously love to have a much cleaner solution! I'll use the new Issue that you opened for any further communication. Thanks again!