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

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

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

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' } );

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

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

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

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