Re: Version checking (was Re: 25 tbreg relays in directory)

[Tripple Moon <tripple.moon@xxxxxxxxx>]

--- On Wed, 4/29/09, Dominik Schaefer <schaedpq2@xxxxxx> wrote:

> From: Dominik Schaefer <schaedpq2@xxxxxx>
> Subject: Re: Version checking (was Re: 25 tbreg relays in directory)
> To: or-talk@xxxxxxxxxxxxx
> Date: Wednesday, April 29, 2009, 7:18 AM
> On 29.04.09 12:33, Tripple Moon wrote:
> >> Also what would be gained from a CRC based on the
> *binary*?
> >> Wouldn't that change according to the system
> that compiled it?
> > Yes it *will* chance depending on the compiled
> (source-)version and architecture and compiler used.
> > But those variables are far less in quantity as the
> possible individual modified versions....
> It will not only change with architecture, exact versions
> of compiler and OS,
> and source code revision (think of all the people using the
> svn/git repo), but
> also with compiler options controlling optimization/code
> generation, ABI,
> statically vs. dynamically linked libs and probably a bunch
> of other. As you
> combine all these you create a huge amount of possible
> permutations.
> But it is anyway useless, because any client can upload any
> data it wants to
> and claim it is its own binary.
> BTW: Do you know, that there are independent
> implementations of Tor based on
> the official design documents? And that this is actually
> encouraged by the
> authors of Tor?
> BTW2: Your approach of locking out other implementations
> contradicts any idea
> of open source and inter-operability.
Yes I agree that those other factors, which were not mentioned yet, are ofcourse also elements to take into account for differences.
And like i previously already admitted this is a difficult topic to make foolproof.
(much like making any software foolproof infact)
But...i disagree with your argument that my approach would contradict the idea of Open-Source as that has noting todo with program's operational logic but more with the public availability of the source codes.
Same with interoperability which is also based on operational logic embedded in software...

About those independent implementations:
Ofcourse its a great way to improve any software that is Open-Source to allow independent modifications to the source code.
But if those changes remain unknown to the development-team of the original software project, then *thats* where problems arise...
Not only from a security P.O.V. but perhaps also concerning licensing violations...
IMHO, all and i mean *all* modifications of the original code and/or design should be committed to the development-tree, that's how things get improved and fixed etc by the community that maintains the development of the project.
We all know how M$ started, right old-guys around? ^^
(Yes billy G. there are still ppl walking around the planet who wont forget how you started that buggy OS)

A---NNN---YYY--wayyy....
I think we all agree that there is a growing need to "somehow" keep the tor network operating at maximum compatibility and stability.
If the tor application wont get means to authenticate itself's internals, then im afraid (IMHO) we will be looking at a future with *many* independent tor networks who are not connected to each others cloud because of differences...