“Just searching the code where the address book API is used” most certainly does not give you increased confidence.
That’s the starting point. It only takes 5 minutes to get there and find the object of interest. If you don’t spend 10-30 minutes more to see how the object is used, you’re doing it wrong. And if you try to read every single line of code in the project, you’re also doing it wrong.
Obfuscation is not that difficult.
Obfuscation is even easier to spot than to create, which on that basis alone would be good grounds to reject a package.
You can only possibly gain confidence if you fully understand every single line of code.
As I said, you need not read every single line of code. Just the code touching the address book.
I ignored it because it’s idiotic. Google isn’t and shouldn’t be building code for you unless you pay for it.
It’s looking more clear that English is not your first language. You continually fail to comprehend what I’ve said, which was the complete opposite of this comment, after you suggested yourself that a code review effort is that of a new hire onboarding effort.
One more time: a company having people review specific code for a specific purpose does not in any way resemble an adversarial code review against bad actors.
Again, that is not the purpose of the code review. If the purpose is to generally find malicious code, that’s a very different criteria than /not exporting an address book/. And if you move the goal posts to that mission, you have no fucking chance to do that with the simple black box analysis you’re advocating.
There are no parallels. A code review gives you literally zero confidence that the writer isn’t malicious
A code review is the absolute cheapest most effective way to find malicious code, if that’s your new goal. You will not find malicious code with any confidence by looking at a TLS traffic tunnel and playing with the app as a user. You can see that the app connects to the Snikket server and you can see that blobs are passed back and forth, which is expected anyway. From there, you have to guess from the timing and payload sizes that something is off, at which point you still really know fuck all. It’s a lot of effort to reach insufficient confidence to condemn the app.
unless you comprehensively understand every single line.
Clearly you’ve never written software. Malicious code does not affect every single line nor does finding malice need an understanding of every single line. Bugs would never be found on any large project if that were true. Every code review I’ve performed has been narrow in scope and yet I still find non-conformant code. A developer can work on a project for ~10-20 years of their life and still only see a small fraction of the code. Yet they still discover bugs in very little time. If you think you need to look at every single line, I suggest avoiding the software career path.
Open source project security is entirely and exclusively reputational.
Reputation matters whether a project is FOSS or not. But if it’s closed-source, reputation is all you have. Of course it’s nonsense to claim FOSS code cannot be reviewed by anyone who cares to step beyond reputation.
That’s the starting point. It only takes 5 minutes to get there and find the object of interest. If you don’t spend 10-30 minutes more to see how the object is used, you’re doing it wrong. And if you try to read every single line of code in the project, you’re also doing it wrong.
Obfuscation is even easier to spot than to create, which on that basis alone would be good grounds to reject a package.
As I said, you need not read every single line of code. Just the code touching the address book.
It’s looking more clear that English is not your first language. You continually fail to comprehend what I’ve said, which was the complete opposite of this comment, after you suggested yourself that a code review effort is that of a new hire onboarding effort.
Again, that is not the purpose of the code review. If the purpose is to generally find malicious code, that’s a very different criteria than /not exporting an address book/. And if you move the goal posts to that mission, you have no fucking chance to do that with the simple black box analysis you’re advocating.
A code review is the absolute cheapest most effective way to find malicious code, if that’s your new goal. You will not find malicious code with any confidence by looking at a TLS traffic tunnel and playing with the app as a user. You can see that the app connects to the Snikket server and you can see that blobs are passed back and forth, which is expected anyway. From there, you have to guess from the timing and payload sizes that something is off, at which point you still really know fuck all. It’s a lot of effort to reach insufficient confidence to condemn the app.
Clearly you’ve never written software. Malicious code does not affect every single line nor does finding malice need an understanding of every single line. Bugs would never be found on any large project if that were true. Every code review I’ve performed has been narrow in scope and yet I still find non-conformant code. A developer can work on a project for ~10-20 years of their life and still only see a small fraction of the code. Yet they still discover bugs in very little time. If you think you need to look at every single line, I suggest avoiding the software career path.
Reputation matters whether a project is FOSS or not. But if it’s closed-source, reputation is all you have. Of course it’s nonsense to claim FOSS code cannot be reviewed by anyone who cares to step beyond reputation.