769148 - can't push mozilla-beta to gitolite

Status: RESOLVED FIXED

(Developer Services :: General, task)

Description

[Hal Wine [:hwine] use NI!]

Attachment: stderr output from push

tried production upload of mozilla-beta to gitolite server releases/mozilla-beat.git (bug 768639 made these available). Fails with "remote: invalid characters in ref or filename: refs/tags/<[e-mail]>", although git fsck does not object.

repeated same upload to releases/mozilla-central.git in order to capture error messages. No stdout output, stderr attached.

Upload was from github-sync1-dev.dmz.scl3, and took 140 seconds wall clock

Comment 1

[Shyam Mani [:fox2mike]]

atoll dug around a bit and came up with :

<atoll> | 2012-06-27.22:37:00     [e-mail]    10.22.74.67     Die generated at line 226 in /usr/share/perl5/vendor_perl/gitolite.pm : invalid characters in ref or filename: refs/tags/<[e-mail]><<newline>> <<newline>>

Seems like this is something on gitolite, poking further with atoll and hwine on IRC.

Comment 2

[:Atoll]

Advise deleting the tag '<[e-mail]>':

-rwxr-x--- 1 hwine hwine    41 Jun 27 20:07 <[e-mail]>

Since gitorious is probably refusing due to < or @:

2012-06-27.19:47:44     [e-mail]    10.22.74.67     Die generated at line 226 in /usr/share/perl5/vendor_perl/gitolite.pm : invalid characters in ref or filename: refs/tags/<[e-mail]><<newline>> <<newline>>

$GL_REF_OR_FILENAME_PATT=qr(^[0-9a-zA-Z][0-9a-zA-Z._\@/+ :,-]*$);

confirmed at http://gitolite.googlecode.com/git-history/89e59ae7725d662919ef7dc8f759d48c173181fd/src/gitolite_rc.pm that < and > are not permitted

Comment 3

[:Atoll]

And I guessed it was a tag because in the attachment:

 * [new tag]         chromium-import-latest -> chromium-import-latest
 * [new tag]         chromium-import-r15462 -> chromium-import-r15462
 * [new tag]         last-mozilla-central -> last-mozilla-central
 ! [remote rejected] <[e-mail]> -> <[e-mail]> (hook declined)

It's listed just like all the other tags, but it's got an error (!) instead of an OK (*).

Comment 4

[:Atoll]

< and > are rumored to be safe to add, based on:

http://sitaramc.github.com/gitolite/g2/rc.html#rcsecurity

by ediing the above-listed _PATT in the gitolite rc file under /repo/whatever

Comment 5

[:Atoll]

added to the SECURITY RISK section of .gitolite.rc:

# 20120627 - permit < and > anywhere in a refs filename, e.g. refs/tags/<[e-mail]>
# $GL_REF_OR_FILENAME_PATT=qr(^[0-9a-zA-Z][0-9a-zA-Z._\@/+ :,-]*$);
$GL_REF_OR_FILENAME_PATT=qr(^[0-9a-zA-Z<>][0-9a-zA-Z._\@/+ :,-<>]*$);

Comment 6

[Shyam Mani [:fox2mike]]

Richard tracked this down like a champ. woo!

shyam@spike ~/mozilla/repos/svn/sysadmins/puppet/trunk/modules/gitolite/templates % svn commit -m "Fix for bug 769148, thanks to atoll"
Sending        templates/gitolite.rc.erb
Transmitting file data .
Committed revision 42002.

Comment 7

[Shyam Mani [:fox2mike]]

joes/kang : Please see comments above. Need an r+ from infrasec before this is taken to production. Thanks!

Comment 8

[Joe Stevensen [:joe]]

This should be harmless. As long as we don't add back quotes or dollar signs, I don't see a problem.

Comment 9

[Hal Wine [:hwine] use NI!]

There may be another path that needs tweaking. The above prevents the issue when importing the repository. However, it doesn't allow repositories to be emptied

Pushing an empty repo atop the existing one, repeatedly yields the following:
[[e-mail]3 hwine]$ git --git-dir empty_repo/.git push --mirror --force git+ssh://mirror_writer/releases/mozilla-beta.git 
remote: invalid characters in ref or filename: refs/tags/<[e-mail]>
remote: error: hook declined to update refs/tags/<[e-mail]>
To git+ssh://mirror_writer/releases/mozilla-beta.git
 ! [remote rejected] <[e-mail]> (hook declined)
error: failed to push some refs to 'git+ssh://mirror_writer/releases/mozilla-beta.git'
[[e-mail]3 hwine]$ 

The browse view also shows the tag from the old repo:
 <http://git1.dmz.scl3.mozilla.com/?p=releases/mozilla-beta.git;a=summary>

Since tag deletion is neither a Q2 requirement, nor needed here (since the repos will be fully reset), I'm fine with splitting this out to a separate bug.

Comment 10

[Hal Wine [:hwine] use NI!]

Ah, the applied fix only affects the one repository. And (per comment #9) only additions. (I just pushed m-b to releases/mozilla-release.git, and received the same illegal tag name error.)

Since these tags are legal-in-git, we may want to consider a server wide deployment.

Comment 11

[Shyam Mani [:fox2mike]]

Hal,

This was my mistake. When I put it into puppet, vim added a # before the line automatically (because the previous line was a comment) and I made the commit. And therefore this was again disabled until now (thanks to bkero for catching that).

Should be alright now. Let me know if you run into this again.