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!