“Just searching the code where the address book API is used” most certainly does not give you increased confidence. Obfuscation is not that difficult. You can only possibly gain confidence if you fully understand every single line of code.
I ignored it because it’s idiotic. Google isn’t and shouldn’t be building code for you unless you pay for it.
Not doing literally every single test every other app is required to is an exemption.
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. There are no parallels. A code review gives you literally zero confidence that the writer isn’t malicious unless you comprehensively understand every single line. Open source project security is entirely and exclusively reputational.
“Just searching the code where the address book API is used” most certainly does not give you increased confidence.
That’s the starting point. If you don’t spend a few minutes more to find the object and see how it is used, you’re 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 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.
unless you comprehensively understand every single line.
Clearly you’ve never written software. Malicious code does not affect every single line nor does it need an understanding of every single line. Every code review I’ve performed has been narrow in scope and yet I still find non-conformant code. If you think you need to look at every single line, I suggest avoiding the software career.
Open source project security is entirely and exclusively reputational.
Reputation matters whether a project is FOSS or not. But if it’s not FOSS, 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.
“Just searching the code where the address book API is used” most certainly does not give you increased confidence. Obfuscation is not that difficult. You can only possibly gain confidence if you fully understand every single line of code.
I ignored it because it’s idiotic. Google isn’t and shouldn’t be building code for you unless you pay for it.
Not doing literally every single test every other app is required to is an exemption.
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. There are no parallels. A code review gives you literally zero confidence that the writer isn’t malicious unless you comprehensively understand every single line. Open source project security is entirely and exclusively reputational.
That’s the starting point. If you don’t spend a few minutes more to find the object and see how it is used, you’re 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 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.
Clearly you’ve never written software. Malicious code does not affect every single line nor does it need an understanding of every single line. Every code review I’ve performed has been narrow in scope and yet I still find non-conformant code. If you think you need to look at every single line, I suggest avoiding the software career.
Reputation matters whether a project is FOSS or not. But if it’s not FOSS, 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.