search

thaljef / Pinto

Curate your own repository of Perl modules
https://metacpan.org/module/Pinto::Manual
66 stars 49 forks source link

add a 'sign' comand to sign checksusms files #185

Closed tartansandal closed 9 years ago

tartansandal commented 9 years ago

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

thaljef commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/thaljef/Pinto/pull/185#issuecomment-76976912.

thaljef commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

tartansandal commented 9 years ago

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 commented 9 years ago

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.