Fedora Account System
Red Hat Associate
Red Hat Customer
Gitolite was found to be vulnerable to local filesystem information leak, where it could create world writable files in the repositories (particularly the gitolite-admin one) depending on the user umask running gitolite setup. References: http://seclists.org/oss-sec/2013/q4/542
Created gitolite tracking bugs for this issue: Affects: fedora-all [bug 1046228] Affects: epel-all [bug 1046231]
Created gitolite3 tracking bugs for this issue: Affects: fedora-19 [bug 1046230] Affects: epel-6 [bug 1046232]
This is fixed in gitolite3 3.5.3.1, which is on it's way everywhere it wasn't. For gitolite, I think the packaging attrs take care of this in all branches. Can you comfirm?
The patch to correct this is here: https://github.com/sitaramc/gitolite/commit/3dad4f8e3214d6ab5f71823019a624fa48b055a3 with further discussion here: https://groups.google.com/forum/#!topic/gitolite/Tu1sjaf7A4A/discussion which in particular states: "If you *are* affected, (i.e., you did a fresh install of gitolite between fa06a34 and v3.5.3), merely upgrading will NOT fix the problem, and you *must* do a one-time chmod fixup as described below. " the chmod fixup is noted in the workaround section (which is probably useful information to have put here...) " - EXISTING INSTALLS: if it affects you (see next section for details), you need to do a one-time 'chmod -R go-rwx' (or such) on ~/.gitolite.rc, ~/.gitolite, and ~/repositories/gitolite-admin.git " Finally, the commit that introduced this was fa06a34, which set the umask as early as possible and was committed on September 3 2013 (https://github.com/sitaramc/gitolite/commit/fa06a34) and as a result earlier versions are _NOT_ affected. Given that gitolite 2.3.1 was released in early 2012, it's not affected. (As an aside, please don't change the status on SRT bugs; they stay NEW until they are CLOSED. Thanks.)
Ok, thanks!