[Lunatixz]

There are dozens of real world examples... and yes a user could wake up to repos installed without their knowledge. It only takes one unauthorized script.

It takes a conscious decision to install things from outside the official repo. And one unauthorised script.
Or an unauthorised script in the official repo.
No?
If third party repos are enabled then this doesn't secure against a malicious script. Does it?

I don't think one person here said this security feature is a end all problem solver. It simply patches one easily exploitable issue.

Sent from my SM-G935T

[trogggy]

I don't think one person here said this security feature is a end all problem solver. It simply patches one easily exploitable issue.

There's the rub.
You patch something.
You cause inconvenience to users until the end of time.
Anyone with a genuinely malicious script* spends 5 minutes re-writing it and is good to go.
Drinks all round.

And if we're not cheering on the sidelines it 'only reflects poorly on you and your knowledge of the situation.'
This feels like being lectured by an ex-smoker.

* I'm genuinely curious to know if there are really 'dozens of examples' of malicious scripts that have taken over official addons btw. Or even one for that matter.

[Lunatixz]

I don't think one person here said this security feature is a end all problem solver. It simply patches one easily exploitable issue.

There's the rub.
You patch something.
You cause inconvenience to users until the end of time.
Anyone with a genuinely malicious script* spends 5 minutes re-writing it and is good to go.
Drinks all round.

And if we're not cheering on the sidelines it 'only reflects poorly on you and your knowledge of the situation.'
This feels like being lectured by an ex-smoker.

* I'm genuinely curious to know if there are really 'dozens of examples' of malicious scripts that have taken over official addons btw.

IC, yeah makes sense all exploits should remain unpatched...

Sent from my SM-G935T

[trogggy]

IC, yeah makes sense all exploits should remain unpatched...

Sure, because that's what I said.

[Lunatixz]

IC, yeah makes sense all exploits should remain unpatched...

Sure, because that's what I said.

ahh, So you are allowed to draw conclusions from my posts, but not vice versa. GOTCHA!

I won't be taking your bait....I can see you have no alternative solutions but lots of opinions on the matter... and we know what they say about opinions

[Lunatixz]

I might be wrong but this looks to me just like a shot aimed at third party addons, I dont see an issue so urgent or bad to justify this override measure.
I always read that Kodi doesn't care about what user do with their kodi installation, nor it tries to force people to use something, but using this feature is like feeding people with what you decide them to use or not.
If you use Kodi for just legit purposes, which the Kodi Team always suggests to do, you dont have the problem of installing un-trustworthy addons so you shouldn't have the need to worry about overriding ids, this problem only comes when you usually install sketchy repos, usually pirate ones, or wizard-builds, and even in the latter case you shouldn't be taking this in such a serious consideration to justify an action like this, after all you don't mind if users use Kodi for pirated content right? it's their fault if they have a sketchy repo so why bother?
I am missing the point here

Yep, you are missing the "security" measure this override provides.

As it is now a user can download a plug-in that was vetted by team Kodi, then a third-party repository can update that plug-ins code. The end-user would be absent to the fact they are no longer running trusted code.

Some users might say "so what" ... Those users should be reminded that a popular third-party repository (TVA) was caught twice pushing malware code to their users.

Sent from my SM-G935T (typie typie)

When this tread started I thought that this is a great idea that should be added but the more I think about it the more I am convinced otherwise.

Implementing the current suggestion would seem to inconvenience the beta testing community and any attempt to mitigate that inconvenience would be fruitless.

With that being said the best solution that I can currently see is to keep track of what repo the addon or skin came from and only accept automatic updates from there. Basically once a third party repo is installed there is not much that can be done to maintain security.

I don't disagree, if you look at post #2 I voice concern for beta repositories.

In the BIG PICTURE of things... I agree, if a user installs a third-party plugins/repo security is on them. However if a plugin id is hosted in the Official repository I think this override is acceptable.

As a developer I DO NOT see any inconvenience adding .dev id tags to my beta development. IMO It makes it easier for the user to know when they are running a "Stable release" or "Beta" code.

[trogggy]

IC, yeah makes sense all exploits should remain unpatched...

Sure, because that's what I said.

ahh, So you are allowed to draw conclusions from my posts, but not vice versa. GOTCHA!

I won't be taking your bait....I can see you have no alternative solutions but lots of opinions on the matter... and we know what they say about opinions

Can you post without being insulting?

[Av3nged]

I don't disagree, if you look at post #2 I voice concern for beta repositories.

In the BIG PICTURE of things... I agree, if a user installs a third-party plugins/repo security is on them. However if a plugin id is hosted in the Official repository I think this override is acceptable.

As a developer I DO NOT see any inconvenience adding .dev id tags to my beta development. IMO It makes it easier for the user to know when they are running a "Stable release" or "Beta" code.

I think that addons should not AUTOMATICALLY update to a higher version form another repo. Is this the way to accomplish it, I don’t know.

I am not a developer but I do have concerns about test versions of dependencies and how that would be managed. The argument of having to redo the settings to the addon or skin I could care less about.

Would it be possible to have a .dev version of an addon automatically used if the stable version is uninstalled or disabled?

Ex: you install script.skin.helper.service.dev then disable script.skin.helper.service to be able to test the function of the .dev addon.

What I am trying to say is that if .dev is used to identify development builds then it should be used as if it had the same id as the one in the kodi repo but have the stable version take precedence over the .dev version if avalible.

Any thoughts on it working that way?

[Lunatixz]

I don't disagree, if you look at post #2 I voice concern for beta repositories.

In the BIG PICTURE of things... I agree, if a user installs a third-party plugins/repo security is on them. However if a plugin id is hosted in the Official repository I think this override is acceptable.

As a developer I DO NOT see any inconvenience adding .dev id tags to my beta development. IMO It makes it easier for the user to know when they are running a "Stable release" or "Beta" code.

I think that addons should not AUTOMATICALLY update to a higher version form another repo. Is this the way to accomplish it, I don’t know.

I am not a developer but I do have concerns about test versions of dependencies and how that would be managed. The argument of having to redo the settings to the addon or skin I could care less about.

Addon's should automatically update... you can always opt out in settings.

Technically speaking there is no reason a beta (ie. .dev) plugin couldn't use the settings from its parent stable version, as for updating they should work as independent plugins.

Ex: you install script.skin.helper.service.dev then disable script.skin.helper.service to be able to test the function of the .dev addon.

What I am trying to say is that if .dev is used to identify development builds then it should be used as if it had the same id as the one in the kodi repo but have the stable version take precedence over the .dev version if avalible.

I think that's the main issue that was brought up... how will Kodi handle two scripts one stable one ".dev"... any code to allow the two to work as one discredits the attempt to "secure" Kodi.

In cases of scripts like skin.helper thats a tough one...

[Gade]

Would it be possible to have a .dev version of an addon automatically used if the stable version is uninstalled or disabled?

Ex: you install script.skin.helper.service.dev then disable script.skin.helper.service to be able to test the function of the .dev addon.

What I am trying to say is that if .dev is used to identify development builds then it should be used as if it had the same id as the one in the kodi repo but have the stable version take precedence over the .dev version if avalible.

Any thoughts on it working that way?

Problem is that you probably won't be able to disable script.skin.helper.service as most skins using it depend on it.
And when skins depend on a script, the user won't be able to disable or uninstall it.

[L0RE]

IC, yeah makes sense all exploits should remain unpatched...

This Patch would mean removing a feature , for more Security..
Another Solution would be not supporting Network, it would make Kodi Much Safer ....
Not every Security solution would be advisable

[Lunatixz]

IC, yeah makes sense all exploits should remain unpatched...

Not every Security solution would be advisable

I agree, but we are not talking about all exploits. This topic is about a specific commit. One that makes the official repository the primary update source.
There has been a lot of valid points for and against this idea.

[User 325245]

You are ovecomplicating things. Make a setting same as "unknown sources" so it can be turned off. And even when turned off, user gets a warning that (if) the update is not coming from the "original" repo. Simple and doesn't bother users too much.

[Lunatixz]

You are ovecomplicating things. Make a setting same as "unknown sources" so it can be turned off. And even when turned off, user gets a warning that (if) the update is not coming from the "original" repo. Simple and doesn't bother users too much.

Adding a switch won't solve the problem...

[jurialmunkey]

The way I see it, it is only add-ons that require skin integration which will be problematic. Namely because:
1. Skin dependencies will prevent disabling the official version of an add-on to test the beta version.
2. These add-ons tend to need skin integration with hardcoded add-on IDs thus requiring extensive modification for beta versions.
3. Some of these add-ons run as a service that fills window properties, so you will essentially have two add-ons filling the same property.

Solutions that do NOT work:
1. Switches or Prompts can easily be overridden.
2. Giving priority to the .dev version or defining a "trusted" beta repo in addon.xml can be easily exploited by malicious repos/wizards/builds

Thinking about this, I have a simple solution:
Have a very limited singular Official Beta Repository which is the only source capable of overriding add-ons from official repo.
- This repo would be updated much more frequently and with less checks than the official repo.
- Only those with an explicit case for needing to override official repo versions would be able to submit.
- So only add-ons that are skin dependencies and run as services or require skin integration to work would be allowed.
- This likely would only be a handful of add-ons: skin helper, next-up, next-aired, skin shortcuts, extended info, colorbox.
- Updates from this repo would still require explicit confirmation via a yes/no prompt so that only selected add-ons are installed.

I think this merges the best of the proposed solutions whilst still retaining the original intent.