(2017-09-06, 15:41)trogggy Wrote:

(2017-09-06, 15:28)Lunatixz Wrote: 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?

(2017-09-06, 15:44)Lunatixz Wrote: I don't think one person here said this security feature is a end all problem solver. It simply patches one easily exploitable issue.

(2017-09-06, 15:49)trogggy Wrote:

(2017-09-06, 15:44)Lunatixz Wrote: 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.

(2017-09-06, 15:52)Lunatixz Wrote: IC, yeah makes sense all exploits should remain unpatched...

(2017-09-06, 15:54)trogggy Wrote:

(2017-09-06, 15:52)Lunatixz Wrote: IC, yeah makes sense all exploits should remain unpatched...

Sure, because that's what I said.

(2017-09-06, 15:21)Av3nged Wrote:

(2017-09-06, 14:46)Lunatixz Wrote:

(2017-09-06, 13:54)ohmykod Wrote: 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.

(2017-09-06, 16:55)Lunatixz Wrote:

(2017-09-06, 15:54)trogggy Wrote:

(2017-09-06, 15:52)Lunatixz Wrote: 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

(2017-09-06, 17:10)Lunatixz Wrote: 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.

(2017-09-06, 17:59)Av3nged Wrote:

(2017-09-06, 17:10)Lunatixz Wrote: 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.

(2017-09-06, 17:59)Av3nged Wrote: 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.

(2017-09-06, 17:59)Av3nged Wrote: 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?

(2017-09-06, 15:52)Lunatixz Wrote: IC, yeah makes sense all exploits should remain unpatched...

(2017-09-06, 21:58)L0RE Wrote:

(2017-09-06, 15:52)Lunatixz Wrote: IC, yeah makes sense all exploits should remain unpatched...

Not every Security solution would be advisable

(2017-09-06, 22:39)DaLanik Wrote: 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.