-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chrome reported w/o AppKit, even though it's being used #15
Comments
Ah, direct dlopen, I see. Well, we should also scan all embedded frameworks, similar to how we scan apps now. |
In the general case, we might want to be smart in terms of embedded frameworks. Many embedded frameworks are auxiliary to the function of the app (metrics, crash reporting, updating) and therefore shouldn’t override the classification of the main binary. OTOH, for something like Chrome, where the main binary gives no clues, and there’s only one embedded framework, then definitely it should be classified as being the main app. |
I disagree on that, if the app embeds the tech whatever, it embeds the tech. |
Thats a tricky one: there are apps, which are AppKit native with all the UI stuff, but they have e.g. a Python interpreter embedded. Reporting that as a Python app is wrong. The reverse is true as well: only because an App links against AppKit doesn't make it an AppKit native app. |
I do agree with that. Ideally we'd have something like the GitHub language detector (25% Swift, 49% JavaScript, etc). But they have your full source, it's a little hard to quantify just based on the binary, but actually not impossible :-) Though in practice, if someone links Python, it is going to use Python. Same for Electron. I do believe that embedding such as a 3rd party module should affect the primary outcome, even if used sparingly. |
OK, I think to deal with it we should scan all embedded frameworks (Frameworks/*.framework).
The main binary just links System/CF: |
What seems to break in this case is that 5 GUIs tries and fails to detect AppKit (“No 👨🏽🦳 AppKit usage to be found? 🤔”). That’s probably because of the structure of Chromium. In order to update cleanly, Chromium (and Google Chrome) is separated into an outer bundle and an inner framework, and the only job of the outer bundle is to call into the inner framework. If all that is being analyzed is the outermost binary, you’re not going to find usage of any system framework. All of Chromium’s AppKit usage (it’s an old-school ~2008 AppKit app) is through the inner framework that isn’t ever explicitly linked to any of the .apps.
I’m not sure of an easy, not special-cased way to detect this. The
main
function usesdlopen
to open a hard-coded path to the inner framework, so there are no obvious traces in metadata.The text was updated successfully, but these errors were encountered: