Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A GTK4 SSH-askpass in Zig

xn--gckvb8fzb.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: A GTK4 SSH-askpass in Zig

#21

Post by quotemstr »

timhh wrote: post #20
quotemstr wrote: post #6

Earlier quoted context omitted.

PAM really needs to be ravamped and support for (among other things) running multiple stacks in par@llel added. This way you could ask for a password OR a fingerprint

I'm vaguely considering rewriting PAM in Rust. It's definitely something that would benefit from Rust's extra security and the code quality isn't that great. Nor is the UX. What "among other things" were you thinking of?

Implementation language is incidental. Rust is... fine, I guess? But I wouldn't mandate modules use it. What's important is to move PAM out of process and sandbox the process host (using landlock, namespaces like bwrap, whatever) so we can run sensitive code with least-privilege on both ends.

Re: A GTK4 SSH-askpass in Zig

#22

Post by timhh »

quotemstr wrote: post #21
timhh wrote: post #20

Earlier quoted context omitted.

I'm vaguely considering rewriting PAM in Rust. It's definitely something that would benefit from Rust's extra security and the code quality isn't that great. Nor is the UX. What "among other things" were you thinking of?

Implementation language is incidental. Rust is... fine, I guess? But I wouldn't mandate modules use it. What's important is to move PAM out of process and sandbox the process host (using landlock, namespaces like bwrap, whatever) so we can run sensitive code with least-privilege on both ends.

Yeah I always thought the whole architecture of PAM being a library is weird. A sane person would have made it a Daemon that processes talk to surely?

Really it should probably be part of SystemD, but I know that would anger the anti-SystemD zealots.

Re: A GTK4 SSH-askpass in Zig

#23

Post by fithisux »

zem wrote: post #13
gen2brain wrote: post #3

Nice, I just use lxqt-openssh-askpass, but I am on X11. A lighter alternative (for single-text input) would be FLTK. Version 1.4 is really nice, with Wayland support, and they even draw custom window decorations on GNOME. Both Cairo and FLTK should be able to compile with -X; not sure, though, about the status of the Zig bindings.

fltk is c++ based which makes language bindings significantly harder in general. gtk is c based which worked out really well in that aspect.

There is cflt and Freebasic FLTK

Re: A GTK4 SSH-askpass in Zig

#24

Post by NekkoDroid »

timhh wrote: post #22
quotemstr wrote: post #21

Earlier quoted context omitted.

Implementation language is incidental. Rust is... fine, I guess? But I wouldn't mandate modules use it. What's important is to move PAM out of process and sandbox the process host (using landlock, namespaces like bwrap, whatever) so we can run sensitive code with least-privilege on both ends.

Yeah I always thought the whole architecture of PAM being a library is weird. A sane person would have made it a Daemon that processes talk to surely? Really it should probably be part of SystemD, but I know that would anger the anti-SystemD zealots.

> A sane person would have made it a Daemon that processes talk to surely?

> Really it should probably be part of SystemD

https://github.com/systemd/systemd/pull/39855

Re: A GTK4 SSH-askpass in Zig

#25

Post by aorth »

porridgeraisin wrote: post #7

I wrap `pinentry` (which is in the dependency trees of gnupg, pacman, gvfs, udisks2 and other software that you can de-facto depend on on desktops) inside my own simple askpass. $ cat ~/scripts/pinentry-askpass #!/usr/bin/env bash pinentry It automatically launches the GTK, TTY, or QT version depending on your environment. It's also useful for agents to use sudo, you can write in instructions to tool-call `sudo -A` a…

Any reason you don't use `pinentry-gnome3` from the `pinentry` package? Your wrapper is clever but doesn't work with gpg-agent.

Re: A GTK4 SSH-askpass in Zig

#26

Post by porridgeraisin »

aorth wrote: post #25
porridgeraisin wrote: post #7

I wrap `pinentry` (which is in the dependency trees of gnupg, pacman, gvfs, udisks2 and other software that you can de-facto depend on on desktops) inside my own simple askpass. $ cat ~/scripts/pinentry-askpass #!/usr/bin/env bash pinentry It automatically launches the GTK, TTY, or QT version depending on your environment. It's also useful for agents to use sudo, you can write in instructions to tool-call `sudo -A` a…

Any reason you don't use `pinentry-gnome3` from the `pinentry` package? Your wrapper is clever but doesn't work with gpg-agent.

No reason, I always thought launching pinentry directly chose the right one out of pinentry, pinentry-curses, pinentry-emacs, pinentry-gnome3, pinentry-gtk, pinentry-qt, pinentry-tty since it always worked for me on xfce+arch+programs I have used.

You can change it I suppose, I don't thing I use gpg-agent often.

Re: A GTK4 SSH-askpass in Zig

#27

Post by quotemstr »

timhh wrote: post #22
quotemstr wrote: post #21

Earlier quoted context omitted.

Implementation language is incidental. Rust is... fine, I guess? But I wouldn't mandate modules use it. What's important is to move PAM out of process and sandbox the process host (using landlock, namespaces like bwrap, whatever) so we can run sensitive code with least-privilege on both ends.

Yeah I always thought the whole architecture of PAM being a library is weird. A sane person would have made it a Daemon that processes talk to surely? Really it should probably be part of SystemD, but I know that would anger the anti-SystemD zealots.

Not everything has to be a "daemon". It's a bad trend in current programming zeitgeist to want to make everything into one. (sccache, no, you do NOT need a daemon to behave like ccache.)

For a PAM replacement, you want a separate process. It doesn't have to be a persistent separate process.

Re: A GTK4 SSH-askpass in Zig

#28

Post by quotemstr »

NekkoDroid wrote: post #24
timhh wrote: post #22

Earlier quoted context omitted.

Yeah I always thought the whole architecture of PAM being a library is weird. A sane person would have made it a Daemon that processes talk to surely? Really it should probably be part of SystemD, but I know that would anger the anti-SystemD zealots.

> A sane person would have made it a Daemon that processes talk to surely? > Really it should probably be part of SystemD https://github.com/systemd/systemd/pull/39855

It's confusing how they want a custom protocol that seems to be converging from JSON-RPC, just spelled differently. They should just use JSON-RPC. In any case, it'd essential to retain PAM's customization ability even if the bulk of the work is moved out-of-process.
Post reply on HN