Desktop: attempt to fix #6052: Create arm64 function for cross-compile support

[noah-nash]

(hopefully) Resolves #6052

The network errors referenced in the issue were caused by not downloading the prebuilt keytar module. Creating a separate electron-rebuild command should make it act similar to prebuild-install and make it fetch the proper prebuilt keytar module when building from source is not possible (different architectures). This should also hopefully work towards making a Linux arm64 build as well.

If this does not solve the issue, it may have to be pushed back earlier in the CI build process, before yarn install.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[noah-nash]

I have read the CLA Document and I hereby sign the CLA

[laurent22]

Thanks @noah-nash. Looks like it builds, but there's an unrelated problem with signing the app which I'll check first before merging this. By the way do you understand how keytar could affect the network lib? As I understand, the request headers somehow were not being passed around anymore but I don't see how that could be related to keytar

[laurent22]

@noah-nash, you have some linter errors. Could you run yarn run linter ./ from the root please?

[noah-nash]

My bad. I just linted the code and it should be good now.

[dreness]

By the way do you understand how keytar could affect the network lib? As I understand, the request headers somehow were not being passed around anymore but I don't see how that could be related to keytar

Looks like keytar's job is to manage Joplin credentials by storing and loading them with the appropriate platform-native credential store. HTTP credentials are typically communicated in the form of HTTP headers, so failure to fetch credentials could certainly yield broken headers.

On macOS, a running application is authorized to access items in the keychain (or not) based on the identity in the code signature of that application. The code signature identity is derived from the developer certificate used to do the signing, which is bound to a specific Apple developer account (or the signature is an ad-hoc signature, which is effectively "anonymous and guaranteed unique"). Ad-hoc signatures are really only useful for development purposes, for reasons I'm about to explain.

Any app is allowed to store new items to the keychain, however only the app that stored a keychain item is allowed to retrieve that item (the exception is when using keychain access groups). Updated versions a given app - i.e. with the same bundle ID and signed by the same developer ID - are authorized to access keychain items stored by other versions of that app. Even if it's the exact same software, if the app is signed by a different identity, Keychain considers it to be a distinct app, which is good, otherwise it would be super easy to steal another app's credentials.

[laurent22]

Any app is allowed to store new items to the keychain, however only the app that stored a keychain item is allowed to retrieve that item (the exception is when using keychain access groups). Updated versions a given app - i.e. with the same bundle ID and signed by the same developer ID - are authorized to access keychain items stored by other versions of that app. Even if it's the exact same software, if the app is signed by a different identity, Keychain considers it to be a distinct app, which is good, otherwise it would be super easy to steal another app's credentials.

Indeed that's probably what is is. We store secrets in the keychain using keytar, and since it was broken they weren't being saved anymore. Hopefully this pull request should fix this.

All tests are passing now, thanks @noah-nash, let's see if we can build this arm64 app!