The loopback pinentry

[Werner Koch]

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
> this.

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
easy.


Shalom-Salam,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.