Community
Participate
Working Groups
Please add the e4Build user to the ACLs (+write) for the Eclipse and Equinox git repositories. This will enable our build to perform tagging operations. Currently we perform tagging as kmoir but Kim won't be doing this anymore after next week. All of the following directories need this permission. /gitroot/platform/* /gitroot/pde/* /gitroot/jdt/* /gitroot/equinox/* Discussed and approved at March 14, 2012 Eclipse PMC meeting: http://wiki.eclipse.org/Eclipse/PMC
Also include /gitroot/e4/* PW
I believe e4Build can/should be added to the "signing directory" ACLs? Or, has that been done already? or covered elsewhere?
(In reply to comment #2) > I believe e4Build can/should be added to the "signing directory" ACLs? Or, has > that been done already? or covered elsewhere? That would remove the need for e4Build to have my ssh keys. PW
I have issues with this, but hey... I have issues with everything. +1
$SETFACL -R -m u:e4Build:rwx /gitroot/platform/ $SETFACL -R -m d:u:e4Build:rwx /gitroot/platform/ $SETFACL -R -m u:e4Build:rwx /gitroot/pde/ $SETFACL -R -m d:u:e4Build:rwx /gitroot/pde/ $SETFACL -R -m u:e4Build:rwx /gitroot/jdt/ $SETFACL -R -m d:u:e4Build:rwx /gitroot/jdt/ $SETFACL -R -m u:e4Build:rwx /gitroot/equinox/ $SETFACL -R -m d:u:e4Build:rwx /gitroot/equinox/ $SETFACL -R -m u:e4Build:rwx /gitroot/e4/ $SETFACL -R -m d:u:e4Build:rwx /gitroot/e4/ $SETFACL -R -m u:e4Build:rwx /opt/public/download-staging.priv/eclipse $SETFACL -R -m d:u:e4Build:rwx /opt/public/download-staging.priv/eclipse $SETFACL -R -m u:e4Build:rwx /opt/public/download-staging.priv/arch $SETFACL -R -m d:u:e4Build:rwx /opt/public/download-staging.priv/arch Did I miss anything?
Adding Kim to CC list. Kim, from a signing/tagging point of view ... does this cover everything you (we :) will need as we move eclipse builds to build.eclipse.org, running under e4Build id? Thanks,
What about the /home/data/httpd/download.eclipse.org/eclipse/ /home/data/httpd/download.eclipse.org/equinox What id will be copying the builds to the download directories?
(In reply to comment #7) > What about the /home/data/httpd/download.eclipse.org/eclipse/ > /home/data/httpd/download.eclipse.org/equinox > > What id will be copying the builds to the download directories? We can use any committer id for that. Ideally longer term we will set up a separate promotion job running as a committer. I think we can live without e4Build being able to write to our downloads...
Perhaps I should ask ... the rest are kind of intuitive ... and maybe this is "obvious" to others ... but, who signs at download-staging.priv/arch ? What "project" is that for?
(In reply to comment #9) > Perhaps I should ask ... the rest are kind of intuitive ... and maybe this is > "obvious" to others ... but, who signs at > > download-staging.priv/arch ? > > What "project" is that for? To guess at an answer to my own question ... From its listing drwxrwsr-x+ 2 root signers 4K 2012-03-15 12:25 arch/ and contents -rw-r--r--+ 1 genie signers 75372K 2012-03-15 12:30 signer.log -rw-rw-r--+ 1 hudsonBuild signers 1K 2012-03-15 12:24 signing_queue.lock.10782 this appears to be some sort of "technical" directory, needed by the signing system itself. So, I'll assume e4Build does need acl access there too (since it is probably not literally in the "signers" group). So, with that, I think this bug can be resolved, and new ones open if something doesn't work as expected. Please re-open if I have misunderstood anything. Much thanks to all.
Unfortunately the ACLs weren't enough. The commit hook is preventing e4Build from pushing tags. Denis how does the commit hook work and is there a way we can make this work?
A test on build.eclipse.org as e4Build cd /shared/eclipse/e4/gitTest/ git clone file:///gitroot/e4/org.eclipse.migration.git cd org.eclipse.migration git tag testTagPush git push --tags I get: Total 0 (delta 0), reused 0 (delta 0) remote: Can't call method "get_value" on an undefined value at hooks/update line 291, <DATA> line 522. remote: error: hook declined to update refs/tags/testTagPush To file:///gitroot/e4/org.eclipse.migration.git ! [remote rejected] testTagPush -> testTagPush (hook declined) error: failed to push some refs to 'file:///gitroot/e4/org.eclipse.migration.git' From a glance, it doesn't like that e4Build is not in the ldap directory. PW
Right, e4Build is not an ldap user -- it's an account we created on build.eclipse.org specifically. *sigh* From here, we either toss the e4Build user into LDAP (which doesn't sound right) or we remove the commit hook on your repositories, because it simply "doesn't fit".
(In reply to comment #13) > > From here, we either toss the e4Build user into LDAP (which doesn't sound > right) or we remove the commit hook on your repositories, because it simply > "doesn't fit". There's the 3rd (also unpalatable) option, where we do add a committer to all of our repos. PW
Removing the commit hook doesn't sound like an option, because it's required by our IP process to maintain provenance information. I could imagine doing this only for our "maps" repository because this is really a special artifact of the build and not a code repository. But that doesn't get us all the way because we need to push tags for other repos. I don't understand how the update hook is checking tags in the first place. Tags don't have author/committer information associated with them so what exactly is being checked here? I don't understand the implications either way of adding e4Build to LDAP. Concretely what does this mean? I'm not arguing for it, just trying to understand what impact that has. I agree the other fallback is to make somebody a committer on everything. This would also require setting up SSH keys so e4Build could become that committer, which is something we were trying to get away from.
(In reply to comment #15) > Removing the commit hook doesn't sound like an option, because it's required by > our IP process to maintain provenance information. Right. The hook exists to ensure that all commits that are being pushed to us contain something that can be traced back to a human being who signed a committer agreement. Unless e4Build is people, that can't happen. We have instances where the Hudson Build account and Gerrit account can write to various locations, but there are front-end applications that are tracking its activity. > I don't understand how the update hook is checking tags in the first place. > Tags don't have author/committer information associated with them so what > exactly is being checked here? The update hook doesn't examine tags, it examines commits, looking at the author and committer lines to see if they belong in the LDAP group that owns the repo.
(In reply to comment #16) > The update hook doesn't examine tags, it examines commits, looking at the > author and committer lines to see if they belong in the LDAP group that owns > the repo. In Paul's test in comment #12 he didn't create any commits. Could there just be some edge case bug in the hook code? remote: Can't call method "get_value" on an undefined value at hooks/update line 291, <DATA> line 522.
There are two places in this hook where I could see us making changes: # Get current committer info { my $mesg = ldap_search ("ou=People,dc=eclipse,dc=org","(uid=$this_user)"); $current_committer_email = $mesg->entry(0)->get_value("mail"); } The above code is used to determine the email address of the current committer. We did that back when each pushed commit had to belong to the committer performing the push. We've since relaxed that rule, and checks are done against each commit record separately. That is currently where your script is failing -- it cannot get e4Build's email address. if ($op ne 'D') { [snip] check_committers (all_new_committers); check_committers (all_new_taggers) if $new_type eq 'tag'; } The check_committers (all_new_taggers) if $new_type eq 'tag'; can probably be dropped too .. do we really care if tags were not created by a committer on the project? I've changed /gitroot/e4/org.eclipse.migration.git/hooks/update to remove the email check -- can you try your push now?
(In reply to comment #18) > The check_committers (all_new_taggers) if $new_type eq 'tag'; can probably be > dropped too .. do we really care if tags were not created by a committer on the > project? I don't see how it can establish who created the tag. If I look into the git metadata, each tag is just a file containing the hash of the commit it is associated with. There is no committer/author information involved (unless it is an annotated tag, but we're not using those). But yes, if this happened: - Joe contributor creates a tag - Jill committer pulls from Joe, and then pushes with --tags to eclipse.org -> The tag originally created by Joe is in eclipse.org. Even if you could tell that the tag originally came from Joe, I don't see a problem with allowing it. There is no interesting IP in a tag.
> I don't see how it can establish who created the tag. FWIW, I didn't write this hook -- I was just a sample update hook by Shawn Pierce that I butchered to make it work for Eclipse IP. If your push works with the heck_committers (all_new_taggers), then great -- we're done. Otherwise we can try removing it too.
(In reply to comment #20) > > If your push works with the heck_committers (all_new_taggers), then great -- > we're done. Otherwise we can try removing it too. I got an error in the perl script, but simply removing the { } on either side of trying to find the email address appears to have worked: bash$ git push --tags Total 0 (delta 0), reused 0 (delta 0) To file:///gitroot/e4/org.eclipse.migration.git * [new tag] testTagPush -> testTagPush So is that email extraction just not needed as part commit hook? It looks like e4Build would be able to push tags all of our repos with this minor hook change (that's good). We just have to decide how we'll push commits to eclipse.platform.releng.maps and org.eclipse.e4.releng. PW
> So is that email extraction just not needed as part commit hook? Not needed at all. Info about the current user performing the push is irrelevant to the hook. I'll update the master copy of the hook, deploy it to all the repos and call this one fixed.
I've deployed the updated hook to the central location (thus, it will be picked up by future initrepo commands) and deployed it to all the existing repos. This is for John A: dev1:/gitroot # find . -maxdepth 3 -type d -name 'hooks' -exec cp /usr/local/share/git-core/templates/hooks/update {}/update \;
(In reply to comment #22) > > So is that email extraction just not needed as part commit hook? > > Not needed at all. Info about the current user performing the push is > irrelevant to the hook. Are you saying that the hook allows to push a change into a repository from someone who is not a committer on that project? That would be wrong, as hence anyone could modify the current HEAD of a project by pushing a change from a real committer/author but which wasn't intended to end up in the central repo.
(In reply to comment #24) > Are you saying that the hook allows to push a change into a repository from > someone who is not a committer on that project? That would be wrong, as hence > anyone could modify the current HEAD of a project by pushing a change from a > real committer/author but which wasn't intended to end up in the central repo. Our primary authentication is still the component ACLs. So no one can push to the repo unless they're a committer on that project. PW
(In reply to comment #25) > (In reply to comment #24) > > Are you saying that the hook allows to push a change into a repository from > > someone who is not a committer on that project? That would be wrong, as hence > > anyone could modify the current HEAD of a project by pushing a change from a > > real committer/author but which wasn't intended to end up in the central repo. > > Our primary authentication is still the component ACLs. So no one can push to > the repo unless they're a committer on that project. > > PW Ah, right, of course!
Add one more issue. e4Build now has rights to "put" things in eclipse signing directory due to ACL chagne ... but, not to execute the "sign" executable. I happen to know you've done this for another project :) (wtpBuild). ...> getfacl /usr/local/bin/sign getfacl: Removing leading '/' from absolute path names # file: usr/local/bin/sign # owner: root # group: signers # flags: -s- user::rwx group::r-x other::--- ...> getent group signers signers:x:8303:wtpBuild Sound doable?
getent group | grep signers signers:x:8303:wtpBuild,e4Build signers:*:8303:droy,genie, We had created a local group with the same gid for the local users. How clever of us. I've added e4Build to the local group.
I suspect that the changes to the commit hook now cause bug 376166.
(In reply to comment #28) > I've added e4Build to the local group. Thanks! Note to self. After such a change, I had to log out of my shell session to e4Build and log back in before having access. > I suspect that the changes to the commit hook now cause bug 376166. Dani, I think the changes would not have caused it, since the changes were to "loosen" requirements for commits related to tagging. But, I think all commit hooks were "updated" (as mentioned in comment 23) thus it may have placed a one there, where is had been previously removed. We think a thing like that happened to the maps repo, I believe it was, which we subsequently removed. I think we can close this bug as fixed?
