prelink should not mess with running executables

[Sam Varshavchik]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120718/7a5324fb/attachment.sig>