About Archive Tags RSS Feed

 

slaughter 2.x is getting closer

26 October 2012 21:50

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):

  • --server=example.com
  • --prefix=/slaughter/

That would result in policies being downloaded from:

  http://example.com/slaughter/

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=http://example.com/slaughter/

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.

| 8 comments

 

Comments on this entry

icon Philipp Kern at 22:04 on 26 October 2012
http://debblog.philkern.de

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

icon rjc at 22:57 on 26 October 2012

Hi Steve,

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

"--transport=http --prefix=http://example.com/slaughter/"

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 "--prefix=example.com/slaugter" or "--prefix=http://example.com/slaughter/" 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.

Cheers,

Raf

icon Steve Kemp at 06:21 on 27 October 2012
http://steve.org.uk/

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:

--prefix=http://private.repository.steve.org.uk/

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:

--prefix=rsync://blah.example.com/blah/

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' } );
icon rjc at 10:37 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
icon Steve Kemp at 22:07 on 26 October 2012
http://steve.org.uk/

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.)


icon Steve Kemp at 23:13 on 3 November 2012
http://steve.org.uk/

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).

icon Nux at 08:47 on 4 November 2012
http://www.nux.ro

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

icon Nux at 23:09 on 3 November 2012
http://www.nux.ro

Hi,

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