Consider using system-wide askpass and app-placeholder instances

[probonopd]

Following https://github.com/helloSystem/ISO/commit/d12eb2f1af324a3c1a57889cc30bea9639503a62 we can consider using system-wide instances instead of bundling them privately inside each placeholder .app bundle:

/usr/local/bin/askpass
/usr/local/libexec/app-placeholder

Doing so would increase maintainability (less duplication) at the expense of making the placeholder .app bundles run only on helloSystem (or any system that ships the above).

[wjk]

My 2¢: I actually prefer the placeholder .app bundles over the ones automatically created by desktop2pkg at boot time. They each work the same way, except the placeholder bundles are more logically organized and have much shorter names. (“PyCharm CE” versus “JetBrains PyCharm IDE Community Edition”.) To this end, I have commented out the command that starts desktop2pkg automatically, and run it manually when needed.

We might also want to think about changing the askpass.py scripts to provide the user more context about what will happen when they input their password, beyond that something is being run using sudo. This would require that askpass be rewritten to read a configuration file containing UI strings (the path to this would be most likely provided via an environment variable set when sudo is called, as I don’t think SUDO_ASKPASS supports arguments).

[probonopd]

They each work the same way, except the placeholder bundles are more logically organized and have much shorter names.

Well, the reason is that with the placeholder ones I hand-edited and hand-categorized them. In doing so, I used different folder names than the usual XDG categories which I find not flexible enough (no "3D printing" there), and partially used different names than the Name= entry in the XDG desktop files. There is simply no way to automatically extract this information from the packages, unless I am mistaken.

We might also want to think about changing the askpass.py scripts to provide the user more context

We could allow for a second argument to be passed in, which the calling applciation would need to deliver in translated form. Would that make sense?

[wjk]

Well, the reason is that with the placeholder ones I hand-edited and hand-categorized them.

Makes sense, and you are correct in that there is no way to do this automatically without hand-creating a long list of packages with better names and categories inside desktop2app.

We could allow for a second argument to be passed in, which the calling applciation would need to deliver in translated form. Would that make sense?

Yes, but according to sudo(8) on my Mac, SUDO_ASKPASS supports the path to the appropriate binary only. No arguments can be provided. I suggested environment variables as those would be easier to transmit. And yes, this argument should be an already (hopefully) localized string describing what the sudo’ed process is about to do.

[probonopd]

Yes, but according to sudo(8) on my Mac, SUDO_ASKPASS supports the path to the appropriate binary only. No arguments can be provided.

You are so right. Sorry I had forgotten.

I suggested environment variables as those would be easier to transmit. And yes, this argument should be an already (hopefully) localized string describing what the sudo’ed process is about to do.

Makes sense to me. Is there already an established convention for the additional variable or should we just define one, such as SUDO_ASKPASS_TEXT?

[wjk]

SUDO_ASKPASS_TEXT sounds good. I know of no existing standard.

[probonopd]

SUDO_ASKPASS_TEXT="We want to change FOO to bar. This is why we need to ask you about your password." askpass ls

[kettle-7]

What do you think?