• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

bleedingdeacons / link / 34699228091
92%

Build:
DEFAULT BRANCH: main
Ran 12 Sep 2026 02:26PM UTC
Jobs 1
Files 22
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

12 Sep 2026 02:25PM UTC coverage: 92.917% (-0.4%) from 93.349%
34699228091

push

github

web-flow
feat: prove who is holding the phone before replacing its key (#43)

* feat: prove who is holding the phone before replacing its key

Fellowship now refuses a key rotation on a device token alone, and it is
right to: the inbox seals from plaintext on every fetch, to whatever key
the device row holds, so substituting that key was enough to have every
message inside the retention window re-sealed to a key of the caller's
choosing. The handset keypair could not help -- it seals, and never
authenticates anything.

So the Settings recovery now gathers a credential, by the same three
routes sign-in uses. The browser leg is extracted rather than copied,
because both callers have to agree that a closed tab means silence and a
second copy is how one of them comes to say something instead.

The device row, its token and its place in the intergroup's list all
survive, which is the whole reason this is a rotation and not a
re-enrolment.

Opening the choices is a separate step from using one, so a member who
taps out of curiosity is not immediately in a browser. And the new pair
is generated inside the rotate call rather than by the caller, so backing
out of the browser tab no longer throws away a key on the way.

RotateKeyAsync now takes a request and answers a result carrying the
server's words. "Sign in as the member this phone belongs to" is the one
refusal here somebody can act on, and flattening it into "that did not
work" would waste it. Only the credential shape actually used is sent:
empty fields alongside a real one are how a server comes to guess which
flow it is looking at.

The dialog now says the replacement asks them to sign in again, which is
the part a member would otherwise meet as a surprise.

Needs bleedingdeacons/fellowship#20. Older Fellowship ignores the extra
fields and accepts the rotation as before, so this is safe to ship first.

* feat: offer the key recovery only while there is one to make

Replacing a key now asks a member to sign in ... (continued)

1220 of 1313 relevant lines covered (92.92%)

15.04 hits per line

Coverage Regressions

Lines Coverage ∆ File
12
87.29
0.22% Services/MessageService.cs
11
96.06
-1.71% Services/FellowshipClient.cs
1
96.3
-1.43% Services/Interfaces/IFellowshipClient.cs
Jobs
ID Job ID Ran Files Coverage
1 34699228091.1 12 Sep 2026 02:26PM UTC 22
92.92
GitHub Action Run
Source Files on build 34699228091
  • Tree
  • List 22
  • Changed 3
  • Source Changed 0
  • Coverage Changed 3
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #34699228091
  • abaea935 on github
  • Prev Build on main (#34694204606)
  • Next Build on main (#34699669469)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc