[BUG] dicedb-spill source repository is unavailable while Spill is shipped in official DiceDB distribution

Summary

The DiceDB repository currently references dicedb/dicedb-spill as a Git submodule, but that repository is no longer publicly accessible.

At the same time, Spill is still presented as part of DiceDB and is enabled in the official Docker distribution.

I'm opening this issue to clarify the current source-availability and build-provenance status of Spill. I have not found evidence that Spill is malicious or contains a backdoor. My concern is that users can no longer independently inspect or reproduce an important native component included with the official DiceDB distribution.

Current observations

The current .gitmodules contains:

[submodule "modules/dicedb-spill"]
    path = modules/dicedb-spill
    url = [email protected]:dicedb/dicedb-spill

However, dicedb/dicedb-spill currently returns a GitHub 404.

Because GitHub also returns 404 for private repositories, I cannot determine externally whether the repository was:

• deleted,
• made private,
• transferred elsewhere, or
• otherwise made unavailable.

I therefore want to avoid assuming the reason for its disappearance.

Spill is still part of the distributed product

The DiceDB README currently states that the official Docker image starts with the spill module enabled.

The DiceDB documentation similarly documents:

--loadmodule /usr/local/lib/lib-spill.so

and describes Spill as the component providing RocksDB-backed storage tiering.

DiceDB 1.0.0 also explicitly listed:

Spill Integration: Added Spill as a Git submodule to support future storage enhancements

The parent repository contains subsequent commits updating the Spill submodule as well.

For example, commit 8f49676 ("[DICEDB] Updating dicedb-spill") updated the Spill submodule from:

8ff21ca -> fb1cd65

and describes changes including per-database RocksDB isolation and FLUSHDB/FLUSHALL handling.

The currently referenced Spill commits cannot be retrieved from the referenced upstream repository.

Why I think this is important

lib-spill.so is not an external service or a loosely coupled optional tool. It is a native Valkey module loaded directly into the DiceDB server process.

Inspection of the distributed binary shows an exported ValkeyModule_OnLoad entry point and use of the Valkey Module API. The module initializes RocksDB and hooks DiceDB's pre-eviction and pre-miss notifications in order to spill and restore keys.

That means the module executes native code with the privileges of the DiceDB server process.

Again, I have not found evidence of malicious behavior in the binary I inspected. The concern here is provenance and auditability rather than an allegation of compromise.

At present, a user attempting to audit the complete software being distributed appears unable to establish the full chain:

public Spill source
        ↓
specific source commit
        ↓
public/reproducible build process
        ↓
lib-spill.so
        ↓
official DiceDB Docker image

Questions for the maintainers

Could you clarify the current status of dicedb/dicedb-spill?

Specifically:

1. Was the repository deleted, made private, or moved?

2. If it was moved, where can the current public source be found?

3. Is Spill still intended to be open source?

4. What source commit corresponds to the lib-spill.so currently distributed in the official Docker image?

5. Is it possible to build the complete official DiceDB distribution, including lib-spill.so, entirely from publicly available source today?

6. Are build instructions or release provenance available for reproducing lib-spill.so?

7. If Spill is intentionally no longer publicly source-available, could that be documented clearly in the README and DiceDB documentation?

Suggested resolution

If the source repository became unavailable unintentionally, restoring it would resolve most of this concern.

If active development has stopped, an archived/read-only public repository containing the commits referenced by DiceDB would also preserve auditability.

It would additionally be helpful to document which Spill source commit corresponds to each distributed DiceDB release/image.

If Spill has intentionally become private/proprietary, documenting that distinction would help users accurately understand which portions of the distributed DiceDB system are publicly auditable.

Thanks for clarifying. My goal with this issue is to establish the provenance and current source-availability status of the component, not to imply that its disappearance is evidence of malicious behavior.