torcs-devel Mailing List for TORCS - The Open Racing Car Simulator

You post was really helpful. I would have given up building torcs without this 
post i guess. Thanks

Hi

> Le lundi 12 mars 2012 18:07:58, vous avez écrit :
>> - Some distributors would like to link to the expat/XXXlibraries they
>> have anyway in their distro, but for the Windows users it is more
>> comfortable to have the source included in the tree, so I leave it there
>> for now. Distributors can patch their builds easily if they like. They
>> prefer this, because they think they can then replace a broken lib once
>> in the distro and this makes maintenance easier, but they do not account
>> the risk (basically you change then all depending application without
>> any QA or serious test, great...).
>
> It is not replacing a broken lib, just patching it is enough for security.
>
>> Regarding security problems the situation with a "built in" lib is not
>> that bad as well, because as long you do not use an affected part of the
>> library, it just does not matter.
>
> Sorry, I disagree : I understand you don't this is important for a game. But
> for a networked application like TORCS, it matters.

TORCS is not yet a networked application:-(

No reason to sorry, multiple viewpoints are useful. I know I compacted 
the argument very much, but I am not in the mood to write a book about 
it. Short:
- I agree, a security fix TRIES just to fix the issue,
- BUT semantically this is impossible, because the calls are in the 
usual languages/API's not formally defined, so the implementation is the 
definition, and if the definition allows a vulnerability it is 
semantically not different from any "normal" functionality.

So this is my purist logic:
-> Security fixes change the semantics of certain calls/inputs, so you 
cannot make guarantees regarding clients.

Of course this works usually "good enough" to be useful for 
toyboxes/desktops, but there have also been prominent screw-ups (where 
fixes really made things worse, clients stopped working, etc., see 
Microsoft Windows, Linux kernel, OpenSSL, ...).

That is the reason why enterprise software packages are usually "self 
contained" to the deepest possible level (own copy of JVM, runtime 
libraries, etc.), the consultants set up your server to match the 
certification, etc., the vendors just guarantee for their products if 
the environment matches. Security patches get there just applied if the 
vendor officially certifies them, this is also a reason why enterprises 
are always a bit behind with their patches/service packs/etc.

> Anyway, let's see if the problem arises also in Debian?

No idea, I do not know which distros contain TORCS. If somebody submits 
a super tiny TORCS patch where one can switch during configure to an 
external expat/whatever I would apply it.

Best regards

Bernhard

Hi

Legal view (I am not a lawyer, just my view):
I think it does not matter. The files contain the license header, so if 
someone edits some of these files he/she can see the license. The usage 
in TORCS is (legally) no problem, because:
- It is not problem to use/link to MPL code (because it was OUR decision 
to agree with it)
- The only drawback is if you edit the MPL 1.0 licensed files, these 
changes can be used in closed source software (because it is MPL 1.0 and 
not GPL), but I guess in a legal lawsuit an unsubstantial change in a 
work would not cause a license violation anyway (e.g. look at citations 
from books, taking a photocopy of 2 pages out of a book etc., if the 
discussed subject if not "big enough" it counts not as "work" and is not 
protected by copyright, people are often not aware of this).
Examples:
- *x header files do not violate Unix copyright, because they are 
interfaces and not substantial part of the "work", even if they look 
almost the same (how could they look very different, if they have to 
define the same symbols), additionally the legislator introduced 
copyright to support innovation, so interfaces have here a hard time anyway
- Code snippets from the internet or books, it is very common to use 
such stuff in everydays work everywhere in software engineering, this is 
as well no problem, as long as these snippets do not represent 
substantial "work" (e.g. a clever compact algorithm spanning more than a 
few lines would be already covered by copyright, where as 
"printf("Hello\n"); exit(0); would have a hard time I think).

Technical view:
- Some distributors would like to link to the expat/XXXlibraries they 
have anyway in their distro, but for the Windows users it is more 
comfortable to have the source included in the tree, so I leave it there 
for now. Distributors can patch their builds easily if they like. They 
prefer this, because they think they can then replace a broken lib once 
in the distro and this makes maintenance easier, but they do not account 
the risk (basically you change then all depending application without 
any QA or serious test, great...).
Regarding security problems the situation with a "built in" lib is not 
that bad as well, because as long you do not use an affected part of the 
library, it just does not matter.

Conclusion:
- For purists it might be not really clean, but it works, changes are 
currently not required regarding this.

Hope this helps

Bernhard


On 03/12/2012 10:24 AM, zezinho wrote:
> I was made aware of a license problem in TORCS :
>
> https://bugs.mageia.org/show_bug.cgi?id=4646
>
> The problem is better spoken here :
>
> https://bugs.mageia.org/show_bug.cgi?id=4646#c10
>
> The fork Speed-Dreams is on the way to use expat lib instead of txml.
>
> What do you think?
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel
>

I was made aware of a license problem in TORCS :

https://bugs.mageia.org/show_bug.cgi?id=4646

The problem is better spoken here :

https://bugs.mageia.org/show_bug.cgi?id=4646#c10

The fork Speed-Dreams is on the way to use expat lib instead of txml.

What do you think?

Hi, compiling torcs on a x86_64 Mac Lion is successfully done now. I opened a little Project on Sourceforge, this helps compilling Torcs, its very simple. 
To get it write down 

git clone git://git.code.sf.net/p/torcsonmac/code torcsonmac

The scripts are commented and they can tell you the whole story of my work.

Anyway I'm running into problems with torcs now. I execute the program and i start a race then i get this error message:

./run.sh 
Visual Properties Report
------------------------
Compatibility mode, properties unknown.
WARNING: grscene:initBackground Failed to open shadow2.rgb for reading
WARNING:         no shadow mapping on cars for this track 
./torcs: line 53:  2390 Segmentation fault: 11  $LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $*


any ideas what this can mean?

greetz Tobias

Hello, 
it seems that it is possible to compile torcs for lion. Well it doenst work with sound and i have to make some changes inside the code. For example i need my own isnan function.

there is a problem with the makefiles, if i run configure and make the first problem is that libconfscreen.so can't compile (at link stage) because there are some symbols missing. For example GfuiScreenCreateEx, this symbol comes from libtgfclient.so. But it immediately tries to compile libconfscreen and not libtgfclient before.

I was trieing to compile all the stuff step by step (tgf, tgfclient,… ) and to put the right libraries inside the Makefiles but i made a mistake and my work is gone now…

any simple ideas for solving this? why does this work on my linux so well, but not on lion?

Greetz Tobias