Disappearing trick?
On 7/8/25 10:13, Jordan Brown via Discuss wrote:
On 7/7/2025 6:13 PM, gene heskett via Discuss wrote:
Another program I use heavily is now called LinuxCNC, mostly written
in the original python & gradually converted to python3 now.
Written in Python isn't a problem. (Or at least no more of a problem
than downloading any other software.)
What makes a Python+SCAD variant somewhat worrisome is that you are
tempted to download models written in Python.
That takes you from downloading one program that other people (maybe
many other people) have watched and used, to downloading dozens of
programs written by single people, that may never have been looked at by
other people.
In theory you might get an e-mail message apparently from a friend that
says "hey, look at this cool model that I made". You run it, and it
eats your data.
I don't generally do that, mainly because I can generally do better code
than I can dl.
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
I think the issue here is whether one can accept source code for a
general programming language (Pascal, C, Python) from an arbitrary or
unknown source and trust that it will be safe to run on one's computer
without inspection. I think the answer is "no".
On the other hand, one can accept source code SCAD files and trust that
they will run safely without inspection.
Attempting to rename things does not change the underlying issue. In
this case, Jordan would be talking about downloading Code (written in
Python) and trusting it. This remains problematic or dangerous when the
origin of the Python is uncertain.
Jon
On 7/8/2025 3:12 PM, Guenther Sohler via Discuss wrote:
you could very easily address This issue, by not referring the Editor
content as "Model" but rather as Snippet/Code
I propose this definition:
STL/3MF/AMF/OBJ Model
SCAD (CSG ) description (Its descriptive
language only)
PY Code/Snippet
SCAD files are NOT models, because (most) slicers can probably not
proicess them
Having this small "correction" in people's minds will not turn python
code into a monster anymore
On Tue, Jul 8, 2025 at 4:12 PM Jordan Brown via Discuss
discuss@lists.openscad.org wrote:
On 7/7/2025 6:13 PM, gene heskett via Discuss wrote:
Another program I use heavily is now called LinuxCNC, mostly
written in the original python & gradually converted to python3 now.
*Written* in Python isn't a problem. (Or at least no more of a
problem than downloading any other software.)
What makes a Python+SCAD variant somewhat worrisome is that you
are tempted to download *models* written in Python.
That takes you from downloading one program that other people
(maybe many other people) have watched and used, to downloading
dozens of programs written by single people, that may never have
been looked at by other people.
In theory you might get an e-mail message apparently from a friend
that says "hey, look at this cool model that I made". You run it,
and it eats your data.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
On Tue, Jul 08, 2025 at 03:26:34PM -0400, gene heskett via Discuss wrote:
In theory you might get an e-mail message apparently from a friend that
says "hey, look at this cool model that I made". You run it, and it
eats your data.
I don't generally do that, mainly because I can generally do better code
than I can dl.
In that case you can be tricked by saying "Please look at this model I
made. It doesn't work as I intended, can you help me improve it"?
Before you know it you've got it loaded up and the python stuff
installs a backdoor onto your system.
(I got about 10 mail messages today with "please see our order in the
accompanying document", "Re: Debit note", "request for quotation",
"prealert for XYE22070102", "Transaction proof Nif 2027944154" etc
etc. Apparently some people click on these to run the
windows-executables inside to give away access to their machine.
Those 10 are the ones that the spamfilter didn't filter out. )
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
To be clear, I really really want Python to be a viable replacement for
the OpenSCAD language. I don't want to reinvent language wheels, and
I'd prefer a more conventional programming language.
But I just can't recommend it until somebody figures out how to sandbox it.
JavaScript is another possible base, with a bit better sandboxing
picture. I don't remember why I came down on the side of preferring
Python as a base. It was probably that python is ubiquitous, while
non-browser JavaScript is somewhat uncommon.
On 7/8/2025 1:00 PM, Jordan Brown via Discuss wrote:
But I just can't recommend it until somebody figures out how to
sandbox it.
But we've discussed that to death, and the conclusion is that for some
people the risk is acceptable and for other people it isn't.
At this point all that's important to me is that people understand the
risk. Caddiy asked about rumors of Python safety problems, so I replied.
I think we can let that subtopic die now.
I think we can let that subtopic die now.
Die subtopic DIE ;-)
On Tue, Jul 8, 2025 at 4:03 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 7/8/2025 1:00 PM, Jordan Brown via Discuss wrote:
But I just can't recommend it until somebody figures out how to sandbox it.
But we've discussed that to death, and the conclusion is that for some
people the risk is acceptable and for other people it isn't.
At this point all that's important to me is that people understand the
risk. Caddiy asked about rumors of Python safety problems, so I replied.
I think we can let that subtopic die now.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Tuesday, July 8, 2025 at 04:00:56 PM EDT, Jordan Brown via Discuss discuss@lists.openscad.org wrote:
To be clear, I really really want Python to be a viable replacement for the OpenSCAD language.
I don't want to reinvent language wheels, and I'd prefer a more conventional programming language.
But I just can't recommend it until somebody figures out how to sandbox it.
My thought on this is that there could be a graphical environment such as Blockly:
https://developers.google.com/blockly
which was limited to only "safe" constructs, then, when a Python file which is not explicitly trusted (there will need to be a set of libraries which are vetted/approved in order to do truly interesting things) it is imported into this safe subset, with any code which does not match isolated into blocks/constructs which are not executed --- the user may then easily review the code and see what the isolated code in question does.
William
--
Sphinx of black quartz, judge my vow.
https://designinto3d.com/
William F. Adams wrote:
when a Python file which is not explicitly trusted ….. is imported into this safe subset, with any code which does not match isolated into blocks/constructs which are not executed --- the user may then easily review the code and see what the isolated code in question does.
That is a question that interests me. An antivirus/malware scanner won’t help, the user has to be capable of reviewing the code and spotting stuff that doesn’t belong there??
Meanwhile, to change the subject yet AGANE, the results of my tests with a parametric simplified gear train and $fn=5 for quicker results:
The numbers of teeth on the fastest gears are down from 60 and 30 to 50 and 25 to make things easier.
The number of frames at which they appear to stand still is 50*720/360 and 25*1440/360 =100. Double that = 200. Above 200, the gears rotate forwards, below they go backwards. If the sign before the $t in the code for the backward gears is reversed, they go forwards! And surprise, surprise: you can’t tell the difference between 180Rx30 (R=reverse, 30 is the FPS in the video program) and 220x30 - no difference in quality! Doubling the number of frames to 360 improves smoothness a bit, but is not really worth doubling the size of the file. Of course, if a gear is reversed to go forwards, it has to be decoupled from parts to which it is attached - you don’t want them going backwards. That way you can save 40 frames.
mikeonenine@web.de wrote:
William F. Adams wrote:
when a Python file which is not explicitly trusted ….. is imported into this safe subset, with any code which does not match isolated into blocks/constructs which are not executed --- the user may then easily review the code and see what the isolated code in question does.
That is a question that interests me. An antivirus/malware scanner won’t help, the user has to be capable of reviewing the code and spotting stuff that doesn’t belong there??
Meanwhile, to change the subject yet AGANE, the results of my tests with a parametric simplified gear train and $fn=5 for quicker results:
The numbers of teeth on the fastest gears are down from 60 and 30 to 50 and 25 to make things easier.
The number of frames at which they appear to stand still is 50*720/360 and 25*1440/360 =100. Double that = 200. Above 200, the gears rotate forwards, below they go backwards. If the sign before the $t in the code for the backward gears is reversed, they go forwards! And surprise, surprise: you can’t tell the difference between 180Rx30 (R=reverse, 30 is the FPS in the video program) and 220x30 - no difference in quality! Doubling the number of frames to 360 improves smoothness a bit, but is not really worth doubling the size of the file. Of course, if a gear is reversed to go forwards, it has to be decoupled from parts to which it is attached - you don’t want them going backwards. That way you can save 40 frames.
Continuation because of limit for attachments.
mikeonenine@web.de wrote:
mikeonenine@web.de wrote:
William F. Adams wrote:
when a Python file which is not explicitly trusted ….. is imported into this safe subset, with any code which does not match isolated into blocks/constructs which are not executed --- the user may then easily review the code and see what the isolated code in question does.
That is a question that interests me. An antivirus/malware scanner won’t help, the user has to be capable of reviewing the code and spotting stuff that doesn’t belong there??
Meanwhile, to change the subject yet AGANE, the results of my tests with a parametric simplified gear train and $fn=5 for quicker results:
The numbers of teeth on the fastest gears are down from 60 and 30 to 50 and 25 to make things easier.
The number of frames at which they appear to stand still is 50*720/360 and 25*1440/360 =100. Double that = 200. Above 200, the gears rotate forwards, below they go backwards. If the sign before the $t in the code for the backward gears is reversed, they go forwards! And surprise, surprise: you can’t tell the difference between 180Rx30 (R=reverse, 30 is the FPS in the video program) and 220x30 - no difference in quality! Doubling the number of frames to 360 improves smoothness a bit, but is not really worth doubling the size of the file. Of course, if a gear is reversed to go forwards, it has to be decoupled from parts to which it is attached - you don’t want them going backwards. That way you can save 40 frames.
Continuation because of limit for attachments.
Continuation because of limit for attachments.
