[Cryptography] GCC bug 30475 (was Re: bounded pointers in C)

[ianG]

On 21/04/2014 03:05 am, Peter Gutmann wrote:
> Arnold Reinhold <agr at me.com> writes:
> 
>> In my opinion, the GNU Project and the developers of GCC would be well
>> advised to get legal advice on their responsibilities and liabilities in this
>> matter.
> 
> They have no responsibilities to anyone, and that's the problem.


This is the nature of OSS and also many commercial projects: limit all
responsibility to zero.  We write the EULAs and similar to remove all
responsibility in all possible ways that we can think of.  (It is taken
to a high art in the PKI industry which layers and structures itself to
ensure complete firewalling of legal responsibilities, indeed the
structure of CAs can only be understood with this in mind.)

In some theoretical generality, there appear to be two solutions with
stability:

     nobody's responsible for anything,

OR

     everyone's responsible generally.

In CAcert, we choose the latter.  Everyone's responsible, even the
developers.  They might not be responsible to you for your particular
itch, but they are in general responsible, they have to accept outside
intervention to decide what the responsibilities are in any particular
dispute. (c.f., arbitration).  With some limitations, it's not perfect,
but you can put a lot of weight on it and it will still carry on.


> Being
> completely disconnected from any responsibility to their users, they have the
> liberty to sit there pontificating about hair-splitting interpretations of the
> standard rather than Doing the Right Thing by users.  This is a serious
> problem with many OSS projects which are driven by the whims of the owners
> rather than real-world considerations


Yes.  I think some of the Linux communities might have adopted
arbitration as a way to deal with disputes but I've not heard of them
taking it to the aggressive level of CAcert.


> (it's also a benefit in some cases, so
> it cuts both ways).


right.  Many smaller OSS projects are powered by developers who are just
happy doing their thing, in a black box.  This is a good thing if it
gets code written that otherwise would not.  It is often necessary to
spark the original project.

But pretty soon the lack of responsibility leads to deadlock.  You can
see this in projects that reach a small number of core developers and
don't grow beyond there;  the reason is typically that the power is
concentrated and the incumbents don't know how to move beyond that
point, don't even know they are deadlocked at that point.

Once responsibility enters, it needs a different sort of mindset to have
fun in that arrangement.  Resources shift over to a new style, which
might take years.

(Somewhere there is a description of the 6 stages of evolution of a
growing OSS project...)


> [Long philosophising discussion about requirements-driven development and
> customer responsiveness snipped since it's really only tangentially security-
> relevant].


[ How can this be?  Security without customers?  What is that? :]




iang