Packaging Scripts Into Songs?

If in the future if we can have scriptable meta-devices, could we have script embedding/packaging into songs?

Security concerns are certainly there since the api can address external resources, but it will certainly come in handy when we can script meta-devices.

is this partially the reasoning for removing meta-devices from the trunk earlier?

If so, can we talk about it?

Scripts on the tools page already have to be previewed before approval. So you can assume that it ain’t possible to pack scripts along with songs, if it will be, scripts will not be allowed to access external resrouces and perform malicious executions.

If that’s the case it sounds like roadmap is deeply convoluted.

… not offered on renoise.com, yeah, but otherwise? Anybody can already write all sorts of malicious scripts and distribute them elsewhere if they so wish. The fact that stuff on renoise.com is trusted while everything else isn’t, seems to support the idea of packing scripts with songs? I figure 99% of all Renoise songs are only passed around in mp3 format anyway.

There still ought to be a way to allow/forbid it, which kinda means Renoise needs to keep track of all songs it has asked permission to load scripts for (think browser cookies: “allow all, deny all, ask”), and to periodically purge the list of old entries (since songs get moved around or renamed). So yeah, it’s not that simple.

I do like the idea of tools.renoise where all the scripts are subjected to scrutiny, and I know if I grab a script from public forum I know I will have to be the person scrutinizing the tool/script. I know I can turn the sandbox feature of my firewall on (Thanks Johann and vV for the mention on Komodo) but mostly I don’t because it keeps messing with the OSC server. So maybe we just need a firewall in renoise?

What would such a renoise firewall do though? Ask for each script (version) if it may send/receive data? But then you can still hide malicious code in more complex stuff that accesses the internet. Besides: the real danger is not so much internet communication, but simply os.execute and the file operations: deleting stuff or corrupting it, null problemo. Of course, combine that with downloading executables and running them and you have a full blown invasion on your hands.

But still, the risk of total destruction is already there anyway, and there is nothing that you can do except go through each script with a comb, OR cripple scripting OR use a lot of resource to make everything safe which will just make it a challenge to find a loophole. Right now Renoise is an open door, which, believe it or not, represents much less of a target IMHO. Seriously, who would write rogue scripts and how far would they get?

A tool that piggybacks or seeds itself into all the botnets of the world, mirrors a current renoise version, installs renoise into the background of all the zomibes and then makes music based on rules and variations of seeded motifs sent through the tool, with options for collaboration with other renoise users.
Could turn the whole world into an orchestra.

But really, if we have to install scripted meta-devices and dsp-devices, sharing songs is going to go even further into convulsion than it is, which isn’t convuluted at all unless the song needs a specific vst on a specific platform.
what if the meta-devices and dsp devices could only use internals, then those could at least be packaged in the songs and no one need to really worry right?

yeah, it’s not like you’d ever need to read/write files/execute stuff or access the internet to play back a song correctly… so you can kinda scratch all I said before about “crippling scripting” LOL.

at the moment, scripts can’t do anything real-time…they can only deal with offline editing operations.
what’s the point of bundling them in songs if they are not a crucial part of the playback?

Are you sure? Bantai’s ActionMatrix tool in the trunk seems pretty real-time.
From what I can tell it creates a server and all the RT is directed through it.
Maybe it’s not a great example because that thing is Genius but I’m pretty certain it’s real-time, unless I am mistaken

Scripted Meta-devices really would need to be real-time in order to be useful though right?
I could see allowing scripted-meta-devices to interact with tools in some limited method, but I think it would be a good idea to allow them to be packaged by the song.

Why should Renoise keep track of songs?
I’m only pointing on the awareness level a user should be given for the fact he/she is installing a script.
By allowing a song installing scripts, this takes away the awareness. Even with a warning dialog and a confirmation button, a user is more quickly tempted to allow the script to be executed anyway without checking.
If the script is offered seperately, it usually comes with a description of what it does.

Ofcourse it will never be possible to ban out all malicious scripts in the world. But taking care the user has a chance to prevent apocalypse on his computer and possibly the rest of his network is simply a matter of care on our side as well.

So it doesn’t have to ask over and over again. When I load my own songs, I want everything in them to be loaded of course. But how is Renoise supposed to know what I consider my songs and which one I downloaded? As I said, think cookies. “allow all, deny all, ask for each song individually” (and that question obviously has a checkbox to “not ask again”, which means the choice for that song gets saved). I personally would probably set it to “allow all” anyway, paranoid people who don’t use scripts in their own songs can set it to deny all, everybody else has “ask”.

It may sound complicated, but what’s the alternative?

So? So does spyware…

You’re saying it would suck if people would “allow the script to be executed anyway without checking”, but somehow not suck if they blindly trusted the description to not be a lie, without checking the script? I don’t see the difference you’re seeing there.

edit: By offering a moderated selection of safe tools on tools.renoise.com that come with descriptions, you take away awareness. Fact. But you don’t have a problem with that, so what would be the problem with scripts in songs and a cookie like mechanism?

I think that’s kinda patronizing, too. My browser allows me detailed security options, and I am aware of them and have configured them. That some tards just allow or deny everything is their business, and I would be infuriated if browsers became simpler because of them. And Renoise is not a farmville portal like browsers are, so if it works fine for browsers, it would work perfectly for Renoise I think.

That will be the minimum that has to guard this stuff initially… (scripts in songs are disabled by default unless specified to act always or ask each time)
But from my own experience… being prompted for it all the time gets old real fast.
Also could be that certain API functions can be disabled (like the os.execute stuff) by default.

I’d be very much in favour of that, same for the socket stuff and even reading and writing files, or anything else I missed… they just doesn’t seem necessary. But then again I don’t use Renoise live etc., I just compose and render songs which are not interactive in any way, so my perspective and needs are kinda limited.

No, but i guess for using Renoise live, some specialized scripts can be written for that and upon the new document notifier you can even specifically activate a script upon loading a specific song.
There is no real need to write along scripts with the song if this currently is for generic API control only.
Don’t know how the custom metadevices will go though… these might be saved along the song perhaps. The devices already lacked access to certain API features, but this could also be due to incompleteness.

Ideas:

  • Some sort of digital signing, so we can opt to ‘trust’ certain authors - The script engine could throw a prompt for certain permissions above and beyond your designated ‘safe’ permissions, and allow you to grant all or some of the requested permissions - Run Renoise in Sandboxie

No, thats not the problem. We planned to allow script !data! in Songs, but not fully blown “Scripts” or tools that actually do something.

Tools should be like plugins. You need to install them manually to the app to get them. Then all what would be present in song, would be some raw data for the scripts, like song specific settings, preferences. Nothing that gets executed and thus also nothing which magically does something you are not aware of. If you don’t have such a missing tool installed, then we either silently ignore that part of the song or tell the user about it. He then can decide by its own if he wants to install it or not.

Same for audio or meta device scripts. Those should be like plugins as well, and should not be bundled with your songs.