Documentation updates for 1.1

[wanderingbort]

• [x] [RPC/cleos] changes to support secondary index types @taokayan
• [x] [RPC] changes to get code/abi (1.0.x changes technically) @heifner
• [x] [RPC] get scheduled transactions @wanderingbort
• [x] [RPC/config] grey listing @taokayan
• [x] [RPC/config] producer lag @taokayan
• [x] [cleos] sudo support @arhag
• [x] [cleos] msig changes @arhag
• [x] [cleos] bidname @taokayan
• [x] [config] http options @wanderingbort
• [x] [config] checkpoints @arhag
• [x] [nodeos] read-mode @moskvanaft
• [x] [nodeos] portable reversible block database (import / export) @arhag
• [x] [plugins] mongodb care and feeding @heifner
• [x] [keosd] PREVIEW RELEASE hardware wallet + build instructions @wanderingbort (based on @spoonincode's notes)

[wanderingbort]

please refer to #4368 #3683 and #3695 for documentation on those features.

[heifner]

See #5066 for documentation of mongo_db_plugin.

[heifner]

@ericiles has some good docker info that could be added to the docs here: #4586.

[wanderingbort]

see #4196 for documentation on nodeos read mode

[wanderingbort]

4470 has notes on get_scheduled_transaction RPC

[wanderingbort]

New configuration options for http-plugin:

max-body-size

The max body size in bytes allowed for incoming RPC requests. Defaults to 1MiB. This can be used to restrict the incoming size over the RPC so that requests cannot abuse the server.

verbose-http-errors

This is either true or false. Defaults to false.

When true, the full log attached to exceptions thrown during processing is returned to the HTTP-RPC client. This is useful when running a development node or an internal testing node for contract development. In normal production cases, this information is large and not necessary so, it is omitted for performance.

http-validate-host

This is either true or false. Defaults to true.

When making HTTP RPC calls clients are required, by the standard, to include an HTTP Host header. If this is true nodeos validates that the contents of that header matches the expected value based on configuration(s). The expected Host header is the host:port combination from http-server-address and/or https-server-address. If the port is the default port for the scheme (eg 80 for HTTP and 443 for HTTPS) then it can be omitted. By default, the expected values are the exact values passed to http-server-address and https-server-address OR the exact raw-IP and port that the client is connecting to.

http-alias

This is any Host:Port string and can be used multiple times.

This configuration provides additional valid values for the HTTP Host: header. For instance, mydomain.com:8000 , api.mydomain.com:8000 , localhost:8000.

[heifner]

See #4507 for documentation on new RPC get_raw_code_and_abi

[wanderingbort]

see #4526 for documentation about Yubi Key support. Secure Enclave Docs are inbound

[wanderingbort]

Building keosd with SecureEnclave Support (PREVIEW RELEASE)

In order to access the SecureEnclave an app must be signed. For debugging and testing purposes, keosd can be self-signed by a developer.

In order to do this an active Apple ID and xcode will be required

Step 1 Create Developer Signing Cert

1. Open xcode and click on Xcode->Preferences... in the menu bar.
2. click on the "Accounts" tab
3. select or add your apple ID to the left side list
4. click "Manage Certificates..."
5. click the plus sign in the bottom left and select "Mac Development"

this should download a developer signing cert from Apple. You will need the the SHA1 fingerprint of this certificate later. This can be found by opening the "Keychain access" app, selecting the "login" entry on the left, selecting the "Mac Developer: ..." certificate on the right and clicking the i button on the bottom.

You should see a dialog with information including the "Organizational Unit" towards the top and "SHA1 fingerprint" towards the bottom at the bottom. You will need these to proceed.

Step 2 create a signing profile

In order to sign keosd we need to create a profile using xcode

1. open xcode
2. create a new project and select "Cocoa App" for "macOS"
3. set a Product Name and Organization Name to something memorable
   • observe the resulting Bundle Identifier, it will be important later
4. complete the new project wizard
5. under the "General" settings "Signing" section click "Enable Development Signing"
6. under the "General" settings "Signing" section Select your Personal account as the "Team"
7. press Command-B or use the menu to build, this will ask you for your password for keychain access. Enter your password and click always allow

You can now close xcode

Your signing profile should be present in ~/Library/MobileDevice/Provisioning Profiles/<uuid> you will need this path to continue

Step 3 build signed keosd

cmake requires extra parameters in order to build a signed keosd given the certificate and provisioning profile previously created. these are:

• -DMAS_CERT_FINGERPRINT which is the SHA1 fingerprint you collected in step 1. For example -DMAS_CERT_FINGERPRINT=9F62000000000000000000000000000000008391
• -DMAS_BASE_APPID which is <Organization Unit from step 1>.<organization name from step 2>. Note the trailing period. For example -DMAS_BASE_APPID=95000000YJ.myorg.
• -DMAS_PROVISIONING_PROFILE which is the full absolute path to the provision profile. for instance -DMAS_PROVISIONING_PROFILE=/Users/alice/Library/MobileDevice/Provisioning Profiles/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.provisionprofile
• -DMAS_KEYCHAIN_GROUP which is <Organization Unit from step 1>.<any string with dots> and defines a group of apps that can share access to the keys. for example -DMAS_KEYCHAIN_GROUP=95000000YJ.mykeys

Once built with these cmake parameters in addition to the normal paramters you can find and run keosd normally at <build director>/keosd.app/Contents/MacOS/keosd

[wanderingbort]

for using keosd with secureEnclave refer to #4244

[taokayan]

see #3274 for bidname updates.

[arhag]

See this comment for documentation on the checkpoints feature.

See this comment for documentation on the exporting to and importing from the portable reversible block database.

See the README of the eosio.sudo contract for documentation on that contract (it includes how to use the cleos sudo exec sub-command).

The guide in that README is also a great source for documentation on the cleos multisig propose_trx sub-command.

[jiangweifeng]

Building keosd with SecureEnclave Support (PREVIEW RELEASE)

For Step 2, item 5, "Enable Development Signing" is not found, and there is a checkbox "Automatically manage signing". And I only see an empty folder "Provisioning Profiles", nothing is there. I tried to set "Provisioning Profile", there are "Import" & "Download" options, Download shows "No Valid Teams".

Please let me know what to do to complete the settings.