Call script on WorkflowImport

[idea4IT]

Hey guys,

 

I've been writing some workflows that are using a few copyright protected icons, for example the Parallels Desktop icon.

To get around the copyright issue, I came up with a script that can generate the icon.png file.

This script needs to be call once and it would be great to do this when the workflow is imported.

 

Is there any way to call a script on WorkflowImport?

 

Regards,

Fabio

[rice.shawn]

Short answer: no.

 

Workaround: Do it on a first run.

 

For the first-run, check to see if the file exists; if it doesn't, then generate it; otherwise, move on. Invoke the first run script each time the workflow runs, and put it at the top of the script filter / script that you're using. Unfortunately, it won't work immediately, but it will work perfectly after the workflow has been run once.

[vitor]

In addition, see this other thread for a short discussion on this issue.

[idea4IT]

Thanks guys, that's what I thought.

 

In order to let the script run only once, I called it in a dedicated "Run Script" element and then removed that element from the info.plist file.

Too bad, that there are no install/uninstall events.

But this could be something I should request in the "Feature Suggestion" forum.

 

What do you think?

[vitor]

As stated on the thread I linked to, having those kinds of events firing automatically is not exactly safe, so in that discussion, I’m for not having that possibility. Sure, we need an extra step for configurations, and although that’s a bit more annoying, it makes us take more care with the configuration process, and to help make it as clear and straightforward as possible.

There are also more cases to take into consideration. For example, in the case of syncing, Alfred would have to keep track of what computers the install event already ran and those where it hasn’t, and act accordingly. And what if the install event does something the user doesn’t want to? There has to be a way to check for that. Specially in the case you mentioned, where you’re removing the traces of the action, there has to be a way to prevent malicious operations. One of Alfred’s strengths is that you have to specifically call the actions you want it to perform. Sure, you can still do it the way it currently works, but at least you can check for it, if you’re so inclined.

All that said, I believe it’d be way more beneficial to have an install message — some configurable text that will appear to the user when installing the workflow, advising what the first command should be; something like the “Readme” section, but that appears as soon as the workflow file is opened for the first time.

[idea4IT]

Sounds reasonable, even though I must say that security-wise, third party workflows will always be a problem.

Edited March 23, 2014 by fniephaus

[vitor]

even though I must say that security-wise, third party workflows will always be a problem.

Again, this has been addressed on the thread I linked to.

 

if you are able to run python/bash/etc, security is out the window. By not allowing installation hooks/scripts/etc, all you do is move the security concerns from installation, to runtime.. which doesn't seem to matter to me.

It does matter. I (and I’m guessing others) tend to open up new workflows to see how they work, in search for interesting solutions; by doing this, it means we can find security issues and alert others without having our own machines compromised in the process. If the code runs at installation time, there’s no way to check it before running, and that is really bad.

Third-party workflows will always be a problem, yes, but so is Alfred itself. The point here is that installation events can significantly increase security risks. In the balance between convenience and security concerns, the destructive powers of installation events that are run automatically without oversight is far greater than the convenience of not having to run one command once, after installation.

[idea4IT]

Fair enough.

Maybe we need something like an approval/voting system, so that people can confirm that a certain workflow is not a security risk.

But yeah, I understand what you mean.

 

Anyway, I found a way to work around the initial issue.

Anything else is up to Andrew, I guess. Thanks!

[rice.shawn]

Third-party workflows will always be a problem, yes, but so is Alfred itself. The point here is that installation events can significantly increase security risks. In the balance between convenience and security concerns, the destructive powers of installation events that are run automatically without oversight is far greater than the convenience of not having to run one command once, after installation.

 

Vítor is, as usual, spot on here. As for the security, it does help that Apple locks down quite a few commands with the need for an administrator password. The workflows are, basically, unsigned software freely distributed, and so they carry the risks of any unsigned software freely distributed. If you grab anything off Packal, then the workflow has been run through a virus scan, but that accounts only for a tiny bit of the security risk. However, we've built up a bit of a community on these forums, and Packal piggybacks off of that. If actual malicious code is spotted in a workflow — which to my knowledge has yet to happen — I'm sure that we'll catch it and throw up all sorts of warning signs. If I'm notified of any malicious workflow that appears on Packal, rest assured that it will be taken out of circulation immediately. Also, organically, we've also come up with a set of best practices for workflow development that values transparency and security. It is discouraged to install anything on anyone's computer without letting them know, and it's always best to try to keep everything contained to the appropriate data and caches directories. Ultimately, the security in these workflows is built around a level of trust in this community. So far, it seems to have worked out fairly well.

[idea4IT]

That's right and I agree with you and Vítor.

But if someone really starts trying to distribute malicious code, there might be no other option than warning users.

Since Alfred executes scripts, attackers might not be able to run commands as root but they can easily delete user files and folder or load more stuff from the web.

 

Let's hope this is not happening anytime soon...

[deanishe]

If you're worried about this kind of thing, you should install Little Snitch. It won't stop a malicious (or broken) script trampling all over your data, but it will warn you (and stop it) if it tries to send anything over the wire.