add a 'sign' comand to sign checksusms files

[tartansandal]

Signs a whole repository. The beginnings of a process to build a web of trust.

[thaljef]

This is another command that won't work with a remote repository. So we either need to make it work, or just tell users that remote repositories aren't supported (we can always add it later).

[tartansandal]

Good catch. Signing a local CHECKSUMS file for a remote repository does not
make much sense to me, so I'll just blocked it. Implemented this the same
way as for 'look'.

[thaljef]

Signing a local CHECKSUMS file for a remote repository does not make much sense to me

Well, I think you'd probably want the server to sign its checksum file with its own key. But we can figure that out later.

[tartansandal]

Well, I think you'd probably want the server to sign its checksum file with its own key. But we can figure that out later.

Ah yes, if the remote is running pintod, that could work. That will be an interesting rabbit hole to explore ;-)

[tartansandal]

Signing stacks is hard :-(

I've thought a lot about this issue. To be compatible with other non-pinto
repositories, we're largely tied to doing exactly the same as what PAUSE
does. The easiest, least intrusive, approach was to clone the target stack
to a single-stack repository. I could then sign that repository and make it
public without making any unwanted (or unwarranted) assertions about
distributions (or versions) that I had not checked.

The only other workable alternative I could come up with was to maintain a
(minimal) mirror of the AUTHORS tree under each stack, perhaps using
soft-links. We could then generate and sign per-stack CHECKSUMS files. We
would have to modify the way the DB and the package-details are maintained,
and this would be a big architectural change, with portability,
back-compatibility and other problems I haven't thought of yet, so I'm not
seriously proposing it ;-)

Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology (m) +61 (0) 4 2573 0382
DealMax Pty Ltd

Suite 1416
401 Docklands Drive
Docklands VIC 3008 Australia

"All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer." -- IBM maintenance manual, 1925

On 4 March 2015 at 03:16, Jeffrey Ryan Thalhammer notifications@github.com
wrote:

Never mind that last comment.

—
Reply to this email directly or view it on GitHub
#185 (comment).

[thaljef]

Some questions came into mind as I was re-reading the code...

What is the use case for a sign command? I mean, why would a human decide to sign (or maybe re-sign) distributions at any particular moment? Would it make more sense to just have a global sign configuration option so that all distributions in the repo are always signed?

[tartansandal]

The use case I had in mind is described in https://github.com/tartansandal/Pinto/blob/audit-notes/lib/Pinto/Manual/Audit.pod. This is a pretty specific workflow. The case for the sign command, as opposed to a configuration option, is that you might want to delay re-signing a repository until you have your whole stack in place, or you may want to resign the repository after fixing an operation that crashed part way. Really think that the 'sign' command belongs with an 'audit' pluggin where the use case and the proposed workflow can be explained in detail. My ideas on this are still very much in flux, and I've not had much time to think about them lately.

[thaljef]

The use case I had in mind is described in...

I see now (don't know why I didn't read that before).

Really think that the 'sign' command belongs with an 'audit' pluggin

I think that is the key (no pun intended). You want signing to be a deliberate and explicit administrative act. Not something that happens implicitly or accidentally. That makes sense.

Also, I suppose you might want to re-sign because you've changed keys. But I'm not sure if that scenario actually happens in the wild.

[thaljef]

Really think that the 'sign' command belongs with an 'audit' pluggin where the use case and the proposed workflow can be explained in detail.

So do you want to ship sign separately? We can leave the hooks in place (Pinto::Repository I think) but the command can be distributed on its own. Things can always be moved into core later. Taking them out is usually harder.

[tartansandal]

Yeah, I think we should ship this separately. Need to find some spare time to think through all the various workflows more carefully.

[tartansandal]

Just checked and sign does not have any hooks in Pinto::Repository so it decouples easily. The verify-upstream stuff is the one with the hooks.

[tartansandal]

Just a heads up that I've moved the signing code and the notes on auditing to https://github.com/tartansandal/Pinto-Action-Sign. Once I've cleaned things up and added some tests, I'll look to uploading this to PAUSE and maybe get some feedback from a wider audience.