Support ceremonies via distinct binaries/scripts

lrvick commented

2024-11-21 04:39:36 +00:00

Owner

Problem

Sometimes very early assets will need to be supported rapidly that already have an existing CLI tool, but don't yet have a proper SDK.

Even if they did have a proper SDK, it may not be in rust, or we may not have time to review it in full.

It is safest to ensure untrusted libraries we lack the resources to fully review are not baked into the default binary we load into memory for all operations, thus cross-contaminating all other operations with a supply chain attack that may or may not be present.

Proposal

Prefer supporting assets via standalone scrips or binaries that obey a fixed input/output format. This will allow easily writing binaries in any language, or quickly writing a script to wrap an existing CLI tool to quickly bring support to keyfork/icepick enabled workflows.

This also lends itself well to scaling support for multiple assets in the future, in which different members of our team, or even external teams, could implement native support in their CLIs for icepick, or bridge binaries/scripts.

Reference

Terraform supports external programs so long as they obey a json input/output contract.

For good UX and help text, the program could also take an argument like "help" and be expected to return the operations that should be exposed to icepick (say tranfer, stake, vote, etc.)

## Problem Sometimes very early assets will need to be supported rapidly that already have an existing CLI tool, but don't yet have a proper SDK. Even if they did have a proper SDK, it may not be in rust, or we may not have time to review it in full. It is safest to ensure untrusted libraries we lack the resources to fully review are not baked into the default binary we load into memory for all operations, thus cross-contaminating all other operations with a supply chain attack that may or may not be present. ## Proposal Prefer supporting assets via standalone scrips or binaries that obey a fixed input/output format. This will allow easily writing binaries in any language, or quickly writing a script to wrap an existing CLI tool to quickly bring support to keyfork/icepick enabled workflows. This also lends itself well to scaling support for multiple assets in the future, in which different members of our team, or even external teams, could implement native support in their CLIs for icepick, or bridge binaries/scripts. ## Reference Terraform supports external programs so long as they obey a json input/output contract. We could do similar: https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/external For good UX and help text, the program could also take an argument like "help" and be expected to return the operations that should be exposed to icepick (say tranfer, stake, vote, etc.)

lrvick changed title from ~~Support coins via distinct binaries/scripts~~ to Support ceremonies via distinct binaries/scripts

2024-11-21 04:42:18 +00:00

ryan added this to the Icepick v0.1.0 milestone 2024-12-12 20:30:52 +00:00

ryan commented

2024-12-12 20:31:59 +00:00

Owner

Closing as this is how SOL is implemented, and how other tokens will be implemented. Internal configuration such as OpenPGP signature validation and saving/loading inputs to/from SD cards or other mediums will also be implemented via modules.

ryan closed this issue

2024-12-12 20:31:59 +00:00

Support ceremonies via distinct binaries/scripts #6

Problem

Proposal

Reference