Attached Link: Re: Content Paradise :-)

Since the original thread (ref the link) seems to have been overtaken by discussions about OSes, I figure that the real security issues may be addressed quicker in a new thread. To make it easier to follow, I will copy some of the relevant posts here. ===== The PDF from the link on the [EGISYS] page (http://www.egisys.de/contentparadise/?lang=EN&res=high&path=) describes Content Paradise in a little more detail. It would seem that the Poser interface to CP is based upon Python. Being a "newbie" to Python, I do not have the slightest inkling how this will effect security concerns, but at least it is somewhere to start. It seems they missed the mark for the August opening, as CP is still listed as "coming soon" according to www.contentparadise.com. It would be interesting to see how this differs from the other 3D brokerages and related sites. === In my quest to answer my own questions, I found the following quote at the link provided [http://www.byte.com/art/9702/sec5/art4.htm]: "In terms of security and today's concern with distributed Internet applications, Java definitely excels. Because Python is more of a scripting language, it can have lots of freedom with the local file system, which creates security risks. Furthermore, Python allows many ways to dynamically invoke commands read from any file type, even a TCP socket. Python does have a restricted mode that 'fakes' many of the standard functions and modules but actually uses only those deemed 'safe.' If an attempt is made by the code to access restricted material, an error is raised and the user is alerted." It would seem to me that the choice of using Python was natural (given that PoserPython seems to be an integral part of the software); however, it seems that the security risks that the above quote implies would prove troublesome with any security-minded individual. Given the date of the article, I would presume that these potential security issues have been addressed a long time ago; however, I have not been able to locate that information on my own as of yet. === The link [http://sourceforge.net/tracker/index.php?func=detail&aid=576711&group_id=5470&atid=105470] is a bug notice that involves the Python 2.2.1 Windows binary (executable). For those who do not know, SSL is the Secure Sockets Layer used by secure websites for such things as encrypting transactions. === I would like to see CLs' response to the two security-related links I posted above; especially the SSL bug. If Python does not currently have native SSL support in it (which is a requirement in order to securely process financial transactions on the Internet), and CL's Content Paradise room is based upon Python, it only stands to reason that CP is insecure in that it does not have support for SSL connections made through P5. Any direct connection using other broswers that support SSL, ie MSIE and Netscape, should not be effected since it does not rely upon the Python scripting to connect. What this will mean to those using CP through P5 is that any information exchanged using the CP will not be encrypted and, therefore, could be easily intercepted and compromised by anyone hacking on the connection. If, by chance, the CP connection is opened and available when P5 is run and you have your Internet connection up, there is also the possibility that someone could hack into your system based upon the information from byte.com. These are serious issues that really need to be addressed.

Anyone from CL care to comment?

My guess is that Python is just doing some background housekeeping. It probably calls on the browser to do the secure stuff? I mean, why reinvent the wheel.

I can't see any reason why CL (or EGISYS, who I believe may have had more involvement in the Content room development) decided to implement this in functionality in Python, even if upgradability was an issue, there are plenty of alternatives. And, of course, the risk of Trojan Horses may put people off using Python scripts, which would be a shame, especially for those of us who are interested in developing substantial plug-ins using this interface. Bill

Attached Link: Content Paradise Site

Seems like it does not matter much right now anyway, since **P5** is shipping and **CP** is still not operational.

"A Picture is worth a thousand words..."

*Graphic Copyright 2002 Curious Labs Incorporated, and EGISYS AG. All rights reserved.

Seems I am not alone in needing an editor.. :o) Jack

Python is one hell of a flexible language... though I haven;t seen an ything near what Python does in P4, let alone P5 (I think only a few limited functions are used in P4), I can see how they would use Python to jump in and about the Content Paradise stuff, though I sincerely doubt it'll be too much of a problem, for two reasons: 1) Python and its libraries are Open Source, so a patch may already be out, if not on the way out... wouldn't take much for CL to include it, if indeed they use any Python at all in their shopping section... which brings me to: 2) Why would they bother using Python to do the shopping in Windows when it's easier to call and use all of the .dll/.ocx/API/hooks/whaddever that IE uses right now? That way, security patches and maintenance thereof become Microsoft's problem, not CL's. Heh - sorry about the OS thingy... I get a bit protective at times :) /P

Attached Link: Content Paradise :-)

Well seeing as how CL is not addressing the issue or clarifying it, in security - as in life - it is always best to err on the side of caution. After all the EGISYS AG PDF, just like most documentation about CP, is vague at best. The link for SourceForge, TTBOMK, is the official "Bug List" for many Open Source projects and states that the bug is still open; hence unfixed at this point. Perhaps the silence ie because CL *does* realize that there is an issue and, rightly so, they are not announcing that a serious flaw that could be exploited exists. However, no response whatsoever to valid concerns gives the impression of avoidance. Days of silence in an electronic world, especially when other posts are being addressed, is akin to being ignored. I am beginning to think that if you ask too many hard questions, you get sent directly to "File 13". There were other questions asked in the linked thread at the beginning that an answer was promised for ("If I find an answer, I will post it to a separate thread."), yet no such thread has been created. Since it is now 3 days later, I guess no response should be expected. However, some of those answers would clarify this issue as well.

Attached Link: http://sourceforge.net/tracker/?group_id=5470&atid=105470

SF hosts the Python bug list alright (I bored into it from http://www.python.org, but the buglist is still hosted on Sourceforge.) Which bug is it in particular (or rather, where is this critter - I can't seem to locate it)? Also, why would they use what is in Windows more of a scripting language than a programming one to buy stuff securely? Seems strange to me. I could understand if they were using it in, say Solaris, Linux, AIX, whatever, where Python is more powerful and useful. Just that it seems like someone is trying to re-invent the wheel if they're using Python in Windows to buy stuff securely. /P

Hi, I'd say the larger problem is the OpenSSL bug, (patched in 0.9.6e) and it's attendent version of Mod-SSL for apache. that's why I've been updating web servers at work. If you're using an old version of the opensourse SSL, then you're already insecure. "All hail slashdot/Bugtraq" :) later jb

Attached Link: Windows binary missing SSL

/P

The link above is the direct link to the bug report. This is the same URL that was placed in the opening post, but not made into a link.

"Also, why would they use what is in Windows more of a scripting language than a programming one to buy stuff securely?"

That is one of the details I am trying to find out, if I ever get a response. The EGISYS PDF clearly states "Native user interface on Python basis in Poser.", which to me would mean that the interface in P5 to Content Paradise is, in fact, Python-based.

If the currently shipping P5 product is Windows-based [verified], and the P5 CP interface is Pyhton-based [apparently verified by EGISYS' PDF], and the Windows Pyhton binary (executable) does not include SSL support [verified through Source Forge], then one could make the logical connection that: Any SSL connection attempted by P5's CP room that uses the affected Windows Python binary would be insecure.

Here again, I invite CL to comment and allay the concerns. However, given the severe nature of this bug and its implications, and not a word from a CL or EGISYS representative other than "Content Paradise is secure" (especially when the technical details were apparently unknown to the individual making the statement), one has to presume the worst-case scenario from a security perspective.

Now that actual users have P5 in their hands, perhaps someone would be so kind as to respond to this post?; since CL has apparently chosen not to weigh in a response. I understand that CP is still unavailable, but for those savvy enough to determine if P5's CP uses Python to connect and/or if the page connected to appears to be SSL-enabled, I would be interested in the community's thoughts, ideas, impressions, etc.