Adds protection against injection attacks to the nodejs layer

The nodejs layer of the Razor back-end was wide open to injection attacks. Not
only did all commands perform shell expansion of the command line, some paths
where also directly mapped to the file system without first checking if they
contained '..' segments. I had no problems letting Razor server up my private
ssh key for instance. This commits adds some code to prevent injection attacks
from happening. It consist of the following:
1. All calls to exec() has been replaced by calls to execFile() to avoid shell
   expansion.
2. When the execFile results in errors, those errors are now handled. They
   were previously ignored.
3. Splitting, decoding, and validation of request path was refactored into one
   function.
4. A new exception type InvalidURIPathError was introduced.
5. All path segments are checked for length (<200 characters) and validated
   with a regexp that ensures that they don't contain any control characters.
6. Several tests were added to verify that some known types of injection
   attacks are trapped.
Prevents web access to the Razor config

One of the points in the security assessment of Razor was
"Unauthenticated access to Razor configuration file".

This commit ensures that this file cannot be accessed using
the web interface by letting the Ruby CLI preventing access
to the 'config' slice for all calls using the -w flag.

A new flag, '-j' was introduced to enable the nodejs layer
to obtain the config in json format. The Ruby CLI will block
all attemts to combine the -w and -j flags.

The prevention check was added to the Ruby layer rather than
in the nodejs layer for two reasons:
1. There are ongoing discussions about replacing nodejs.
2. The check would have been added for all http methods. In
   the Ruby CLI, it was enough to add it in one place.

A more elaborate solution where the check was moved into the
'config' slice was considered but rejected because I wanted
to keep the alteration as limited (and thus easy to review)
as possible.

The commit also contains some tests to verify that the config
is impossible to obtain using the web.
Merge pull request #392 from daniel-pittman/feature/master/388-handle-updated-internal-package-repo-layout

Update internal package Microkernel ISO location
Merge pull request #1 from thallgren/bug/master/nodejs-security

Bug/master/nodejs security
New download path for Microkernel images
Fixes #395 (Complex Razor Microkernel version numbers not handled properly); changes made in December of 2012 to handle the more complex version numbers that could be generated by the, at the time, newly revised Microkernel ISO build process led to issues when comparing newer, stable versions of a Microkernel with older, patched versions of the Microkernel.  The code that calculate the weights used to determine which to load was not calculating these numbers correctly.  This change should resolve that issue by calculating the weights as floating point numbers (with the part after the decimal being the commit number and the part before the decimal being an integer representation of the latest tag) instead of comparing these versions as integer numbers (which did not work...older, patched versions were preferred over newer, unpatched versions).
Add BuildArch of noarch to the redhat spec

When no BuildArch is present in the specfile, rpms will be built assuming the
build is arch specific. As razor is pure ruby, there is no compilation needed
and it should be a noarch package, so this commit adds a BuildArch of noarch to
the specfile.
Remove leading epoch from spec file changelog

This looks like a lingering artifact from the facter spec file. There was an
epoch of 1 in the spec file previously, and so the changelog had a leading 1 in
the version section. That wouldn't have affected the package but could be
confusing to those reading the changelog. This commit removes that epoch from
the changelog.
Modified weight calculations further to properly handle the new semantic version numbering scheme being applied to the Razor Microkernel project (so that v0.10.0 will evaluate higher than v0.9.3.0)
Merge pull request #396 from tjmcs/tb/fixes-rz-mk-versioning-problem

(#395) Complex Razor Microkernel version numbers not handled properly
Merge pull request #394 from haus/specfile_fixups

Redhat spec file fixups
(#388) Update to handle three flavours of Microkernel

During the earlier builds I forgot that we build three flavours of
Microkernel, the production, development, and debug types.  The tests and
other CI infrastructure then only tested one, which was not sufficient for
the project.

This fixes up the internal repo layouts to respect the three different types,
and enables testing and releasing all of the different flavours in our nightly
builds area.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>