SAS verification completes and the device shows as verified in moho, but the signature is never uploaded — crypto.rs:217-224 skips SignatureUpload, and verification.rs:164 discards the upload returned by Sas::confirm().
This is a deliberate scope decision (self-verification only, no cross-signing — documented at crypto.rs:20-31), and the scope is defensible. The problem is the silence: somebody verifies a session, sees a tick, and reasonably concludes Element will agree. It will not.
Done looks like: either bootstrap cross-signing and upload signatures, or say plainly in MatrixAccountTools.tsx that verification here is local to moho. The second is small and honest; the first is the real fix.
SAS verification completes and the device shows as verified in moho, but the signature is never uploaded — `crypto.rs:217-224` skips `SignatureUpload`, and `verification.rs:164` discards the upload returned by `Sas::confirm()`.
This is a deliberate scope decision (self-verification only, no cross-signing — documented at `crypto.rs:20-31`), and the scope is defensible. The problem is the silence: somebody verifies a session, sees a tick, and reasonably concludes Element will agree. It will not.
**Done looks like:** either bootstrap cross-signing and upload signatures, or say plainly in `MatrixAccountTools.tsx` that verification here is local to moho. The second is small and honest; the first is the real fix.
Closing this as the honesty fix rather than the feature, which is what the issue asked for: cross-signing is out of scope by design (crypto.rs:20-31), and the problem was the silence around that, not the scope.
The sessions panel now says plainly that verifying marks a session as trusted in moho, and that other clients will still show it unverified because moho does no cross-signing.
That matters more than it sounds. Somebody verifies a session, sees a tick, opens Element, and finds the same device listed as unverified — and the reasonable conclusion is that one of the two clients is broken. A missing feature that is named is a limitation; an unnamed one is a bug report waiting to happen.
If cross-signing itself is wanted later — bootstrapping master/self-signing/user-signing keys and uploading signatures — that is a considerably larger piece and deserves its own ticket rather than being folded in here.
Finished — https://git.salastil.com/Salastil/moho/commit/2fcf085
Closing this as the honesty fix rather than the feature, which is what the issue asked for: cross-signing is out of scope by design (`crypto.rs:20-31`), and the problem was the silence around that, not the scope.
The sessions panel now says plainly that verifying marks a session as trusted **in moho**, and that other clients will still show it unverified because moho does no cross-signing.
That matters more than it sounds. Somebody verifies a session, sees a tick, opens Element, and finds the same device listed as unverified — and the reasonable conclusion is that one of the two clients is broken. A missing feature that is named is a limitation; an unnamed one is a bug report waiting to happen.
If cross-signing itself is wanted later — bootstrapping master/self-signing/user-signing keys and uploading signatures — that is a considerably larger piece and deserves its own ticket rather than being folded in here.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
SAS verification completes and the device shows as verified in moho, but the signature is never uploaded —
crypto.rs:217-224skipsSignatureUpload, andverification.rs:164discards the upload returned bySas::confirm().This is a deliberate scope decision (self-verification only, no cross-signing — documented at
crypto.rs:20-31), and the scope is defensible. The problem is the silence: somebody verifies a session, sees a tick, and reasonably concludes Element will agree. It will not.Done looks like: either bootstrap cross-signing and upload signatures, or say plainly in
MatrixAccountTools.tsxthat verification here is local to moho. The second is small and honest; the first is the real fix.Finished — https://git.salastil.com/Salastil/moho/commit/2fcf085
Closing this as the honesty fix rather than the feature, which is what the issue asked for: cross-signing is out of scope by design (
crypto.rs:20-31), and the problem was the silence around that, not the scope.The sessions panel now says plainly that verifying marks a session as trusted in moho, and that other clients will still show it unverified because moho does no cross-signing.
That matters more than it sounds. Somebody verifies a session, sees a tick, opens Element, and finds the same device listed as unverified — and the reasonable conclusion is that one of the two clients is broken. A missing feature that is named is a limitation; an unnamed one is a bug report waiting to happen.
If cross-signing itself is wanted later — bootstrapping master/self-signing/user-signing keys and uploading signatures — that is a considerably larger piece and deserves its own ticket rather than being folded in here.