[indiana-discuss] [sw-porters-discuss] contrib and pending repo processes

[Guido Berhoerster]

* Shawn Walker <swalker at opensolaris.org> [2008-11-13 17:23]:
> John Sonnenschein wrote:
>  > I'd just like to throw my thoughts in to the ring for this, but the 
> genunix page lists "Binary only packages allowed" as a goal..
>  >
>  > That is, in my opinion, a /TERRIBLE/ idea, and likely to get people 
> in more trouble and reflect worse on (open)solaris than just simply not 
> having the packages at all. Any sort of poor software, either through 
> malice (trojans) or incompetence (running being heavily dependent on the 
> builder's specific system setup) can be sneaked in with absolutely no 
> oversight.
> 
> That's assuming that the packages don't:
> 
> 1) receive any vetting at all

So how does the reviewer make sure (with reasonable effort) that
the submitter has not injected malicious code in the binary package
he submitted?

> 2) that all contributed packages will have source code legally available

That would probably be the majority of all cases as the number of
redistributable binary software for OpenSolaris is rather small
compared to the huge number of FOSS which could be ported.
Besides, closed source packages need not be excluded if packages
are built with standardized recipes on os.o. pkgbuild recipes can
handle them. However I _can choose_ not to install them.

>  > Binary blobs are fine, but they ought to be the exception, and ought 
> to require human intervention that they are trusted enough to deliver 
> binary ( I'm sure if adobe came up and wanted to dump stuff in contrib/ 
> that they'd be greenlit. )
> 
> That's the point.  For example, if someone wants to contribute a driver 
> package, they should be able to do so even if they can't release the source.
> 
> Obviously, binaries require extra vetting (as much as possible), but 
> they should in no way be prevented from being contributed.

Having a build system does not preclude that, see above. Besides,
if you read the original poster, he didn't talk about excluding
closed-source software.

> Source code != trust; look at the fairly recent debian incident with one 

That's a null argument, I could argue that this was found because
of the source code and build recipe was open and available.
Generalizing an incident like this is absurd.

> of their encryption related packages.  Just because you automate a build 
> does not make the software trustworthy.

No, but it eleminates one source of risk, that is the submitter.
I still have to trust the author and the distributor (the
OpenSolaris project). And if it is OSS the risk of malicious code
in the is lower as there is a bigger chance of people discovering
it, furthermore I have at least the theoretical possibility to
audit the source myself if I want to.

-- 
Guido Berhoerster