scripting proposal draft 3

Miguel Angel Alvarez maacruz at gmail.com
Wed Apr 9 15:15:48 UTC 2008


El Miércoles 09 Abril 2008, K Robinson escribió:
> On Saturday 22 March 2008 5:22:30 pm Ian Monroe wrote:
> > On Sat, Mar 22, 2008 at 4:16 PM, Miguel Angel Alvarez <maacruz at gmail.com>
>
> wrote:
> >  > Again, binary scripts are a no-go. They will not be supported.
> > >
> > >  Again, think of ways of enabling users, not disabling them (let that
> > > to M$ and Apple and MPAA).
> > >  You don't have to support anything. Just provide us a good interface,
> > >  everything else is our work.
> >
> > No we have some quality control responsibilities.
>
> Has anyone done some security or threat analysis on the script interface,
> or is this planned?  I didn't spot anything in the proposal.  While I want
> scripts to be able to do a lot, I also want users to be able to (at a
> minimum) quickly audit what a script is doing or has done in the past. 
> This also ties in with quality assurance problems.  If a script is causing
> instability in Amarok or elsewhere, it would be nice for users who know
> little to be able to figure out it's a script, not amarok itself.
A script is just a command fed by stdin, which can communicate with amarok via 
dcop/dbus to change it's behaviour, so no way the script can cause any 
instability in amarok which is not a quality problem of amarok itself (except 
DOS attacks)
Since it is nothing more and nothing less than that, it can do anything that 
any command run in the same user account can do, and that's all. Users are 
able to install and run anything, so there are no more security implications 
than anything else the user can do. If the user is afraid of what a script 
can do, he may be able to run amarok under a different user account (the same 
applies to web browsers).

-- 
Don't see the world through a window, be open{source}minded, and be free :-)



More information about the Amarok mailing list