incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Mon, 27 Aug 2012 15:21:24 GMT
On Mon, Aug 27, 2012 at 10:38 AM, Jim Jagielski <jim@jagunet.com> wrote:
> After this, please drop general@
>
> On Aug 27, 2012, at 10:16 AM, Rob Weir <robweir@apache.org> wrote:
>
>>>
>>> A signature does 2 things:
>>>
>>>  1. Ensures that no bits have been changed
>>>  2. That the bits come from a known (and trusted) entity.
>>>
>>
>> Almost.  It doesn't guarantee trust.
>
> Sure it does. If something is signed by Bill or Ross, etc I
> trust that it came from them. Anything else is tangential to
> what a signature provides.
>

Identity != Trust.

Identity + Reputation == Trust.

The signature only guarantees identity.

>
>>  CA's don't require any specific
>> level of software quality assurance before they issue a certificate.
>> Any trust is implied by association with the identity of the signer.
>> So it is a brand association.  This is similar to the association that
>> comes with association with a project's release announcement, or from
>> distribution via Apache mirrors, or links from Apache websites.  These
>> all imply -- in one degree or another -- an association with Apache,
>> and the trust that flows from that.
>>
>> But what code signing does do is help protect ASF reputation.
>
> Huh? All it says is that these bits originated from this entity.
> If you trust that entity, then you can trust those bits. The
> "reputation" stuff is part of the release process, not the signing
> process.
>

End users know absolutely nothing about Apache release process.  They
know brands.  So their view of trust is brand-based, not informed by
the technical minutia of Apache release process.  Of course, given a
suboptimal process, if bad releases result from this, then the brand
reputation will suffer over time.


>>  By
>> having the binaries signed we can distance ourselves from those who
>> distribute versions of AOO with virus and malware attached.  Again,
>> this is something you probably don't see in the server world, but it
>> is quite common with popular end-user open source software.
>
> Again... Huh??? WTF do you think we sign code, esp stuff destined for
> the server? So the end-user is ensured that the bits came from a
> trusted source.
>

End-users ascribe trust to brands.  With education they might learn to
ascribe trust to validated/signed binaries based on the identity of
the signer.  But this has not been a great success in the web world,
with SSL certificates, etc.  Phishing is an industry now.

This is why the OS vendors are now close to mandating signed code.
End-users cannot be trusted to verify trust on their own.   If you
want to wear a tin foil hat, you can also see this probably leading to
the U.S. Government holding a "kill switch" on software, via
certification revocations, based on any malware that comes out with a
signature.

> "Oh look, I found the Apache 2.4.3 source tarball on some warez site
> signed by 'Ben Dover' who has an unknown key. Looks good to me. Think
> I'll install it on my website"
>

Today it is more likely that they see a binary called "OpenOffice",
with or without the Apache name, and without verifying the signature,
the user just installs it.  That is the sad state of end-user security
awareness today.

This is not going to get better by technology alone.  It will require
user education as well.

>>
>> So trust (reputation) is important.  But we're already seeing that
>> trust and reputation can be hurt by lack of code signing.
>
> We. Sign. Code.
>

AOO does not currently do this, at least not in a form that end users
can verify with their tool and skill set.  But we're working in it.

> So I'm again unsure what the issue is... it sounds like we're talking
> in circles. Can we have a real-world example? From my understanding,
> Apple's App Store is likely the most onerous situation. So what, right
> now, is "broken" with the AOO release process as related to the App
> Store and what would need to be done to "fix" it?
>

Honestly?  I never said there was an issue.  I merely forwarded, as
required, the community graduation vote post to the IPMC.  But since I
did that I've heard no end of criticisms. A quick summary is:

1) The AOO 3.4.1 release ballot is defective because it refers to
binaries and Apache does not release binaries

2) Something (unspecified, though I asked on numerous occasions) about
the AOO binaries does not confirm with unwritten (though I asked on
numerous occasions) ASF policy on binaries.

3) The AOO podling should not graduate because it has an ungodly
emphasis on binaries

4) The AOO podling has some unresolved issues regarding their binaries
that they need to resolve before graduation

5) The AOO podling should bring up some (unstated, though I asked on
numerous occasions) questions to legal-discuss

6) 5) The AOO podling should bring up some (unstated, though I asked
on numerous occasions) questions to Infra

7) The AOO podling is going to ignore ASF policy and do whatever it
wants when it graduates.

8) Inchoate FUD about liability and indemnification

9) Then it morphed into a code signing discussion.  I'm not sure how
that happened.

10) Finally, in a bizarre fashion,  we were then accused of not
understanding how the ASF works or decide issues.  This is bizarre
since we never raised the code signing question on general.i.a.o.
We've been working that question through infra-dev for over a month
now.  The fact that approximately equal numbers of IPMC members are
shouting that there is no problem while another group is asking
questions, does not help.  But I think that is an IPMC
disfunctionality, not an AOO podling concern.

So what's the issue?  Honestly, the meta issue is that ASF policy in
this area is not written down.  You would not have 3-4 IPMC members
asking for clarifications, suggesting various opposing
interpretations, if this basic ASF policy concern was documented.
Having still other IPMC members shouting that it is clear and obvious
what the policy is does not help, of course.  What is clear and
unambiguous is judged from the perspective of the listener, not the
speaker.


-Rob

> If that's the wrong example, I'll take any other one.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Mime
View raw message