CCF 2.0.x node start questions

[divneil-intel]

I am trying to create a basic 2.0.x CCF network (without sandbox.sh).
As per my understanding, 1.0.x is not a good reference point as a lot has changed now in terms of client library and configuration.

So, I am using the following steps:
a. /opt/ccf/bin/keygenerator.sh to generate all the key pairs (members, users)
b. /opt/ccf/bin/cchost --config node/start_config.json

Now, post this:
a. Is it mandatory to start another node before a member is considered active? I tried activating the user but it is failing

/opt/ccf/bin/scurl.sh https://127.0.0.1:8080/gov/proposals --cacert service_cert.pem --signing-key member0_privk.pem --signing-cert member0_cert.pem --data-binary @set_user.json -H "content-type: application/json"

{"error":{"code":"AuthorizationFailed","message":"Member is not active."}}

b. Since, ccf/clients.py is not there, so, I am trying to wrap the calls in requests and there are lot of headers being passed to it. What is the recommendation here, use requests or call scurl.sh?

[achamayou]

@divneil-intel all members, whether added later or from the start, need to ack before they are considered active and taking part in the network. This is to avoid the addition, inadvertent or malicious, of public keys for which the owner of the private key will not or cannot participate.

For the time being, we still use http request signing, and so you will either need to use scurl.sh, or implement something similar to what's in clients.py. Because that draft has failed to converge, and achieve adoption, we've looked at other options, and we're in the process of adding support for COSE Sign1 payloads, for which there is comparatively good library support and does require setting any headers.

[divneil-intel]

Thanks @achamayou for sharing the details. I will stick to scurl.sh for time being.
I am calling scurl.sh from .py file and I see parsing of stderr of underlying curl is bit problematic due to the generic logs coming from it. If possible, can you pls add the options --silent --show-error to it. It will be good to have.

[eddyashton]

@divneil-intel Most of the args that you pass to scurl.sh are directly forwarded to curl. We intercept a few that are scurl-specific (--signing-key, --signing-cert), but everything else is passed to and handled by curl. So you should be able to add --silent --show-error args and they'll be passed to curl. I guess the thing that misses is errors written by scurl itself, but those should only be output for misconfiguration/bad args.