Andrew Haley writes:
On 07/18/2012 12:06 PM, Sam Varshavchik wrote: >> >> But that's not a use case. There's no way to know why you want to do >> this: why you care that another process is running the exact same >> executable. >> Because that's the only process I want to talk to. A form of authentication,> which I already explained. More than once. You have _claimed_ that it's a form of authentication, but you've produced no reason to believe that it is. How do you know that the exact same binary isn't running as some rogue user, with other data injected into it?
How do you know that the server that gave you a seemingly verified SSL certificate, that checks out, isn't an impostor that managed to crack the right prime. It's mathematically possible, you know. Any authentication mechanism, short of a mind ray-beam implementation over the Internet, can be defeated. It's only a matter of how much resources are required. Even if some particular approach is not 100% NSA-grade bulletproof, it does not mean that it's worthless. I reject that claim.
And this is just another feeble attempt to change the topic. The degree to which this kind of authentication is or isn't reliable, is completely irrelevant and has no bearing on the problem that prelink is creating, by rewriting executables which are currently running. That, I believe, can be evaluated on its own merits.
If what prelink is doing is hunky-dory, then why is it that its wrapper has special-case band-aid init? That's a defacto acknowledgement that prelink is broken, and this is just a lame, pathetic coverup for one of the breaks.
> And we've been over this. Yes we have. You've made claims, none of which you've justified. Or you
The only claim I made is that prelink's design is broken, and there's plenty of justification for that.
may have done but I missed them. But as it stands this is an utterly hopeless way to authenticate anything.
I have not asked, and have no intention of asking anyone to evaluate the merits of this kind of authentication. Nor do I care.
Attachment:
pgpykEj5pgUiH.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
