search

cryptomator / cryptomator-win

Cryptomator .exe installer for Windows
GNU General Public License v3.0
21 stars 12 forks source link

Update registry to match macOS #36

Closed JaniruTEC closed 3 years ago

JaniruTEC commented 3 years ago

This PR continues the efforts made in https://github.com/cryptomator/cryptomator-win/pull/35 and aims to mirror the changes introduced by https://github.com/cryptomator/cryptomator-mac/pull/7 on macOS. The windows installer will contain the same feature set as the matching file on macOS after this PR is merged. This PR is required to close https://github.com/cryptomator/cryptomator/issues/1089 - see there for general motivation and reasoning.

JaniruTEC commented 3 years ago

A note on HKA vs. HKCR: In administrative install mode the effect is the same for both Roots: Keys are written to HKLM/Software/Classes. In local user install mode the effects differ: Keys are written to HKLM/Software/Classes for HKCR and to HKCU/Software/Classes for HKA. The current setup (with it's deletions, etc.) works fine with administrative install, but may cause problems if we open installations for local users. Since it's not recommended to remove the file extension keys (like .cryptomator), I changed the script to only delete the ProgIDs (like Cryptomator.MasterkeyFile.1). If the user now installs Cryptomator version X in local mode and installs version X+1 in admin mode, changes to the file extensions in X (like changing the MIME Type) still will outrank the newer administrative changes (like updating the ProgID version). As mentioned this will only cause problems in the very specific scenario that the user installs an admin version over a local user version and will only affect the file extension entry, not the matching ProgID.

See here for info about HKCR and here for info about HKA.

overheadhunter commented 3 years ago

Since it's not recommended to remove the file extension keys (like .cryptomator), I changed the script to only delete the ProgIDs (like Cryptomator.MasterkeyFile.1).

How does appending .1 to an arbitrary string protect a key from being deleted?

If the user now installs Cryptomator version X in local mode and installs version X+1 in admin mode, changes to the file extensions in X (like changing the MIME Type) still will outrank the newer administrative changes (like updating the ProgID version).

Can you please explain what a ProgID or ProgIDVersion is? Edit: Ok I figured out, that ProgID is the name, MS uses and ProgIDVersion is your creation for the version suffix.

Who defines/changes the value? Edit: We do. But when should we increase it? What benefit does it have?

Why should the mime type differ between user or system-wide installation? Edit: Ok the mime type is not versioned, just the program association, right? So let's assume we had two hypothetical versions installed in parallel. How does a versioned ProgID help? The association still would point to only one version. Would it automagically fallback to the other version, if the former gets uninstalled? If not, I really don't see the benefit.

JaniruTEC commented 3 years ago

Generally speaking the Registry registers file extensions like this:

  1. Create a key for the actual extension (e.g. .cryptomator) in HKCR (or HKLM/Software/Classes)
  2. Create a matching ProgID (e.g. Cryptomator.MasterkeyFile)
  3. Link the ProgID in the extension key
  4. Define behavior for the extension in the ProgID

The benefit of this approach can be seen on the .c9r and .c9s extensions. Both reference the same ProgID, thus share the same Icon, description and behavior on doubleclick, but don't necessarily share a MIME Type or perceived type.

How does appending .1 to an arbitrary string protect a key from being deleted?

Those are different matters. Microsoft recommends to not delete the extension from the registry in case the user switched out the ProgID for a different one, that means: Changed the app that opens the file (another benefit of the dual approach) ProgIDs should be deleted on uninstall (and install to clean them up and start fresh). If a extension contains a deleted/unknown ProgID, Windows falls back to asking the user.

Can you please explain what a ProgID or ProgIDVersion is? Edit: Ok I figured out, that ProgID is the name, MS uses and ProgIDVersion is your creation for the version suffix.

ProgID: See above Microsoft recommends using versioned ProgIDs to enable multi-version-install and allow better maintenance from a dev perspective. In fact I ran into a problem yesterday and using a versioned ProgID was the easiest solution. ProgIDVersion is just the current version suffix.

Who defines/changes the value? Edit: We do. But when should we increase it? What benefit does it have?

As you said, we do. Increasing is usually is only necessary if the change something about the ProgID structure and need to make sure changes are reflected correctly. Also having a version ProgID allows better control by scripts on installation time.

Why should the mime type differ between user or system-wide installation? Edit: Ok the mime type is not versioned, just the program association, right? So let's assume we had two hypothetical versions installed in parallel. How does a versioned ProgID help? The association still would point to only one version. Would it automagically fallback to the other version, if the former gets uninstalled? If not, I really don't see the benefit.

The ProgID is versioned, the file extension only references the versioned ProgID. The file extension wouldn't fallback to the other ProgID, but switching and updating becomes easier because a ProgID can be called "by name". See: https://web.archive.org/web/20210203223928/https://docs.microsoft.com/de-de/windows/win32/shell/fa-progids#using-versioned-programmatic-identifiers