pass-secrets icon indicating copy to clipboard operation
pass-secrets copied to clipboard

Also provide instructions for FreeBSD

Open probonopd opened this issue 2 years ago • 6 comments

Thank you for this useful tool. The README seems to refer to systemd, which we don't use on FreeBSD:

% systemctl --user enable pass-secrets
zsh: command not found: systemctl

Please also provide instructions for FreeBSD.

Usage is not exactly clear:

% pass-secrets 
zsh: abort      pass-secrets

% pass-secrets -h
zsh: abort      pass-secrets -h

% pass-secrets --help
zsh: abort      pass-secrets --help

% sudo pass-secrets 
Password:
zsh: abort      sudo pass-secrets

Thanks!

probonopd avatar Feb 19 '23 10:02 probonopd

Maybe this is #4. I thought I added a check so it wouldn't immediately abort when launched.

Anyways, the way you are running it should be correct. There's no configuration or anything, it should take up the PASSWORD_STORE environment variable and locate the directory, if it doesn't exist it's supposed to create it and display an error if it can't.

I'll edit the README to note how it can be run standalone. I'm not a FreeBSD user, so I'm not sure if there are user service management or if you just have to run it in your RC/XINIT.

nullobsi avatar Feb 21 '23 01:02 nullobsi

Maybe this is https://github.com/nullobsi/pass-secrets/issues/4.

Not really...

% pass-secrets 
zsh: abort      pass-secrets

% mkdir ~/.password-store
% pass-secrets           
zsh: abort      pass-secrets

% env PASSWORD_STORE_DIR=~/.password-store pass-secrets 
zsh: abort      env PASSWORD_STORE_DIR=~/.password-store pass-secrets

probonopd avatar Feb 21 '23 23:02 probonopd

% systemctl --user enable pass-secrets
zsh: command not found: systemctl

Auto-starting without systemd uses DBus activation. As the shipped .service file installs with conflicting filename and Exec=/bin/false downstream currently disables INSTALL_DBUS_SERVICE. For a fix look at how mako/fnott/dunst/etc provide org.freedesktop.Notifications.

% pass-secrets 
zsh: abort      pass-secrets

Silent crashes are likely due to std::runtime_error outside of try {} catch {}, similar to https://github.com/hyprwm/Hyprland/issues/3031.

% mkdir ~/.password-store

I think, the directory is supposed to be created by pass e.g.,

# pkg install pass-secrets libsecret
$ gpg --pinentry-mode loopback --quick-generate-key $USER
$ pass init <new_gpg_key>
$ pass-secrets &
$ secret-tool store --label=test foo bar
$ secret-tool search foo bar
[/<hash>]
label = test
secret = 1234
created = 2023-01-01 00:00:01
modified = 2023-01-01 00:00:01
attribute.foo = bar
$ pass show
Password Store
└── secretservice
    └── <hash>
        ├── collection.json
        └── <hash>
            ├── item.json
            └── secret

jbeich avatar Aug 21 '23 18:08 jbeich

I don't use FreeDesktop much anymore so I don't have motivation to continue improving this project with features.

But I see what you mean with the D-Bus service and how the others do it, I need to rename the file while keeping the definition the same, I think.

I can also refactor the std::runtime_error to print out on systems that need that.

nullobsi avatar Aug 23 '23 15:08 nullobsi

I'm currently running FreeBSD 13.2-RELEASE with dbus 1.14.10 and ran into the same issue with pass-secrets dying of a SIGABRT. I tracked down the responsible function and with this patch:

diff --git a/main.cpp b/main.cpp
index e269637..5c7baf3 100644
--- a/main.cpp
+++ b/main.cpp
@@ -8,7 +8,12 @@
 int
 main() {
 
-	auto conn = sdbus::createSessionBusConnection();
+	std::unique_ptr<sdbus::IConnection> conn;
+	try {
+		conn = sdbus::createSessionBusConnection();
+	} catch (std::runtime_error &e) {
+		std::cerr << e.what() << std::endl;
+	}
 	conn->requestName("org.freedesktop.secrets");
 
     std::shared_ptr<SecretService> service;    

...the SIGABRT is replaced with the following error from sdbus, both with the packaged version 1.3.0 and the latest 1.4.0:

[org.freedesktop.DBus.Error.FileNotFound] Failed to open bus (No such file or directory)
zsh: segmentation fault (core dumped)  pass-secrets

It seems that others have encountered this problem with sdbus in non-systemd environments, and they've closed the issue even though this bug is definitely still present.

halcyonseeker avatar Oct 16 '23 05:10 halcyonseeker

"Failed to open bus" is not a bug. Auto-launching a daemon from a library is fragile e.g., not implemented by every DBus client library (libdbus vs. sdbus/basu). systemd and dinit+turnstile properly support user services, so both system bus and session bus usually always exist on Linux. FreeBSD supports system services (e.g., dbus-daemon --system via dbus_enable in /etc/rc.conf) but not user services (e.g., dbus-daemon --session), so until rc.d(8) and/or login(1) improve one can start session bus via shell startup e.g.,

$ cat /etc/profile.d/dbus.sh
# WARNING: zsh only reads /etc/zprofile, so make sure to symlink
# XDG_RUNTIME_DIR is preferred but usually requires pam_xdg or consolekit2 (pam_ck_connector or ck_launch_session)
if [ -n "$XDG_RUNTIME_DIR" ]; then
    if ! pgrep -qf -U ${USER:-$(id -u)} dbus.\*--session; then
        dbus-daemon --session --fork --address=unix:runtime=yes 2>/dev/null
    fi
    # Only necessary for some apps that fail to find default session bus (e.g., Emacs, Chrome)
    # https://gitlab.freedesktop.org/dbus/dbus/-/commit/e3f117e7610b
    export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
else
    eval $(dbus-launch --sh-syntax --exit-with-session 2>/dev/null)
fi

jbeich avatar Oct 16 '23 06:10 jbeich