Support ceremonies via distinct binaries/scripts #6

New Issue

Open

opened 2024-11-21 04:39:36 +00:00 by lrvick · 0 comments

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

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: public/icepick#6

No description provided.