Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[desktop/linux] fix & upgrade keytar #3809

Closed
3 tasks done
ganthern opened this issue Jan 18, 2022 · 6 comments · Fixed by #3773
Closed
3 tasks done

[desktop/linux] fix & upgrade keytar #3809

ganthern opened this issue Jan 18, 2022 · 6 comments · Fixed by #3773
Labels
desktop Desktop client related issues maintenance dependency updates, key renewals, code cleanup state:done meets our definition of done state:tested We tested it and are about to release it
Milestone

Comments

@ganthern
Copy link
Contributor

ganthern commented Jan 18, 2022

Stock keytar doesn't tell us whether getPassword can't return a password due to user cancellation or because there's no password saved.

https://github.com/tutao/node-keytar makes that distinction visible on linux

Testing

On Linux specifically:

  • starting tutanota desktop with an unlocked login keychain works as expected and sseInfo, notifications and alarms get loaded (install seahorse to check the keychain)
  • starting tutanota desktop with a locked login keychain will prompt for the password and
    • cancelling shows an error dialog that the keychain is unavailable
    • unlocking the keychain causes startup to proceed normally
@ganthern ganthern added desktop Desktop client related issues maintenance dependency updates, key renewals, code cleanup labels Jan 18, 2022
@ganthern ganthern added this to the Next release milestone Jan 18, 2022
@evilrobot-01
Copy link

Will this build on arm64? I believe the existing keytar was one of the blockers for getting Tutanota running on arm64 Linux, so would be great if this was solved. 🙏

@charlag
Copy link
Contributor

charlag commented Jan 24, 2022

@EVLRBT-01 it's not a blocker anymore since we build keytar on our own anyway. We just don't provide ARM builds yet, for either Linux or Mac. Someone could just do it (like AUR does probably?)

@evilrobot-01
Copy link

evilrobot-01 commented Jan 24, 2022 via email

@bedhub bedhub removed this from the Next release milestone Jan 24, 2022
@ganthern ganthern added the state:done meets our definition of done label Jan 25, 2022
@evilrobot-01
Copy link

I was able to get an arm64 build based on https://github.com/tutao/tutanota/blob/master/doc/BUILDING.md#building-and-running-your-own-tutanota-desktop-client and a few changes to buildSrc/electron-package-json-template.js, based on #3020

diff --git a/buildSrc/electron-package-json-template.js b/buildSrc/electron-package-json-template.js
index 8d57ead03..a1f547340 100644
--- a/buildSrc/electron-package-json-template.js
+++ b/buildSrc/electron-package-json-template.js
@@ -81,7 +81,7 @@ export default function generateTemplate({nameSuffix, version, updateUrl, iconPa
                        "productName": nameSuffix.length > 0
                                ? nameSuffix.slice(1) + " Tutanota Desktop"
                                : "Tutanota Desktop",
-                       "artifactName": "${name}-${os}.${ext}",
+                       "artifactName": "${name}-${os}-${arch}.${ext}",
                        "afterSign": notarize ? "buildSrc/notarize.cjs" : undefined,
                        "protocols": [
                                {
@@ -125,7 +125,7 @@ export default function generateTemplate({nameSuffix, version, updateUrl, iconPa
                                "target": [
                                        {
                                                "target": unpacked ? "dir" : "nsis",
-                                               "arch": "x64"
+                                               "arch": ["x64", "arm64"]
                                        }
                                ]
                        },
@@ -171,7 +171,7 @@ export default function generateTemplate({nameSuffix, version, updateUrl, iconPa
                                "target": [
                                        {
                                                "target": unpacked ? "dir" : "AppImage",
-                                               "arch": "x64"
+                                               "arch": ["x64", "arm64"]
                                        }
                                ]
                        }

@charlag charlag added this to the 3.91.X milestone Feb 3, 2022
@charlag
Copy link
Contributor

charlag commented Feb 4, 2022

I couldn't get it to work yet. Here's what I did:

  • run gnome-keyring-daemon -f -r to effectively "lock" the keychain
  • Start the app
  • See keyring prompt, cancel it
  • See another keyring prompt, cancel it
  • client shows "could not access secret storage" dialog, see from output that client treats it like cancellation (like it should)
  • try to select stored credentials
  • See 2 other prompts and cancel them
  • client output "key credentials-device-lock-key not found, generating a new one" which shouldn't actually happen. Also 2 error dialogs (native and in app)

@charlag charlag reopened this Feb 4, 2022
@charlag
Copy link
Contributor

charlag commented Feb 4, 2022

This is actually more of a #3733 so I will move it there

@charlag charlag closed this as completed Feb 4, 2022
@charlag charlag added the state:tested We tested it and are about to release it label Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
desktop Desktop client related issues maintenance dependency updates, key renewals, code cleanup state:done meets our definition of done state:tested We tested it and are about to release it
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants