Mailinglist Archive: opensuse-buildservice (311 mails)

< Previous Next >
Re: [opensuse-buildservice] Unique vendors per repository are a must and the current setup is a timebomb / security hole
  • From: Stephan Kleine <bitdealer@xxxxxxxxx>
  • Date: Thu, 26 Nov 2009 11:05:00 +0100
  • Message-id: <200911261105.00881.bitdealer@xxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
References