> You can test the process without pushing exploits to the real kernel.
No, you can't, because that is the test! If you manage to push exploits to the real kernel, the test failed. If you get caught, the test passes. They did get caught.
You totally can... contact the kernel maintainers, tell them you want them to review a merge for security and they can give you a go/no go. If they approve your merge, then it's the same effect as purposely compromising millions without compromising millions.
Again, that's not the same, because then they will look for problems. What you want to test is that they're looking for problems all the time, on every patch, without you telling them to do so.
If they don't, then that's the vulnerability in the process.
> You can test the process without pushing exploits to the real kernel.
No, you can't, because that is the test! If you manage to push exploits to the real kernel, the test failed. If you get caught, the test passes. They did get caught.
You totally can... contact the kernel maintainers, tell them you want them to review a merge for security and they can give you a go/no go. If they approve your merge, then it's the same effect as purposely compromising millions without compromising millions.
Again, that's not the same, because then they will look for problems. What you want to test is that they're looking for problems all the time, on every patch, without you telling them to do so.
If they don't, then that's the vulnerability in the process.
2 replies →