4 ms·

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

threeseed 2y ago
> 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 https://github.com/python/cpython/issues/120522
- josephcsible 2y ago
  The app in question doesn't actually do any such thing, though.
  - threeseed 2y ago
    The wording could be better. But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call.
    - Ukv 2y ago
      My baseline would be similar to that which you get from modern compilers and automated tests. Something like: Lib/urllib/parse.py contains disallowed string "itms-services" at line 62 column 25 Reason: Apps may not install or launch executable code, such as through the itms-services URI schema. To get credit for "giving you a clear direction", I'd want them to make available and suggest a fix. In general that could be "if this is a false positive, click to request a human reviewer make an exemption" but ideally monitoring for this kind of issue in the first place (sudden increase in identical rejections) and fixing the broken check. Instead, Apple seem to omit the information on the first line that they likely already get from their internal tool, and not only don't suggest a fix but make the proper fix so unavailable that it's easier to get the language itself changed than a check in their review framework. > But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call. It's true that someone with folk knowledge about the way Apple does checks, gleaned about the process by other frustrated users, could likely infer the way in which Apple's test is broken and so eventually deduce the first line from the second line. That's not Apple giving a clear direction - that's developers managing to work around an inscrutable system.
      - dwaite 2y ago
        Such a check would be possible if: 1. Apple received a copy of your source code to do source analysis 2. Apple actually supported running python code as an option for writing iOS apps and wrote source code analysis tools for python for reporting compliance issues neither of these are true.
        Ukv 2y ago
        I'm not suggesting any language-specific features like telling you which function it's in - just the filename, position, and matched string. This is information already available to Apple, and can be useful even for compiled/object code. From the linked Github issue: > After lots of 'we can provide you with no further information' I finally submitted an appeal for the rejection which at last resulted in Apple telling me that parse.py and its .pyc were the offending files

> 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 https://github.com/python/cpython/issues/120522

josephcsible 2y ago
The app in question doesn't actually do any such thing, though.
- threeseed 2y ago
  The wording could be better. But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call.
  - Ukv 2y ago
    My baseline would be similar to that which you get from modern compilers and automated tests. Something like: Lib/urllib/parse.py contains disallowed string "itms-services" at line 62 column 25 Reason: Apps may not install or launch executable code, such as through the itms-services URI schema. To get credit for "giving you a clear direction", I'd want them to make available and suggest a fix. In general that could be "if this is a false positive, click to request a human reviewer make an exemption" but ideally monitoring for this kind of issue in the first place (sudden increase in identical rejections) and fixing the broken check. Instead, Apple seem to omit the information on the first line that they likely already get from their internal tool, and not only don't suggest a fix but make the proper fix so unavailable that it's easier to get the language itself changed than a check in their review framework. > But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call. It's true that someone with folk knowledge about the way Apple does checks, gleaned about the process by other frustrated users, could likely infer the way in which Apple's test is broken and so eventually deduce the first line from the second line. That's not Apple giving a clear direction - that's developers managing to work around an inscrutable system.
    - dwaite 2y ago
      Such a check would be possible if: 1. Apple received a copy of your source code to do source analysis 2. Apple actually supported running python code as an option for writing iOS apps and wrote source code analysis tools for python for reporting compliance issues neither of these are true.
      - Ukv 2y ago
        I'm not suggesting any language-specific features like telling you which function it's in - just the filename, position, and matched string. This is information already available to Apple, and can be useful even for compiled/object code. From the linked Github issue: > After lots of 'we can provide you with no further information' I finally submitted an appeal for the rejection which at last resulted in Apple telling me that parse.py and its .pyc were the offending files