The threat levels are obsolete and they have been superseded by the
Allow_<func>= lines in the osslEnable.ini initialization file. Every
region reads a copy of this file when it boots. If there is an
Allow_...= line for a function, that can allow region owners, estate
managers, gods, parcel owners, specific avatars by UUID to call the
function or combinations. It can enable each function one at a time for
all to use or disable them one at a time for everyone. If there is any
Allow_...= line in the INI files, the threat level is never checked. So
threat levels could be thrown out. EXCEPT that since they are still
there some people still use them (like LBSA Plaza, the place you arrive
by default in OSGrid, the testing ground of Open Simulator). So as
someone trying to be a professional scripter I'd like to make sure my
code works even in the cases where region owners still rely on threat
level. Too bad threat level is hard-coded into each function and not
readable by any other function. I'm building my own table with a copy of
this information so I can use that copy to do the test.
It was pointed out to me that finding out WHY a script generated an
error is a potential security violation. Getting a message that says
"you can't run that function because the threat level of this region is
VeryLow and this function is Moderate" gives a griefer information about
what will work here. The correct secure way for the function to work is
to just return TRUE if the function will work and FALSE if not. I can do
that. I don't care WHY I should not call a function only if I CAN or
not. I don't care if it is because of Allow permissions or threat level.
I just want to know that if I skip calling a function, an annoying
incomprehensible message WILL NOT appear.
Note that the threat level can be different in every region, even in one
grid. The Allow_...= permissions can also be different in every region.
So a script would like to know every time it changes region, or grid,
what is safe to call and what is not.
On 10/17/2019 9:09 PM, Mike Lorrey wrote:
Been lurking for quite a while, and I have to ask, Mel mentioned that the
threat warnings were created to protect against a griefer threat that never
materialized. If the perceived threat never happened, why are we keeping
the threat levels at all? Keeping them is the same sort of illogic for
keeping a government agency funded and operating despite having nothing to
do, like regulating buggy whips. How about we turn this stuff off
completely? I don't need to deal with OSSL functions if I wanted to grief
opensim, theres plenty of LSL functions I could use to bring a grid to its
knees if I wanted to. Furthermore, the main threat in opensim, the problem
of copybotters, the devs do absolutely nothing about, so you cannot claim
to be protecting us against a nonexistent threat when you are doing nothing
about a real threat.
On Thu, Oct 17, 2019 at 3:51 PM Dahlia Trimble <dahliatrim...@gmail.com>
wrote:
In SL we used to set up error event handlers with a listener on
DEBUG_CHANNEL. Errors will still show in red on the script debug window but
you're script will be able to be aware of the error(s). I don't recall if
I've ever tried it on OpenSImulator but I'd be surprised if it didn't work
there also.
Users don't usually see the red text as most keep the script debug window
open.
On Thu, Oct 17, 2019 at 11:05 AM Mike Higgins <m...@kayaker.net> wrote:
I agree that many functions are dangerous, and some grid owners may
shoot themselves in the foot by enabling them. But I am talking about
writing scripts that behave in a professional way, so I can hand them
out for lots of people to use. If I wrote a phone app that popped up
internal error messages in some locations, this would be considered very
unprofessional and people would down-vote my app and stop using it. Most
programming languages have a try/catch (or on_error) flow control
construct, but LSL does not. I would love to add such a construct to LSL
but I do not have the skill to add that to the language. (I'm of the
opinion that a new error event rather than an error state is the way to
go).
I do have enough skill to add an osPermissionToCall function that
returns some information about the OSSL functions. I agree this is not
ideal, but I could write the code for this function and submit it to the
Devs, saving them from needing to do this trivial task and saving them
from the more difficult task of adding error catching to LSL. Ubit tells
me he would reject this try-before-you-call submission. But I assume he
does not have the time to do the better option of adding an on_error()
state to the language. The result is that there is no way for us
scripters to write professional programs in OpenSim.
Here is the scenario I am looking at: I write a useful script that
people want to use as they hypergrid around. I thought it was safe to
call osGetGridName which seems an innocuous function and will probably
be allowed everywhere. But it turns out that osGetGridName has a
"moderate" threat level and some places, (most notably LBSA Plaza in
OSGrid), have the threat level set to "Very Low" and do not have an
“Allow_” line to override this for osGetGridName. So my script works
most places in the Metaverse, but fails and pops up messages when one of
the users of my script shows up there. I would love to catch that error
and do something reasonable with it. But LSL has no way to do this and
the developers are resisting alternative ways to do this. (In the case
of osGetGridName, I could catch the error and substitute “OpenSim” as
the grid name, or have the script tell my users “Sorry, I can't tell
where you are now”).
There was a secondary issue that when osGetGridName fails, it not only
popped up an internal error message, but it sends that message to every
avatar in the region. Ubit has thrown me a bone by adding an option to
the INI files that suppresses this behavior and only sends the message
to the user of the script. This has several problems: 1) Note that it is
the user of the script that gets the message, not the scripter. 2) Most
of my users and most of the avatars that get this message are that:
USERS, not grid owners who have the power to change the INI file. Since
they can't effect the outcome, they will stop using my script. And all
scripters like me will just stop calling ANY of the OSSL function in the
scripts we hand out. Even the innocuous looking ones. And all the effort
that the Devs have spent on writing the OSSL functions will have been
wasted.
Imagine that I write a phone app that works fine on the SPRINT network
but pops up internal error messages when you are roaming on AT&T. But
then it paws through my contact list and also sends a copy of that
incomprehensible error message to all my friends. Ubit has given me
equivalent of a tool that can stop that last behavior, but only if
SPRINT and AT&T change some internal flag on their servers. Unlikely to
happen. People are still going to get error messages and stop using my
phone app.
Then there is an additional problem: Currently there is no way for an
osPermissionToCall function to know what the threat level is for any of
the other OSSL functions. That threat level is hard-coded into each
function. Ubit resists moving that information to a central location in
the code. He also resists moving this information into the INI files.
But I still want to find a way to write professional scripts on OpenSim.
So if you are still reading this Ubit: Would you accept a patch with an
osPermmissionToCall function that was completely self contained and did
not require changing the location of the threat level values? For
example, the osPermissionToCall functioin could have a local table of
all the other functions and their threat levels. This might introduce
bugs if threat levels ever change, but that seems unlikely.
On 10/17/2019 8:10 AM, Leal Duarte wrote:
Well lets try put some perspective on this...
The problem is not how hard it is to detected and handle disabled
functions
The problem is WHY are you using them !!!
See OSSL got a lot a functions in time and for very different reasons.
Many are there because they are just funny/useful on very specific
regions or cases.
Once the allow control was introduced, that got worse, because as dev
in can just not care, i just flag a specious feature as SEVERE,
ESTATE_OWNER only. And just let you change it and shoot your own feet,
or worse someone else feet...
And in many cases you are just doing that. ( the C# scripts was a
example i just had to kill )
see a very simple and useful(?) example
osGetNotecardLine(..)
none of that Dataserv mess of llGetNotecardLine(..) right?
well wrong.. Dataservice is need because the notecard may be on a
assets server on the other side of the world...
and not using it will stall the engine thread, potentially all of then.
Why do i see its errors at osgrid LBSA ?
A lot more examples, but you got the point.
When one writes a script, one must take in consideration its target
audience..
you can't use osSlerp() if you want it to run at current Kitely, can
you?
So issue is to identify a set that should be universally supported,
and everyone make the effort to support it.
...
Ubit
On 17-Oct-19 15:17, dz wrote:
......
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
