Live data from Hacker News

Python grapples with Apple App Store rejections

lwn.net

31–40 of 118 posts

Re: Python grapples with Apple App Store rejections

#31
post #16

Earlier quoted context omitted.

They are opaquely rejecting apps for just literally containing the string "itms-services" in the binary and you still give them credit for a more sophisticated analysis? Lol.

We can assume that a simple string search is one of the basic checks they do before moving onto more advanced checks.

[dead]

Re: Python grapples with Apple App Store rejections

#32

Earlier quoted context omitted.

It's not just Python apps. It's anything by small-time developers without expensive certificates. I once used MSVC to compile a C program that was little more than a "Hello, World", and Defender called it the Win32/Wacatac Trojan.

> It's not just Python apps. It's anything by small-time developers without expensive certificates. This is definitely the case and has been my experience, as well. We live in some dark times when it comes to building and sharing anything as small developers, especially if the things you're building are free. I stopped updating my open-source Mac apps because I can't justify the cost of jumping over artificial hurdle…

I think Homebrew is the best solution for shipping open source Mac apps if you don't want to pay the developer fee or jump through any hurdles, assuming your users are technical enough to use it.

The alternative is not signing your binaries and explaining to users that they can run them by right clicking and selecting "Open" from the menu.

Re: Python grapples with Apple App Store rejections

#33

Earlier quoted context omitted.

The review process is about Apple giving you a clear direction about what is acceptable. There are many ways to get around their restrictions. But doing so will get you banned.

They refused to tell him why it was rejected, hardly "clear direction"

> The app installed or launched executable code. Specifically, the app uses the itms-services URL scheme to install an app.

Seems like pretty clear direction to me:

https://github.com/python/cpython/issues/120522

Re: Python grapples with Apple App Store rejections

#34
post #16
post #9

Obfuscation seems like a great way to get your developer account suspended. I suspect Apple is doing a lot more than just basic static analysis of the binary on disk. Glad they went with a config option instead.

They are opaquely rejecting apps for just literally containing the string "itms-services" in the binary and you still give them credit for a more sophisticated analysis? Lol.

You’re assuming that’s all they are doing, and that it’s all they will ever do, but neither assumption is supported by any evidence.

Apple is saying what test broke, not that other tests aren’t running.

Re: Python grapples with Apple App Store rejections

#35

Earlier quoted context omitted.

That came up in the original post with whether an obfuscation could be an acceptable workaround; but it came up that Apple really doesn’t like obfuscation techniques. The workaround for now is a compiler flag that excludes problematic code from iOS builds. I’m still asking though why, if Apple doesn’t like apps which use this protocol, the sandbox is not intervening; as surely an approved app could have a malicious w…

Sandboxed apps are allowed to use itms-services:// links, it's just not allowed in the App Store - iOS enterprise apps using in-house deployments can use it for installs and updates, and sandboxed Mac apps deployed outside of the App Store can use it as well. However, App Review Guidelines forbid App Store apps from installing other apps, so that scheme gets scanned during review.

This can be handled by granting privileges to open that scheme to enterprise Apps and not granting to regular App Store apps. Relying on string scanning is simply not secure.

Re: Python grapples with Apple App Store rejections

#36

Earlier quoted context omitted.

They refused to tell him why it was rejected, hardly "clear direction"

> The app installed or launched executable code. Specifically, the app uses the itms-services URL scheme to install an app. Seems like pretty clear direction to me: https://github.com/python/cpython/issues/120522

The app in question doesn't actually do any such thing, though.

Re: Python grapples with Apple App Store rejections

#37

It's not just Apple that pulls shenanigans like this. Try building a Python app with PyInstaller while you have Windows Defender live scanning on, which is the default setting. You won't even be able to compile a binary without Defender preventing you from doing so. Similarly, try running the binary produced by PyInstaller with Windows Defender on. Defender will say it's malicious and won't run it. It's a bit dystopi…

Windows isn't a platform for developers. It's a platform for normie consoomers. Isn't that obvious?

If you want an engineering OS, use GNU/Linux.

Re: Python grapples with Apple App Store rejections

#38
post #32

Earlier quoted context omitted.

> It's not just Python apps. It's anything by small-time developers without expensive certificates. This is definitely the case and has been my experience, as well. We live in some dark times when it comes to building and sharing anything as small developers, especially if the things you're building are free. I stopped updating my open-source Mac apps because I can't justify the cost of jumping over artificial hurdle…

I think Homebrew is the best solution for shipping open source Mac apps if you don't want to pay the developer fee or jump through any hurdles, assuming your users are technical enough to use it. The alternative is not signing your binaries and explaining to users that they can run them by right clicking and selecting "Open" from the menu.

Unfortunately, getting users to install Homebrew is a hurdle that's hard to pass for what I'm dealing with. It's a non-starter if users have to open a terminal to install anything, even though Homebrew has a .pkg installer now. The users typically don't know what a terminal even is.

> The alternative is not signing your binaries and explaining to users that they can run them by right clicking and selecting "Open" from the menu.

That's what I'm doing now, and it's still an issue, unfortunately. Non-power users are not going to remember the right-click -> Open ritual when they just double-click on everything else.

And the warnings Gatekeeper shows also caused users to think their apps, and even computers, were broken or hacked.

Re: Python grapples with Apple App Store rejections

#39

Earlier quoted context omitted.

Sandboxed apps are allowed to use itms-services:// links, it's just not allowed in the App Store - iOS enterprise apps using in-house deployments can use it for installs and updates, and sandboxed Mac apps deployed outside of the App Store can use it as well. However, App Review Guidelines forbid App Store apps from installing other apps, so that scheme gets scanned during review.

This can be handled by granting privileges to open that scheme to enterprise Apps and not granting to regular App Store apps. Relying on string scanning is simply not secure.

Welcome to Apple's much applauded security model.

More seriously, I'm sure they also prevent the privilege to that URI scheme. This is likely part of some ill-thought defense-in-depth approach. Same way they search for the names of private symbols in the exec, even when the linker will outright refuse to give you those. I absolutely detest this pervasiveness of useless layers of security that add almost nothing. But since almost nothing is not nothing, no one can remove any of them. Like cockroach papers, I'm going to call them "cockroach security". Practically everything is infested with those these days.

Re: Python grapples with Apple App Store rejections

#40
post #16

Earlier quoted context omitted.

They are opaquely rejecting apps for just literally containing the string "itms-services" in the binary and you still give them credit for a more sophisticated analysis? Lol.

We can assume that a simple string search is one of the basic checks they do before moving onto more advanced checks.

Every story I've seen over the years about MAS/iOS AS rejections point to their checks not being advanced at all.
Post reply on HN