Security Patch

Eliminate denial of service vulnerability

Leap v3.2.4 contains a security patch eliminating a denial of service vulnerability present in all prior versions of Leap.

Bug Fixes

Don't check signatures on dry run transactions

Summary:

Signature checks for dry-run transactions were failing.

Impact:

The previous code failed to handle signature checks correctly for dry-run transactions, leading to unnecessary authorization checks. This issue could potentially result in erroneous behavior and wasted computational resources.

Resolution:

The following actions have been taken to resolve the issue:

• Modified the code to ensure that signature checks do not fail for dry-run transactions.
• Refactored the authorization manager to properly handle dry-run transactions.
• Backported the fixes to the 3.2 release of the software.
• Assigned appropriate milestones and labels to track the progress of the issue.

These improvements ensure that signature checks for dry-run transactions are correctly handled.

Fix i256 key type conversion by initialize buffer before usage

Summary:

There was an issue related to the i256 key type conversion.

Impact:

The previous code had a bug where the export_bits function did not fill every byte in the buffer. This issue could potentially cause unpredictable behavior and incorrect results in code that used the i256 key type conversion.

Resolution:

The following actions have been taken to resolve the issue:

• Modified the code to initialize the buffer before usage, ensuring that every byte is properly filled during the export_bits operation.
• Backported the fix from pull request #1252 to the release/3.2 branch.

Report transaction failed if trx was exhausted in non-producing mode

Summary:

Improved handling of exhausted transactions in non-producing mode.

Impact:

In previous versions, when running in non-default --read-mode speculative, exhausted transactions were not retried until a new block was received. This resulted in delays and potential inefficiencies in transaction processing.

Resolution:

To address this issue, the following changes were implemented:

• Modified the code to restart a speculative block immediately when a transaction is exhausted in non-producing mode, instead of waiting for a new block.
• Updated the logic in the process_incoming_transaction_async function to correctly handle exhausted blocks based on the pending block mode.
• Introduced the in_producing_mode() and in_speculating_mode() members to enhance transaction handling.
• Merged the changes into the release/3.2 branch.

These enhancements ensure that exhausted transactions in non-producing mode are promptly retried, improving the responsiveness and efficiency of transaction processing in Leap v3.2.

leap-util: Require output-dir for extract-blocks subcommand

Summary:

Leap v3.2 requires the output-dir parameter for the extract-blocks subcommand of leap-util block-log.

Impact:

Previously, the output-dir parameter was not enforced for the extract-blocks subcommand, leading to potential filesystem errors and cryptic error messages. Users were not prompted to provide the output directory for the block log extracted from the specified blocks directory.

Resolution:

To address this issue, the following actions have been taken:

• Modified the blocklog_actions::setup function in the programs/leap-util/actions/blocklog.cpp file to make the --output-dir option required for the extract-blocks subcommand.
• Updated the code to enforce the requirement of the output-dir parameter, ensuring that users must provide the output directory.
• Merged the changes into the release/3.2 branch of the AntelopeIO/leap repository.

These improvements ensure that the output-dir parameter is mandatory for the extract-blocks subcommand of leap-util block-log, preventing filesystem errors and providing a clear requirement for users.

Respond to requests with disallowed HTTP HOST header

Summary:

The behavior of the HTTP server in Leap has been improved to provide more informative error responses when the Host header value is not allowed.

Impact:

In Leap version 3.1, when the Host header value was not allowed by the http_plugin, an empty 400 response was returned to the client. However, in version 3.2 and onwards, the connection was simply closed without sending any headers to the client. This behavior change caused confusion and lacked proper error reporting.

Resolution:

The resolution for the issue involved modifications to the http_plugin:

• If the Host header is not allowed, a bad request error response is sent to the client.
• The response includes the HTTP status code and a descriptive message with details of the error.

These improvements ensure that when the Host header value is not allowed, an error response is sent to the client, providing valuable information about the error. The changes enhance the usability and clarity of the HTTP server behavior in Leap.

Fixed incorrect serialization scenario

Summary:

Fixed incorrect serialization of std::optional fields in the AntelopeIO/leap repository. The issue occurred when a value was not provided for a std::optional field during serialization, resulting in missing flags. This PR addresses the problem by adding the necessary flags to properly serialize missing values.

Problem:

Incorrect serialization of std::optional fields when a value is not provided.

Impact:

The missing flags during serialization of std::optional fields led to incorrect representation of missing values.

Changes:

• Added flags to the serialization process to indicate missing values in std::optional fields.
• Updated the ABI serializer and test cases.
• Made changes to the libraries/libfc/include/fc/time.hpp and unittests/abi_tests.cpp files.

Resolution:

Missing values in std::optional fields are correctly serialized, addressing the issue and preventing incorrect representation.

Other Changes

Changes to Logging

Log all HTTP request/response at debug log level

Summary

This pull request introduces the feature of logging all HTTP request and response information at the debug log level. The log output is limited to 1024 characters to prevent excessive logging.

Impact

Previously, there was no comprehensive logging of HTTP request and response data, making it difficult to debug and analyze issues related to HTTP communication. The lack of detailed logging hindered troubleshooting efforts and affected the overall visibility of the system.

Resolution

The following changes have been made to improve logging of HTTP request and response data:

• Modified the logging mechanism to include HTTP request and response information at the debug log level.
• Implemented a limit of 1024 characters for the logged output to prevent excessive logging and avoid overwhelming the log files.

These improvements provide detailed logging of HTTP request and response data, enhancing the system's visibility and aiding in troubleshooting efforts.

Reduce producer_plugin debug level log spam

Summary

This pull request addresses the issue of excessive debug level log messages generated by the producer_plugin. The modification reduces the log spam and improves the log output efficiency.

Impact:

Previously, the producer_plugin was generating an excessive amount of debug level log messages, leading to log spam. This log spam could negatively impact the system's performance and make it difficult to analyze important log information.

Resolution:

Modified the logging condition in the producer_plugin_impl class to log blocks only every 1000 during synchronization or when the time difference between the current time and the block's timestamp is less than 5 minutes. These improvements effectively reduce the log spam generated by the producer_plugin, making the log output more manageable and improving overall system performance.

Changes to Pinned Builds

Summary:

In this release of leap (v3.2), we have introduced a new manual dispatch workflow for Pinned Builds in CI. This workflow allows for more control and flexibility in running Pinned Builds using GitHub Actions.

Changes:

To enable the manual dispatch workflow for Pinned Builds, the following actions were taken in leap v3.2:

1. Build-script changes to enable manual dispatch.
2. Pinned builds now run seamlessly in GitHub Actions, ensuring reliable and consistent execution.
3. The artifact name for Pinned Builds has been to improve clarity and organization.

Benefits:

The introduction of the manual dispatch workflow for Pinned Builds brings the following benefits:

1. Pinned builds can now be executed in a controlled manner.
2. Improved integration with GitHub Actions for build automation.
3. Enhanced traceability and visibility of Pinned Build execution.

Further details on changes since last release

Contributors

Special thanks to the contributors that submitted patches for this release:

• @huangminghuang
• @heifner
• @vladtr
• @greg7mdp
• @spoonincode
• @oschwaldp-oci
• @PinelliaC
• @learnforpractice

Full list of changes since last release

Full Changelog: v3.2.3...v3.2.4