Tales of an IT Nobody

devbox:~$ iptables -A OUTPUT -j DROP

Atlassian Fisheye starter license and 10 commiter limit November 28, 2012

The problem with Atlassian Fisheye starter license:

I love using Atlassian Fisheye at work. It’s a very nice frill to have for a small team especially since it saves us time and adds a very easy, fast way to document the reviews and be open about feedback.

I have one gripe however; the 10 commiter limit (5 repos is bad enough). Our team has 4 developers – so we’re _technically_ 4 committers.

When we first started to use source control (Mercurial), our system setups would have inconsistencies in usernames: “Justin Rovang”, “RovangJu”, “rovangju” are all treated as unique usernames. Add to the fact that after we converted from HG to Git, all of the email addresses associated with those turned into <devnull@localhost> from the conversion script.

Git is sensitive to username AND email address for unique users. So our new set ups would be ‘Justin Rovang <justin.rovang@domain.com>’; but the history that was converted would have ‘Justin Rovang <devnull@localhost>’. So it’s easy to see how quickly even a small team could exceed that 10-commiter limit very fast in that circumstance.

Enter the .mailmap file:

So here’s the rundown, first you need to know what to map to what – so take an inventory of all of the incorrect/out-dated usernames that should point to a more modern/recent one; to do that I used this one-liner:

That provides an output like so:

I want to map those according to the page linked in the subtitle above; so here’s an example .mailmap entry:

You can verify the results by running the command above again (git log –format … etc); and you’ll see that the list has changed. This applies to -ALL- git log output, and therefore fixes the ’10 committers’ issue I was having with Atlassian Fisheye and Crucible.

No Comments on Atlassian Fisheye starter license and 10 commiter limit
Categories: git rant tools

GitHub hacked, and private repositories March 5, 2012

And this is precisely why albeit ‘nifty’, storing your private/proprietary code in a ‘private repository’ on the likes of GitHub / Bitbucket is a generally poor idea. – Keeping your code in SCM behind closed doors isn’t difficult. I find it very troublesome (annoying) to see how many people can’t function using Git without GitHub. (If you don’t believe me, look back several months to the PHP.INTERNALS discussion about moving to new SCM)

GitHub’s response was far too gracious to this guy. I understand the power he had, and behaved responsibly for it. But you could have just as easily made other communication attempts.

GitHub wants to stay afloat by having paying customers? You OWE your paying customers much, much more you do this bozo. Ban him. File a criminal complaint.

It seems that the majority of people posting on the Blog posts regarding this disclosure are “still happy customers” and are generally “ok” with it.

I have three categories for these kinds of people:

1. FSF (Free software foundation)-style hippies
2. “Younger” coders who are pushovers (limited sight)
3. Hacker-types who feel the same way to convey that something is insecure: via “lulz”.

p.s.: I should add, you can’t draw a comparison to the past breaches to Apache.org, or MySql.com because the resulting risks were much less than this. Comparing it to kernel.org’s intrusion would be a better fit, as that was more serious and they went dark for almost a full month reloading everything and thoroughly investigating.

No Comments on GitHub hacked, and private repositories
Categories: git rant security

The inherent risks of ‘daemonize’ features in developer tools – Git, Mercurial (hg) September 24, 2011

A handful of tools such as mercurial, git, (soon PHP – which chances are will be it’s own binary) have their own ‘daemonize’ functionality.

Whatever your reasons – if you want to disable these; there’s little to no help in figuring out how… til now…

If you want to disable Mercurial’s hg serve:
Open the file (Your python install path may differ, but this should give you an idea of what to search for)


Find the function ‘create-server’ and add ‘sys.exit()’ in the first line:

How to verify this works:

1. Before patching – run ‘hg serve’ from a mercurial repository. It will report the port number and remain active in console.
2. After patching – ‘hg serve’ from a mercurial repository will simply exit and say nothing.
3. netstat, ps -A ux |grep ‘hg serve’

If you want to disable git’s git daemon:
This one is probably the easiest of the two: find and ‘chmod a-x’ (remove execute permissions) from the ‘git-daemon’ binary on your system – mine is in /usr/libexec/git-core. You can also relocate it somewhere in-accessible.

How to verify this works:

1. Before relocating/removing/chmodding – run ‘git daemon’ – your console will remain active as if it’s listening. (You can try a base dir for a proper daemon setup if you want …)
2. After relocating/removing – run ‘git daemon’, you’ll get an error saying there are insufficient privileges, or in the case of relocating/removing you’ll see “not a git command”.
3. netstat, ps -A ux |grep ‘git daemon’

No Comments on The inherent risks of ‘daemonize’ features in developer tools – Git, Mercurial (hg)
Categories: git hg linux security servers