On Tuesday 29 July 2008 19:05:55 Archie Cobbs wrote:
On Tue, Jul 29, 2008 at 11:50 AM, Adrian Schröter
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@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org