Re: symmetric passphrase with remote (extra, restricted) gpg-agent

2024-02-26 Thread Werner Koch via Gnupg-users
Hi!

sorry, for the wrong order of the messages, I simply forgot to sent
them yesterday.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: symmetric passphrase with remote (extra, restricted) gpg-agent

2024-02-26 Thread Werner Koch via Gnupg-users
On Fri, 23 Feb 2024 22:59, Marcin Wrochna said:

> However, I cannot make `gpg --symmetric` encryption work on the remote,
> as it tells me getting a passphrase is "Forbidden".

Right.  It does not sund like a good idea to give the server access to
your local password store (in gpg-agent).  This way the server might get
access to any password sored in the cache.

You need to look at the code in gnupg/agent/commands.c - search for the
function cmd_get_passphrase.  The first statement there is

  if (ctrl->restricted)
return leave_cmd (ctx, gpg_error (GPG_ERR_FORBIDDEN));

The function (test with gpg-connect-agent and "help get_passphrase") has
an option --no-ask which only returns value from the cache or errors
out. What we might do is another option (e.g. --only-query) to only
popup the pinentry and return the value.  Maybe this can be the default
for a restricted connection.


Salam-Shalom,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: symmetric passphrase with remote (extra, restricted) gpg-agent

2024-02-26 Thread Werner Koch via Gnupg-users
Hi again!

you may want to try the attached patch.  It is against the current 2.4
head but should apply also to somewhat older versions.  If this solves
your problem, it can go into 2.4.5 soon.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
From 4025da324903093736f238329274f5e234f5339e Mon Sep 17 00:00:00 2001
From: Werner Koch 
Date: Sun, 25 Feb 2024 15:55:14 +0100
Subject: [PATCH GnuPG] agent: Allow GET_PASSPHRASE in restricted mode.

* agent/command.c (cmd_get_passphrase): Allow use in restricted mode
but ignore the cacheid.
--

The use case is symmetric encryption via the extra-socket.  To avoid
that the gpg running on the server has access to the cache we set the
cache id to NULL so that the cache is not used at all.
---
 agent/command.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/agent/command.c b/agent/command.c
index 20ae08e9f..100b97f57 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -1988,9 +1988,6 @@ cmd_get_passphrase (assuan_context_t ctx, char *line)
   struct pin_entry_info_s *pi2 = NULL;
   int is_generated;
 
-  if (ctrl->restricted)
-return leave_cmd (ctx, gpg_error (GPG_ERR_FORBIDDEN));
-
   opt_data = has_option (line, "--data");
   opt_check = has_option (line, "--check");
   opt_no_ask = has_option (line, "--no-ask");
@@ -2039,7 +2036,9 @@ cmd_get_passphrase (assuan_context_t ctx, char *line)
   if (!desc)
 return set_error (GPG_ERR_ASS_PARAMETER, "no description given");
 
-  if (!strcmp (cacheid, "X"))
+  /* The only limitation in restricted mode is that we don't considere
+   * the cache.  */
+  if (ctrl->restricted || !strcmp (cacheid, "X"))
 cacheid = NULL;
   if (!strcmp (errtext, "X"))
 errtext = NULL;
@@ -2121,7 +2120,7 @@ cmd_get_passphrase (assuan_context_t ctx, char *line)
   entry_errtext = NULL;
   is_generated = !!(pi->status & PINENTRY_STATUS_PASSWORD_GENERATED);
 
-  /* We don't allow an empty passpharse in this mode.  */
+  /* We don't allow an empty passphrase in this mode.  */
   if (!is_generated
   && check_passphrase_constraints (ctrl, pi->pin,
pi->constraints_flags,
-- 
2.39.2



openpgp-digital-signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


symmetric passphrase with remote (extra, restricted) gpg-agent

2024-02-23 Thread Marcin Wrochna via Gnupg-users
Hi!

I'm using gpg remotely over ssh by forwarding my local
agent-extra-socket as my remote's regular agent-socket. I use it with
a (local) nitrokey mostly without problems for signing:
on the remote I can use `gpg --sign`, it asks for the PIN with a GUI
pinentry popping up
on my local desktop and even uses it with the local nitrokey card.

However, I cannot make `gpg --symmetric` encryption work on the remote,
as it tells me getting a passphrase is "Forbidden".
Is it possible at all?
I can't find any documentation about what is actually 'restricted' by
the restricted mode of the extra socket.
Or must I use two agents (one forwarded, one local to the remote), and
if so, is there any guide as to how to do that?
I don't care much about passphrase cache, I just want to encrypt a
file by entering a passphrase with whatever pinentry.

Thanks for any pointers,
Marcin

--- Logs -
Local gpg version: 2.4.3, Remote gpg version: 2.2.27

Remote output:
```
$ gpg -vvv --symmetric tmp.txt
gpg: using character set 'utf-8'
gpg: connection to agent is in restricted mode
gpg: problem with the agent: Forbidden
gpg: error creating passphrase: Operation cancelled
gpg: symmetric encryption of 'tmp.txt' failed: Operation cancelled
```

Local gpg-agent logs when trying from remote:
```
2024-02-23 22:11:07 gpg-agent[132208]DBG: chan_10 -> OK Pleased to
meet you, process 132243
<- RESET
-> OK
<- OPTION ttyname=/dev/pts/7
-> ERR 67109115 Forbidden 
<- GETINFO restricted
-> OK
<- GETINFO version
-> D 2.4.3
-> OK
<- OPTION allow-pinentry-notify
-> ERR 67109115 Forbidden 
<- OPTION agent-awareness=2.1.0
-> OK
<- GETINFO s2k_count
S2K calibration: 44149760 -> 101ms
-> D 44149760
-> OK
<- GETINFO cmd_has_option GET_PASSPHRASE repeat
-> OK
<- GETINFO cmd_has_option GET_PASSPHRASE newsymkey
-> OK
<- GET_PASSPHRASE --data --repeat=1 --check --newsymkey --
SE3EC318CC514D3C1 X X Enter+passphrase%0A
command 'GET_PASSPHRASE' failed: Forbidden
-> ERR 67109115 Forbidden 
<- [eof]
```

Local gpg-agent logs when doing gpg --symmetric locally:
```
2024-02-23 22:44:48 gpg-agent[132208] DBG: chan_10 -> OK Pleased to
meet you, process 134008
<- RESET
-> OK
<- OPTION ttyname=/dev/pts/7
-> OK
<- OPTION ttytype=xterm-256color
-> OK
<- OPTION display=:0
-> OK
<- OPTION xauthority=/run/user/1000/xauth_hZahio
-> OK
<- OPTION putenv=XMODIFIERS=@im=none
-> OK
<- OPTION putenv=WAYLAND_DISPLAY=wayland-0
 -> OK
<- OPTION putenv=XDG_SESSION_TYPE=wayland
-> OK
<- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
-> OK
<- OPTION lc-ctype=en_US.UTF-8
-> OK
<- OPTION lc-messages=en_US.UTF-8
-> OK
<- GETINFO version
-> D 2.4.3
-> OK
<- OPTION allow-pinentry-notify
-> OK
<- OPTION agent-awareness=2.1.0
-> OK
<- GETINFO s2k_count
-> D 44149760
-> OK
<- GETINFO cmd_has_option GET_PASSPHRASE repeat
-> OK
<- GETINFO cmd_has_option GET_PASSPHRASE newsymkey
-> OK
<- GET_PASSPHRASE --data --repeat=1 --check --newsymkey --
S545B95646F9BD365 X X Enter+passphrase%0A
agent_get_cache 'S545B95646F9BD365'.0 (mode 3) ...
... miss
starting a new PIN Entry
connection to PIN entry established
-> INQUIRE PINENTRY_LAUNCHED 134010 qt 1.2.1 /dev/pts/7 xterm-256color
:0 20620/1000/5 1000/1000 0
<- END
starting a new PIN Entry
connection to PIN entry established
-> INQUIRE PINENTRY_LAUNCHED 134027 qt 1.2.1 /dev/pts/7 xterm-256color
:0 20620/1000/5 1000/1000 0
<- END
agent_put_cache 'S545B95646F9BD365'.0 (mode 3) requested ttl=0
-> [[Confidential data not shown]]
-> OK
<- [eof]
```

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users