Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cli should throw error if --chain-id not provided #810

Closed
ebuchman opened this issue Apr 6, 2018 · 17 comments
Closed

cli should throw error if --chain-id not provided #810

ebuchman opened this issue Apr 6, 2018 · 17 comments
Assignees

Comments

@ebuchman
Copy link
Member

ebuchman commented Apr 6, 2018

Txs require --chain-id to be provided so it can be signed.

Note the chainid is not included in the tx itself, but it is part of the bytes that get signed to prevent cross-chain replay attacks.

Unfortunately, it means the error message just comes up as "signature verification failed" and we can't really detect why.

Thus, if the --chain-id is not provided, we should throw an error and tell the user it must be provided.

@ebuchman ebuchman added the C:CLI label Apr 6, 2018
@cwgoes
Copy link
Contributor

cwgoes commented Apr 6, 2018

Can we load the chain ID automatically from the genesis file, if present?

@cwgoes
Copy link
Contributor

cwgoes commented Apr 6, 2018

Will the light client keep a genesis file with chain ID? democli init isn't implemented, not sure if that's intended to write genesis information or not.

@ebuchman
Copy link
Member Author

Note we have to implement the basecli init functionality, which should set a chain id and other stuff like the node id and the initial validator set (to be socially authenticated).

See #822

@Onefox
Copy link

Onefox commented Dec 3, 2018

This problem is there again with gaiacli tx sign. No error is giving and a signature is produces that can not be broadcasted.

@cwgoes cwgoes reopened this Dec 3, 2018
@cwgoes
Copy link
Contributor

cwgoes commented Dec 3, 2018

This problem is there again with gaiacli tx sign. No error is giving and a signature is produces that can not be broadcasted.

Yes, you're right, looks like a regression here.

cc @alessio Thoughts?

@cwgoes cwgoes assigned alessio and unassigned cwgoes Dec 3, 2018
@alexanderbez
Copy link
Contributor

There is a function we can already use to get the default chain ID. If the user does not provide one, it seems like a reasonable UX to fall back on the default. Alternatively, we could simply require the chain ID.

@cwgoes
Copy link
Contributor

cwgoes commented Dec 3, 2018

There is a function we can already use to get the default chain ID. If the user does not provide one, it seems like a reasonable UX to fall back on the default. Alternatively, we could simply require the chain ID.

I think this is a bit dangerous - chain ID is part of the signature; if you sign over a message with a chain ID you didn't intend it could have deleterious consequences (e.g. it might be a valid tx on a different blockchain). Better to require chain ID, if it isn't specified in the CLI config.

@alexanderbez
Copy link
Contributor

Indeed. Seems like we have an actionable item here to require the chain ID flag.

@alessio
Copy link
Contributor

alessio commented Dec 14, 2018

When --chain-id is not specified on the command line, it shoud be automatically set:

func NewTxBuilderFromCLI() TxBuilder {
	// if chain ID is not specified manually, read default chain ID
	chainID := viper.GetString(client.FlagChainID)
	if chainID == "" {
		defaultChainID, err := sdk.DefaultChainID()
		if err != nil {
			chainID = defaultChainID
		}
	}

[snip]

Well, sdk.DefaultChainID() returns "":

// DefaultChainID returns the chain ID from the genesis file if present. An
// error is returned if the file cannot be read or parsed.
//
// TODO: This should be removed and the chainID should always be provided by
// the end user.
func DefaultChainID() (string, error) {
	cfg, err := tcmd.ParseConfig()
	if err != nil {
		return "", err
	}

	doc, err := tmtypes.GenesisDocFromFile(cfg.GenesisFile())
	if err != nil {
		return "", err
	}

	return doc.ChainID, nil
}

IMO we should get rid of DefaultChainID once and for all, the user needs to provide --chain-id

alessio pushed a commit that referenced this issue Dec 14, 2018
- Remove DefaultChainID(). User needs to suplly chain ID
  via either config or flag.
- Mark --chain-id as required by all tx commands.
- Fix gaiacli config values containing underscores.
  Underscore '_' character is not automagically translated
  into hyphen '-'. Viper values wouldn't be affected.
- Refresh gaiacli config tests

Closes: #810
@alessio alessio added the T:Bug label Dec 14, 2018
alessio pushed a commit that referenced this issue Dec 16, 2018
- Remove DefaultChainID(). User needs to suplly chain ID
  via either config or flag.
- Mark --chain-id as required by all tx commands.
- Fix gaiacli config values containing underscores.
  Underscore '_' character is not automagically translated
  into hyphen '-'. Viper values wouldn't be affected.
- Refresh gaiacli config tests

Closes: #810
alessio pushed a commit that referenced this issue Dec 18, 2018
- Remove DefaultChainID(). User needs to suplly chain ID
  via either config or flag.
- Mark --chain-id as required by all tx commands.
- Fix gaiacli config values containing underscores.
  Underscore '_' character is not automagically translated
  into hyphen '-'. Viper values wouldn't be affected.
- Refresh gaiacli config tests

Closes: #810
cwgoes pushed a commit that referenced this issue Dec 18, 2018
- Remove DefaultChainID(). User needs to suplly chain ID
  via either config or flag.
- Mark --chain-id as required by all tx commands.
- Fix gaiacli config values containing underscores.
  Underscore '_' character is not automagically translated
  into hyphen '-'. Viper values wouldn't be affected.
- Refresh gaiacli config tests

Closes: #810
@aaronc
Copy link
Member

aaronc commented Jan 10, 2019

I had previously setup my client to pull the chain-id from a config file in the cli settings dir. For our project I had even setup a cli init command. PR #3127 broke this with the addition of c.MarkFlagRequired(FlagChainID) in client/flags.go. At first I thought something had changed with the viper config, but eventually I tracked it down to this.

Is the intention here to always require cli users to specify the chain-id even if they have a config file setup?

@jackzampolin
Copy link
Member

I'm with @aaronc on this one. This also broke the gaiad config file for chain ID too...

@jackzampolin jackzampolin reopened this Jan 10, 2019
@alessio
Copy link
Contributor

alessio commented Jan 12, 2019

@aaronc Thank you for taking the time to report this bug and helping to make Cosmos SDK better.

Is the intention here to always require cli users to specify the chain-id even if they have a config file setup?

No, that was not the intention. I'll look into it ASAP.

@alessio
Copy link
Contributor

alessio commented Jan 12, 2019

@aaronc can you paste your config file please?

@aaronc
Copy link
Member

aaronc commented Jan 15, 2019

@alessio Here's a config file I use to connect to our testnet:

node = "tcp://xrn-us-east-1.regen.network:26657"
chain-id = "xrn-test-2"

@alessio
Copy link
Contributor

alessio commented Jan 21, 2019

@aaronc this is done now, please test

@jackzampolin
Copy link
Member

My CLI is giving an error when chainid not provided.

@alessio
Copy link
Contributor

alessio commented Jan 21, 2019

@jackzampolin please run gaiacli config

chillyvee pushed a commit to chillyvee/cosmos-sdk that referenced this issue Mar 1, 2024
Updated some of the `gaiad` command during setup. I also changed some of the names i.e. `my-node`, `my-chain`, `my-account` to better distinguish between the various components involved in setup

Co-authored-by: Callum Waters <cmwaters19@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants