The loopback pinentry
wk at gnupg.org
Thu Apr 21 14:06:07 CEST 2016
On Thu, 21 Apr 2016 01:04, bre at pagekite.net said:
> Qubes would be an exception, if this changes for 2.2 we might
> want to reach out to them and make sure they are aware of the
Okay. Let's figure out their needs.
Anyone from Qubes reading this thread?
> change. Are people aware of any other common cases where the
> agent is actually isolated and protected from other apps run by
I doubt that there is proper SE_Linux support. Some time agod we talked
here about using a side-avvount for the agent, but that is a future
thing. dkg: Are you considering this as an option for Stretch?
> we're discussing, for some reason the GnuPG 2.0.28 on my box
> appears to have shipped with a man page (and info) that describes
> a bunch of 2.1 features that don't actually work. ;-)
The miracles of conditional Texinfo compilation - sorry.
> place. I'd rather not generate them without a passphrase (so
> Mailpile generates a strong random one), so I still need a way to
> automate the authentication.
Please keep in mind that the passphrase is more of fail-safe feature
than a everyday protection. If you do not want that a key is used make
sure that the key can't be used. I can imagine a feature to mark keys
available only for certain types of sessions - the question is how to
identify such a session. Right now we have a standard sessions and
restricted session via --extra-socket. We may be abale to extend this
system. But not for 2.2.
> features by default. Somewhere you draw a line and say "this is
> good enough".
Actually this is the new poilicy we try to implement: Make GnuPG as safe
as possible by default but for extra saftey, which anyway requires some
kind of training, require the setting of an option.
> I don't want to speak for Neal and Werner, but after discussing
> with them, I did get the impression that they agree with me on
In general, yes. For certain options I would not mind, if a tool
re-configures that option to a more sensible value. But if this is the
case, we can also chnage the default for that option.
> If a user has explicitly requested no loopback, then they
> probably have a good reason and Mailpile should honour that and
> gracefully fail in the remote scenarios the user has forbidden.
There a lot of other options you can enable to make things go wrong.
Those who play with the options should know what they do.
> automate certain things with GnuPG 2+. The current defaults rule
> out entire classes of interesting applications, for no obvious
> security benefit.
If we want to replace 1.4 by 2.x also for servers we should make it
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel