Light mode skips signature verification

[Carrotrust]

validation.js's top-level validate() function, when conf.bLight is true, returns success for any joint without a ball field before ever reaching validateAuthors() / Definition.validateAuthentifiers() — i.e. before any cryptographic signature is checked at all:

// validation.js:340-348
if (conf.bLight){
    if (!isPositiveInteger(objUnit.timestamp) && !objJoint.unsigned)
        return callbacks.ifJointError("bad timestamp");
    if (objJoint.ball)
        return callbacks.ifJointError(lightStableErrorMessage);
    return objJoint.unsigned 
        ? callbacks.ifOkUnsigned(true) 
        : callbacks.ifOk({sequence: 'good', arrDoubleSpendInputs: [], arrAdditionalQueries: []}, function(){});
}

validateLight() (validation.js:97-116) is a thin synchronous wrapper around this same validate(), and is exactly what light.js's processHistory calls on every joint in a hub's light/get_history response (light.js:245). Two checks that would have caught this were deliberately commented out (light.js:241-244, 251-252, commit 4975d23) with the justification "we receive unconfirmed units too" — a legitimate reason to accept genuinely unconfirmed/pending units, but that only justifies skipping the stability/proofchain check, not skipping signature verification entirely, which appears to be an unintended side effect rather than a considered decision.

Impact: a malicious or compromised light-vendor hub can inject a fully fabricated joint (arbitrary author address, garbage/empty authentifiers, self-consistent attacker-computed hash) into a get_history response, with a payment input referencing a victim's real, currently-unspent output. writer.saveJoint accepts it (since validateLight returned success), and light.js's fixIsSpentFlag (light.js:448-469) then flips the victim's real output to is_spent=1 in the local wallet database, based on nothing but this unverified, forged inputs row — with zero cryptographic basis. The victim's wallet will refuse to spend that real, intact output for as long as they stay connected to the malicious hub (the light-vendor URL is sticky and doesn't auto-fallback, and the 24h self-correction path queries the same hub that lied in the first place).

Note on real-world impact: the underlying value is never destroyed or moved to the attacker — it's a false-spent flag local to one victim's light-client database, recoverable by switching light vendor or re-importing the same seed elsewhere. This is why it doesn't meet a fund-loss bar, but it's still a real breach of the light-client protocol's core trust model (a light client is supposed to be safe against a lying hub for exactly this kind of thing).

Suggested fix: for unstable (non-ball) joints in light mode, still require and verify validateAuthors()/signature checks against the unit's declared author definitions, rather than skipping straight to ifOk.

[tonyofbyteball]

That's the intended behavior (for now). validateAuthors() is not always just validation of signatures, it might also include querying data feeds, attestations, 'seen address', etc -- data that is no easily available on light nodes. If you know how to validate transactions in all cases, I'll be happy to hear your ideas.

[Carrotrust]

Thanks for the context, that makes sense for the general case. One idea that might help without needing a full solution: sig verification itself only needs the address's definition (already fetched by light clients), the authentifier, and the unit hash ,no data feeds or attestations required. So that part could be checked even under current constraints.

For definitions that mix sig with data feed/attestation branches, a short-circuit evaluation could work without solving the general case:

• or: if any locally checkable branch is true, the unit is authorized regardless of the rest.
• and: if any locally checkable branch is false, it's unauthorized regardless of the rest.
• Otherwise, fall back to today's behavior (unverified until stable).
  This wouldn't cover every definition, but since most addresses are plain sig or simple combinations of it, it could close the forged signature gap for the majority of cases. Happy to elaborate if it's useful.

[tonyofbyteball]

That could work but would add quite some branching if we add a "light mode" in validateAuthentifiers().

sig verification itself only needs the address's definition (already fetched by light clients),

where is it fetched?

[Carrotrust]

Fair catch, "fetched" was the wrong word. For your own address, nothing is fetched at all: the definition is generated locally when the wallet creates the address and stored in its own my_addresses table (initial-db/byteball-sqlite-light.sql:497-506, definition TEXT NOT NULL). No network round-trip needed.
For third-party addresses there's a hub-side light/get_definition_for_address (network.js:3813-3869), but I couldn't find where ocore calls it client-side, so I can't speak to that case with the same confidence.
On the branching concern, this wouldn't need general branching in validateAuthentifiers(). Just a narrow check before the existing light-mode skip: if the joint's claimed author is one of the wallet's own addresses, verify that signature against the locally-stored definition. Small and self-contained.