hoosegow 1.2.0 → 1.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 08457775221dac7f850e7f3ba83e41661a45ae62
-  data.tar.gz: 64919e4a0404a832ff1cd700bb8b665af96fd63e
+  metadata.gz: 8a743e7ec41c3707de2a2e28ac52496e05453c70
+  data.tar.gz: b69f9d254a0c2fe8f3639cdeaadaf2957632e1af
 SHA512:
-  metadata.gz: fe8880787a543fca141ec9c2f59df2ae778dc7d791709c7a9f39e304f2ea0f16800d79d3236c0e28f4feff3fb7afc3077c124c4a645be2206a46f4dc85d8e6d6
-  data.tar.gz: edda7d73693b4944a81dc1cbdbf699feb2ffba8507412fb12d0207188fcf74cead9732fd37cad938516eccdb007c2d24e513cfcb350bb915d23ed35eff63669b
+  metadata.gz: 51cca6f9ed8ab60e905c3f601541eefa119425fd4a24e969c3f0426daa34d87d31aa9b1adf02a76bf03e58c7f832beb17309438dcac7e0b249d776fbbc338d68
+  data.tar.gz: 6a424b86b4fbf080eb87056a9a85d5266bc6071d044bac12751557ece029d9f7ae712a98b60db1f87abea488fb240f36799d6b3352b46723074aff88d27b0618

data/README.md

@@ -8,7 +8,7 @@ Hoosegow runs both in your code and in a Docker container. When you call a metho
 
 Hoosegow is intended to add a layer of security to projects that need to run code that is not fully trusted/audited. Because the untrusted code is running inside a Docker container, an attacker who manages to exploit a vulnerability in the code must also break out of the Docker container before gaining any access to the host system.
 
-This means that Hoosegow is only as strong as Docker. Docker employs Kernel namespaces, capabilities, and cgroups to contain processes running inside a container. This is not true Virtualization though, and a process running as root inside the container *can* compromise the host system. Any priviledge escalation bugs in the host Kernel could also be used to become root and compromise the host machine. Further hardening of the base Ubuntu image, along with tools like AppArmor or SE-Linux can improve the security posture of an application relying on Hoosegow/Docker.
+This means that Hoosegow is only as strong as Docker. Docker employs Kernel namespaces, capabilities, and cgroups to contain processes running inside a container. This is not true virtualization though, and a process running as root inside the container *can* compromise the host system. Any privilege escalation bugs in the host Kernel could also be used to become root and compromise the host machine. Further hardening of the base Ubuntu image, along with tools like AppArmor or SE-Linux can improve the security posture of an application relying on Hoosegow/Docker.
 
 The following are some useful resources regarding the security of Docker:
 

data/hoosegow.gemspec

@@ -2,7 +2,7 @@ require 'rake'
 
 Gem::Specification.new do |s|
   s.name        = 'hoosegow'
-  s.version     = '1.2.0'
+  s.version     = '1.2.1'
   s.summary     = "A Docker jail for ruby code"
   s.description = "Hoosegow provides an RPC layer on top of Docker containers so that you can isolate unsafe parts of your application."
   s.authors     = ["Ben Toews", "Matt Burke"]

data/script/bootstrap

@@ -0,0 +1,2 @@
+#!/bin/bash
+bundle install -j4

data/script/cibuild

@@ -0,0 +1,2 @@
+#!/bin/bash
+bundle exec rake spec

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: hoosegow
 version: !ruby/object:Gem::Version
-  version: 1.2.0
+  version: 1.2.1
 platform: ruby
 authors:
 - Ben Toews
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2014-10-23 00:00:00.000000000 Z
+date: 2015-06-11 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rake
@@ -128,6 +128,8 @@ files:
 - lib/hoosegow/exceptions.rb
 - lib/hoosegow/image_bundle.rb
 - lib/hoosegow/protocol.rb
+- script/bootstrap
+- script/cibuild
 - script/proxy-integration-test
 - spec/hoosegow_docker_spec.rb
 - spec/hoosegow_spec.rb
@@ -152,7 +154,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.2.2
+rubygems_version: 2.2.3
 signing_key: 
 specification_version: 4
 summary: A Docker jail for ruby code