On Mon, Aug 27, 2012 at 10:38 AM, Jim Jagielski <[email protected]> wrote: > After this, please drop general@ > > On Aug 27, 2012, at 10:16 AM, Rob Weir <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] >
