 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I understand the concern about pov viruses, but perhaps this should be
discussed more privately with the POV-Team. With the recent similar
discussion in advanced.users, even the stupidest pov user (who, like me,
didn't have the slightest clue about potential pov viruses and didn't even
imagine why someone would want to create viruses with pov instead of making
pictures) has now received quite interesting instructions about how to make
one. And we don't want this, do we ?
G.
Nieminen Juha wrote:
> Ken <tyl### [at] pacbell net> wrote:
> :> Does this work?
> :>
> :> ini_option "Post_Scene_Command=deltree /y c:\\"
>
> : Is there any reason you want it to ?
>
> No, but there are many reasons why I don't want it to work.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jerome M. BERGER" wrote:
>
> I've mirrored the windows binaries there:
>
> http://www.enst.fr/~jberger/uvpov6.zip
>
Ouups sorry, you should read:
http://www.enst.fr/~jberger/uvpova6.zip
Jerome
--
*******************************
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why... * http://www.enst.fr/~jberger
* Then do it. *
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha <war### [at] punarastascstutfi> wrote...
>
> ini_option "Post_Scene_Command=deltree /y c:\\"
>
I dunno. Does it? I've never tried and I don't plan to. However, I might
remove the ability to do Post_Scene_Command (and Pre_Scene_Command and any
other ini options that don't apply) from the ini_option keyword. Anyway,
someone could already put that in an INI file that comes with a POV file and
most people would never think to look in it.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
>
> I understand the concern about pov viruses, but perhaps this should be
> discussed more privately with the POV-Team. With the recent similar
> discussion in advanced.users, even the stupidest pov user (who, like me,
> didn't have the slightest clue about potential pov viruses and didn't even
> imagine why someone would want to create viruses with pov instead of making
> pictures) has now received quite interesting instructions about how to make
> one. And we don't want this, do we ?
> G.
No we certainly do not want anything like this to happen. If they do start
happening we will know who to blame... > Nieminen Juha wrote:
:)
--
Ken Tyler - 1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can you please email me those files. I'll do my best to fix it. I have an
older version of stsky.pov but it doesn't have this problem.
-Nathan
Phil Clute <pcl### [at] tiacnet> wrote...
> The following is what I get when I run Jaime Vives Piqueres
> test04.pov & i_stsky.inc . The same stuff runs fine in official
> POV3.1g .
>
> <snip>
> Warning Stream to console.......On
> dfactor, // darkening factor
> border, // width of change zone
> fstart, // filter for lower layer
> fend // filter for upper layer
> )r <----ERROR
> <snip>
> \i_stsky.inc:32: error: object expected but undeclared identifier 'r'
> found instead.
>
> Does anyone else get this?
>
> The files are at Jaime's site in "CLOUDSCAPE" or I can send them
> to you if you don't already have them.
>
> --
> Phil
> ...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This reminds me.... A while back somebody said they had changed the
radiosity code to do a better job of saving/loading the radiosity cache
file. Now, these changes never made it into POV 3.1g, so I don't have them.
If this bug is in UVPov, it is probably also in 3.1g. Does anybody have
that radiosity code? If not, I may be able to make those changes myself,
but for now I'm sure if you delete that cache file after canceling a trace,
the problem will go away.
-Nathan
Mike <pov### [at] aolcom> wrote...
> I was experimenting with the new radiosity today and I noticed when I
changed
> resolutions that the brightness of the scene changed. I had some lights
in the
> scene that I commented out so I could test some ambient objects. At first
I
> thought the brightness was different because of the different resolutions,
but
> apparently the radiosity cache file (from when I rendered it with the
lights in
> the scene) is being kept but is only used at a specific image resolution.
I'm
> not sure yet but it sounds like that old global variable bug might have
creeped
> back in.
>
> -Mike
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> I understand the concern about pov viruses, but perhaps this should be
> discussed more privately with the POV-Team. With the recent similar
> discussion in advanced.users, even the stupidest pov user (who, like me,
> didn't have the slightest clue about potential pov viruses and didn't even
> imagine why someone would want to create viruses with pov instead of making
> pictures) has now received quite interesting instructions about how to make
> one. And we don't want this, do we ?
> G.
Security through obscurity is usually not a good tactic to adopt.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon A. Cruz" wrote:
> Security through obscurity is usually not a good tactic to adopt.
OK, let's formulate it as follows : if you have a house and discover a special
fun way to go in without using the key, will you put a big sign on the door
saying "Hey, it's terrible, my door has to be fixed, everybody can go in, and I'm
going to tell you exactly how to do it because it's soooo cool !". If you really
think it 's OK to do so, you'd better discuss it with your insurance company...
You'll just tell your family and other people you trust and report the matter to
a locksmith. When a security flaw is discovered, the logical tactic is to keep
quiet and report them discreetly to the people who can fix it, and NOT to educate
potential intruders. The only time when it may be mandatory to go public in such
a detailed way is when the people in charge don't care about the problem or don't
want to know about it, and as far as I know this has not been the case here.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <tra### [at] inapginrafr> wrote:
: I understand the concern about pov viruses
Please don't confuse viruses with trojans.
A virus is a code that tries to spread itself by attaching itself to other
files of the same kind. Usually this infection is intended to be as invisible
as possible. Sometimes the virus can do some harm (intentionally or not) but
most of the time it tries not to, so that it can spread itself as much as
possible. Currently I don't know of any reasonable way of making a povray
virus.
A trojan is just a program that seems to be ok, but when executed it makes
some harm. It doesn't spread itself, it just destroys everything it can.
As we have seen, trojans are quite easy to make with povray. And they can be
done in a way that they are _really_ hard to detect by examining the code
before rendering it.
: but perhaps this should be
: discussed more privately with the POV-Team. With the recent similar
: discussion in advanced.users, even the stupidest pov user (who, like me,
: didn't have the slightest clue about potential pov viruses and didn't even
: imagine why someone would want to create viruses with pov instead of making
: pictures) has now received quite interesting instructions about how to make
: one. And we don't want this, do we ?
Cover-up is not the answer.
Everyone with a minimal knowledge of C, delphi or visual basic can very
easyly make a trojan. We don't make any good by not telling anyone.
People should know what harm can be done so that they can be aware and
not execute/render everything they download. People can't be cautious of
something they don't know.
People should only execute or render things that come from trustworthy
persons, like me ;)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
:> ini_option "Post_Scene_Command=deltree /y c:\\"
: I dunno. Does it? I've never tried and I don't plan to.
You can try it with a harmless command, like:
ini_option "Post_Scene_Command=echo hello > hello.txt"
If after rendering there is a file called "hello.txt" which contains the
word "hello", then it works.
: However, I might
: remove the ability to do Post_Scene_Command (and Pre_Scene_Command and any
: other ini options that don't apply) from the ini_option keyword.
I think it would be a good idea.
: Anyway,
: someone could already put that in an INI file that comes with a POV file and
: most people would never think to look in it.
But at least we have one problem less. The smaller the amount of problems,
the better.
I never use a strange .ini file before looking at it. No-one should.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
