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