atom feed14 messages in org.apache.incubator.generalRe: [discuss] Apache OpenWhisk Incuba...
FromSent OnAttachments
Sam RubyOct 13, 2016 1:27 pm 
Greg SteinOct 13, 2016 10:31 pm 
Mark StrubergOct 13, 2016 11:15 pm 
Sam RubyOct 14, 2016 3:29 am 
John D. AmentOct 14, 2016 3:50 am 
Felix MeschbergerOct 14, 2016 4:52 am 
Mark StrubergOct 14, 2016 6:37 am 
Felix MeschbergerOct 14, 2016 7:16 am 
Greg SteinOct 14, 2016 7:26 am 
Mark StrubergOct 14, 2016 7:51 am 
Mark StrubergOct 14, 2016 8:00 am 
Jim JagielskiOct 17, 2016 8:30 am 
Sam RubyOct 17, 2016 8:48 am 
Isabel Drost-FrommOct 19, 2016 3:58 am 
Subject:Re: [discuss] Apache OpenWhisk Incubator Proposal
From:Mark Struberg (
Date:Oct 14, 2016 8:00:47 am

PS we could Force the use of the new -S git Option and verify it with the Pub
key stored at the asf. Needs a few Experiments but might work.

Lg, Strub

-------------------------------------------- On Fri, 14/10/16, Mark Struberg <> wrote:

Subject: Re: [discuss] Apache OpenWhisk Incubator Proposal To: "" <> Date: Friday, 14 October, 2016, 16:51

Git repositories are effectively cryptographically-signed (weak/strong,

immaterial to this discussion), so a readonly mirror on ASF hardware is

equivalent to a read/write

repository living on GitHub.

Allow me to disagree. The hashes are cryptographically strong. But it's only sha1 hashes and no real signing. The sha1 hashes only the things you tell him. Try to do  git config "Foo Baz" and you are Mr Foo Baz from now on. If you push this to github then your own authentity is lost for the commit. I could e.g. also commit something with your name and your email ;) We still hope that this would get catched if the commit gets mirrored to the list...

The -s option is btw something completely different.

But Felix is right, it's a foundation wide question and we should continue this discussion on the infra lists.

txs and LieGrue, strub

On Friday, 14 October 2016, 16:26, Greg

Stein <> wrote:

On Fri, Oct 14, 2016 at

8:37 AM, Mark Struberg <>


  The problem with github is that we (ASF) cannot give any guarantees if the   main stuff doesn't originate from our own hardware.

Git repositories are effectively cryptographically-signed (weak/strong, immaterial to this discussion), so a readonly mirror on ASF hardware is

equivalent to a read/write repository living on GitHub.

  Not whether the ticket system

doesn't loose all tickets (didn't


  happen in

the past?) nor whether really only IP clean stuff got committed.

All commits, issues, PRs, etc will/must be sent to ASF mailing lists for archival. Some projects do/have used third party systems. The ASF doesn't

mind, as long as we capture that work into our archives.

  You e.g. have no clue if someone else uses your email and name in a commit   and pushes it.   Everyone else can create a commit with your email and name in GIT, there   is no check. And when pulling in changes, a faked one might get piggy   packed and introduce a backdoor. I know this might be close to paranoid but   it is theoretically possible.

We require that anybody committing to a GitHub repository authenticates with

BOTH: GitHub, and the ASF. No commits without that multiple

authentication. (this is based on our current experiments with Whimsy and Traffic Server; same rules would apply to this podling)

  The workflow

with git hosted @ASF is btw pretty much exactly the same for

  committers. And a PR

integration does exist as well. So I don't see


  you miss?

ASF repositories mirrored to GitHub cannot merge/close PRs. They cannot manage

issues. They cannot use labels. There is a large amount of GitHub

tooling that is not available to ASF-based projects/workflows. The Github repository is a simple mirror. ... OpenWhisk proposes to continue using

their GitHub workflows and tooling during incubation. At the *end* of

incubation, the Foundation will allow them to stay (as we'll be allowing other projects to similarly change their focal point of development), or they

will be required to shift their focal point to ASF-based workflows (as

we require today).



--------------------------------------------------------------------- To unsubscribe, e-mail: For additional commands, e-mail: