bleedingdeacons / link / 34694204606
92%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 21
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 93.349%. Remained the same
34694204606

push

github

web-flow 
fix: correct what a lost device key actually costs (#42)

Six places across Link and Fellowship said that replacing a handset's
keypair leaves every message sent before it permanently unreadable, and
reasoned the same way each time: the messages were sealed to a public key
whose private half is gone, Fellowship never held that half, so nobody
can re-seal them.

The second step does not follow. Fellowship is not storing sealed
messages. It stores bodies in plain text and seals them on every fetch,
to whichever public key the asking device presents --
MessageController::inbox calls seal(payloadFor($message),
$device->publicKey) per poll. So once a new key is presented the next
sync re-delivers everything still inside the retention window.

What is genuinely lost is narrower: what the server has already swept,
and any push sealed and sent before the change, because nothing re-sends
a push.

THE WORST OF IT WAS USER FACING. The confirmation dialog on Settings told
a member that messages already sent "cannot be recovered -- nobody,
including the intergroup, can unlock them now" before they tapped the one
button that fixes their phone. It now says what happens.

The specs were passing on the same mistake, which is the part worth
fixing properly rather than editing prose around. FakeFellowshipClient
held pre-sealed envelopes, so it modelled a store-sealed server that does
not exist, and KeyLoss.feature asserted the false claim happily. It now
holds payloads in the clear and seals them at fetch, to a public key the
server holds separately from whatever the handset is carrying -- which is
the actual asymmetry, and is what makes a lost keystore entry
reproducible without pretending the server cannot recover from it.

Three new scenarios say what really happens: everything comes back once
the new key is presented; until it is presented the server goes on
sealing to the old one; and a push is the one delivery genuinely lost,
because nothing re-sends it.

The cons... (continued)

1193 of 1278 relevant lines covered (93.35%)

15.41 hits per line

Coverage Regressions

Lines Coverage ∆ File
8
88.46
0.0% Models/MessagePayloadCipher.cs
1
97.73
0.0% Services/Interfaces/IFellowshipClient.cs
Jobs
ID Job ID Ran Files Coverage
1 34694204606.1 21
93.35
GitHub Action Run
Source Files on build 34694204606