Hi,
I'd like to discuss a new feature for (NU) Services.
A service can contain multiple repos and they may change over time. All these changes are automatically apllied to the system during a refresh of the service.
But one thing is missing IMHO. All new repos always remain disabled and have to be enabled manually. In the registration process we therefore enable each repo one by one. The server has no way to tell the client what repos should be enabled in his opinion. And the client has no possibility to change the policy to always enable repos in services.
I'd recommend to add a new property to the repo definition in the repoindex.xml: enable="1". Repos tagged like this should be enabled (of course only in the opinion of the server).
When a service gets added on a client the service should get a new parameter: autoenable=<value> in its service file (zypper needs to support it).
The value might be one of: all = automatically enable all repos that the server has remote = automatically enable all repos that are tagged with enable="1" none = no automatic enabling - default (if missing), to be backward compatible
By this, the authority still remains on the client. The client can decide what policy he wants to use. And the change of the policy is per service, so changing the policy for one service does not change for all services.
This would be a nice feature for services as you could add one service that you trust (maybe you administer it yourself) and then forget about it, as the repos will always adapt automatically.
I had short conversations with Duncan MacVicar and Marcus Meissner about this topic today but now want to open it for a discussion. What do you think? Are there better ways to do this? Are there side-effects or security issues?
Ciao, Daniel
On 07/23/2009 06:55 PM, J. Daniel Schmidt wrote:
Hi,
I'd like to discuss a new feature for (NU) Services.
A service can contain multiple repos and they may change over time. All these changes are automatically apllied to the system during a refresh of the service.
But one thing is missing IMHO. All new repos always remain disabled and have to be enabled manually. In the registration process we therefore enable each repo one by one. The server has no way to tell the client what repos should be enabled in his opinion. And the client has no possibility to change the policy to always enable repos in services.
This is pretty easy to add.
I'd recommend to add a new property to the repo definition in the repoindex.xml: enable="1". Repos tagged like this should be enabled (of course only in the opinion of the server).
When a service gets added on a client the service should get a new parameter: autoenable=<value> in its service file (zypper needs to support it).
The value might be one of: all = automatically enable all repos that the server has remote = automatically enable all repos that are tagged with enable="1" none = no automatic enabling - default (if missing), to be backward compatible
Sounds good. I would just replace 'remote' with 'auto' (automatically, as directed by the repoindex) or 'tagged'.
By this, the authority still remains on the client. The client can decide what policy he wants to use. And the change of the policy is per service, so changing the policy for one service does not change for all services.
This would be a nice feature for services as you could add one service that you trust (maybe you administer it yourself) and then forget about it, as the repos will always adapt automatically.
I had short conversations with Duncan MacVicar and Marcus Meissner about this topic today but now want to open it for a discussion. What do you think? Are there better ways to do this? Are there side-effects or security issues?
To the point where an attacker hacks the repo index porovider site and actually returns a different set of repositories, the security should be equivalent to current solution AFAICS. Even then the user needs to confirm s/he trusts the newly added repo's GPG key (yup, users like to ignore such dialogs).
But, as you wrote, once you trust the RIS provider, you trust also the repos. Maybe we could require that the repoindex is signed by a gpg key as well as the repos(?). This could be a bit difficult to implement if the provider generates the repoindex dynamically, but doable.
On 10/01/2009 03:30 PM, Jano Kupec wrote:
On 07/23/2009 06:55 PM, J. Daniel Schmidt wrote:
Hi,
I'd like to discuss a new feature for (NU) Services.
A service can contain multiple repos and they may change over time. All these changes are automatically apllied to the system during a refresh of the service.
But one thing is missing IMHO. All new repos always remain disabled and have to be enabled manually. In the registration process we therefore enable each repo one by one. The server has no way to tell the client what repos should be enabled in his opinion. And the client has no possibility to change the policy to always enable repos in services.
This is pretty easy to add.
I'd recommend to add a new property to the repo definition in the repoindex.xml: enable="1". Repos tagged like this should be enabled (of course only in the opinion of the server).
When a service gets added on a client the service should get a new parameter: autoenable=<value> in its service file (zypper needs to support it).
The value might be one of: all = automatically enable all repos that the server has remote = automatically enable all repos that are tagged with enable="1" none = no automatic enabling - default (if missing), to be backward compatible
Sounds good. I would just replace 'remote' with 'auto' (automatically, as directed by the repoindex) or 'tagged'.
By this, the authority still remains on the client. The client can decide what policy he wants to use. And the change of the policy is per service, so changing the policy for one service does not change for all services.
This would be a nice feature for services as you could add one service that you trust (maybe you administer it yourself) and then forget about it, as the repos will always adapt automatically.
I had short conversations with Duncan MacVicar and Marcus Meissner about this topic today but now want to open it for a discussion. What do you think? Are there better ways to do this? Are there side-effects or security issues?
To the point where an attacker hacks the repo index porovider site and actually returns a different set of repositories, the security should be equivalent to current solution AFAICS. Even then the user needs to confirm s/he trusts the newly added repo's GPG key (yup, users like to ignore such dialogs).
But, as you wrote, once you trust the RIS provider, you trust also the repos. Maybe we could require that the repoindex is signed by a gpg key as well as the repos(?). This could be a bit difficult to implement if the provider generates the repoindex dynamically, but doable.
There are more people wanting this: http://lists.opensuse.org/opensuse-packaging/2010-09/msg00121.html
softwaremgmt@lists.opensuse.org
-
J. Daniel Schmidt -
Jano Kupec