slaughter 2.x is getting closer

Friday, 26 October 2012

Work on slaughter 2.x is going rather well.

The scripting hasn't changed, and no primitives have been altered to break backward compatibility, but it is probably best to release this as "slaughter2" - because the way to specify the source from which to pull scripts has changed.

Previously we'd specify two arguments (or have them in a configuration file):

  • --prefix=/slaughter/

That would result in policies being downloaded from:

Now the rework is complete we use "transports" and "prefixes". The new way to specify the old default is to run with:

--transport=http --prefix=

I've implemented four transports thus far:

  • GIT
  • http
  • Mercurial
  • rsync

The code has been made considerably neater, the test-cases are complete, and the POD/inline documentation is almost 100% complete.

Adding additional revision-controlled transports would be trivial at this point - but I suspect I'd be wasting my time if I were to add CVS support!

Life is good. Though I've still got a fair bit more documentation, prettification and updates to make before I'm ready to release it.

Play along at home if you wish: via the repository.



Comments On This Entry

[gravitar] Philipp Kern

Submitted at 22:04:14 on 26 October 2012

So you had no need to add additional client-side verification?

[gravitar] Steve Kemp

Submitted at 22:07:50 on 26 October 2012

There will be a new step added, step two in this list:

  • 1. Download policy, via transport.
  • 2. Validate policy.
  • 3. Execute policy.

However right now the assumption is that if you're using git, for example, the git checkout will do its own validation. Similarly mercurial will check hashes, etc, when it runs its checkout.

What I'll do is allow you to invoke a local command, or execute a particular Perl module interface, and if you wish to plugin extra validation you can do so in that fashion.

I've stopped short of mandating GPG-signatures on files, but I'd be willing to make that optionally available. The concern there is that if your remote server is compromised the user could delete the .sig files - which would allow things to work as before. (i.e. Removal of signatures would make the optional step not apply - which would be a simple thing for an attacker to do, compared to generating a valid signature on a trojaned policy file.)

[gravitar] rjc

Submitted at 22:57:48 on 26 October 2012

Hi Steve,

Just a thought - it's meant as constructive criticism BTW ;^) - in the example above:

"--transport=http --prefix="

it seems like if "--transport" is specified, the scheme name (i.e. "http" in this example) in "--prefix" seems to be redundant, a kind of a pleonasm if you like.

"--transport=http" with "" or "--prefix=" on its own seems to make more sense (at least to me at this very moment).

Unless there's a reson behind it which I have failed to notice.



[gravitar] Steve Kemp

Submitted at 06:21:58 on 27 October 2012

It might look like it, but there is ambiguity. Consider the case where you're specifying a remote mercurial repository, which happens to be served over HTTP:


If we were to assume "http" then we would fail.

Sure you could pretend that mercurial repositories end with "/blah.hg" but that wouldn't be true all the time.

I guess rsync is a good case where there is redundancy. Given:


The transport is obvious, and unique. As it happens I do try to guess which transport to use if one isn't specified, but I don't think there is redundancy:

        # git://.... or   http://.../foo.git
        $CONFIG{ 'transport' } = "git"
          if ( $CONFIG{ 'prefix' } =~ /(^git|\.git$)/i );

        # http://.../foo.hg
        $CONFIG{ 'transport' } = "hg" if ( $CONFIG{ 'prefix' } =~ /\.hg$/i );

        # rsync://.../
        $CONFIG{ 'transport' } = "rsync"
          if ( $CONFIG{ 'prefix' } =~ /^rsync/i );

        # fall-back to HTTP.
        $CONFIG{ 'transport' } = "http" if ( !$CONFIG{ 'transport' } );
[gravitar] rjc

Submitted at 10:37:45 on 28 October 2012

I thought I might have missed something ;^)

Thanks for clarifying.

Just a thougt, how about "+"* in scheme names?

  • known from SVN (svn+ssh), virt-manager (qemu+ssh), ssvnc (vnc+(ssl|ssh) and other tools
[gravitar] Nux

Submitted at 23:09:55 on 3 November 2012


Slaughter looks very nice, but I have a quick question: how Debian specific is this tool? (not a Debian fan, but a Steve fan :> )

[gravitar] Steve Kemp

Submitted at 23:13:01 on 3 November 2012

Thus far I've only implemented the packaging primitives for systems that understand apt-get and yum.

Supporting over versions of Linux is almost trivial, and in addition to that I've recently ported it to both OpenBSD & NetBSD. There is also (contributed) historical support for Microsoft Windows under Strawberry perl which I have no means of testing (I believe it still works, but cannot verify it).

[gravitar] Nux

Submitted at 08:47:01 on 4 November 2012

"yum" is good enough for me. Thanks!
Bravo on the *BSD work.


Comments are closed on posts which are more than ten days old.