Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

EOSIO 1.2.3 Release Notes
Compare
Choose a tag to compare
@arhag arhag released this 28 Aug 22:52
· 11695 commits to master since this release
v1.2.3
e87d245
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

This release provides bug fixes and regression tests.

Description of the Issues

Deprecation of the ability of a notified contract to bill RAM to authorizers of the original action

EOSIO blockchains enable a useful feature which allows one contract executing an action to notify another contract of the action because it may pertain to it. EOSIO blockchains have up to now had an additional capability which allows the notified contract to bill any of the authorizers of the original action for the RAM costs of storing data in the blockchain state. This powerful, but ultimately undesirable, capability has allowed smart contracts to adopt a common pattern of executing sophisticated operations which consume RAM in response to receiving tokens from a transfer action; however, the capability has also been abused by malicious contracts to waste the available RAM of users.

For this reason, this additional capability of allowing a notified contract to bill additional RAM to the authorizers of the original action is now deprecated. Legitimate smart contracts that currently utilize this capability can upgrade to instead use more appropriate patterns (such as the one discussed in the description of #5451). This release introduces a mitigation (#5451) to subjectively restrict this capability if all active block producers of the blockchain deploy the mitigation. An objective solution will be introduced at a later date.

For more information about these changes, please see: https://medium.com/@bytemaster/preventing-unexpected-ram-consumption-8029a9342659

Fixes to CPU greylist feature (#5462)

The greylist feature (or the ability for block producers to subjectively throttle the bandwidth resource usage of certain accounts to only what they are allowed to use under high blockchain load) was a feature introduced in version 1.1.0 (see #4368 and #4410). However, the original implementation of the feature did not make a distinction between CPU resource exhaustion errors caused due to greylisting (which are subjective) versus those caused by the normal objective reasons, which could potentially lead to retiring deferred transactions in a generated block with a status that is not reproducible by validating nodes. This release made changes to mark that distinction which not only makes the error messages due to greylisting more descriptive but also may solve a source of missed blocks for block producers.

Regression Tests for Previous Security Issues

This release includes regression tests that cover issues fixed through version 1.1.1. Regression tests lag the disclosing release(s) by one-month to enhance the security of operational networks.

Other

  • [nodeos] Fix framework casing for case sensitive MacOS builds (#5403)
  • [eosiocpp/eosio-abigen] Fixed eosiocpp ABI generation error (#5401)
  • [eosiocpp/eosio-abigen] Fixed bug ignoring action name in ABI generation (#5459)
  • [nodeos] Fixes to bnet threading issues (#5417)
  • [nodeos] Reduce error log output in net_plugin (#5423)
  • [nodeos] Do not apply transaction optimizations on light-nodes when speculating (#5415)
  • [cleos] Do not modify transaction during push transaction if it is already signed (#5461)

Mitigations

  • Nodes running version 1.2.3 will by default subjectively reject transactions in which a contract executing an action notification handler tries to bill RAM to any other account. The subjective rejection can be disabled on a node by setting the disable-ram-billing-notify-checks boolean field to true in config.ini. This mitigation, if adopted by all active block producers of an EOSIO blockchain, will protect contracts and users of that blockchain from malicious contracts which attempt to waste the available RAM of accounts that (indirectly) trigger the execution of those malicious contracts. Enabling this mitigation, however, disables a common pattern found in some EOSIO-based smart contracts (e.g. creating a new database table row in response to an eosio::transfer action directed to the contract as a recipient), which may disrupt the operation of effected smart contracts until they are updated to use more appropriate patterns (see #5451 for details).
Assets 2
Loading