Re: [opensuse-buildservice] Unique vendors per repository are a must and the current setup is a timebomb / security hole
On Thursday 26 November 2009 08:27:32 you wrote:
Am Donnerstag, 26. November 2009 08:09:27 schrieb Stephan Kleine:
On Thursday 26 November 2009 05:50:09 you wrote:
Am Donnerstag, 26. November 2009 03:53:32 schrieb Stephan Kleine:
...
Proposed solution:
1. Feel free to use the same key to sign different (sub)repositories (as it is now) if the "trustlevel" is the same.
2. Use _unique_ vendors per repository so one is able to say "I want PackageX only from RepositoryY and nowhere else." which is currently _not_ possible.
Vendor is saying "who" is publishing something. So it makes absolut no sense to have different vendors below home:adrianSuSE, because it is always me. (at least by default).
No. The pgp says who is publishing what. Still the stuff is spread over various subprojects (mostly) and I want to be in control in deciding what is installed from where.
E.g. I might want to have some stuff from home:adrian and some other stuff from home:adrian:svn-snapshots while not mixing them up.
yes, but adrian has decided not to support this (by not switching away from defaults for good reasons, details see below). What you want is a override over project owner opinion.
Well adrian knows how to use OBS while the rest of the world just creates packages and projects.
Now, as soon as I add home:adrian:svn-snapshots cause I want whatever app from there my stable stuff from home:adrian gets switched over because both repos use the same vendor.
Possible Implementation:
1. Use the pgp keys as you use them currently. 2. Assign an _unique_ vendor to every existing repository and generate unique vendors for all new repos.
Final conclusion:
1. I consider being able to say "I want PackageX only from RepositoryY and nowhere else." absolutely mandatory but this is currently _not_ possible with zypp.
2. This could easily be changed by using unique vendors per repository on OBS.
3. I honestly fail to see why you argue soo much against using unique vendors per repository.
So please either tell me a solution that solves the above described usecases or change the public OBS configuration so unique vendors per repository are used.
Your very special use case is to have multiple repos added with alternative packages added, but you want to keep older packages in some cases from some repos in some case.
I neither want older packages nor is it some special case IMHO.
All I want is a way that allows me to define to get package X only from repo Y and nowhere else.
Yes and this would be actually a feature request for your installer tool to support this.
With all due respect but that is somehow ridiculous. IMHO the whole purpose of a package manger is to install stuff while resolving dependencies. Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this. Or IOW how many people would consider it a "feature" that heir package management only installs stuff from the repo they originally added and nowhere else. I dare to claim that my assumption is shared by the majority and therefore it's not a feature but a bug of the current setup.
So, you want manual mix package versions and override package manage decisions. I can currently not imagine how this can be a valid usecase.
No. All I want to have is a way that allows me to say that a package sticks with the repository from which I installed it from. This neither involves manual changes, overriding package management decisions or whatever but merely ensuring that the package management doesn't bite me in the ass as soon as I don't look after every single package update.
It is overriding the project owner decisions.
No. I just want to install stuff from the repo I originally added and not from somewhere else.
And frankly, I can not image any project which I have, where I want to support this.
As said, there are exceptions like oss, oss-update, perhaps some KDE: and so on. Nevertheless those should be the _exception_ of the rule.
Just simple examples, I can imagine hat osc from openSUSE:Tools:Unstable works well well together with stuff from openSUSE:Tools. But that does not mean I want to support this for _all_ packages (and subpackages) in the entire project.
That's unrelated. The way I want it to have both repos have a different vendor. So, as soon as you switch some package from one repo to the other you have to agree on the vendor change for the package itself as well as for all its dependencies that can't be satisfied by the currently enabled repos.. Preventing any version fuckup is up to you by specifying proper versions but you would have to do that anyways once you move stuff from unstable to stable.
For example, this would mean that I would need to introduce a new package dependency when I move the runlevel script, in project openSUSE:Tools:Unstable for service X from subpackage A to B. And I would need to check these dependencies not only with all packages from this project, but also for openSUSE:Tools and :Devel.
No, why? Your "customers" are subscribed to unstable so, thanks to the "vendor stickiness" they will just get updated to the newer package on the next "zypper up". I honestly fail to see how that would be related to this topic.
I don't want to support this. And I think our defaults are good, since the reduce the number of possible combinations by default.
Totally understandable but this issue doesn't exist. Please read above.
If a project owner decides to support the mixing he is fine to do so and switch the vendor. But he may need to add quite some more dependencies and he need to debug way more combinations when people come to him
Probably. Point being currently I get randomly switched back and forth from one repo to the other if the containing versions screw me over. That's surely different to packages sticking to the repository they got installed from and therefore all dependencies being the versions that were specified in the installed rpm.
So, I think it is perfect that we reduce the wasted time in debugging obscur combinations, we never had in mind when we set up the project.
I totally agree, but, again, that does only happen if you allow packages to switch freely back and forth between repos you use. OTOH if a package just sticks with the repo it got installed from until you _intentionally_ switch it over to some other repo it should be a pretty clearly defined state. If it isn't you probably have to specify your dependencies more specifically.
It is of course a complete different think if a user should be able to override the project owner opinion. But that must be solved in the clients. And the user need to do a special action, so he is aware of what he is doing. (this is similar to install a package with --nodeps).
The project owner surely has an opinion and he can freely express his opinion by setting up the required packages & versions parameters in Requires: but I sure as hell expect the package management to be able to let me specify from which repo a package gets installed and _not_ to change this repository without manual intervention (e.g. package foo requires newer lib so switch the vendor please). If it can't satisfy a specified dependency it will ask and so I'm fine.
Yes, you could argue that there are alway dependencies missing when such a problem is happening. But frankly I do not think that we are able to maintain them and our spec files would look quite horrible over time.
No. Missing dependencies are resolved by the package management which _asks_ if it is ok to switch the vendor and _only_ does it on manual confirmation. There is _nothing_ you have to maintain for this except setting the compatible versions for some required library (which, as you probably know, isn't that much of a problem most of the times). So, to sum that up once again: I want a way that allows me to say to get PackageX only from RepoY and nowhere else without switching it to some other repo just cause it happens to get signed by the same pgp key. The possibility of packages getting switched to another repo without confirmation is IMHO a security hole and the hole discussion weren't necessary if you would just use unqiue vendors (_not_ pgp keys) per repo. And, considering that it were still possible for repos to use the same vendor _if choosen on purpose_ instead of by default I honestly fail to see one single reason that makes this behavior impossible or inconvenient. best, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Stephan Kleine wrote:
I want a way that allows me to say to get PackageX only from RepoY and nowhere else without switching it to some other repo just cause it happens to get signed by the same pgp key.
The possibility of packages getting switched to another repo without confirmation is IMHO a security hole and the hole discussion weren't necessary if you would just use unqiue vendors (_not_ pgp keys) per repo.
And, considering that it were still possible for repos to use the same vendor _if choosen on purpose_ instead of by default I honestly fail to see one single reason that makes this behavior impossible or inconvenient.
I guess the bug or missing feature you are trying to report is that all subprojects of e.g. home:$USER have the same vendor. There's an API call to change the GPG key of subprojects but none to change the vendor. Furthermore you are suggesting to change the default of having the same vendor for all subprojects to having separate vendors for all subprojects. Correct? I don't get the part about security though. The repo trust setting is all or nothing. You can't only trust individual packages from a repo. Sure vendor stickyness prevents exchanging already installed packages but that's not really a security feature. An enabled, yet untrusted repo could still install arbitrary packages via e.g. Enhances tags. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Nov 26, 2009 at 11:05:00AM +0100, Stephan Kleine wrote:
Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this.
AFAIK zypp is the only software manager that looks at the vendor to prevent repo switching. All other managers smart, yum, apt...) only have repo priorities. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-2/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 26 November 2009, 17:21:53 Michael Schroeder wrote:
On Thu, Nov 26, 2009 at 11:05:00AM +0100, Stephan Kleine wrote:
Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this.
AFAIK zypp is the only software manager that looks at the vendor to prevent repo switching. All other managers smart, yum, apt...) only have repo priorities.
but yum provides exclude patterns, which I do miss from time to time. Pete -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Nov 26, 2009 at 06:06:47PM +0100, Hans-Peter Jansen wrote:
On Thursday 26 November 2009, 17:21:53 Michael Schroeder wrote:
On Thu, Nov 26, 2009 at 11:05:00AM +0100, Stephan Kleine wrote:
Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this.
AFAIK zypp is the only software manager that looks at the vendor to prevent repo switching. All other managers smart, yum, apt...) only have repo priorities.
but yum provides exclude patterns, which I do miss from time to time.
Just curious: how are they different from locks? Thanks, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2009-11-26 18:37:46 +0100, Michael Schroeder wrote:
On Thu, Nov 26, 2009 at 06:06:47PM +0100, Hans-Peter Jansen wrote:
On Thursday 26 November 2009, 17:21:53 Michael Schroeder wrote:
On Thu, Nov 26, 2009 at 11:05:00AM +0100, Stephan Kleine wrote:
Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this.
AFAIK zypp is the only software manager that looks at the vendor to prevent repo switching. All other managers smart, yum, apt...) only have repo priorities.
but yum provides exclude patterns, which I do miss from time to time.
Just curious: how are they different from locks?
it will update the packages from that repos. but only those packages. yum also an option to limit a repository to only a subset of packages. so i could e.g. have openSUSE:Tools limited to osc because i want to keep my old obs-server packages. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Nov 26, 2009 at 06:41:33PM +0100, Marcus Rueckert wrote:
so i could e.g. have openSUSE:Tools limited to osc because i want to keep my old obs-server packages.
Locks in zypp work the same way. I'm not sure if you can specify "lock everything from that repo but osc", though. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 26 November 2009, 18:37:46 Michael Schroeder wrote:
On Thu, Nov 26, 2009 at 06:06:47PM +0100, Hans-Peter Jansen wrote:
On Thursday 26 November 2009, 17:21:53 Michael Schroeder wrote:
On Thu, Nov 26, 2009 at 11:05:00AM +0100, Stephan Kleine wrote:
Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this.
AFAIK zypp is the only software manager that looks at the vendor to prevent repo switching. All other managers smart, yum, apt...) only have repo priorities.
but yum provides exclude patterns, which I do miss from time to time.
Just curious: how are they different from locks?
Hrmpf. Apart from the fact, that yum is missing an UI, they pretty much resemble the same functionality ;-). Thanks for bringing this to my attention - I didn't notice before, silly me. Thanks, Pete -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Donnerstag, 26. November 2009 11:05:00 schrieb Stephan Kleine:
On Thursday 26 November 2009 08:27:32 you wrote:
Am Donnerstag, 26. November 2009 08:09:27 schrieb Stephan Kleine:
On Thursday 26 November 2009 05:50:09 you wrote:
Am Donnerstag, 26. November 2009 03:53:32 schrieb Stephan Kleine: ... Your very special use case is to have multiple repos added with alternative packages added, but you want to keep older packages in some cases from some repos in some case.
I neither want older packages nor is it some special case IMHO.
All I want is a way that allows me to define to get package X only from repo Y and nowhere else.
Yes and this would be actually a feature request for your installer tool to support this.
With all due respect but that is somehow ridiculous.
IMHO the whole purpose of a package manger is to install stuff while resolving dependencies.
Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this.
Or IOW how many people would consider it a "feature" that heir package management only installs stuff from the repo they originally added and nowhere else.
I dare to claim that my assumption is shared by the majority and therefore it's not a feature but a bug of the current setup.
The problem here is that our dependencies are usually not enough to keep the package manager deciding this. A usual packager (like me) is not thinking about the dependencies to this degree. For example, when I move a init script from obs-server to obs-api, this would mean that I would have to add new dependincies to the packages, which protects the user to mix obs-api from openSUSE:Tools:Unstable with the obs-server from openSUSE:Tools for example. So this mean, a packager would always need to rethink all combinations and can't rely on the fact to ask the users to run "zypper update" or whatever. Also our spec files would look quite messy with all this needed Provides/Requires of the time. So, I think our defaults are very well choosen. By default neither the packager nor the user needs to think about these kinds of problems. And when the packager/project owner wants it, he needs to set the vendor in the project config and he need to rethink all possible combinations of his packages with the other project(s).
So, you want manual mix package versions and override package manage decisions. I can currently not imagine how this can be a valid usecase.
No. All I want to have is a way that allows me to say that a package sticks with the repository from which I installed it from. This neither involves manual changes, overriding package management decisions or whatever but merely ensuring that the package management doesn't bite me in the ass as soon as I don't look after every single package update.
It is overriding the project owner decisions.
No. I just want to install stuff from the repo I originally added and not from somewhere else.
yes, but you are anyway overriding the defaults ;) ...
So, to sum that up once again:
I want a way that allows me to say to get PackageX only from RepoY and nowhere else without switching it to some other repo just cause it happens to get signed by the same pgp key.
okay, but you should know that you override the project owner defaults. Therefore such a feature belongs to the client (and I think it should warn to use it). At least the user needs to be aware of the fact that is doing something special. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (6)
-
Adrian Schröter -
Hans-Peter Jansen -
Ludwig Nussel -
Marcus Rueckert -
Michael Schroeder -
Stephan Kleine