Skills are auto updated by msm, from a repo owned by random developer joe
I think security should come first and this feature rolled back until other mechanisms are in place
here is the story of SWIM and how he distributed malware
Abusing skills repo for malware distribution https://jarbasai.github.io//posts/2017/10/skills_malware/
My first goal with the mycroft-skills repo was to get skill devs on-board with the process of putting their skills in a shared and easily found location, submitting their skill using the standard README.md template at (http://rawgit.com/MycroftAI/mycroft-skills/master/meta_editor.html), etc. Now that this is starting to happen, we also need a solid structure to allow devs to reasonably support API changes without having to play a coding whack-a-mole game while the platform evolves.
Now that we have 17.08, I plan to use that as the basis of a forthcoming mycroft-skills repo mechanism:
The current “master” of the mycroft-skills repo will become the “17.08” branch. Skill developers who submit skills there can feel confident that the API will not change out from under them – only backwards compatible changes will be allowed in mycroft-core 17.08. The MSM that is part of 17.08 will pull only from this “master” (soon to be “17.08”) branch of the mycroft-skills repo.
When a new major version of mycroft-core starts up (e.g. 18.02) and begins to make breaking changes, an “18.02” branch will be created in the mycroft-skills repo. Old skills will need to be updated and resubmitted to make it into this branch. If an author doesn’t want to continue updating a skill, that is OK – it will continue to work on units that are still running 17.08. But eventually they will age out and disappear.
With devs getting used to submitting skills multiple times, we can now lock down the MSM update mechanism. Instead of it pulling from the head of the master branch for each skill all the time, it will instead only download the exact version that was submitted to mycroft-skills as a submodule.
The last is the real security piece. This will prevent someone from being evil and changing their sheep skill into a wolf skill. However, this requires someone to review each skill PR in order to be effective.
I recently transferred the ownership of the skill repo to the community – it no longer belongs to Mycroft AI Inc. That group and the community needs to figure out how we manage what will become a large body of PRs requesting to be included in the mycroft-skills repo.
I believe automated tools can assist in this work, but I don’t want to prematurely implement a policy and either stifle the excitement of some new devs who are pushing out updates to their skill every day or two…but then see them languish waiting on the acceptance of a PR. I also don’t want the skill acceptance to become a rubber-stamp – I think that is even more dangerous in creating a false sense of security.
Help, discussion and ideas are welcome!
I think there’s inherent risk in installing any software - there’s a huge web of people to be trusted. Especially at this stage in Mycroft’s development, I think most Mycroft users probably understand that, and for those who want to avoid the automatic updates, they can install the skills themselves (relatively simple to just clone them into the skills directory). This allows them to verify and update at their own pace.
That said, it might be worth making the auto-update feature of msm very explicit (e.g. in the docs, as well as asking for confirmation before installing skills), so that people are aware of the risk.
Going forward, it might make sense to have some kind of ‘endorsements.’ There could be ‘Endorsed by Mycroft’ and ‘Endorsed by X Community Members’ tags for specific skills and/or versions of skills, indicating they’ve been vetted. Then, people could choose to install skills/versions that have not been vetted (no longer held up by the PR process), but there is a system for denoting trust of certain skills.
tldr: you need to specify a reason before “banning” a skill
So my skill was not accepted, why?
“I’m going to close this pr. You’ve gotten a response in the forums as well as in matter most to your concerns. Feel free to bring up other issues you have there, where we can productively work together to address them.”
The answer i need is “closed source skills are not allowed” or whatever reasons it was for it not being accepted,
does not accepting my skill mean no closed source skills will be allowed from now on?
does it mean instead that skills that are too simple will not be allowed?
it also is the first example of running C compiled code in a mycroft skill, does this mean i can never again submit a skill not 100% python?
is it because i’m not a trusted member?
where is the official policy for not accepting skills, since this is the first time a skill is rejected from the repo
it is my opinion skill auto update should be disabled by default / configurable until this is addressed, should security come first?
i think msm overall needs some changes:
I agree with making the auto-update feature of msm very explicit in the docs and i like the idea of endorsements, what would be the way to go about that? where does it fit in the skill submission/download process?
Another question, if someone were to make “paid” skills, would these be rejected? at long term this is expected to happen in a complex “app ecosystem”, developers will want to be rewarded for their work. Many will probably avoid developing skills until they can charge for them
My hope is that we as a community will always have an effective open source answer to every closed source skill, but should we deny those with different views from using our open platform?
Relevant discussion in mattermost: https://chat.mycroft.ai/community/pl/yina1dyx5tbe5d5fzikjekujyh
Several responses here, some policy/ethics some technical. Let me start with the technical since I think those are a little more straightforward:
Jarbas said:
i think msm overall needs some changes:
allow to choose default skills
allow blacklisting some skills
make auto update configurable per skill```
MSM and the mycroft-skills repo definitely aren’t perfect or general consumer ready. But before the repo existed discovering skills was very difficult. Once it existed, instructions were still difficult. Now there is a consistent way of installing – “hey mycroft, install Whatever”.
Recently I made the “default” skills configurable by the default skills repo, including platform dependent defaults. More on that below in the Policy discussion.
Disabling the auto-update is simply too early, IMHO. Basically, every skill today is at the “minimum viable product” level and needs to improve. Making the process of improvement slower today would be a hinderance, not a true help to the community. There is a path to not auto-update (see above), so I living on the edge during the alpha phase should be expected. When I walk onto a construction site I expect to wear a hardhat and look out for the frontloaders driving around, and that is where Mycroft is today.
I could easily add a mechanism to disable MSM for now. But I really don’t want to create user interfaces to do that, it is a bad precedent that would interfere with the better solution outlined above. So if you are doing it via a keyboard, just rename msm/msm to something like msm/msm-manual. Just my $0.02, but I’d be willing to accept a mycroft.conf setting PR if you want to invest the effort in implementing it.
Jarbas said:
you need to specify a reason before “banning” a skill
Well, it was called “Evil skill”.And you didn’t hide that the purpose of it was to create discussion, not to do anything useful. Thank you for linking that PR to this discussion – that was what I suggested be done.
Jarbas said:
Another question, if someone were to make “paid” skills, would these be rejected?
Nope! That is absolutely intended to be supported and I’ve talked for at least a year about the idea of including skill fees in the metadata to describe a skill. For today, the technical hurdles of making a “paid” skill are what make this tricky. Here are the things I see as difficulties and where I want to go with them:
Policy stuff
This is the most debatable bit. What are the lines that exist for Mycroft? Where do we declare “acceptable” and what what isn’t?
Several months ago I officially handed over the mycroft-skills repo to the Mycroft Community. I create a board of 5 people to manage it for the community and, most importantly, to create the mechanisms for managing it as a Community. I.e. how big should the board be, how do we pick future board members, what are the mechanisms for submitting a skill, what are the guidelines for nameing/tagging skills, …
In addition to that, we have a lot of stuff to decide that is even more nebulous. How do we deal with legal issues, especially since we are an international system? Are there guidelines for NSFW/Obscene and if so how do we define what that means – or how do we avoid having to define them? I think this last point is probably worthy of an entirely different post and open debate. In general, these sorts of decisions will be the “constitution” for the Mycroft ecosystem and I want these decisions to be made thoughtfully.