Mailinglist Archive: opensuse-buildservice (314 mails)

< Previous Next >
Re: [opensuse-buildservice] Integrating packages into Factory
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Tue, 29 Jul 2008 19:35:53 +0200
  • Message-id: <200807291935.54040.adrian@xxxxxxx>
On Tuesday 29 July 2008 19:05:55 Archie Cobbs wrote:
On Tue, Jul 29, 2008 at 11:50 AM, Adrian Schröter <adrian@xxxxxxx> wrote:
So here's my suggestion. First, keep the three "levels of trust" we
have now: 1 = factory, 2 = established category projects like
network:telephony, Apache, etc., 3 = home:user projects.

Next, with each release of SUSE, create the normal SUSE distribution
using level 1 stuff, but also create a new "3rd party distribution"
containing the union of all level 2 projects, taken as a snapshot at
release time. The "3rd party distribution" could be shipped as a
separate set of ISO images and would also be hosted in a *single*
online repository (called e.g., "openSUSE 10.3 3rdParty").

This would have basically two effects:

1) The repository would cause plenty of conflicts, because we allow by
intention that packagers replace/update packages. It would cause a real
dependency hell when installing any package in YaST.

Yes, that is a potential problem. However, why should package X exist
in two different incarnations (not just _aggregate) in two different
projects (not counting home:user projects)? It seems like the
conflicts are caused by a separate underlying disorganization that
should be fixed and has nothing to do with how you split up repos.
Maybe I'm oversimplifying things?

_aggregate is just increasing problems for a number of reasons, I do want to
explain in detail this evening.

It is also the concept that we allow builds of the same package, for example
to change some configuration or to use newer/incompatible base libs. In this
case the resulting package is also incompatible.

2) everybody would be able to inject evil code to everybodys system.
(you do not even need to install a specific package, you would always
get the package with %post script sending your credit card credentials
to someone else). So no one should ever add this repo ever, simply
because it is a soo easy target that for sure plenty people will do it.

Seriously, I saw often enough code in configure scripts talk with online
server and sending private data that I will never install software which
is not trustable to some degree (or I have reviewed myself).

So... are you saying that projects like Apache and network:telephony
are not to be trusted? Then hmm, OBS just became a lot less useful to
the world.

I say that they are only trusted to that degree that you trust the people with
write access there and that you trust the upstream project (or trust that the
packagers have reviewed the sources).

Yes I agree there must be some kind of oversight to prevent evil %post
scripts. This is true of any open source project. Perhaps this is an
argument for setting up OSC commit mailing lists (like SVN commit
emails) for each OBS project, so other members of the project can
monitor changes... ?

Hermes is aimed to do that. Will be launched this or next week. (and you can
select there certain projects/packages for notifications. No one will be able
to read all changes).

In any case the trust question is an important one but is also a
separate one: if you can't trust Apache and network:telephony together
in one repository, then you can't trust them in two repositories
either. Orthogonal question.

Yes, but when you want to install package X from Apache, you need only to
bother about this project and not to check if you can trust also all people
and sources from network:telephony.

When you say merge all home: projects blindly, it is obvious from my POV that
we will either get daily attacks because it is so easy to infect plenty of
systems or we need to tell everbody that never ever you should add this repo.
So it becomes pointless from my POV.

So yes the trust equation needs to be figured out. But separate from
that, a single unified repository would be a lot more convenient,
trustworthy or not.

Seriously, I will refuse to host a repository on our servers where everybody
in the world can immediate infect a large number of our users at any time.

I think we would be also liable for such a setup.

First of all, we wanted to discuss what are the rules for Factory packages, so
this discussion is kind of off topic.

secondly, lets improve the behaviour to add repos and install software. It
solves a lot of problems. And makes actually also the package manager lots
faster when you add only a number of small repos instead of one large monster
repo.

bye
adrian

--

Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian@xxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups