Changelog

Each release is published as a GPG-signed tag on GitHub. Verify the tag before you install, as described in the security best practices. Security fixes are detailed in the security bulletins, which say for each issue whether existing shares need to be regenerated.

v1.4.2 (2026-10-23)

The share format and the encrypted file format do not change. Shares and .enc files produced by v1.4.0 and v1.4.1 decrypt with v1.4.2.

Security

These fixes are described in bulletin FSB-2026-02.

  • Package signature verification works. Since v1.4.1 the Docker image could not be built: it called gpg --verify in a base image that has no gpg. The build now installs gnupg, imports the signing key, verifies packages/CHECKSUMS.sha256, then removes gnupg from the image. The bootstrap scripts import the same key. When gpg is absent, as on some air-gapped machines, they print a warning and fall back to the SHA-256 check instead of aborting the install.
  • The signing key ships with the source. fractum-signing-key.asc is now part of the release package, so the signature can be checked offline without a keyserver.
  • Output files are readable by their owner only. The .enc file, the share archives and the recovered plaintext are created with mode 0600. They previously followed the process umask, which is 0644 on most systems, so other local users could read them.
  • No share material is left behind after a failed decrypt. Extracted share files are removed from the temporary directory in every case. Before, an invalid or unreadable share skipped the cleanup.
  • Plaintext share files are protected while they exist. During fractum encrypt, each share is written to a JSON file before it is archived. That file is now created 0600, and it is deleted even if archiving fails. Before, an archiving error, a full disk for example, left every share of the set on disk in clear.
  • Core dumps are disabled. At startup, before any command runs, Fractum sets the core dump limit to zero (and, on Linux, marks the process as non-dumpable). A crash while the AES key is in memory can no longer write it to a core file. On platforms without this control, Windows in particular, Fractum prints a warning and continues.
  • Key material is held in buffers that can be wiped. The reconstructed AES key and the shares loaded from disk are now bytearray objects, which Fractum overwrites after use. The internal wipe function now refuses immutable bytes. Before, it accepted them, wiped a copy, and left the original in memory.

Changes

  • One directory per share set. When shares/ already holds files, fractum encrypt writes the new set to shares/set-2/, then shares/set-3/, and so on, and tells you where. An empty shares/ is used as is. Before, a second run added its shares to the existing shares/ directory, and nothing in the file names told the two sets apart. Decrypting then failed with "No compatible shares found" even though the right shares were in the folder. To decrypt a later set, point --shares-dir at its own directory, for example --shares-dir shares/set-2.

  • Thresholds above 5 decrypt in the default mode. Shares written without --full-metadata do not record the total number of shares, and Fractum fell back to 5. A set with a threshold above 5, a 6-of-9 for example, then failed with "No compatible shares found", and could not be reused with --existing-shares. Fractum now falls back to the threshold. Existing 6-of-9 shares written by v1.4.0 and v1.4.1 decrypt with v1.4.2.

License and documentation

  • LICENSE is now the unmodified Apache License 2.0 text. The rules on the Fractum name and logo moved to a separate TRADEMARK.md, and the project is no longer described as proprietary.
  • The documentation now says that Fractum splits the AES key into shares, not the file itself. The encrypted file is a single .enc file.

v1.4.1 (2026-07-15)

  • The offline Docker build works: setuptools and wheel are now vendored in packages/, so the build no longer needs PyPI.
  • A linux/aarch64 wheel of PyCryptodome is vendored, so the offline build also works on ARM machines.
  • Files encrypted by an earlier 1.x version are accepted. The version check required an exact version match and refused them.
  • Share archives are checked for compression ratio and total size before extraction, so a crafted archive cannot fill the disk (FSB-2026-03).
  • In the default (minimal metadata) mode, Fractum now says that the label is not written into the shares (#32).
  • An incomplete error handler in manual share entry was fixed.

v1.4.0 (2026-07-01)

Fixes three issues described in bulletin FSB-2026-01.

Security

  • Encrypted-file metadata is authenticated by AES-256-GCM, so any change to it is detected at decryption.
  • The plaintext hash is no longer stored in the encrypted file's metadata.
  • Each share carries a hash, so a corrupted or modified share is detected before reconstruction.
  • Shares carry minimal metadata by default. The label, the total share count, the share set ID and the tool integrity details are only written with --full-metadata.
  • Key handling uses mutable buffers, memory locking where the platform allows it, and explicit clearing of reconstructed share data.
  • Random bytes come directly from the operating system.
  • Decryption refuses to overwrite an existing output file.
  • Share archives are extracted into dedicated temporary directories that are cleaned up.

Changes

  • --label is optional and defaults to the input file name.
  • .enc files are no longer copied into every share archive. --bundle-encrypted restores that behaviour for those who want it.
  • Manual share entry asks only for the threshold and the shares needed for reconstruction, and accepts Base64 or hexadecimal values.
  • Clearer error messages for duplicate share indices, corrupted shares, incompatible share sets, version mismatches and refused overwrites.
  • Shares in the older formats remain readable.

Supply chain

  • The Docker base image is pinned by digest, and GitHub Actions by commit SHA.
  • The release workflow is hardened against shell injection.
  • Vendored packages come with a checksum file, verified by the installers.
  • The bootstrap scripts verify the SHA-256 of what they download on Linux, macOS and Windows.

v1.3.0 (2025-06-23)

  • The share verification feature was removed. It gave a false sense of security.
  • Manual mode (-m) asks its questions in the right order, and the threshold and total share count are shown at the start.
  • Clearer --help output.
  • Python 3.12.11.
  • Code formatted to PEP 8, initialization code moved out of __init__.py files.

v1.2.0 (2025-06-02)

  • Quality and security analysis tools added to the development workflow.

v1.1.0 (2025-05-22)

  • Code split into modules (CLI, cryptography, shares, utilities).

v1.0.0 (2025-05-15)

  • First public release.