date:20121010

Can you clarify? I understand that being able to speak to someone face to
face, and seeing their mannerisms and expressions, allows you to understand
them better. Some deep rooted human thing. But how does this impact
security or trust, in the context of key signing?

On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 If you know the person, it adds something that you don't get.

 On Tue, Oct 9, 2012 at 3:40 PM, Noah Slater nsla...@tumbolia.org wrote:

  What, precisely, does a video call actually provide?
 
  The point of meeting in person is to verify photo IDs. Just talking to
  somebody with a face doesn't prove anybody. I am fairly certain that YOU
  have a face, and I have never even seen it. If all you're doing is
 having a
  chit chat and swapping key IDs, you may as well do that via IRC or email.
  Doing it with a video adds nothing, as far as I can see. It certainly
 does
  not establish identity. Beyond a person who says their name is Bob has a
  face which looks like [this]. Is that useful? I don't think so.
 
  On Tue, Oct 9, 2012 at 11:01 PM, Marvin Humphrey mar...@rectangular.com
  wrote:
 
   On Mon, Oct 8, 2012 at 2:24 PM, Noah Slater nsla...@tumbolia.org
  wrote:
1. The key owner convinces the signer that the identity in the UID
 is
indeed their own identity by whatever evidence the signer is willing
  to
accept as convincing. Usually this means the key owner must present
 a
government issued ID with a picture and information that match up
 with
   the
key owner. (Some signers know that government issued ID's are easily
   forged
and that the trustability of the issuing authorities is often
 suspect
   and
so they may require additional and/or alternative evidence of
  identity).
   
2. The key owner verifies that the fingerprint and the length of the
  key
about to be signed is indeed their own.
   
How would you do this via Skype?
  
   Here's a rough draft for a protocol:
  
   Several podling committers convene in a Google Plus Hangout with
  Hangouts
   On
   Air enabled (so that the video gets archived to YouTube).
  
   Everyone states their name and what they had for lunch, then reads
 their
   public key fingerprint aloud.  The lunch items are combined into a key
   phrase.
   Participants then commit to a text file under ASF version control,
   contributing a few lines containing their name, their public key
   fingerprint
   and the key phrase -- linking together face and voice, public key
   fingerprint,
   ASF credentials and by extension, an iCLA.
  
   Optionally, the project is then discussed by the participants for some
   arbitrary length of time; the discussion of shared experience adds
  another
   layer of confidence that participants are who they say they are.
  
   Physical IDs are *not* shown during this session because the video is
 to
  be
   archived in a public location, but participants are encouraged to
 request
   such
   ids via private channels later.
  
   After the session ends, the archival video link is submitted to the
   podling's
   dev list, giving people the opportunity to initiate contact via email,
   phone
   or other channels with the committers in question -- or better yet
 their
   associates and colleagues, pointing to the video link and requesting
   confirmation of identity.
  
   Once a potential key-signer believes that a high degree of certainty
 has
   been
   established for a given candidate (it may make sense to codify some
 best
   practice guidelines), they sign the key and report to the dev list,
   documenting both what key was signed and what criteria they used when
   deciding
   to sign.
  
   ...
  
   While this protocol does not rely heavily on validating
 government-issued
   IDs,
   the Debian guidelines quoted above point out that some people object to
   giving
   such IDs too much creedence:
  
   (Some signers know that government issued ID's are easily forged
 and
   that
   the trustability of the issuing authorities is often suspect and so
   they
   may require additional and/or alternative evidence of identity).
  
   Instead, it relies on a layered approach a la multi-factor
  authentication.
  
If we don't take this seriously, how can we expect other people to
 take
   our
keys seriously?
  
   Since the Incubator PMC consistently approves releases signed by keys
  which
   are not connected to the web of trust, apparently we don't take the web
  of
   trust very seriously right now.  ;)
  
   But seriously...
  
   I interpret take this seriously to mean that before signing the key,
 it
   is
   important to...
  
   1.  Establish the identity of the key owner to a high degree of
  certainty.
   2.  Establish the link between the key and the key owner to a high
 degree
   of
   certainty.
  
   The point is that the degree of certainty is independent of the means
  used
   to
   obtain that certainty -- and the GnuPG

Re: key signing

2012-10-10 Thread Benson Margulies

A different angle.

Noah asks me to sign his key.

Noah tells me that he's committed it to KEYS for CloudStack in svn
revision 314159.

I examine that revision and see that it was made by, indeed, noah's
Apache ID, which is associated with a particular email address.

I send email to secretary@, asking Can you confirm that
nsla...@apache.org corresponds to a CLA signed by a person named Noah
Slater?

The secretary says yes.

I then feel that it's perfectly reasonable to sign a key that has two
things in it: the name Noah Slater and nsla...@apache.org, because if
this process doesn't verify an adequate association, then no one can
trust the Apache IP process, either, and which has the same signature
as the one in SVN.

What am I missing here that would be improved by an in-person
examination of his, oh, passport? A risk of some baroque MITM attack
on Apache's svn server?

It seems to me that this highlights a global issue with the WoT: how
can I know the standards and level of care of every link in a chain of
trust from me to some other person?

None of this, of course, changes my concern that the average Apache
user isn't connected, but if the argument is persuasive it should
unleash a positive avalanche of key signing.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Nick Kew


On 10 Oct 2012, at 11:25, Benson Margulies wrote:

 I then feel that it's perfectly reasonable to sign a key that has two
 things in it: the name Noah Slater and nsla...@apache.org, because if
 this process doesn't verify an adequate association, then no one can
 trust the Apache IP process, either, and which has the same signature
 as the one in SVN.

The apache process is satisfied with his identity.  The apache process
says so by publishing the key under his name at apache.org, thus
establishing a certain level of trust.

That most certainly doesn't mean I should sign the key: for me to do
so based on hearsay (my own trust not in his key but in the apache
process) just muddies the waters.

The missing link is my ability to formalise my WoT level of trust
(whatever it might be) in the apache process by signing a key
labelled something like ASF committer enrolment process which
in turn automatically signs everyone's keys.  Were it not for the risk 
of rather serious misunderstanding, I should advocate such a key.

-- 
Nick Kew

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Benson Margulies

On Wed, Oct 10, 2012 at 6:52 AM, Nick Kew n...@apache.org wrote:

 On 10 Oct 2012, at 11:25, Benson Margulies wrote:

 I then feel that it's perfectly reasonable to sign a key that has two
 things in it: the name Noah Slater and nsla...@apache.org, because if
 this process doesn't verify an adequate association, then no one can
 trust the Apache IP process, either, and which has the same signature
 as the one in SVN.

 The apache process is satisfied with his identity.  The apache process
 says so by publishing the key under his name at apache.org, thus
 establishing a certain level of trust.

 That most certainly doesn't mean I should sign the key: for me to do
 so based on hearsay (my own trust not in his key but in the apache
 process) just muddies the waters.


Nick: On the one hand, how is trusting the Apache process better or
worse than trusting the State of Massachusetts? Both offer an
assertion of a relationship between someone and a legal identity. In
the state of MA case, I'm matching a face to a piece of (forgeable)
plastic. In the Apache case, I'm matching an email to the Apache
process. In both cases, I could be the subject of a fraud: someone I
'know' via mailing list interactions shows up in person, shows me a
driver's license, and satisfies me that he or she is the same person I
'know' online. Enter the mole.

If the answer to this is that WoT is supposed to be based on some
level of 'real personal trust' (the opposite, after a fashion, of a
'Facebook Friend'), then I shouldn't sign keys at signing parties,
since there's just about no one at Apache whom I know well enough to
meet the standard. And I feel reinforced in my original urge to write
web pages around here that put the Apache process above the WoT.
Ironically, I could argue that we'd be better-served with X.509 certs.
An Apache CA could be programmed to issue a cert to each committer.
Users would just verify the source CA, and we'd accomplish the goal of
giving users assurance.



 The missing link is my ability to formalise my WoT level of trust
 (whatever it might be) in the apache process by signing a key
 labelled something like ASF committer enrolment process which
 in turn automatically signs everyone's keys.  Were it not for the risk
 of rather serious misunderstanding, I should advocate such a key.

 --
 Nick Kew

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Shane Curcuru


Comments:

- For many people, ensuring that the human who holds a specific key is 
the same one who has been using the j...@doe.foo email address and the 
john...@apache.org SVN/GIT account over a period of time is what is most 
important.  Less important is ensuring that that human's legal name is 
John Doe.


I.e. what is often viewed as more important is the tie between a 
person's consistent past actions and their key, rather than a tie 
between their key and the name they are legally known as in some 
jurisdiction.


Especially on the internet, it's hard to know if someone else is a dog 
or not.  But it is possible to see a consistent pattern of activity over 
time that is directly associated with an Apache ID and email addresses.


- The ASF's tie of legal identity to a committer ID and the Commonwealth 
of Massachusetts' (or other legal entities) tie of identity to a drivers 
license are very different things, both in terms of difficulty to forge, 
consequences of fraud, and purpose for being.


In most cases, forging country identity cards is a crime, and actually 
takes some work.  Forging identity on the Apache iCLA is merely a matter 
of an email address and a signature.


More importantly, country identity cards have multiple reasons for 
(attempting to be) secure and reliable.  The iCLA is primarily about 
ensuring that an IP that iCLA's signer grants to us is actually 
license-able under the AL.  While we certainly hope that our 
contributors will be well behaved, honest, and secure in their work 
here, what's fundamental for each iCLA signer is that the ASF has the 
rights to ship their contributions in our products.


- The WoT doesn't scale to normal end users.  Remember, the majority of 
them have never been on the dev@ list - they just want to run our 
software in their enterprise.  I dunno what to do about that, but it 
would be useful if we could at least explain what the WoT and signing 
releases does show to our users.



- Shane


On 10/10/2012 7:20 AM, Benson Margulies wrote:

On Wed, Oct 10, 2012 at 6:52 AM, Nick Kew n...@apache.org wrote:


On 10 Oct 2012, at 11:25, Benson Margulies wrote:


I then feel that it's perfectly reasonable to sign a key that has two
things in it: the name Noah Slater and nsla...@apache.org, because if
this process doesn't verify an adequate association, then no one can
trust the Apache IP process, either, and which has the same signature
as the one in SVN.


The apache process is satisfied with his identity.  The apache process
says so by publishing the key under his name at apache.org, thus
establishing a certain level of trust.

That most certainly doesn't mean I should sign the key: for me to do
so based on hearsay (my own trust not in his key but in the apache
process) just muddies the waters.



Nick: On the one hand, how is trusting the Apache process better or
worse than trusting the State of Massachusetts? Both offer an
assertion of a relationship between someone and a legal identity. In
the state of MA case, I'm matching a face to a piece of (forgeable)
plastic. In the Apache case, I'm matching an email to the Apache
process. In both cases, I could be the subject of a fraud: someone I
'know' via mailing list interactions shows up in person, shows me a
driver's license, and satisfies me that he or she is the same person I
'know' online. Enter the mole.

If the answer to this is that WoT is supposed to be based on some
level of 'real personal trust' (the opposite, after a fashion, of a
'Facebook Friend'), then I shouldn't sign keys at signing parties,
since there's just about no one at Apache whom I know well enough to
meet the standard. And I feel reinforced in my original urge to write
web pages around here that put the Apache process above the WoT.
Ironically, I could argue that we'd be better-served with X.509 certs.
An Apache CA could be programmed to issue a cert to each committer.
Users would just verify the source CA, and we'd accomplish the goal of
giving users assurance.




The missing link is my ability to formalise my WoT level of trust
(whatever it might be) in the apache process by signing a key
labelled something like ASF committer enrolment process which
in turn automatically signs everyone's keys.  Were it not for the risk
of rather serious misunderstanding, I should advocate such a key.

--
Nick Kew

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing - trust path check

2012-10-10 Thread Shane Curcuru

Anyone interested in details of PGP signing and tracing trust paths at 
the ASF should say thank you to long-time member henkp who has done a 
ton of work documenting and verifying release signing and keys:


  https://people.apache.org/~henkp/trust/

- Shane

On 10/8/2012 6:37 PM, Noah Slater wrote:

Found one... Just poking around manually...

J. Daniel Kulp dk...@apache.org
http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x858FC4C4F43856A3

Signed by Carsten Ziegeler cziege...@apache.org
http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x132E49D4E41EDC7E

Signed by Marcus Crafter craft...@debian.org
http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x394D2FE3C4C57B42

And all Debian folk are connected, as per my pervious email. :)

There should be a tool for this!

On Mon, Oct 8, 2012 at 11:23 PM, Benson Margulies bimargul...@gmail.comwrote:


Let's try a little statistically-invalid experiment of sample size
one. The last time I had a key signed at Apache, it was by Dan Kulp.
Now, pretend that you are a suspicious user of one of the many Maven
plugins releases that I RM. Can you reach Dan from yourself in the
web? Is there anyone you, personally, trust who starts a chain that
leads to him?

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Ted Dunning



Sent from my iPhone

On Oct 10, 2012, at 2:47 AM, Noah Slater nsla...@tumbolia.org wrote:

 Can you clarify? I understand that being able to speak to someone face to
 face, and seeing their mannerisms and expressions, allows you to understand
 them better. Some deep rooted human thing. But how does this impact
 security or trust, in the context of key signing?

I have friends who live far away.  I know them well.  I don't know their key 
fingerprint.  

If we send emails or if we text back and forth I  not clear that it is them.  
If I have a video conference and the hold up the fingerprint I know it is them. 


 
 On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning ted.dunn...@gmail.com wrote:
 
 If you know the person, it adds something that you don't get.
 
 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Stephen Connolly

On 10 October 2012 15:20, Ted Dunning ted.dunn...@gmail.com wrote:



 Sent from my iPhone

 On Oct 10, 2012, at 2:47 AM, Noah Slater nsla...@tumbolia.org wrote:

  Can you clarify? I understand that being able to speak to someone face to
  face, and seeing their mannerisms and expressions, allows you to
 understand
  them better. Some deep rooted human thing. But how does this impact
  security or trust, in the context of key signing?

 I have friends who live far away.  I know them well.  I don't know their
 key fingerprint.

 If we send emails or if we text back and forth I  not clear that it is
 them.  If I have a video conference and the hold up the fingerprint I know
 it is them.


or someone with a very good disguise... and you don't rule out the man in
the mask behind the camera holding the gun pointed at them to get them to
hold up the masked man's fingerprint and not their own.

Though face-to-face doesn't remove the masked man threats... it does make
them harder (relying on threats to family/friends, etc)

;-)




 
  On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning ted.dunn...@gmail.com
 wrote:
 
  If you know the person, it adds something that you don't get.
 
 

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Kafka 0.7.2-incubating (Candidate 5)

2012-10-10 Thread Alan D. Cabrera

+1 binding


Regards,
Alan

On Oct 3, 2012, at 8:40 AM, Joe Stein wrote:

 Hello,
 
 Kafka Incubator has passed the vote for 0.7.2 RC5
 http://www.mail-archive.com/kafka-dev@incubator.apache.org/msg04980.html
 
 I would like to call a vote now from the IPMC.
 
 This is the fifth candidate for the third incubator release for Apache
 Kafka, version 0.7.2-incubating.
 
 This release fixes the following issues
 http://people.apache.org/~joestein/kafka-0.7.2-incubating-candidate-5/RELEASE-NOTES.html
 
 *** Please download, test and vote by Saturday October, 6th, 9am PDT ***
 
 Release artifacts to be voted upon:
 https://people.apache.org/~joestein/kafka-0.7.2-incubating-candidate-5/
 
 The tag (off the 0.7.2 branch) for release artifacts:
 https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.2-incubating-candidate-5
 
 Kafka's KEYS file containing PGP keys we use to sign the release:
 https://svn.apache.org/repos/asf/incubator/kafka/KEYS
 
 /*
 Joe Stein
 http://www.linkedin.com/in/charmalloc
 Twitter: @allthingshadoop http://www.twitter.com/allthingshadoop
 */


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Nick Kew


On 10 Oct 2012, at 12:20, Benson Margulies wrote:

 Nick: On the one hand, how is trusting the Apache process better or
 worse than trusting the State of Massachusetts?

When I sign a key I'm basing it on more information than that.

Either it's a one-off, when I have additional knowledge of someone:
e.g. a personal or working relationship.  Or it's a keysigning party,
when I'm one of many.  In the latter case, if I'm signing keys at
ApacheCon and someone I've never met identifies himself as
Benson Margulies, I have not only the passport but a room full
of Apache folks - some of whom surely know Benson Margulies
well - to reassure me.

-- 
Nick Kew

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Florian Holeczek

Hi Benson,

 A different angle.
 
 Noah asks me to sign his key.
 
 Noah tells me that he's committed it to KEYS for CloudStack in svn
 revision 314159.
 
 I examine that revision and see that it was made by, indeed, noah's
 Apache ID, which is associated with a particular email address.
 
 I send email to secretary@, asking Can you confirm that
 nsla...@apache.org corresponds to a CLA signed by a person named Noah
 Slater?
 
 The secretary says yes.
 
 I then feel that it's perfectly reasonable to sign a key that has two
 things in it: the name Noah Slater and nsla...@apache.org,

In this scenario, you assume:
* that Noah's account is solely under his own control
* that your mail ping pong with secretary is secure
* that the ASF did verify Noah's identity correctly
* in general, that the whole infrastructure used in this process is secure 
(trust root, no MITM, the usual stuff)

The PGP/GPG WoT is generally built upon assuring the identity of a real person 
(normally this person's name is the name used in the key, but this is a point 
often discussed), and upon doing this personally, i.e. not relying on the 
assumption that others have done it correctly! It's *you* who is signing the 
key, stating that *you* can certify that this key belongs to that person, and 
that the person is the one he/she claims to be. After all, other users on the 
WoT will rely on this information.
Signing pseudonym keys is a special thing, see [1] for example. It is important 
to mention that using a pseudonym doesn't mean that identity verification can't 
take place - these are two different things.

 because if
 this process doesn't verify an adequate association, then no one can
 trust the Apache IP process, either, and which has the same signature
 as the one in SVN.

I don't remember what exactly I had to do, but AFAIR not as much that the ASF 
would be able to sign my real-name-key based on this information. Sad but true.

 What am I missing here that would be improved by an in-person
 examination of his, oh, passport? A risk of some baroque MITM attack
 on Apache's svn server?
 
 It seems to me that this highlights a global issue with the WoT: how
 can I know the standards and level of care of every link in a chain of
 trust from me to some other person?
 
 None of this, of course, changes my concern that the average Apache
 user isn't connected, but if the argument is persuasive it should
 unleash a positive avalanche of key signing.

Of course, the WoT concept results in some effort for every participant. It's a 
decentralized concept, and this is one of its disadvantages.

However, what would now be totally wrong IMO is, that some guys in the ASF 
redefine these rules in order to make the process of release signing more 
simple. In the WoT big picture, this would automatically mean that every key 
that is signed based on these weak rules would have to be marked as marginally 
trusted (if at all) by people who want to really follow the PGP/GPG WoT concept.

I think there are the following basic questions:
a) Which basic concept should be used at all? Is it a decentralized Web of 
Trust, or should a hierarchical Apache CA be established for code signing 
purposes?
b) Should it be possible to contribute to ASF projects using a pseudonym, 
including code signing?

Assuming WoT for a), since there is probably no suiting manpower available for 
running a CA.

Assuming Yes for b) and proposing that there should be rules for pseudonym keys 
making it possible to distinguish them from real name keys (for example 
Superman (PSEUDONYM CODE SIGNING KEY) super...@apache.org).

Furthermore proposing the following rules:
* signing keys MUST be included in the KEYS file in the svn repository
* signing keys SHOULD be signed by other ASF members and/or other people in 
order to integrate the key into a WoT. However, signing MUST take place 
following commonly known rules when it comes to verifying identity (TODO: maybe 
it's best to really specify these rules in detail, like many people out there 
already do in the PGP/GPG sections of their personal web pages). It's up to the 
key signer whether he wants to sign pseudonym keys (TODO: Which rules do apply 
to verify identity in this case?).
* It's ok for unsigned keys to be used. In this case, a person verifying an 
artifact's signature would be relying solely on the assumption that the Apache 
infrastructure isn't compromised.

My 2 cents so far.

Regards
 Florian

[1] http://lists.gnupg.org/pipermail/gnupg-users/2004-May/022553.html

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Marvin Humphrey

On Wed, Oct 10, 2012 at 7:19 AM, Nick Kew n...@webthing.com wrote:

 On 10 Oct 2012, at 12:20, Benson Margulies wrote:

 Nick: On the one hand, how is trusting the Apache process better or
 worse than trusting the State of Massachusetts?

 When I sign a key I'm basing it on more information than that.

Exactly -- certainty increases linearly the as the strength of any one factor
improves, but increases exponentially with the addition of multiple factors.

Weak:

  amateur inspection of photo ID

Stronger, but depends on trust in third parties:

  amateur inspection of photo ID
+ third party testimonials

Stronger still:

  amateur inspection of photo ID
+ third party testimonials
+ permanent archived video (to discourage impersonation)
+ verification of Apache credentials

 Either it's a one-off, when I have additional knowledge of someone:
 e.g. a personal or working relationship.  Or it's a keysigning party,
 when I'm one of many.  In the latter case, if I'm signing keys at
 ApacheCon and someone I've never met identifies himself as
 Benson Margulies, I have not only the passport but a room full
 of Apache folks - some of whom surely know Benson Margulies
 well - to reassure me.

Protocols for key signing parties can be quite elaborate to ensure that each
participant provides multiple factors:

http://cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Proposed resolution: Establish the Apache OpenOffice Project

2012-10-10 Thread Donald Harbison

On Tue, Oct 9, 2012 at 4:24 AM, Andrea Pescetti pesce...@apache.org wrote:
 The Apache OpenOffice PPMC and Community believe the project is ready to
 graduate to a Top Level Project.

 Multiple steps were taken in this direction, including:
 - Community vote to start graduation process: http://s.apache.org/e7F
 - Consensus on resolution text: http://s.apache.org/JN8
 - Election of Starting Membership for the PMC: http://s.apache.org/aR9
 - Election of a (future) PMC Chair: http://s.apache.org/019
 - Feedback from mentors: http://markmail.org/message/utklcwlfwl5wp5sx

 The proposed resolution text follows. I expect to start a VOTE on it on
 general@incubator as soon as there is consensus (on the same list).

Andrea, I believe we have established consensus here and encourage you
to start the VOTE on general@incubator at your earliest convenience.

   ---
 WHEREAS, the Board of Directors deems it to be in the best interests of the
 Foundation and consistent with the Foundation's purpose to establish a
 Project Management Committee charged with the creation and maintenance of
 open-source software related to the OpenOffice personal productivity
 applications, for distribution at no charge to the public.

 NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
 to be known as the Apache OpenOffice Project, be and hereby is established
 pursuant to Bylaws of the Foundation; and be it further

 RESOLVED, that the Apache OpenOffice Project be and hereby is responsible
 for the creation and maintenance of software related to the OpenOffice
 personal productivity applications; and be it further

 RESOLVED, that the office of Vice President, OpenOffice be and hereby is
 created, the person holding such office to serve at the direction of the
 Board of Directors as the chair of the Apache OpenOffice Project, and to
 have primary responsibility for management of the projects within the scope
 of responsibility of the Apache OpenOffice Project; and be it further

 RESOLVED, that the persons listed immediately below be and hereby are
 appointed to serve as the initial members of the Apache OpenOffice Project:

 * Andre Fischer (af)
 * Andrea Pescetti (pescetti)
 * Andrew Rist (arist)
 * Ariel Constenla-Haile (arielch)
 * Armin Le Grand (alg)
 * Dave Fisher (wave)
 * Donald Harbison (dpharbison)
 * Drew Jensen (atjensen)
 * Ian Lynch (ingotian)
 * Jürgen Schmidt (jsc)
 * Kay Schenk (kschenk)
 * Kazunari Hirano (khirano)
 * Louis Suarez-Potts (louis)
 * Marcus Lange (marcus)
 * Oliver-Rainer Wittmann (orw)
 * Pedro Giffuni (pfg)
 * Peter Junge (pj)
 * Raphael Bircher (rbircher)
 * Regina Henschel (regina)
 * RGB.ES (rgb-es)
 * Roberto Galoppini (galoppini)
 * Yang Shih-Ching (imacat)
 * Yong Lin Ma (mayongl)

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed to
 the office of Vice President, OpenOffice, to serve in accordance with and
 subject to the direction of the Board of Directors and the Bylaws of the
 Foundation until death, resignation, retirement, removal or
 disqualification, or until a successor is appointed; and be it further

 RESOLVED, that the initial Apache OpenOffice Project be and hereby is tasked
 with the creation of a set of bylaws intended to encourage open development
 and increased participation in the OpenOffice Project; and be it further

 RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with
 the migration and rationalization of the Apache OpenOffice.org podling; and
 be it further

 RESOLVED, that all responsibilities pertaining to the Apache Incubator
 OpenOffice.org podling encumbered upon the Apache Incubator Project are
 hereafter discharged.
   ---
 Best regards,
   Andrea Pescetti - Apache OpenOffice PPMC.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Permission to publish Allura website?

2012-10-10 Thread Rich Bowen

The Incubator docs state:

The website is published by checking out the content from SVN into the 
directory/www/incubator.apache.org/content/podlingname on people.apache.org. 

When I try to do this, I get 

 svn checkout https://svn.apache.org/repos/asf/incubator/allura/site allura
svn: E13: Can't make directory 
'/x1/www/incubator.apache.org/content/allura': Permission denied


Can I get added to the right group to be able to do this? Or should I open an 
infra ticket for that?

-- 
Rich Bowen
rbo...@rcbowen.com :: @rbowen
rbo...@apache.org

Re: key signing

2012-10-10 Thread Marvin Humphrey

On Wed, Oct 10, 2012 at 8:11 AM, Florian Holeczek flor...@holeczek.de wrote:
 However, what would now be totally wrong IMO is, that some guys in the ASF
 redefine these rules in order to make the process of release signing more
 simple. In the WoT big picture, this would automatically mean that every key
 that is signed based on these weak rules would have to be marked as
 marginally trusted (if at all) by people who want to really follow the
 PGP/GPG WoT concept.

In my opinion, we have sufficient expertise here at the ASF to devise an
authentication protocol whose reliability exceeds that of individuals
participating unsupervised in a web of trust, particularly if the protocol
were to incorporate archived video and auditing by a PMC.

That said, persuading others that no corners are being cut may be a more
daunting challenge. :P

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: key signing

2012-10-10 Thread Dennis E. Hamilton

+1

An Apache CA would also be handy for setting up code signing (the kind carried 
in the code package and recognized by operating systems, not an external 
signature of the kind being discussed here).

To clarify one aspect of the Apache Trust Chain.

It is not about email.  It is about the public-key cert being on 
https://people.apache.org/keys/committer/ and the fingerprint of that cert 
being in the Account Record of the identified committer.  It is the fact that 
only a person with the committer's credentials (or a highly trusted internal 
party) can manipulate the Account Record to establish a fingerprint.  The 
appearance of a name@ a.o e-mail as an identifier in the cert is not a 
free-standing claim.  It is verifiable by confirming the Apache Trust Chain 
related to (1) that committer Apache Name/ID and (2) the cert/fingerprint 
provided for that identity in the keys/committer/ directory.  Someone who knows 
to do this can mark that certificate as one that is trusted in their own store 
of certs without contributing to any WoT.

The security issues are around privacy of the committer's Apache credentials 
(same as privacy of a secret key), security of modifications to Account Records 
(and whatever audit trails there are), and security of the keys/committer 
records.  That is the transitive trust dependency for the external signatures 
claimed to be made by that committer.  The foundation of the chain is the 
validity of the issuance of the committer ID and credentials and their 
connection to an iCLA for the e-mail to which the credentials were delivered.  

This process also depends on the trustworthiness of those individuals who 
produce and issue the initial credentials and operate the services on which the 
trusted artifacts are retained.  Since that is always the foundation, 
additional web-of-trust ceremony may be satisfying but the attack surface is 
right here and unchanged.  (One could even argue that reliance on WoT increases 
the attack surface, especially if folks rely on the WoT to the exclusion of the 
Apache Trust Chain.)

I think the fundamental problems are that (1) this trust structure is not 
widely understood, even among (new) committers, and (2) the process is opaque 
to external parties who might want to know how an external signature earns ASF 
trust.  (I'm not certain that there are such folks, apart from security wonks 
and vulnerability seekers, but that is no reason to avoid an understandable, 
transparent account.)  

 - Dennis

PS: I do think one might want to threat-model the existing attack surface and 
see what can be done there.  I am not sure it mitigates against malicious 
introduction of exploitable vulnerabilities, presumably the real concern.  That 
requires examination of a much broader attack surface around all the ways code 
can be injected and vulnerabilities passed undetected into an Apache release.  
There is a high level of trust placed in the processes used, and it has little 
to do with the trustworthiness of digital certificates.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Wednesday, October 10, 2012 04:20
To: general@incubator.apache.org
Subject: Re: key signing

I could argue that we'd be better-served with X.509 certs.
An Apache CA could be programmed to issue a cert to each committer.
Users would just verify the source CA, and we'd accomplish the goal of
giving users assurance.


[ ... ]


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Accept Helix into Apache Incubator

2012-10-10 Thread kishore g

Hi,

I would like to call a vote for accepting Helix for incubation in the
Apache Incubator. I have pasted the full proposal below.

Please cast your vote:

[ ] +1, bring Helix into Incubator
[ ] +0, I don't care either way,
[ ] -1, do not bring Helix into Incubator, because ...

This vote will be open for 72 hours and only votes from the Incubator
PMC are binding.

Thanks,
Kishore G


== Abstract ==
Helix is a cluster management system for managing partitioned and
replicated resources in distributed data systems.

== Proposal ==
Helix provides an abstraction that separates coordination and
management tasks from functional tasks of a distributed system. The
developer defines the system behavior via a state machine, the
transitions between those states, and constraints on states and
transitions that govern the system’s valid settings. Helix ensures the
distributed system satisfies the state machine, controlling state
changes as appropriate during common operational activities such as
upgrades, component failures, bootstrapping, running maintenance
tasks, and adding capacity.

== Background ==
Helix was developed at LinkedIn to manage large clusters for several
diverse applications, including a distributed, partitioned,
replicated, highly available document store with a master-slave model,
a search service with multiple replicas that are updated atomically
and in near real-time, and a change data capture service for reliably
transporting database changes to caches, other dependent databases and
indexes.

These services use Helix to reliably manage dozens of clusters in
multiple data centers.  These services meet stringent SLAs at large
scale for mission-critical production applications such as search,
social gestures, and profiles.
Helix has proven to be flexible for a wide variety of system
configurations and operational patterns, is easy to integrate, with
pluggable interfaces enabling custom behavior.  It depends on Apache
Zookeeper for coordination and tracking of system state across the
cluster, as well as providing fault tolerance.
Helix is written in Java. It was developed internally at LinkedIn to
meet our particular use cases, but will be useful to many
organizations facing a similar need to manage large clusters.
Therefore, we would like to share it the ASF and begin developing a
community of developers and users within Apache.

== Rationale ==
Many organizations can benefit from a generalized cluster management
system such as Helix. While our distributed data systems use-cases for
a very large website like LinkedIn has driven the design of Helix, its
uses are varied and we expect many new use cases to emerge.

== Current Status ==
=== Meritocracy ===
Our intent with this incubator proposal is to start building a diverse
developer community around Helix following the Apache meritocracy
model. Since Helix was initially developed in late 2011, we have had
fast adoption and contributions by multiple teams at LinkedIn.
We plan to continue support for new contributors and work with those
who contribute significantly to the project to make them committers.

=== Community ===
Helix is currently being used internally at LinkedIn and is in
production in that company for customer-facing features. Recent public
presentations of Helix and its goals garnered much interest from
potential contributors. We hope to extend our contributor base
significantly and invite all those who are interested in building
large-scale distributed systems to participate.
To further this goal, we use GitHub issue tracking and branching facilities.

=== Core Developers ===
Helix is currently being developed by three engineers at LinkedIn:
Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
an engineer at Trifacta.  Kishore, the lead developer and architect,
has experience within Apache as an S4 committer. Shi developed the
partition to node mapping and rebalancing algorithm, cluster admin
APIs, and the health check framework.  Jason developed the cluster
controller and most of the test framework.  Adam developed the rich
alerting framework that enables cluster-wide, “intelligent“ alerts.

=== Alignment ===
The ASF is the natural choice to host the Helix project as its goal of
encouraging community-driven open-source projects fits with our vision
for Helix. Many projects that can benefit from Helix will rely on
Apache ZooKeeper for cluster state management, and can far more easily
achieve their operational goals by using Helix.

== Known Risks ==
=== Orphaned Products ===
The core developers plan to work full time on the project. There is
very little risk of Helix being abandoned as it is a critical part of
LinkedIn's internal infrastructure and is in production use.

=== Inexperience with Open Source ===
Only one of the core developers has experience with open source
development. Kishore has been actively involved with the ASF as a
committer and lead developer of S4.

=== Homogeneous Developers ===
The current core

RE: key signing

2012-10-10 Thread Dennis E. Hamilton

Just for completeness for building an understanding what I have been 
capitalizing as the Apache Trust Chain:

 1. There must also be understanding of the cert expiration and cert revocation 
cases.

 2. As a demonstration for how it all comes down to the Apache logon for 
committers, consider the way that an SSH certificate is established for a 
people.apache.org account.  The initial login is with the Apache Name/ID 
credentials and the password that goes with the account.  Only then can the 
user upload an SSH certificate to the appropriate location for a 
certificate-based SSH login.  I'm not suggesting that is a particular weakness 
(although folks provide a fair amount of trust to their peers on 
people.apache.org).  The point is that it also stems from the foundation of the 
Apache Trust Chain.  And so do the authz record entries, of course.

-Original Message-
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Wednesday, October 10, 2012 09:28
To: general@incubator.apache.org
Subject: RE: key signing

[ ... ]

I think the fundamental problems are that (1) this trust structure is not 
widely understood, even among (new) committers, and (2) the process is opaque 
to external parties who might want to know how an external signature earns ASF 
trust.  (I'm not certain that there are such folks, apart from security wonks 
and vulnerability seekers, but that is no reason to avoid an understandable, 
transparent account.)  

 - Dennis

PS: I do think one might want to threat-model the existing attack surface and 
see what can be done there.  I am not sure it mitigates against malicious 
introduction of exploitable vulnerabilities, presumably the real concern.  That 
requires examination of a much broader attack surface around all the ways code 
can be injected and vulnerabilities passed undetected into an Apache release.  
There is a high level of trust placed in the processes used, and it has little 
to do with the trustworthiness of digital certificates.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Wednesday, October 10, 2012 04:20
To: general@incubator.apache.org
Subject: Re: key signing

I could argue that we'd be better-served with X.509 certs.
An Apache CA could be programmed to issue a cert to each committer.
Users would just verify the source CA, and we'd accomplish the goal of
giving users assurance.


[ ... ]


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Kafka 0.7.2-incubating (Candidate 5)

2012-10-10 Thread Owen O'Malley

On Sun, Oct 7, 2012 at 10:17 AM, Joe Stein crypt...@gmail.com wrote:
 I would like to keep the vote open for another few days to give the IPMC 
 members time to review and vote, thanks.

Joe,
   Could you update your gpg key:
* set it in id.apache.org
* get someone who knows you to sign it.

WIthout a signed key that is on id.apache.org, I'm -0 (binding) on the
release. I did verify the md5 checksum.

-- Owen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Florian Holeczek

Hi Marvin,

 On Wed, Oct 10, 2012 at 8:11 AM, Florian Holeczek flor...@holeczek.de wrote:
 However, what would now be totally wrong IMO is, that some guys in the ASF
 redefine these rules in order to make the process of release signing more
 simple. In the WoT big picture, this would automatically mean that every key
 that is signed based on these weak rules would have to be marked as
 marginally trusted (if at all) by people who want to really follow the
 PGP/GPG WoT concept.
 
 In my opinion, we have sufficient expertise here at the ASF to devise an
 authentication protocol whose reliability exceeds that of individuals
 participating unsupervised in a web of trust, particularly if the protocol
 were to incorporate archived video and auditing by a PMC.

that may well be. Having read most of the mails on this thread, I was kind of 
shocked by how carelessly some would sign a key though, too, and that's what I 
meant by weak rules.
Defining a good key signing protocol containing multiple factors, like you've 
mentioned in a different mail on this thread, would certainly help here, that's 
true.

Regards
 Florian

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Recommend to the Board to establish the Apache OpenOffice Project

2012-10-10 Thread Andrea Pescetti

Seeing no objections to my last message, and keeping into account that 
this list had been regularly informed about the steps Apache OpenOffice 
was taking towards graduation, I'm hereby asking the IPMC to recommend 
the following resolution to the Board. Aim of the resolution is to 
establish the Apache OpenOffice Project as a Top Level Project.


Please cast your vote:

[ ] +1, recommend the resolution to the Board
[ ] +0, abstain/don't care
[ ] -1, do not recommend the resolution to the Board, because...

This vote will be open for 72 hours from now; only votes from the 
Incubator PMC are binding.


Resolution text:
  ---
WHEREAS, the Board of Directors deems it to be in the best interests of 
the Foundation and consistent with the Foundation's purpose to establish 
a Project Management Committee charged with the creation and maintenance 
of open-source software related to the OpenOffice personal productivity 
applications, for distribution at no charge to the public.


NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee 
(PMC), to be known as the Apache OpenOffice Project, be and hereby is 
established pursuant to Bylaws of the Foundation; and be it further


RESOLVED, that the Apache OpenOffice Project be and hereby is 
responsible for the creation and maintenance of software related to the 
OpenOffice personal productivity applications; and be it further


RESOLVED, that the office of Vice President, OpenOffice be and hereby 
is created, the person holding such office to serve at the direction of 
the Board of Directors as the chair of the Apache OpenOffice Project, 
and to have primary responsibility for management of the projects within 
the scope of responsibility of the Apache OpenOffice Project; and be it 
further


RESOLVED, that the persons listed immediately below be and hereby are 
appointed to serve as the initial members of the Apache OpenOffice Project:


* Andre Fischer (af)
* Andrea Pescetti (pescetti)
* Andrew Rist (arist)
* Ariel Constenla-Haile (arielch)
* Armin Le Grand (alg)
* Dave Fisher (wave)
* Donald Harbison (dpharbison)
* Drew Jensen (atjensen)
* Ian Lynch (ingotian)
* Jürgen Schmidt (jsc)
* Kay Schenk (kschenk)
* Kazunari Hirano (khirano)
* Louis Suarez-Potts (louis)
* Marcus Lange (marcus)
* Oliver-Rainer Wittmann (orw)
* Pedro Giffuni (pfg)
* Peter Junge (pj)
* Raphael Bircher (rbircher)
* Regina Henschel (regina)
* RGB.ES (rgb-es)
* Roberto Galoppini (galoppini)
* Yang Shih-Ching (imacat)
* Yong Lin Ma (mayongl)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be 
appointed to the office of Vice President, OpenOffice, to serve in 
accordance with and subject to the direction of the Board of Directors 
and the Bylaws of the Foundation until death, resignation, retirement, 
removal or disqualification, or until a successor is appointed; and be 
it further


RESOLVED, that the initial Apache OpenOffice Project be and hereby is 
tasked with the creation of a set of bylaws intended to encourage open 
development and increased participation in the OpenOffice Project; and 
be it further


RESOLVED, that the Apache OpenOffice Project be and hereby is tasked 
with the migration and rationalization of the Apache OpenOffice.org 
podling; and be it further


RESOLVED, that all responsibilities pertaining to the Apache Incubator 
OpenOffice.org podling encumbered upon the Apache Incubator Project are 
hereafter discharged.

  ---
Best regards,
  Andrea Pescetti - Apache OpenOffice PPMC.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Helix for the Apache Incubator

2012-10-10 Thread Mahadev Konar

The proposal looks good.

Thanks
mahadev

On Oct 9, 2012, at 5:47 PM, kishore g wrote:

 Hello,
 
 The proposal is fixed http://wiki.apache.org/incubator/HelixProposal.
 
 We have also made the Github link public.
 
 Home Page: http://linkedin.github.com/helix/
 Github source: https://github.com/linkedin/helix
 Documentation: https://github.com/linkedin/helix/wiki
 Javadocs: http://linkedin.github.com/helix/apidocs/
 
 
 Thanks,
 Kishore G
 
 On Tue, Oct 9, 2012 at 12:50 PM, kishore g g.kish...@gmail.com wrote:
 Thanks Jakob. We do use Cobertura for coverage. I will fix the proposal.
 
 On Tue, Oct 9, 2012 at 12:04 PM, Jakob Homan jgho...@gmail.com wrote:
 Non-Apache build tools that are used by Crunch are as follows:
 * Cobertura: GNU GPLv2
 Note that Cobertura is optional and is only used for calculating unit
 test coverage.
 
 What do Crunch and Cobertura have to do with Helix? Is this a bit on
 incomplete proposal recycling?
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Rat report

2012-10-10 Thread Craig L Russell


Hi Juan Pablo,

The license update is looking very good. Thanks for pitching in and  
doing all this heavy lifting!


I have some concerns with the files listed below.

1. The SilkIconSet images are licensed under CC-attribution 2.5  
license. The NOTICE needs to accommodate the comment from the source  
file:


All I ask is that you include a link back to this page in your  
credits.


Something like:

SilkIconSet (C) Mark James. http://www.famfamfam.com/lab/icons/silk/

2. fckconfig.js can be licensed under any of several licenses, but you  
have to choose one of them and include which one in the NOTICE and  
then copy the entire license into the LICENSE. The MPL 1.1 or later is  
explicitly mentioned, and since there have been issues with MPL 1.1,  
I'd suggest choosing MPL 2.0 in which these issues have been resolved.


For example:

fckconfig.js Copyright (C) 2003-2008 Frederico Caldeira Knabben  
licensed under the terms of Mozilla Public License Version 2.0 http://http 
://www.mozilla.org/MPL/2.0


3. mootools.js

The source contains a problematic comment: MIT Style License. But  
the web site says MooTools is released under the Open SourceMIT  
license, which gives you the possibility to use it and modify it in  
every circumstance.


So, I'd go with:

mootools.js Copyright (c) 2006 Valerio Proietti, http:// 
mad4milk.net, licensed under the terms of the MIT license http://opensource.org/licenses/mit-license.php


4. posteditor.js

Looking at http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-dev/201204.mbox/%3c701083845.7526.1335706069329.javamail.tom...@hel.zones.apache.org%3E 
 it's not clear whether posteditor.js is even part of the release any  
more?


5. Some other contents of NOTICE are not enlightening. For example,

OSCache Copyright (c) 2001 The OpenSymphony Group. All rights reserved.

The All rights reserved doesn't actually grant us any rights. The  
license under which we are using the files needs to be explicit.


Similarly for all the other projects with All rights reserved.

6. The LICENSE file needs to copy verbatim all of the licenses for all  
of the projects that we are including. I notice that in the docs/ 
LICENSE.* you have reproduced many of the licenses in use, but these  
should be put either into the top level LICENSE file or in a LICENSE  
file where the code is actually located in the source tree. The former  
is my advice.


Craig

On Oct 9, 2012, at 2:31 PM, juanpa...@apache.org wrote:


Modified: incubator/jspwiki/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/incubator/jspwiki/trunk/build.xml?rev=1396339r1=1396338r2=1396339view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==

--- incubator/jspwiki/trunk/build.xml (original)
+++ incubator/jspwiki/trunk/build.xml Tue Oct  9 21:31:17 2012
@@ -1703,8 +1703,8 @@ To automate the JAR signing processs, yo

report reportFile=${doc.rat}/rat.txt addLicenseHeaders=true
  fileset dir=src/org/
-  fileset dir=src/webdocs excludes=**/*.js
-  /fileset
+  fileset dir=src/webdocs
+   excludes=**/SilkIconSet-readme.txt,**/ 
fckconfig.js,**/mootools.js,**/posteditor.js /

  fileset dir=tests/org/
/report
  /target



Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Helix into Apache Incubator

2012-10-10 Thread Ted Dunning

+1 (binding)

On Wed, Oct 10, 2012 at 9:37 AM, kishore g g.kish...@gmail.com wrote:

 Hi,

 I would like to call a vote for accepting Helix for incubation in the
 Apache Incubator. I have pasted the full proposal below.

 Please cast your vote:

 [ ] +1, bring Helix into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring Helix into Incubator, because ...

 This vote will be open for 72 hours and only votes from the Incubator
 PMC are binding.

 Thanks,
 Kishore G


 == Abstract ==
 Helix is a cluster management system for managing partitioned and
 replicated resources in distributed data systems.

 == Proposal ==
 Helix provides an abstraction that separates coordination and
 management tasks from functional tasks of a distributed system. The
 developer defines the system behavior via a state machine, the
 transitions between those states, and constraints on states and
 transitions that govern the system’s valid settings. Helix ensures the
 distributed system satisfies the state machine, controlling state
 changes as appropriate during common operational activities such as
 upgrades, component failures, bootstrapping, running maintenance
 tasks, and adding capacity.

 == Background ==
 Helix was developed at LinkedIn to manage large clusters for several
 diverse applications, including a distributed, partitioned,
 replicated, highly available document store with a master-slave model,
 a search service with multiple replicas that are updated atomically
 and in near real-time, and a change data capture service for reliably
 transporting database changes to caches, other dependent databases and
 indexes.

 These services use Helix to reliably manage dozens of clusters in
 multiple data centers.  These services meet stringent SLAs at large
 scale for mission-critical production applications such as search,
 social gestures, and profiles.
 Helix has proven to be flexible for a wide variety of system
 configurations and operational patterns, is easy to integrate, with
 pluggable interfaces enabling custom behavior.  It depends on Apache
 Zookeeper for coordination and tracking of system state across the
 cluster, as well as providing fault tolerance.
 Helix is written in Java. It was developed internally at LinkedIn to
 meet our particular use cases, but will be useful to many
 organizations facing a similar need to manage large clusters.
 Therefore, we would like to share it the ASF and begin developing a
 community of developers and users within Apache.

 == Rationale ==
 Many organizations can benefit from a generalized cluster management
 system such as Helix. While our distributed data systems use-cases for
 a very large website like LinkedIn has driven the design of Helix, its
 uses are varied and we expect many new use cases to emerge.

 == Current Status ==
 === Meritocracy ===
 Our intent with this incubator proposal is to start building a diverse
 developer community around Helix following the Apache meritocracy
 model. Since Helix was initially developed in late 2011, we have had
 fast adoption and contributions by multiple teams at LinkedIn.
 We plan to continue support for new contributors and work with those
 who contribute significantly to the project to make them committers.

 === Community ===
 Helix is currently being used internally at LinkedIn and is in
 production in that company for customer-facing features. Recent public
 presentations of Helix and its goals garnered much interest from
 potential contributors. We hope to extend our contributor base
 significantly and invite all those who are interested in building
 large-scale distributed systems to participate.
 To further this goal, we use GitHub issue tracking and branching
 facilities.

 === Core Developers ===
 Helix is currently being developed by three engineers at LinkedIn:
 Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
 an engineer at Trifacta.  Kishore, the lead developer and architect,
 has experience within Apache as an S4 committer. Shi developed the
 partition to node mapping and rebalancing algorithm, cluster admin
 APIs, and the health check framework.  Jason developed the cluster
 controller and most of the test framework.  Adam developed the rich
 alerting framework that enables cluster-wide, “intelligent“ alerts.

 === Alignment ===
 The ASF is the natural choice to host the Helix project as its goal of
 encouraging community-driven open-source projects fits with our vision
 for Helix. Many projects that can benefit from Helix will rely on
 Apache ZooKeeper for cluster state management, and can far more easily
 achieve their operational goals by using Helix.

 == Known Risks ==
 === Orphaned Products ===
 The core developers plan to work full time on the project. There is
 very little risk of Helix being abandoned as it is a critical part of
 LinkedIn's internal infrastructure and is in production use.

 === Inexperience with Open Source ===
 Only one of the core developers has

Re: [VOTE] Accept Helix into Apache Incubator

2012-10-10 Thread Jakob Homan

Binding +1.

On Wed, Oct 10, 2012 at 1:32 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 +1 (binding)

 On Wed, Oct 10, 2012 at 9:37 AM, kishore g g.kish...@gmail.com wrote:

 Hi,

 I would like to call a vote for accepting Helix for incubation in the
 Apache Incubator. I have pasted the full proposal below.

 Please cast your vote:

 [ ] +1, bring Helix into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring Helix into Incubator, because ...

 This vote will be open for 72 hours and only votes from the Incubator
 PMC are binding.

 Thanks,
 Kishore G


 == Abstract ==
 Helix is a cluster management system for managing partitioned and
 replicated resources in distributed data systems.

 == Proposal ==
 Helix provides an abstraction that separates coordination and
 management tasks from functional tasks of a distributed system. The
 developer defines the system behavior via a state machine, the
 transitions between those states, and constraints on states and
 transitions that govern the system’s valid settings. Helix ensures the
 distributed system satisfies the state machine, controlling state
 changes as appropriate during common operational activities such as
 upgrades, component failures, bootstrapping, running maintenance
 tasks, and adding capacity.

 == Background ==
 Helix was developed at LinkedIn to manage large clusters for several
 diverse applications, including a distributed, partitioned,
 replicated, highly available document store with a master-slave model,
 a search service with multiple replicas that are updated atomically
 and in near real-time, and a change data capture service for reliably
 transporting database changes to caches, other dependent databases and
 indexes.

 These services use Helix to reliably manage dozens of clusters in
 multiple data centers.  These services meet stringent SLAs at large
 scale for mission-critical production applications such as search,
 social gestures, and profiles.
 Helix has proven to be flexible for a wide variety of system
 configurations and operational patterns, is easy to integrate, with
 pluggable interfaces enabling custom behavior.  It depends on Apache
 Zookeeper for coordination and tracking of system state across the
 cluster, as well as providing fault tolerance.
 Helix is written in Java. It was developed internally at LinkedIn to
 meet our particular use cases, but will be useful to many
 organizations facing a similar need to manage large clusters.
 Therefore, we would like to share it the ASF and begin developing a
 community of developers and users within Apache.

 == Rationale ==
 Many organizations can benefit from a generalized cluster management
 system such as Helix. While our distributed data systems use-cases for
 a very large website like LinkedIn has driven the design of Helix, its
 uses are varied and we expect many new use cases to emerge.

 == Current Status ==
 === Meritocracy ===
 Our intent with this incubator proposal is to start building a diverse
 developer community around Helix following the Apache meritocracy
 model. Since Helix was initially developed in late 2011, we have had
 fast adoption and contributions by multiple teams at LinkedIn.
 We plan to continue support for new contributors and work with those
 who contribute significantly to the project to make them committers.

 === Community ===
 Helix is currently being used internally at LinkedIn and is in
 production in that company for customer-facing features. Recent public
 presentations of Helix and its goals garnered much interest from
 potential contributors. We hope to extend our contributor base
 significantly and invite all those who are interested in building
 large-scale distributed systems to participate.
 To further this goal, we use GitHub issue tracking and branching
 facilities.

 === Core Developers ===
 Helix is currently being developed by three engineers at LinkedIn:
 Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
 an engineer at Trifacta.  Kishore, the lead developer and architect,
 has experience within Apache as an S4 committer. Shi developed the
 partition to node mapping and rebalancing algorithm, cluster admin
 APIs, and the health check framework.  Jason developed the cluster
 controller and most of the test framework.  Adam developed the rich
 alerting framework that enables cluster-wide, “intelligent“ alerts.

 === Alignment ===
 The ASF is the natural choice to host the Helix project as its goal of
 encouraging community-driven open-source projects fits with our vision
 for Helix. Many projects that can benefit from Helix will rely on
 Apache ZooKeeper for cluster state management, and can far more easily
 achieve their operational goals by using Helix.

 == Known Risks ==
 === Orphaned Products ===
 The core developers plan to work full time on the project. There is
 very little risk of Helix being abandoned as it is a critical part of
 LinkedIn's internal infrastructure and is in

Re: Permission to publish Allura website?

2012-10-10 Thread sebb

On 10 October 2012 16:54, Rich Bowen rbo...@rcbowen.com wrote:
 The Incubator docs state:

 The website is published by checking out the content from SVN into the 
 directory/www/incubator.apache.org/content/podlingname on people.apache.org.

 When I try to do this, I get

 svn checkout https://svn.apache.org/repos/asf/incubator/allura/site allura
 svn: E13: Can't make directory 
 '/x1/www/incubator.apache.org/content/allura': Permission denied


 Can I get added to the right group to be able to do this? Or should I open an 
 infra ticket for that?

AFAIK, new sites have to use svnpubsub, (plus CMS if required).
The process needs to be initiated by INFRA.

 --
 Rich Bowen
 rbo...@rcbowen.com :: @rbowen
 rbo...@apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Helix into Apache Incubator

2012-10-10 Thread Chris Douglas

+1 (binding) -C

On Wed, Oct 10, 2012 at 9:37 AM, kishore g g.kish...@gmail.com wrote:
 Hi,

 I would like to call a vote for accepting Helix for incubation in the
 Apache Incubator. I have pasted the full proposal below.

 Please cast your vote:

 [ ] +1, bring Helix into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring Helix into Incubator, because ...

 This vote will be open for 72 hours and only votes from the Incubator
 PMC are binding.

 Thanks,
 Kishore G


 == Abstract ==
 Helix is a cluster management system for managing partitioned and
 replicated resources in distributed data systems.

 == Proposal ==
 Helix provides an abstraction that separates coordination and
 management tasks from functional tasks of a distributed system. The
 developer defines the system behavior via a state machine, the
 transitions between those states, and constraints on states and
 transitions that govern the system’s valid settings. Helix ensures the
 distributed system satisfies the state machine, controlling state
 changes as appropriate during common operational activities such as
 upgrades, component failures, bootstrapping, running maintenance
 tasks, and adding capacity.

 == Background ==
 Helix was developed at LinkedIn to manage large clusters for several
 diverse applications, including a distributed, partitioned,
 replicated, highly available document store with a master-slave model,
 a search service with multiple replicas that are updated atomically
 and in near real-time, and a change data capture service for reliably
 transporting database changes to caches, other dependent databases and
 indexes.

 These services use Helix to reliably manage dozens of clusters in
 multiple data centers.  These services meet stringent SLAs at large
 scale for mission-critical production applications such as search,
 social gestures, and profiles.
 Helix has proven to be flexible for a wide variety of system
 configurations and operational patterns, is easy to integrate, with
 pluggable interfaces enabling custom behavior.  It depends on Apache
 Zookeeper for coordination and tracking of system state across the
 cluster, as well as providing fault tolerance.
 Helix is written in Java. It was developed internally at LinkedIn to
 meet our particular use cases, but will be useful to many
 organizations facing a similar need to manage large clusters.
 Therefore, we would like to share it the ASF and begin developing a
 community of developers and users within Apache.

 == Rationale ==
 Many organizations can benefit from a generalized cluster management
 system such as Helix. While our distributed data systems use-cases for
 a very large website like LinkedIn has driven the design of Helix, its
 uses are varied and we expect many new use cases to emerge.

 == Current Status ==
 === Meritocracy ===
 Our intent with this incubator proposal is to start building a diverse
 developer community around Helix following the Apache meritocracy
 model. Since Helix was initially developed in late 2011, we have had
 fast adoption and contributions by multiple teams at LinkedIn.
 We plan to continue support for new contributors and work with those
 who contribute significantly to the project to make them committers.

 === Community ===
 Helix is currently being used internally at LinkedIn and is in
 production in that company for customer-facing features. Recent public
 presentations of Helix and its goals garnered much interest from
 potential contributors. We hope to extend our contributor base
 significantly and invite all those who are interested in building
 large-scale distributed systems to participate.
 To further this goal, we use GitHub issue tracking and branching facilities.

 === Core Developers ===
 Helix is currently being developed by three engineers at LinkedIn:
 Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
 an engineer at Trifacta.  Kishore, the lead developer and architect,
 has experience within Apache as an S4 committer. Shi developed the
 partition to node mapping and rebalancing algorithm, cluster admin
 APIs, and the health check framework.  Jason developed the cluster
 controller and most of the test framework.  Adam developed the rich
 alerting framework that enables cluster-wide, “intelligent“ alerts.

 === Alignment ===
 The ASF is the natural choice to host the Helix project as its goal of
 encouraging community-driven open-source projects fits with our vision
 for Helix. Many projects that can benefit from Helix will rely on
 Apache ZooKeeper for cluster state management, and can far more easily
 achieve their operational goals by using Helix.

 == Known Risks ==
 === Orphaned Products ===
 The core developers plan to work full time on the project. There is
 very little risk of Helix being abandoned as it is a critical part of
 LinkedIn's internal infrastructure and is in production use.

 === Inexperience with Open Source ===
 Only one of the core developers has

Re: key signing

On Wed, Oct 10, 2012 at 3:20 PM, Ted Dunning ted.dunn...@gmail.com wrote:


 I have friends who live far away.  I know them well.  I don't know their
 key fingerprint.

 If we send emails or if we text back and forth I  not clear that it is
 them.  If I have a video conference and the hold up the fingerprint I know
 it is them.


This is not an applicable user story for Apache, though. We're not all long
distance pen palls who used to know each other in real life. As Shane
points out, the important thing is that we can establish email and key
ownership. I still contend that actually being able to say the person who
controls this email and this key happens to have some ID proving their IRL
identity. Perhaps that is not important for Apache. But for the WoT in
general, it certainly seems to be the case.

-- 
NS

Re: key signing

I've said it already in this thread, but I will say it one last time before
I drop it. Archiving video provides zero benefits, beyond the human to
human connection of seeing what somebody looks like. It provides no way to
establish identity or ownership of email/keys that email does not already
provide. Or perhaps email with a photograph of me included?

On Wed, Oct 10, 2012 at 5:04 PM, Marvin Humphrey mar...@rectangular.comwrote:

 On Wed, Oct 10, 2012 at 8:11 AM, Florian Holeczek flor...@holeczek.de
 wrote:
  However, what would now be totally wrong IMO is, that some guys in the
 ASF
  redefine these rules in order to make the process of release signing more
  simple. In the WoT big picture, this would automatically mean that every
 key
  that is signed based on these weak rules would have to be marked as
  marginally trusted (if at all) by people who want to really follow the
  PGP/GPG WoT concept.

 In my opinion, we have sufficient expertise here at the ASF to devise an
 authentication protocol whose reliability exceeds that of individuals
 participating unsupervised in a web of trust, particularly if the protocol
 were to incorporate archived video and auditing by a PMC.

 That said, persuading others that no corners are being cut may be a more
 daunting challenge. :P

 Marvin Humphrey

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
NS

Re: key signing

2012-10-10 Thread Benson Margulies

Just to be clear, I don't think I've ever signed a key in my life. In
part, because this criteria seem impossibly mushy.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

Most people develop their own key signing policy and publish it. Or
organisations as a whole do, and ask their members to adhere to it.
Something which we might want to consider formalising.

On Wed, Oct 10, 2012 at 10:18 PM, Benson Margulies bimargul...@gmail.comwrote:

 Just to be clear, I don't think I've ever signed a key in my life. In
 part, because this criteria seem impossibly mushy.

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
NS

Re: key signing - trust path check

This is awesome! Unfortunately I (61D50B88) am not in the strong set.
Bummer. :(

On Wed, Oct 10, 2012 at 2:43 PM, Shane Curcuru a...@shanecurcuru.org wrote:

 Anyone interested in details of PGP signing and tracing trust paths at the
 ASF should say thank you to long-time member henkp who has done a ton of
 work documenting and verifying release signing and keys:

   
 https://people.apache.org/~**henkp/trust/https://people.apache.org/~henkp/trust/

 - Shane

 On 10/8/2012 6:37 PM, Noah Slater wrote:

 Found one... Just poking around manually...

 J. Daniel Kulp dk...@apache.org
 http://pgp.mit.edu:11371/pks/**lookup?op=vindexsearch=**
 0x858FC4C4F43856A3http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x858FC4C4F43856A3

 Signed by Carsten Ziegeler cziege...@apache.org
 http://pgp.mit.edu:11371/pks/**lookup?op=vindexsearch=**
 0x132E49D4E41EDC7Ehttp://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x132E49D4E41EDC7E

 Signed by Marcus Crafter craft...@debian.org
 http://pgp.mit.edu:11371/pks/**lookup?op=vindexsearch=**
 0x394D2FE3C4C57B42http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x394D2FE3C4C57B42

 And all Debian folk are connected, as per my pervious email. :)

 There should be a tool for this!

 On Mon, Oct 8, 2012 at 11:23 PM, Benson Margulies bimargul...@gmail.com
 wrote:

  Let's try a little statistically-invalid experiment of sample size
 one. The last time I had a key signed at Apache, it was by Dan Kulp.
 Now, pretend that you are a suspicious user of one of the many Maven
 plugins releases that I RM. Can you reach Dan from yourself in the
 web? Is there anyone you, personally, trust who starts a chain that
 leads to him?

 --**--**
 -
 To unsubscribe, e-mail: 
 general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org
 For additional commands, e-mail: 
 general-help@incubator.apache.**orggeneral-h...@incubator.apache.org





 --**--**-
 To unsubscribe, e-mail: 
 general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org
 For additional commands, e-mail: 
 general-help@incubator.apache.**orggeneral-h...@incubator.apache.org




-- 
NS

Re: [VOTE] Accept Helix into Apache Incubator

Hi,

On Wed, Oct 10, 2012 at 7:37 PM, kishore g g.kish...@gmail.com wrote:
 I would like to call a vote for accepting Helix for incubation in the
 Apache Incubator. I have pasted the full proposal below.

  [x] +1, bring Helix into Incubator

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Nick Kew


On 10 Oct 2012, at 17:04, Marvin Humphrey wrote:

 In my opinion, we have sufficient expertise here at the ASF to devise an
 authentication protocol whose reliability exceeds that of individuals
 participating unsupervised in a web of trust, particularly if the protocol
 were to incorporate archived video and auditing by a PMC.

That may be, but I don't think general@incubator is the place to develop it.

FWIW for myself I like to back WOT paths by checking manually,
and feel best about it when I can identify a chain of trust involving only
people I trust to be savvy enough not to sign keys willy-nilly.
PGP/GPG support different levels of trust, so the model helps there.

-- 
Nick Kew

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Rat report

2012-10-10 Thread Juan Pablo Santos Rodríguez

Hi Craig,

just committed some changes to address those concerns:

- issues #1 and #2: added into NOTICE/LICENSE

- #3: that comment is most probably there because it is a minified version,
anyway, I've added the appropiate text in NOTICE

- #4: more or less, the same issue as #3. We contacted the author and asked
him to explicitly state the license, which was done soon after. The file is
still used although we may switch to other alternatives in the future. The
whole history can be tracked at
https://issues.apache.org/jira/browse/JSPWIKI-382

- #5: removed the All rights reserved text and explicitly stated all
types of licenses in the NOTICE file.

- #6: included all the licenses verbatim in the main LICENSE file. Really
long file there. Also, I've noticed some jars' versions where incorrect and
in some cases the license had also changed (for instance jetty is licensed
under AL2.0 now) so, I updated that too.

Hope that all is fine now, thanks for looking into this!

br,
juan pablo

On Wed, Oct 10, 2012 at 9:53 PM, Craig L Russell
craig.russ...@oracle.comwrote:

Hi Juan Pablo,

The license update is looking very good. Thanks for pitching in and doing
all this heavy lifting!

I have some concerns with the files listed below.

1. The SilkIconSet images are licensed under CC-attribution 2.5 license.
The NOTICE needs to accommodate the comment from the source file:

All I ask is that you include a link back to this page in your credits.

Something like:

SilkIconSet (C) Mark James.
http://www.famfamfam.com/lab/**icons/silk/http://www.famfamfam.com/lab/icons/silk/

2. fckconfig.js can be licensed under any of several licenses, but you
have to choose one of them and include which one in the NOTICE and then
copy the entire license into the LICENSE. The MPL 1.1 or later is
explicitly mentioned, and since there have been issues with MPL 1.1, I'd
suggest choosing MPL 2.0 in which these issues have been resolved.

For example:

fckconfig.js Copyright (C) 2003-2008 Frederico Caldeira Knabben licensed
under the terms of Mozilla Public License Version 2.0 http://
http://www.mozilla.org/**MPL/2.0 http://www.mozilla.org/MPL/2.0

3. mootools.js

The source contains a problematic comment: MIT Style License. But the
web site says MooTools is released under the Open SourceMIT license, which
gives you the possibility to use it and modify it in every circumstance.

So, I'd go with:

mootools.js Copyright (c) 2006 Valerio Proietti, http://mad4milk.net,
licensed under the terms of the MIT license http://opensource.org/**
licenses/mit-license.php http://opensource.org/licenses/mit-license.php

4. posteditor.js

Looking at http://mail-archives.apache.**org/mod_mbox/incubator-**
jspwiki-dev/201204.mbox/%**3C701083845.7526.**
1335706069329.JavaMail.tomcat@**hel.zones.apache.org%3Ehttp://mail-archives.apache.org/mod_mbox/incubator-jspwiki-dev/201204.mbox/%3c701083845.7526.1335706069329.javamail.tom...@hel.zones.apache.org%3Eit's
not clear whether posteditor.js is even part of the release any more?

5. Some other contents of NOTICE are not enlightening. For example,

The All rights reserved doesn't actually grant us any rights. The
license under which we are using the files needs to be explicit.

6. The LICENSE file needs to copy verbatim all of the licenses for all of
the projects that we are including. I notice that in the docs/LICENSE.* you
have reproduced many of the licenses in use, but these should be put either
into the top level LICENSE file or in a LICENSE file where the code is
actually located in the source tree. The former is my advice.

Craig

On Oct 9, 2012, at 2:31 PM, juanpa...@apache.org wrote:

Modified: incubator/jspwiki/trunk/build.**xml
URL: http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/build.**
xml?rev=1396339r1=1396338r2=**1396339view=diffhttp://svn.apache.org/viewvc/incubator/jspwiki/trunk/build.xml?rev=1396339r1=1396338r2=1396339view=diff
==**==**
==
--- incubator/jspwiki/trunk/build.**xml (original)
+++ incubator/jspwiki/trunk/build.**xml Tue Oct 9 21:31:17 2012
@@ -1703,8 +1703,8 @@ To automate the JAR signing processs, yo

report reportFile=${doc.rat}/rat.**txt addLicenseHeaders=true
fileset dir=src/org/
- fileset dir=src/webdocs excludes=**/*.js
- /fileset
+ fileset dir=src/webdocs
+ excludes=**/SilkIconSet-**readme.txt,**/fckconfig.js,**/
**mootools.js,**/posteditor.js /
fileset dir=tests/org/
/report
/target

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.**com craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!

--**--**-
To unsubscribe, e-mail:

Re: [VOTE] Accept Helix into Apache Incubator

2012-10-10 Thread Roman Shaposhnik

On Wed, Oct 10, 2012 at 7:37 PM, kishore g g.kish...@gmail.com wrote:
 I would like to call a vote for accepting Helix for incubation in the
 Apache Incubator. I have pasted the full proposal below.

 +1 (not binding)

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Cordova podling from Apache Incubator

2012-10-10 Thread Andrew Savory

Hi,

On 9 October 2012 23:24, Steven Gill stevengil...@gmail.com wrote:

 This is a call for vote to graduate the Cordova podling from Apache
 Incubator.


+1


Andrew.
--
asav...@apache.org / cont...@andrewsavory.com
http://www.andrewsavory.com/

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

Hi,

On Wed, Oct 10, 2012 at 10:00 PM, Andrea Pescetti pesce...@apache.org wrote:
 Seeing no objections to my last message, and keeping into account that this
 list had been regularly informed about the steps Apache OpenOffice was
 taking towards graduation, I'm hereby asking the IPMC to recommend the
 following resolution to the Board. Aim of the resolution is to establish the
 Apache OpenOffice Project as a Top Level Project.

  [x] +1, recommend the resolution to the Board

Good luck, and a big thank you to everyone involved!

 WHEREAS, the Board of Directors deems it to be in the best interests of the
 Foundation and consistent with the Foundation's purpose to establish a
 Project Management Committee charged with the creation and maintenance of
 open-source software related to the OpenOffice personal productivity
 applications, for distribution at no charge to the public.

The recommended resolution template has changed a bit recently. I
suggest you update the text to (otherwise the board will likely do so
in any case):

[...] charged with the creation and maintenance of
open-source software, for distribution at no charge to
the public, related to open-source software related to
the OpenOffice personal productivity applications.

See 
https://svn.apache.org/repos/private/committers/board/templates/podling-tlp-resolution.txt.

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Cordova podling from Apache Incubator

Hi,

On Wed, Oct 10, 2012 at 1:24 AM, Steven Gill stevengil...@gmail.com wrote:
 This is a call for vote to graduate the Cordova podling from Apache
 Incubator.

  [x] +1 Graduate Cordova podling from Apache Incubator

(mentor)

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

2012-10-10 Thread Andrew Rist


[ x ] +1, recommend the resolution to the Board

That's a +1 (non-binding)

Andrew


On 10/10/2012 12:00 PM, Andrea Pescetti wrote:
Seeing no objections to my last message, and keeping into account that 
this list had been regularly informed about the steps Apache 
OpenOffice was taking towards graduation, I'm hereby asking the IPMC 
to recommend the following resolution to the Board. Aim of the 
resolution is to establish the Apache OpenOffice Project as a Top 
Level Project.


Please cast your vote:

[ ] +1, recommend the resolution to the Board
[ ] +0, abstain/don't care
[ ] -1, do not recommend the resolution to the Board, because...

This vote will be open for 72 hours from now; only votes from the 
Incubator PMC are binding.


Resolution text:
  ---
WHEREAS, the Board of Directors deems it to be in the best interests 
of the Foundation and consistent with the Foundation's purpose to 
establish a Project Management Committee charged with the creation and 
maintenance of open-source software related to the OpenOffice personal 
productivity applications, for distribution at no charge to the public.


NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee 
(PMC), to be known as the Apache OpenOffice Project, be and hereby 
is established pursuant to Bylaws of the Foundation; and be it further


RESOLVED, that the Apache OpenOffice Project be and hereby is 
responsible for the creation and maintenance of software related to 
the OpenOffice personal productivity applications; and be it further


RESOLVED, that the office of Vice President, OpenOffice be and 
hereby is created, the person holding such office to serve at the 
direction of the Board of Directors as the chair of the Apache 
OpenOffice Project, and to have primary responsibility for management 
of the projects within the scope of responsibility of the Apache 
OpenOffice Project; and be it further


RESOLVED, that the persons listed immediately below be and hereby are 
appointed to serve as the initial members of the Apache OpenOffice 
Project:


* Andre Fischer (af)
* Andrea Pescetti (pescetti)
* Andrew Rist (arist)
* Ariel Constenla-Haile (arielch)
* Armin Le Grand (alg)
* Dave Fisher (wave)
* Donald Harbison (dpharbison)
* Drew Jensen (atjensen)
* Ian Lynch (ingotian)
* Jürgen Schmidt (jsc)
* Kay Schenk (kschenk)
* Kazunari Hirano (khirano)
* Louis Suarez-Potts (louis)
* Marcus Lange (marcus)
* Oliver-Rainer Wittmann (orw)
* Pedro Giffuni (pfg)
* Peter Junge (pj)
* Raphael Bircher (rbircher)
* Regina Henschel (regina)
* RGB.ES (rgb-es)
* Roberto Galoppini (galoppini)
* Yang Shih-Ching (imacat)
* Yong Lin Ma (mayongl)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be 
appointed to the office of Vice President, OpenOffice, to serve in 
accordance with and subject to the direction of the Board of Directors 
and the Bylaws of the Foundation until death, resignation, retirement, 
removal or disqualification, or until a successor is appointed; and be 
it further


RESOLVED, that the initial Apache OpenOffice Project be and hereby is 
tasked with the creation of a set of bylaws intended to encourage open 
development and increased participation in the OpenOffice Project; and 
be it further


RESOLVED, that the Apache OpenOffice Project be and hereby is tasked 
with the migration and rationalization of the Apache OpenOffice.org 
podling; and be it further


RESOLVED, that all responsibilities pertaining to the Apache Incubator 
OpenOffice.org podling encumbered upon the Apache Incubator Project 
are hereafter discharged.

  ---
Best regards,
  Andrea Pescetti - Apache OpenOffice PPMC.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Preparing for the October reports

Hi,

On Tue, Oct 9, 2012 at 9:27 PM, Jakob Homan jgho...@gmail.com wrote:
 Following up, the Kafka-not-showing-any-new-people issue was a
 documentation problem, not an actual one.  We've fixed that and are
 moving forward towards the graduation vote.

Sounds great, thanks for the update!

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Preparing for the October reports

Hi,

Thanks for the reviews, Benson! I added you as a signer-off on these reports.

As reported and discussed, Kafka remains ready to graduate and will
hopefully complete that transition shortly.

On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies bimargul...@gmail.com wrote:
 ODFToolkit, on the other hand, seems to have a metadata problem. It
 shows no total committers and one new committer. Does anyone
 understand that? Otherwise, all their boxes are green.

Any thoughts on this from mentors or committers of the project?

How should we categorize the status of ODF Toolkit? In June we
classified the podling under low activty due to the low commit counts.
That figure and those of list activity look a bit better now, though
it's hard to tell how much of that is just temporary improvement from
the GSoC work.

Like in June, there were no mentor sign-offs on the ODF Toolkit report
and I see little mentor activity on odf-dev@. Do we need more/new
mentors for the project?

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Preparing for the October reports

Hi,

On Mon, Sep 24, 2012 at 10:34 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 It would be nice if we had all reviews ready by Tuesday, October 9th,
 to give one extra day for unexpected delays.

I'm again running a bit late on completing the Incubator report. I
hope to have it finished and submitted already tomorrow, but for that
we still need the following shepherd reviews:

   Dave Fisher  - Celix
   Jukka Zitting- EasyAnt
   Matt Franklin- CloudStack, Tashi
   Matt Hogstrom- VXQuery
   Ross Gardler - DeviceMap, JSPWiki

Let us know if you won't have time to do the review by tomorrow, so I
or someone else can jump in where needed.

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

I've read this entire thread (whew!), and would actually like to throw out
a contrary position:

No signed keys.

Consider: releases come from the ASF, not a person. The RM builds the
release artifacts and checks them into version control along with hash
checksums. Other PMC members validate the artifacts for release criteria
and matching checksums, voting +1 via version control.

All of the above is done via authenticated ASF accounts. The above
establishes an ASF release.

Please explain how keys are needed for this ASF release? Consumers are
already told to verify the SHA1 and nothing more. I doubt any more is
needed.

(assume secure Infrastructure)

Cheers,
-g
On Oct 5, 2012 5:04 AM, Benson Margulies bimargul...@gmail.com wrote:

 I'm offering this discussion here, but it might need to go elsewhere
 if it goes anywhere at all.

 It seems to me that the there is a gap in the incubation process, and
 I don't know how to fill it.

 As far as I can see, we don't do anything to facilitate or encourage
 getting PGP keys signed. We tell people to create a key and put it in
 the SVN 'keys' file.

 Key signing strikes me as a bit of a conundrum for us. In all other
 respects, we emphasize that anyone, anywhere, in any time zone, can be
 a full member of a community. However, key signing requires something
 else. [1] Generally, it requires a face-to-face interaction.

 It is perhaps interesting to note that the foundation accepts CLAs as
 legally binding without any face-to-face identity verification. If you
 send in a CLA with a signature, we believe it, and we believe that the
 email address you provide is, in fact, controlled by the legal person
 who signed the form.

 I wonder, then, if secretary@ should be willing to sign a key.
 Alternatively, since the chain is CLA - svn access - unsigned key in
 svn, perhaps all we really need is to document that a signature
 corresponding to a key in svn is really good enough, and users need
 not be concerned further.



 [1]: http://httpd.apache.org/dev/verification.html

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

2012-10-10 Thread Ian Holsman


On Oct 11, 2012, at 10:44 AM, Greg Stein gst...@gmail.com wrote:

 
 (assume secure Infrastructure)

That's a pretty big assumption isn't it?
There have been public instances where open source infrastructures have been 
hacked, and releases have been messed with. 

I think keys removes the need for the assumption. 

--
Ian Holsman
i...@holsman.com.au
http://doitwithdata.com.au
PH: +61-400-988-964 Skype:iholsman



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Helix into Apache Incubator

2012-10-10 Thread Patrick Hunt

+1, bring Helix into Incubator (binding)

Patrick

On Wed, Oct 10, 2012 at 9:37 AM, kishore g g.kish...@gmail.com wrote:
 Hi,

 I would like to call a vote for accepting Helix for incubation in the
 Apache Incubator. I have pasted the full proposal below.

 Please cast your vote:

 [ ] +1, bring Helix into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring Helix into Incubator, because ...

 This vote will be open for 72 hours and only votes from the Incubator
 PMC are binding.

 Thanks,
 Kishore G


 == Abstract ==
 Helix is a cluster management system for managing partitioned and
 replicated resources in distributed data systems.

 == Proposal ==
 Helix provides an abstraction that separates coordination and
 management tasks from functional tasks of a distributed system. The
 developer defines the system behavior via a state machine, the
 transitions between those states, and constraints on states and
 transitions that govern the system’s valid settings. Helix ensures the
 distributed system satisfies the state machine, controlling state
 changes as appropriate during common operational activities such as
 upgrades, component failures, bootstrapping, running maintenance
 tasks, and adding capacity.

 == Background ==
 Helix was developed at LinkedIn to manage large clusters for several
 diverse applications, including a distributed, partitioned,
 replicated, highly available document store with a master-slave model,
 a search service with multiple replicas that are updated atomically
 and in near real-time, and a change data capture service for reliably
 transporting database changes to caches, other dependent databases and
 indexes.

 These services use Helix to reliably manage dozens of clusters in
 multiple data centers.  These services meet stringent SLAs at large
 scale for mission-critical production applications such as search,
 social gestures, and profiles.
 Helix has proven to be flexible for a wide variety of system
 configurations and operational patterns, is easy to integrate, with
 pluggable interfaces enabling custom behavior.  It depends on Apache
 Zookeeper for coordination and tracking of system state across the
 cluster, as well as providing fault tolerance.
 Helix is written in Java. It was developed internally at LinkedIn to
 meet our particular use cases, but will be useful to many
 organizations facing a similar need to manage large clusters.
 Therefore, we would like to share it the ASF and begin developing a
 community of developers and users within Apache.

 == Rationale ==
 Many organizations can benefit from a generalized cluster management
 system such as Helix. While our distributed data systems use-cases for
 a very large website like LinkedIn has driven the design of Helix, its
 uses are varied and we expect many new use cases to emerge.

 == Current Status ==
 === Meritocracy ===
 Our intent with this incubator proposal is to start building a diverse
 developer community around Helix following the Apache meritocracy
 model. Since Helix was initially developed in late 2011, we have had
 fast adoption and contributions by multiple teams at LinkedIn.
 We plan to continue support for new contributors and work with those
 who contribute significantly to the project to make them committers.

 === Community ===
 Helix is currently being used internally at LinkedIn and is in
 production in that company for customer-facing features. Recent public
 presentations of Helix and its goals garnered much interest from
 potential contributors. We hope to extend our contributor base
 significantly and invite all those who are interested in building
 large-scale distributed systems to participate.
 To further this goal, we use GitHub issue tracking and branching facilities.

 === Core Developers ===
 Helix is currently being developed by three engineers at LinkedIn:
 Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
 an engineer at Trifacta.  Kishore, the lead developer and architect,
 has experience within Apache as an S4 committer. Shi developed the
 partition to node mapping and rebalancing algorithm, cluster admin
 APIs, and the health check framework.  Jason developed the cluster
 controller and most of the test framework.  Adam developed the rich
 alerting framework that enables cluster-wide, “intelligent“ alerts.

 === Alignment ===
 The ASF is the natural choice to host the Helix project as its goal of
 encouraging community-driven open-source projects fits with our vision
 for Helix. Many projects that can benefit from Helix will rely on
 Apache ZooKeeper for cluster state management, and can far more easily
 achieve their operational goals by using Helix.

 == Known Risks ==
 === Orphaned Products ===
 The core developers plan to work full time on the project. There is
 very little risk of Helix being abandoned as it is a critical part of
 LinkedIn's internal infrastructure and is in production use.

 === Inexperience with Open Source ===
 Only

Re: [VOTE] Accept Helix into Apache Incubator

2012-10-10 Thread Ahmed Radwan

[ ] +1, bring Helix into Incubator
(non-binding)

On Wed, Oct 10, 2012 at 9:37 AM, kishore g g.kish...@gmail.com wrote:
 Hi,

 I would like to call a vote for accepting Helix for incubation in the
 Apache Incubator. I have pasted the full proposal below.

 Please cast your vote:

 [ ] +1, bring Helix into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring Helix into Incubator, because ...

 This vote will be open for 72 hours and only votes from the Incubator
 PMC are binding.

 Thanks,
 Kishore G


 == Abstract ==
 Helix is a cluster management system for managing partitioned and
 replicated resources in distributed data systems.

 == Proposal ==
 Helix provides an abstraction that separates coordination and
 management tasks from functional tasks of a distributed system. The
 developer defines the system behavior via a state machine, the
 transitions between those states, and constraints on states and
 transitions that govern the system’s valid settings. Helix ensures the
 distributed system satisfies the state machine, controlling state
 changes as appropriate during common operational activities such as
 upgrades, component failures, bootstrapping, running maintenance
 tasks, and adding capacity.

 == Background ==
 Helix was developed at LinkedIn to manage large clusters for several
 diverse applications, including a distributed, partitioned,
 replicated, highly available document store with a master-slave model,
 a search service with multiple replicas that are updated atomically
 and in near real-time, and a change data capture service for reliably
 transporting database changes to caches, other dependent databases and
 indexes.

 These services use Helix to reliably manage dozens of clusters in
 multiple data centers.  These services meet stringent SLAs at large
 scale for mission-critical production applications such as search,
 social gestures, and profiles.
 Helix has proven to be flexible for a wide variety of system
 configurations and operational patterns, is easy to integrate, with
 pluggable interfaces enabling custom behavior.  It depends on Apache
 Zookeeper for coordination and tracking of system state across the
 cluster, as well as providing fault tolerance.
 Helix is written in Java. It was developed internally at LinkedIn to
 meet our particular use cases, but will be useful to many
 organizations facing a similar need to manage large clusters.
 Therefore, we would like to share it the ASF and begin developing a
 community of developers and users within Apache.

 == Rationale ==
 Many organizations can benefit from a generalized cluster management
 system such as Helix. While our distributed data systems use-cases for
 a very large website like LinkedIn has driven the design of Helix, its
 uses are varied and we expect many new use cases to emerge.

 == Current Status ==
 === Meritocracy ===
 Our intent with this incubator proposal is to start building a diverse
 developer community around Helix following the Apache meritocracy
 model. Since Helix was initially developed in late 2011, we have had
 fast adoption and contributions by multiple teams at LinkedIn.
 We plan to continue support for new contributors and work with those
 who contribute significantly to the project to make them committers.

 === Community ===
 Helix is currently being used internally at LinkedIn and is in
 production in that company for customer-facing features. Recent public
 presentations of Helix and its goals garnered much interest from
 potential contributors. We hope to extend our contributor base
 significantly and invite all those who are interested in building
 large-scale distributed systems to participate.
 To further this goal, we use GitHub issue tracking and branching facilities.

 === Core Developers ===
 Helix is currently being developed by three engineers at LinkedIn:
 Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
 an engineer at Trifacta.  Kishore, the lead developer and architect,
 has experience within Apache as an S4 committer. Shi developed the
 partition to node mapping and rebalancing algorithm, cluster admin
 APIs, and the health check framework.  Jason developed the cluster
 controller and most of the test framework.  Adam developed the rich
 alerting framework that enables cluster-wide, “intelligent“ alerts.

 === Alignment ===
 The ASF is the natural choice to host the Helix project as its goal of
 encouraging community-driven open-source projects fits with our vision
 for Helix. Many projects that can benefit from Helix will rely on
 Apache ZooKeeper for cluster state management, and can far more easily
 achieve their operational goals by using Helix.

 == Known Risks ==
 === Orphaned Products ===
 The core developers plan to work full time on the project. There is
 very little risk of Helix being abandoned as it is a critical part of
 LinkedIn's internal infrastructure and is in production use.

 === Inexperience with Open Source ===
 Only

[DISCUSS] Jr. Mentor role

2012-10-10 Thread Roman Shaposhnik

Hi!

ever since Bigtop has incubated I've been thinking
about the experience that I've had and that it would
be very nice if I could help the new projects at least
1/10th the amount of help I received from some of the
mentors.

Also, seeing a steady stream of graduating projects
I would imagine that some of the newly appointed
VPs might also want to help (especially while the
experience of going through the Incubator is still
fresh :-)).

Now, as it stands it seems like there are two issues
that would prevent somebody like me to actually
help the existing pool of mentors shoulder the
responsibility of shepherding the new podlings:
   #1 formal mentors are required to be IMPC
   #2 the good mentoring skills need to be honed
over time and can't be assumed

So here's what I'm wondering: is there a place for
a Jr. Mentor type of a role within the Incubator?
Basically somebody who can help more Sr. mentors
with more mundane tasks, but still deffer to their
judgement in certain cases.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

Ian Holsman wrote on Thu, Oct 11, 2012 at 10:53:11 +1100:
 
 On Oct 11, 2012, at 10:44 AM, Greg Stein gst...@gmail.com wrote:
 
  
  (assume secure Infrastructure)
 
 That's a pretty big assumption isn't it?
 There have been public instances where open source infrastructures have been 
 hacked, and releases have been messed with. 
 
 I think keys removes the need for the assumption. 

Signatures also allow verifying whoever signed this tarball is the
same person who signed the previous tarball.  Hash functions don't do
that.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Kafka 0.7.2-incubating (Candidate 5)

2012-10-10 Thread Joe Stein

[3] +1 (binding)  Alan, Jakob, Chris
[1] +1 (non-binding) Jun
[1] 0  (binding) Owen)
[0] -1

the vote passes IPMC

and with the PPMC vote already passsed

[3] +1 (binding) Jun, Neha, Chris
[1] +1 (non-binding) Joel
[0] 0
[0] -1

0.7.2 is ready to ship

i will push the release to the origin server and update our download site
and then send an anounce on the anouncement list

Owen, I updated my pgp key @ id.apache.org and have an email out to folks
in the trust chain I know to sign my pgp key which i put in my home dir...
If I don't hear back from anyone by strata/hadoop world i will bug people
in person =8^)

thanks everyone

On Wed, Oct 10, 2012 at 1:18 PM, Owen O'Malley omal...@apache.org wrote:

 On Sun, Oct 7, 2012 at 10:17 AM, Joe Stein crypt...@gmail.com wrote:
  I would like to keep the vote open for another few days to give the IPMC
 members time to review and vote, thanks.

 Joe,
Could you update your gpg key:
 * set it in id.apache.org
 * get someone who knows you to sign it.

 WIthout a signed key that is on id.apache.org, I'm -0 (binding) on the
 release. I did verify the md5 checksum.

 -- Owen

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 

/*
Joe Stein
http://www.linkedin.com/in/charmalloc
Twitter: @allthingshadoop http://www.twitter.com/allthingshadoop
*/

Re: key signing

Greg Stein wrote on Wed, Oct 10, 2012 at 19:44:30 -0400:
 I've read this entire thread (whew!), and would actually like to throw out
 a contrary position:
 
 No signed keys.
 
 Consider: releases come from the ASF, not a person.

Therefore, releases should be signed by the ASF as an organisation, not
by individual persons.  Right?

 The RM builds the
 release artifacts and checks them into version control along with hash
 checksums. Other PMC members validate the artifacts for release criteria
 and matching checksums, voting +1 via version control.
 
 All of the above is done via authenticated ASF accounts. The above
 establishes an ASF release.
 
 Please explain how keys are needed for this ASF release? Consumers are
 already told to verify the SHA1 and nothing more. I doubt any more is
 needed.
 
 (assume secure Infrastructure)
 
 Cheers,
 -g

Daniel
(infra hat off, devil's advocate hat on)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

On Wed, Oct 10, 2012 at 9:10 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
 Greg Stein wrote on Wed, Oct 10, 2012 at 19:44:30 -0400:
 I've read this entire thread (whew!), and would actually like to throw out
 a contrary position:

 No signed keys.

 Consider: releases come from the ASF, not a person.

 Therefore, releases should be signed by the ASF as an organisation, not
 by individual persons.  Right?

I would be completely supportive of an Infra-managed private key for
signing releases.

My point is that our instructions to users don't really incorporoate
the notions of keys, and (thus) provide near-zero utility. For such
a long thread, for such little gain... my thought was toss the
concept. throw out the keys.

...
 Daniel
 (infra hat off, devil's advocate hat on)

hehe. And my devil's advocate is: keys provide no additional benefit
for end users. demonstrate otherwise.

Cheers,
-g

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: Preparing for the October reports

2012-10-10 Thread Franklin, Matthew B.

-Original Message-
From: Jukka Zitting [mailto:jukka.zitt...@gmail.com]
Sent: Wednesday, October 10, 2012 7:28 PM
To: general
Subject: Re: Preparing for the October reports

Hi,

On Mon, Sep 24, 2012 at 10:34 PM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
 It would be nice if we had all reviews ready by Tuesday, October 9th,
 to give one extra day for unexpected delays.

I'm again running a bit late on completing the Incubator report. I
hope to have it finished and submitted already tomorrow, but for that
we still need the following shepherd reviews:

   Dave Fisher  - Celix
   Jukka Zitting- EasyAnt
   Matt Franklin- CloudStack, Tashi
   Matt Hogstrom- VXQuery
   Ross Gardler - DeviceMap, JSPWiki

Let us know if you won't have time to do the review by tomorrow, so I
or someone else can jump in where needed.

I will have mine in tomorrow morning.  Apologies for the tardiness. 

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: key signing

2012-10-10 Thread Dennis E. Hamilton

There is value of the external signature for attesting something about the 
creation of the artifact.  The digest simply demonstrates that the artifact is 
intact.

I've already agreed that the signing of other people's certificate is not that 
valuable in the case of Apache releases.

Because of the security of Apache credentials, confirming a certificate is 
easy: Import the certificate located on the Apache site into your favorite key 
(certificate) store.  Send an encrypted message to the corresponding name@ 
apache.org.
Have the recipient send the decrypted message back to you encrypted with your 
public key (also identified in the message, etc.)

If the recipient doesn't receive it or can't return the decrypted message, 
don't trust the public key cert.  You can probably indicate the key is trusted 
by you, locally, if the exercise succeeds.  You don't have to do a WoT signing 
though.

This is a pretty standard ceremony for an e-mail non-persona.  

 - Dennis

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Wednesday, October 10, 2012 16:45
To: general@incubator.apache.org
Subject: Re: key signing

I've read this entire thread (whew!), and would actually like to throw out
a contrary position:

No signed keys.

Consider: releases come from the ASF, not a person. The RM builds the
release artifacts and checks them into version control along with hash
checksums. Other PMC members validate the artifacts for release criteria
and matching checksums, voting +1 via version control.

All of the above is done via authenticated ASF accounts. The above
establishes an ASF release.

Please explain how keys are needed for this ASF release? Consumers are
already told to verify the SHA1 and nothing more. I doubt any more is
needed.

(assume secure Infrastructure)

Cheers,
-g
[ ... ]


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

On Wed, Oct 10, 2012 at 7:53 PM, Ian Holsman i...@holsman.com.au wrote:
 On Oct 11, 2012, at 10:44 AM, Greg Stein gst...@gmail.com wrote:
 (assume secure Infrastructure)

 That's a pretty big assumption isn't it?

Empirically, we've had break-ins, so we can assume it will happen
again. But now you're talking that somebody has to change the svn/dist
system to install new tarballs and new checksums. Without being
noticed once control is regained.

 There have been public instances where open source infrastructures have been 
 hacked, and releases have been messed with.

 I think keys removes the need for the assumption.

Not too much. We still instruct users take the signatures and verify
them against blah.apache.org/KEYS. John Blackhat could replace the
signatures and install his entry into KEYS.

I still see no need for key-based signing here :-)

Cheers,
-g

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

Greg Stein wrote on Wed, Oct 10, 2012 at 21:14:15 -0400:
 On Wed, Oct 10, 2012 at 9:10 PM, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
  Greg Stein wrote on Wed, Oct 10, 2012 at 19:44:30 -0400:
  I've read this entire thread (whew!), and would actually like to throw out
  a contrary position:
 
  No signed keys.
 
  Consider: releases come from the ASF, not a person.
 
  Therefore, releases should be signed by the ASF as an organisation, not
  by individual persons.  Right?
 
 I would be completely supportive of an Infra-managed private key for
 signing releases.
 
 My point is that our instructions to users don't really incorporoate
 the notions of keys, and (thus) provide near-zero utility. For such

So, provide better instructions?

 a long thread, for such little gain... my thought was toss the
 concept. throw out the keys.
 
 ...
  Daniel
  (infra hat off, devil's advocate hat on)
 
 hehe. And my devil's advocate is: keys provide no additional benefit
 for end users. demonstrate otherwise.
 

One benefit I named in my next-to-last message: upon a new release,
users who downloaded the previous release and its signature can verify
that the new release was signed by the same entity that signed the
previous release.  This binds releases to each another.

Shane hinted at another: a person who signs a release using the same key
he uses for day-to-day dev@ work links the release not to his legal
identity but to his dev@ identity.  This binds releases to people doing
dev work.

SHA-1 checksums don't provide any binding whatsoever, other than
whoever generated the checksum was looking at the same file I am
looking at.

 Cheers,
 -g
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400:
 Not too much. We still instruct users take the signatures and verify
 them against blah.apache.org/KEYS. John Blackhat could replace the
 signatures and install his entry into KEYS.

If you use https://people.apache.org/keys/ instead of KEYS files in the
dist/ tree, John would have to crack two machines rather than one.

/plug :-P

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

On Wed, Oct 10, 2012 at 9:35 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
 Greg Stein wrote on Wed, Oct 10, 2012 at 21:14:15 -0400:
...
 My point is that our instructions to users don't really incorporoate
 the notions of keys, and (thus) provide near-zero utility. For such

 So, provide better instructions?

That's the implication that I'm getting at... rip out all the key
stuff, and just talk about the SHA1 checksums.

...
 One benefit I named in my next-to-last message: upon a new release,
 users who downloaded the previous release and its signature can verify
 that the new release was signed by the same entity that signed the
 previous release.  This binds releases to each another.

 Shane hinted at another: a person who signs a release using the same key
 he uses for day-to-day dev@ work links the release not to his legal
 identity but to his dev@ identity.  This binds releases to people doing
 dev work.

 SHA-1 checksums don't provide any binding whatsoever, other than
 whoever generated the checksum was looking at the same file I am
 looking at.

I understand there is no binding. I'm only considering a binding
against the ASF. It is residing on our infrastructure, its checksum
matches, therefore it must be authentic.

Does the extra glue really matter? Do we really need to figure out key
signing parties? What are we truly getting out of this?

I look at the glue of the committer's identifier. I'm posting to
dev@ as gstein, and then I commit the tarball artifact as gstein.
Binding is now complete.

Cheers,
-g

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing