[opensuse-buildservice] Unique vendors per repository are a must and the current setup is a timebomb / security hole
Hi folks. In https://bugzilla.novell.com/show_bug.cgi?id=503276 Michael asked me to take my issue to the mailing list so I'm gonna present my case here: My problem is that currently a repositories' "vendor" apparently is bound to its pgp key which IMHO is a timebomb cause of zypp's "vendor stickiness" cause it does currently consider every repository that gets signed with the same key as the same "vendor". Now consider the following usecase: 1. There are repos A:Foo and A:Bar. 2. Since A:Foo & A:Bar use the same pgp key they also use the same vendor. 3. A:Foo contains Package1 and unstable svn snapshots of Package2 4. A:Bar contains Package2 and unstable svn snapshots of Package1 Now I want to install Package1 from A:Foo and Package2 from A:Bar and I don't want to install their respective svn copies. So I have to specify for every package which repository to use but this wont work cause both use the same vendor cause they use the same pgp key. It was suggested to use repository priorities but this doesn't work either in that case because the stable / unstable (svn) stuff is in the other repo. That theoretical setting aside it also makes using OBS with zypp kinda russian roulette cause there's no way to foresee when someone will publish a newer binary in some sub repository (that uses the same vendor cause it gets signed by the same pgp key) and then gets me updated to that newer version in a different repo _which I do not want_! So this also introduces a pretty severe security hole IMHO. IOW: I consider it absolutely mandatory to be able to say I want to get PackageX _only_ from RepositoryY and _nowhere_ else which currently is _not_ possible. Other thoughts: 1. I agree that using the same pgp key to sign different (sub)repositories makes sense cause the "trustlevel" is the same. 2. I totally disagree that linking the signing pgp key to the repositories vendor is a good idea cause the trustlevel (pgp key) simply is a different thing than the state of the repo from which I would like to get a certain package. 3. Manually setting the vendor in the prjconf is no option cause I'm not able to do that on the public OBS and there are far too many repos to write everyone an email and to ask him / her to set an unique vendor. 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. 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. best, Stephan. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Donnerstag, 26. November 2009 03:53:32 schrieb Stephan Kleine:
Hi folks.
In https://bugzilla.novell.com/show_bug.cgi?id=503276 Michael asked me to take my issue to the mailing list so I'm gonna present my case here:
My problem is that currently a repositories' "vendor" apparently is bound to its pgp key which IMHO is a timebomb cause of zypp's "vendor stickiness" cause it does currently consider every repository that gets signed with the same key as the same "vendor".
This is not true, because the upper level project owner has setup it in this way and he has anyway access rights to all others below. So this represents the real access rights. And when this person (group) decides that further people get write access to some packages or projects below, it is his decision.
Now consider the following usecase:
1. There are repos A:Foo and A:Bar. 2. Since A:Foo & A:Bar use the same pgp key they also use the same vendor. 3. A:Foo contains Package1 and unstable svn snapshots of Package2 4. A:Bar contains Package2 and unstable svn snapshots of Package1
Now I want to install Package1 from A:Foo and Package2 from A:Bar and I don't want to install their respective svn copies.
So I have to specify for every package which repository to use but this wont work cause both use the same vendor cause they use the same pgp key.
It was suggested to use repository priorities but this doesn't work either in that case because the stable / unstable (svn) stuff is in the other repo.
That theoretical setting aside it also makes using OBS with zypp kinda russian roulette cause there's no way to foresee when someone will publish a newer binary in some sub repository (that uses the same vendor cause it gets signed by the same pgp key) and then gets me updated to that newer version in a different repo _which I do not want_!
So this also introduces a pretty severe security hole IMHO.
No, it was decided by the project owners to setup it in this way. You may not like it, but this not a security whole. You need anyway to trust the people when you add the repo. And we want to allow that eG. all projects below home:adrianSuSE have the same key. The gpg key is representing the trust level and this is there always the same, because it is done by the same person. Vendor is following the gpg key by default, but can be changed in case, if you want to overwrite it as project owner.
IOW: I consider it absolutely mandatory to be able to say I want to get PackageX _only_ from RepositoryY and _nowhere_ else which currently is _not_ possible.
No, this is only wanted in one usecase. And the project owners are free to set it up in this way. But there definitive use cases, as described where we do not want this.
Other thoughts:
1. I agree that using the same pgp key to sign different (sub)repositories makes sense cause the "trustlevel" is the same.
2. I totally disagree that linking the signing pgp key to the repositories vendor is a good idea cause the trustlevel (pgp key) simply is a different thing than the state of the repo from which I would like to get a certain package.
3. Manually setting the vendor in the prjconf is no option cause I'm not able to do that on the public OBS and there are far too many repos to write everyone an email and to ask him / her to set an unique vendor.
You are able to do it, when you have write access to project. It is just editing the project config.
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).
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. So, you want manual mix package versions and override package manage decisions. I can currently not imagine how this can be a valid usecase. 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
Am Donnerstag, 26. November 2009 05:50:09 schrieb Adrian Schröter:
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).
Just to add this, if we enforce different vendors for each project, setups like the "released packages from project X" and updates from project Y are not possible anymore (or at least not without OBS administrator overwrite rights). This is used for example in openSUSE:11.2 and openSUSE:11.2:Update. Other examples are openSUSE:Tools which contain the stable packages and openSUSE:Tools:Unstable which just contain some replacements for testing. If you would manually override only to use some packages of :Unstable but ignore some others this is not a use case which is intended by us project owners. by 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 (2)
-
Adrian Schröter
-
Stephan Kleine