Visor.app: drop the old Mac apps' migration in the release after the switch

Open
  • Is something wrong?
#210 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, swift
Domain
desktop, security

Research direction

Start in applications/visor_mac/Sources/FormerApps.swift and its call sites in Sources/VisorMacApp.swift, and check that the switch release has already shipped, since this step only applies after it. Remove FormerApps, the reads of the two old keychain services, and the visor.adoptedFormerApps flag, then do the same for VisorServer.formerBundleIDs in libraries/visor_server/Sources/VisorServer.swift and +Access.swift if nothing still runs an older build. Done when the merged change leaves no references to the old bundle ids and a launch on a Mac that had the old apps shows no keychain dialog.

Written by the indexing model from the issue text.

Description

Logan (4 Nov, relayed by Manager) chose to ship the switch to Visor.app with the old apps' secrets carried over: one Always Allow dialog per old keychain item, once per Mac. He also asked that, in the release after the switch, the code that reads the old apps' keychain items and migrates them be removed, not kept around.

Today (applications/visor_mac)

Visor.app keeps using the old apps' places rather than its own. Sources/FormerApps.swift, used in Sources/VisorMacApp.swift:

  • The server's secrets: KeychainSecrets(service: FormerApps.server), under the service com.LoganShire.VisorServer.macOS.
  • The client's secrets and saved computers: NativeVisorSettingsService(keychainService: FormerApps.client), under com.LoganShire.VisorClient.macOS.
  • The message caches: each stays in Application Support under the old app's bundle id (FormerApps.folder(of:)).
  • The client's settings: copied once from the old defaults (adoptClientSettings, guarded by visor.adoptedFormerApps).
  • The server's data folder (Application Support/Visor) is shared and needs nothing.

So as it stands, there's nothing to delete later: the old services are where the data lives.

The two steps

  1. With the switch (the release that ships Visor.app): a one-time copy into Visor.app's own places. On first launch:

    • read each old item (the dialogs Logan accepted) and write it under Visor.app's own service (com.LoganShire.Visor). Items Visor.app makes are its own, so they never prompt.
    • move or copy the two caches into Visor.app's own Application Support folder.
    • from then on, read only its own.

    The old apps' items and folders are left as they are, so the old apps still work if reopened.

  2. The release after the switch: delete the migration:

    • FormerApps and its calls;
    • the reads of com.LoganShire.VisorServer.macOS / com.LoganShire.VisorClient.macOS;
    • the visor.adoptedFormerApps flag.

    A Mac that skipped the switch release would then start fresh: set the server password again and add its computers again. Its release notes should say so.

Also in scope for step 2

VisorServer.formerBundleIDs (com.LoganShire.Visor.MenuBar, libraries/visor_server/Sources/VisorServer.swift and +Access.swift) is an older adoption of the same kind. It could go at the same time, if nothing still runs a build from before it.

Done when

  • Step 1 is part of the switch's pull request.
  • Step 2's pull request is merged into the release after it.
  • On a Mac that had the old apps, a launch of each release shows no keychain dialog after the first.
Dominant language
Swift
Stars
1
Forks
0
Avg merge
7h 43m
Merged PRs (30d)
131

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AttilaTheFun/visor

All issues in AttilaTheFun/visor

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.