Source Code Validation — Ensuring Integrity of XRPL Builds

[dangell7]

Source Code Validation — Ensuring Integrity of XRPL Builds

Title: Source Code Validation
Type: Draft
Author:
Denis Angell, XRPL-Labs (dangell7)
Affiliation: XRPL-Labs

Problem Statement

In the development and deployment of software, ensuring the integrity and authenticity of the source code is paramount, especially for systems handling financial transactions like the XRPL. Currently, there is no standardized method to verify that the source code used to build the software matches the original source code. This lack of verification can lead to security vulnerabilities, as malicious alterations to the code could go undetected. To address this issue, we propose a new amendment that introduces a robust framework for validating the source code used in XRPL builds. This will enhance security by ensuring that the software being executed is indeed the software that was intended to be built.

Limitations of GPG Key Verification

While GPG key verification is a useful method for ensuring the authenticity of software packages, it is not as secure as hash verification. GPG keys can be compromised, and if an attacker gains access to a trusted key, they could sign malicious code, making it appear legitimate. In contrast, hash verification directly compares the generated hash of the source code with the expected hash, providing a more robust assurance that the code has not been altered.

Optional Implementation

It is important to note that the implementation of this source code validation framework is optional. Developers and organizations can choose to adopt this mechanism based on their security requirements and risk assessments. For those who prioritize enhanced security, especially in production environments, this validation process can serve as an additional layer of protection against unauthorized code modifications.

Amendment

The proposed amendment introduces a new framework for validating the source code used in XRPL builds, providing a method to ensure that the software being executed matches the original source code.

The amendment adds:

• A new function and script for hashing the source code.
• Modifications to the rippled.cfg file to include new stanzas for public keys and signatures.
• A verification process that utilizes the public keys, signatures, and generated hash to confirm the integrity of the source code.

New Configuration Stanzas

The rippled.cfg file will be updated to include the following new stanzas:

• strict: A list of public keys / signatures used for verification.

Example rippled.cfg entries:

[strict]
<public_key_1>:<signature_1>
<public_key_2>:<signature_2>

Verification Process

When starting the software, the following steps will be executed:

1. Hash Generation: The software will compute the SHA256 hash of the binary file generated from the source code. This is done using the computeBinaryHash function, which reads the binary file and generates the hash.

   std::string configHash = computeBinaryHash(sourceDir);

2. Configuration File Parsing: The software will read the strict stanza public keys and signatures from the rippled.cfg file. Each entry in the [strict] section will be split into a public key and its corresponding signature.

3. Signature Verification: For each public key and signature pair, the software will:

   • Convert the public key from hex to binary.
   • Convert the generated hash from hex to binary.
   • Verify the signature against the public key and the generated hash using the ripple::verify function.

   if (!ripple::verify(publicKey, makeSlice(*hash), makeSlice(*sig))) {
       Throw<std::runtime_error>(
       "The hash generated does not match the publickey/signature in the config file.");
   }

4. Execution Control: If any verification fails, the software will not start, ensuring that only valid source code is executed.

Example Hashing Script

A Bash script is provided to compute the hash of the binary:

#!/bin/bash

# Check if the source directory and output binary name are provided
if [ "$#" -ne 1 ]; then
    echo "Usage: $0 <output_binary>"
    exit 1
fi

OUTPUT_BINARY=$1
BINARY_HASH_FILE="binary_hash.txt"

echo "Computing hash of the binary $OUTPUT_BINARY..."
BINARY_HASH=$(openssl dgst -sha256 -hex "$OUTPUT_BINARY" | awk '{ print $2 }')

echo "$BINARY_HASH" > "$BINARY_HASH_FILE"
echo "Binary hash saved to $BINARY_HASH_FILE"

[mvadari]

The hashes are already published on xrpl.org as a norm - for example, see https://xrpl.org/blog/2024/rippled-2.2.3#install-/-upgrade

[ximinez]

Would the config file need to be updated every time the operator installs a new version?

If that's the case, how about adding a link to an external file (similar to [validators_file] / validators.txt) to hold the [strict] stanza, and which package maintainers could force-update with every new version?

[dangell7]

Superseded by #659. It keeps the idea here of signatures from parties the operator chooses, and moves verification out of the binary: releases build reproducibly, rebuilders attest each release on ledger, and the installed node checks the next package before install. @ximinez your external file suggestion became the trust policy file.