Byron
commented
3 weeks ago GitButler uses the keyring crate to store and retrieve credentials. And by the looks of it, it's not actually persisting secrets on this system.
Since it's not permanently failing, it feels like either it's keeping secrets for the session only, or the UI saves tokens in its own in-memory store.
There is something you could try if you could compile the application on your own with the following patch applied…
diff --git a/crates/gitbutler-tauri/src/main.rs b/crates/gitbutler-tauri/src/main.rs
index 5e7465ce4..88de94b3d 100644
--- a/crates/gitbutler-tauri/src/main.rs
+++ b/crates/gitbutler-tauri/src/main.rs
@@ -68,7 +68,7 @@ fn main() {
// the binary is rebuilt. To counter that, use a git-credential based implementation.
// This isn't an issue for actual release build (i.e. nightly, production),
// hence the specific condition.
- if cfg!(debug_assertions) && cfg!(target_os = "macos") {
+ if true {
gitbutler_secret::secret::git_credentials::setup().ok();
}…to see if that fixes the issue. If so, then using git credentials to store credentials seems to be more portable and might be something that should be exposed in the application settings.
Thanks for your help with this.
ndom91
n-a-m-e
Version
0.13.12
Operating System
Linux
Distribution Method
deb (Linux)
Describe the issue
I am using a Fedora Atomic Desktop (https://getaurora.dev/) which means that the base OS is read only.
I am running into the same issue with the flatpak and the rpm. Everything works normally i can push pull merge etc. but if I close Gitbutler and then reopen it I have go to Preferences > Integrations and sign in again and then re authorize github.
I have a feeling that gitbutler is trying to save the Access Token somewhere that is read only. Which directory on the host file system is is the Access token being saved to?
Below are the relevant logs
ui-logs.log
GitButler.2024-11-08.log
How to reproduce
No response
Expected behavior
No response
Relevant log output
No response