Noticed that when I build this it ends up with direct linking against a half-dozen libraries it doesn't actually use, at least on Ubuntu. Fixed it by replacing the linking commands with this:
In my case, at least, this doesn't change the full library tree because gtk-4 still links against all of the libraries that are removed from this binary's list, but it does mean that programs which calculate dependencies, like dpkg-shlibdeps, won't report spurious "required" dependencies when analyzing the binary.
When building on Ubuntu 26.04, the binary no longer directly links against lib{pango, cairo, pangocairo, cairo-gobject, harfbuzz, gdk_pixbuf, graphene, gio, vulkan}.
Can't create an account on the site so I figured I'd post this here. If you're going for absolute minimalism this seems like another step in the right direction for anyone building on a more 'gratuitous' GTK build (such as Ubuntu's)
There are tools to generate bindings. They probably meant it as a marker of quality.
And in languages like zig or odin which are quite similar to C in many ways, writing bindings to C code really isn’t bad.
It is so easy that I decided to write my own bindings in Odin to sqlite - bindings exist but it really was so very easy that I didn’t want to bring in a generator or another dependency.
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.
Sure, you need to wrap it in C, but there is also `cfltk` that is maintained and used in Rust bindings.
Btw., the difference in memory usage is huge with GTK4. FLTK hello world is ~10M, GTK3 is ~15M, GTK4 is 40M! With Cairo rendering, it's about 30M, but still a lot.
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.
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` and you get a GUI popup to enter the password, and the agent continues from there.
And since the "prompt" in pinentry can be customised... you can get the agent to set up a temporary askpass, which replaces "Password:" in the prompt with questions like "Can I delete this old log file in /var?" and you enter your password to authorise.
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.
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.
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.
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.
Everyone doing parallel biometric and password authentication on Linux today is either running two PAM stacks in parallel (which is meta-policy that kind of defeats the purpose of PAM) or just bypassing PAM entirely.
Noticed that when I build this it ends up with direct linking against a half-dozen libraries it doesn't actually use, at least on Ubuntu. Fixed it by replacing the linking commands with this:
In my case, at least, this doesn't change the full library tree because gtk-4 still links against all of the libraries that are removed from this binary's list, but it does mean that programs which calculate dependencies, like dpkg-shlibdeps, won't report spurious "required" dependencies when analyzing the binary.When building on Ubuntu 26.04, the binary no longer directly links against lib{pango, cairo, pangocairo, cairo-gobject, harfbuzz, gdk_pixbuf, graphene, gio, vulkan}.
Can't create an account on the site so I figured I'd post this here. If you're going for absolute minimalism this seems like another step in the right direction for anyone building on a more 'gratuitous' GTK build (such as Ubuntu's)
Whenever someone writes "with hand-written bindings" I read "will stop working 8 minutes after the next release"
There are tools to generate bindings. They probably meant it as a marker of quality.
And in languages like zig or odin which are quite similar to C in many ways, writing bindings to C code really isn’t bad. It is so easy that I decided to write my own bindings in Odin to sqlite - bindings exist but it really was so very easy that I didn’t want to bring in a generator or another dependency.
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.
Sure, you need to wrap it in C, but there is also `cfltk` that is maintained and used in Rust bindings. Btw., the difference in memory usage is huge with GTK4. FLTK hello world is ~10M, GTK3 is ~15M, GTK4 is 40M! With Cairo rendering, it's about 30M, but still a lot.
GTK4 memory usage is ludicrous
ah neat, I wasn't aware that cfltk was already used by rust.
There is cflt and Freebasic FLTK
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.
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` and you get a GUI popup to enter the password, and the agent continues from there. And since the "prompt" in pinentry can be customised... you can get the agent to set up a temporary askpass, which replaces "Password:" in the prompt with questions like "Can I delete this old log file in /var?" and you enter your password to authorise.
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.
These implementations really need to also include fingerprint sensor support
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.
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.
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.
Keypassxc does it perfectly.
Everyone doing parallel biometric and password authentication on Linux today is either running two PAM stacks in parallel (which is meta-policy that kind of defeats the purpose of PAM) or just bypassing PAM entirely.
Fingerprint is an authentication mechanism, not an authorization one.
It's both.
Love the tab title shenanigans when switching to and from the tab.
Would love to see more projects using gtk and zig. Always nice to have another language option.
this is realy good and helpfull information thanks.