[Info] Unreviewed Security-Relevant TODOs

[tummetott]

Issue Description

The review identified three security-relevant TODOs in production code. As the corresponding logic has not yet been implemented, these code paths could not be fully assessed during the review:

• The secret-loading wrapper serai_env::var, reads directly from process environment variables while noting that secrets should move to a proper secret store and be unset after reading.
• In the runtime, substrate/runtime/src/wasm/mod.rs leaves signature verification weight at zero and wires several pallets with type Weights = (); // TODO, including coins, validator sets, signals, DEX, genesis liquidity, and in-instructions. These placeholders acknowledge that resource costs for security-relevant execution paths are not yet deliberately priced.
• The node service layer carries a consensus-facing TODO in create_inherent_data_providers, where timestamps are taken from system time with a note that they should be bounded according to Serai's own minimum-increment rules.

Taken together, these TODOs identify production code paths where secret handling, runtime pricing, or validation bounds remain unfinished, which prevents a complete security assessment of those behaviors at this commit.

Risk

This issue is informational. The relevant code paths contain explicit TODOs for behavior that is not yet finalized, so these areas could not be fully reviewed at this commit. As a result, the security impact of the eventual implementation remains unclear until the deferred work is completed and the affected paths are reviewed again.

Mitigation Suggestion

Implement the deferred work described by these TODOs and re-review the affected paths once the final behavior is in place.

[StrawberryChocolateFudge]

Seems like serai still has a lot of work ahead.
Are there any paid positions or bounties to solve TODOs ?

[kayabaNerve]

This issue is completely heard. While these topics aren't under the current scope, due to not being complete, there's other comparable topics such as our usage of sc-cli. As it's planned to be replaced, when it's replaced, the replacement will be something eligible for review yet not part of this engagement with/review by SR Labs.

Regarding serai_env::var, serai-env is planned to be an abstract view over some environment. While currently, that is the literal OS environment, that's planned to be replaced with a more secure solution. In practice, the OS environment should be considered insecure as any process on the system would be able to read the environment variables for any other process, effectively storing any environment variables in an anyone-may-read file on the system. This isn't inherently insecure to a fatal degree as it still requires the adversary be able to exfiltrate such a file off a remote system, but is no way near as secure as it reasonably could be. This can also be discussed w.r.t. orchestration/, which also isn't in the current scope, but is intended to resolve as the tooling to spawn and manage our services (with associated security-relevant context and configuration).

For create_inherent_data_providers, that should be fine as-is given synchrony bounds. Specifically, the TODO notes that if one attempts to author a block within half the slot time of the prior block's timestamp, it would produce an invalid inherent that could otherwise be trivially caught within a max(time, prior_time + 3s). Given a sane system time, and slot authoring schedule, this property should be inherently met however. The current logic just isn't fully robust.

[kayabaNerve]

@StrawberryChocolateFudge Serai is sans premine, dev fund, ICO, or similar. Historically, I covered all expenses out of my own pocket, from a developer to external reviews to our bug bounty program, though this decreased my own funds notably and I never accepted donations for my work on Serai (including the work I contracted out). Thankfully, a generous donor did step up and enable one developer to be paid to work on Serai's tests, and some external reviews such as the current one with SR Labs, but Serai isn't a corporate project nor one I have directly received funding for. While it may be possible for more work to be sponsored, there's no explicitly open positions/tasks other than our standing Bug Bounty Program with Immunefi. The project is best seen as a community effort accordingly.