Security concerns with split-gpg1 to split-gpg2 migration
17 visualizações
Pular para a primeira mensagem não lida
Demi Marie Obenour
2 de jul. de 2022, 21:51:2402/07/2022
para Qubes OS Development Mailing List, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
split-gpg2 [1] is the planned replacement for split-gpg1 [2]. It has
several advantages, such as much lower attack surface, support for all
of gpg(1)’s options, and support for key management operations.
However, the last is also a potential security concern.
Right now, a compromised frontend VM can sign or decrypt messages with
any key in the backend VM, but it *cannot* sign or revoke keys. This
limitation is also useful, since a mail client (for example) has no need
to perform these operations. However it is difficult for split-gpg2 to
enforce this restriction.
The technical reason for this restriction is that the “type” byte in an
OpenPGP signature of a message is always 0 or 1, but other signatures
use different types. The type of a signature is part of the signed
data, so it is not possible to pretend that a signature of one type is a
signature of another type. The type of a signature that GnuPG will
generate depends on the options passed to it, but split-gpg1 only allows
a subset of these options. The subset of options passed by split-gpg1
only allow signatures of type 0 or 1 to be created, and those are only
valid as signatures of messages.
Unfortunately, split-gpg2 does not see the data being signed! It only
sees the hash of that data. Therefore, split-gpg2 has no idea what type
of signature it is making: it could be a signature on a binary document,
a signature of a key and user ID, or even something that is not an
OpenPGP signature at all. For instance, gpgsm also uses gpg-agent, and
so is also supported by split-gpg2. It generates CMS (Cryptographic
Message Syntax, also known as S/MIME) signatures, which are different
than OpenPGP signatures.
The best solution that I have come up with is to not allow the frontend
to use any key it wishes, but only allow it to use a subset of keys.
Migrating from split-gpg1 to split-gpg2 would involve generating a
subkey that is capable of signing data, but is *not* capable of
certification (signing other keys, revoking keys, etc). split-gpg2
would then be configured to only allow the frontend to use this subkey,
*not* the main key. The frontend could still generate signatures of
other keys with this subkey, but these signatures are not valid. If a
program trusts these signatures, then either it has imported a key
controlled by the frontend (in which case the frontend could have just
generated its own key) or the program has a security vulnerability.
Sadly, split-gpg2 does not have support for this — yet. There is no
fundamental reason such support cannot be added, but right now
split-gpg2 (like split-gpg1) either allows all access or denies all
access. There are various workarounds, but all of them are more complex
than I would like.
What are people’s thoughts on this issue? In the short term, one option
is to use split-gpg2 as the backend for split-gpg1, which works fine.
However, split-gpg1 is a maintenance hog with a lot of attack surface,
so migrating entirely to split-gpg2 is definitely preferred.
[1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2
[2]: https://github.com/QubesOS/qubes-app-linux-split-gpg
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLA9hgACgkQsoi1X/+c
IsE4QQ/+Mrou3OjktLirktp3QsSB6SuINxoY+oSUScecz10SnQkyMORkn+D3xGZq
Ed7xa8E1VIpws7KNHrqc01q5jW4OpccZSrHhnI2SMGdNGeo5r4BA+R7+YaSU40g2
iqJ1Blt15nT1QDl+fEwtO8bgWYrMiN5IYOiSKx+vrsBy83qnvWRp8CogO9Zr9JjW
Bsg8qrWklsUT3/VCA+9zosBtjXx749NBZpdHMw/kK7ulhHvNrtcSMFDIx8Fyl5XH
dMXV8Lj65zF/g70gOck/4EIfVuFzOFo3LmfiVXQgZFmn80q2hJe2Fr3G2N0troG5
V3+vg4+1ed1p3mPVhzZEfYkmBrEqKsma1CVTctmMMPLTdiHGojbjbd+U2zgqHM8w
8K/+aPL3/KCy6h9zIY0/aSyLgDueUfdgvsGwlA9GpumaX3lDjFF6SpnYPgrnysd/
3bMSwXejSWpNwqIR5zmAllR5l23k1Oz0Y2fRMaHTeMhj/jqn/X9g1nNpCRckFkpu
899ihnmHl+otpyLavRusfctGFmnngBcjNJhIPrXAry5ECioOcIHC38GXX3xuLt30
ss6lNgGrMxQU/6pd89rRWlVGHiC3h6rkHI5v67bcOD9KPWNQEeQADRXYHgc8eDOi
e5m7TFF/L1OGmZPwHChP4ae+pSXE7X791vOpnl9d7h3gfYQ3sKo=
=wpg3
-----END PGP SIGNATURE-----
Hash: SHA512
split-gpg2 [1] is the planned replacement for split-gpg1 [2]. It has
several advantages, such as much lower attack surface, support for all
of gpg(1)’s options, and support for key management operations.
However, the last is also a potential security concern.
Right now, a compromised frontend VM can sign or decrypt messages with
any key in the backend VM, but it *cannot* sign or revoke keys. This
limitation is also useful, since a mail client (for example) has no need
to perform these operations. However it is difficult for split-gpg2 to
enforce this restriction.
The technical reason for this restriction is that the “type” byte in an
OpenPGP signature of a message is always 0 or 1, but other signatures
use different types. The type of a signature is part of the signed
data, so it is not possible to pretend that a signature of one type is a
signature of another type. The type of a signature that GnuPG will
generate depends on the options passed to it, but split-gpg1 only allows
a subset of these options. The subset of options passed by split-gpg1
only allow signatures of type 0 or 1 to be created, and those are only
valid as signatures of messages.
Unfortunately, split-gpg2 does not see the data being signed! It only
sees the hash of that data. Therefore, split-gpg2 has no idea what type
of signature it is making: it could be a signature on a binary document,
a signature of a key and user ID, or even something that is not an
OpenPGP signature at all. For instance, gpgsm also uses gpg-agent, and
so is also supported by split-gpg2. It generates CMS (Cryptographic
Message Syntax, also known as S/MIME) signatures, which are different
than OpenPGP signatures.
The best solution that I have come up with is to not allow the frontend
to use any key it wishes, but only allow it to use a subset of keys.
Migrating from split-gpg1 to split-gpg2 would involve generating a
subkey that is capable of signing data, but is *not* capable of
certification (signing other keys, revoking keys, etc). split-gpg2
would then be configured to only allow the frontend to use this subkey,
*not* the main key. The frontend could still generate signatures of
other keys with this subkey, but these signatures are not valid. If a
program trusts these signatures, then either it has imported a key
controlled by the frontend (in which case the frontend could have just
generated its own key) or the program has a security vulnerability.
Sadly, split-gpg2 does not have support for this — yet. There is no
fundamental reason such support cannot be added, but right now
split-gpg2 (like split-gpg1) either allows all access or denies all
access. There are various workarounds, but all of them are more complex
than I would like.
What are people’s thoughts on this issue? In the short term, one option
is to use split-gpg2 as the backend for split-gpg1, which works fine.
However, split-gpg1 is a maintenance hog with a lot of attack surface,
so migrating entirely to split-gpg2 is definitely preferred.
[1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2
[2]: https://github.com/QubesOS/qubes-app-linux-split-gpg
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLA9hgACgkQsoi1X/+c
IsE4QQ/+Mrou3OjktLirktp3QsSB6SuINxoY+oSUScecz10SnQkyMORkn+D3xGZq
Ed7xa8E1VIpws7KNHrqc01q5jW4OpccZSrHhnI2SMGdNGeo5r4BA+R7+YaSU40g2
iqJ1Blt15nT1QDl+fEwtO8bgWYrMiN5IYOiSKx+vrsBy83qnvWRp8CogO9Zr9JjW
Bsg8qrWklsUT3/VCA+9zosBtjXx749NBZpdHMw/kK7ulhHvNrtcSMFDIx8Fyl5XH
dMXV8Lj65zF/g70gOck/4EIfVuFzOFo3LmfiVXQgZFmn80q2hJe2Fr3G2N0troG5
V3+vg4+1ed1p3mPVhzZEfYkmBrEqKsma1CVTctmMMPLTdiHGojbjbd+U2zgqHM8w
8K/+aPL3/KCy6h9zIY0/aSyLgDueUfdgvsGwlA9GpumaX3lDjFF6SpnYPgrnysd/
3bMSwXejSWpNwqIR5zmAllR5l23k1Oz0Y2fRMaHTeMhj/jqn/X9g1nNpCRckFkpu
899ihnmHl+otpyLavRusfctGFmnngBcjNJhIPrXAry5ECioOcIHC38GXX3xuLt30
ss6lNgGrMxQU/6pd89rRWlVGHiC3h6rkHI5v67bcOD9KPWNQEeQADRXYHgc8eDOi
e5m7TFF/L1OGmZPwHChP4ae+pSXE7X791vOpnl9d7h3gfYQ3sKo=
=wpg3
-----END PGP SIGNATURE-----
Simon Gaiser
13 de jul. de 2022, 07:49:2513/07/2022
para Qubes OS Development Mailing List, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Demi Marie Obenour:
Hash: SHA512
acknowledge button). There are indeed things that are not possible with
the splt-gpg2 architecture that are possible with split-gpg1, for
example showing the data you are about to sign (only useful in a few
cases).
For such special cases I would recommend to use neither split-gpg
variants and instead use a dedicated qrexec service that just does the
needed operations. This also makes other things like for example an
audit log much easier. Of course you loose the "gpg drop-in" feature of
both split-gpg variants.
> The best solution that I have come up with is to not allow the
> frontend to use any key it wishes, but only allow it to use a subset
> of keys.
> Migrating from split-gpg1 to split-gpg2 would involve generating a
> subkey that is capable of signing data, but is *not* capable of
> certification (signing other keys, revoking keys, etc). split-gpg2
> would then be configured to only allow the frontend to use this
> subkey, *not* the main key. The frontend could still generate
> signatures of other keys with this subkey, but these signatures are
> not valid. If a program trusts these signatures, then either it has
> imported a key controlled by the frontend (in which case the frontend
> could have just generated its own key) or the program has a security
> vulnerability.
>
> Sadly, split-gpg2 does not have support for this — yet. There is no
> fundamental reason such support cannot be added, but right now
> split-gpg2 (like split-gpg1) either allows all access or denies all
> access.
beyond not importing them to your GNUPGHOME (I consider that a feature,
due to reduced complexity). But what you seem to have missed is that
GnuPG has native support for exactly this scenario, see the
- --export-secret-subkeys option.
- From the manpage:
--export-secret-keys
--export-secret-subkeys
[...]
The second form of the command has the special property to
render the secret part of the primary key useless; this is a GNU
extension to OpenPGP and other implementations can not be
expected to successfully import such a key. Its intended use is
in generating a full key with an additional signing subkey on a
dedicated machine. This command then exports the key without the
primary key to the main machine.
> There are various workarounds, but all of them are more complex than I
> would like.
>
> What are people’s thoughts on this issue? In the short term, one
> option is to use split-gpg2 as the backend for split-gpg1, which works
> fine. However, split-gpg1 is a maintenance hog with a lot of attack
> surface, so migrating entirely to split-gpg2 is definitely preferred.
>
> [1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2
> [2]: https://github.com/QubesOS/qubes-app-linux-split-gpg>
iQJRBAEBCgA7FiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmLOsMEdHHNpbW9uQGlu
dmlzaWJsZXRoaW5nc2xhYi5jb20ACgkQkO9xfO/xly/IlA//T1NObwctB+I0gLH3
nIzbX4HNrWR5voXszEhHYDcnv1UN6ID3zPwQLru3GS4btP5mCHVTAYXzNbB/UodW
mYp/9PjNrOTjRF8o1K6MQKwnZ368n1X7g8vVtPLRHrRzU5iwYULtbEq18le95E3/
7oMgzRVBA4JryZVb3XA6VLBLGk0cF+bI7gHVgAU8H4ev69cvWFJGzir/Dfx8N1MD
1xyKgOqHo/lHRQE+X8/iU5Yzki7iz0eIfQdEuSBFiA56vwNu3zPUvbBKHKMnF37r
MXvqLffehoqQJIR19vmPC6VjPRz3Ef28+zoHOZ3VTqWAZX4JrnyVyM5bT1O1J3Hy
v+/5DR5wcTHxucx2DcfwzxSxcz5jBYzgvKrrkShOubtHUobB6rhJxRGP6QaF6TvZ
yov3zB3mvv5kPjVUWljVRtiHIL+4PRN8hgo/RgeoT6tifzea7PQ4rPvgnFwbx8Lc
aoNYL0Pwc7BzVho5p9eDVsFWcd79L+I765m7rGF9HgxkqtUCOBnu3vLi3Ria6MUo
EgvqMuhM/fnpEyr82hNBJzfhzE/QLFtqvdiz+Nx4NxcKMuc6JVCXg4bJUFq0X6wh
xf2upWfcQJdu+/KgqG5jYSQ4oGEGa64HjO0VP6BDLpE/36qwsEdDwYDWezA8N2o2
mz7KgPPtcR7cuXls70woRTAcpsU=
=EeKi
-----END PGP SIGNATURE-----
Simon Gaiser
13 de jul. de 2022, 07:57:1513/07/2022
para Qubes OS Development Mailing List, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
[ Sorry for the previous mail with broken white space, hopefully fixed
Hash: SHA512
now. Really annoying that Google Groups still prevents using PGP/MIME. ]
Demi Marie Obenour:
Correct. You need to think of split-gpg2 as a smartcard (that has one
acknowledge button). There are indeed things that are not possible with
the splt-gpg2 architecture that are possible with split-gpg1, for
example showing the data you are about to sign (only useful in a few
cases).
For such special cases I would recommend to use neither split-gpg
variants and instead use a dedicated qrexec service that just does the
needed operations. This also makes other things like for example an
audit log much easier. Of course you loose the "gpg drop-in" feature of
both split-gpg variants.
acknowledge button). There are indeed things that are not possible with
the splt-gpg2 architecture that are possible with split-gpg1, for
example showing the data you are about to sign (only useful in a few
cases).
For such special cases I would recommend to use neither split-gpg
variants and instead use a dedicated qrexec service that just does the
needed operations. This also makes other things like for example an
audit log much easier. Of course you loose the "gpg drop-in" feature of
both split-gpg variants.
> The best solution that I have come up with is to not allow the
> frontend to use any key it wishes, but only allow it to use a subset
> of keys.
Exactly!
> frontend to use any key it wishes, but only allow it to use a subset
> of keys.
> Migrating from split-gpg1 to split-gpg2 would involve generating a
> subkey that is capable of signing data, but is *not* capable of
> certification (signing other keys, revoking keys, etc). split-gpg2
> would then be configured to only allow the frontend to use this
> subkey, *not* the main key. The frontend could still generate
> signatures of other keys with this subkey, but these signatures are
> not valid. If a program trusts these signatures, then either it has
> imported a key controlled by the frontend (in which case the frontend
> could have just generated its own key) or the program has a security
> vulnerability.
>
> Sadly, split-gpg2 does not have support for this — yet. There is no
> fundamental reason such support cannot be added, but right now
> split-gpg2 (like split-gpg1) either allows all access or denies all
> access.
That's not quite true. Yes they don't provide an option to filter keys,
beyond not importing them to your GNUPGHOME (I consider that a feature,
due to reduced complexity). But what you seem to have missed is that
GnuPG has native support for exactly this scenario, see the
- --export-secret-subkeys option.
- From the manpage:
--export-secret-keys
--export-secret-subkeys
[...]
The second form of the command has the special property to
render the secret part of the primary key useless; this is a GNU
extension to OpenPGP and other implementations can not be
expected to successfully import such a key. Its intended use is
in generating a full key with an additional signing subkey on a
dedicated machine. This command then exports the key without the
primary key to the main machine.
beyond not importing them to your GNUPGHOME (I consider that a feature,
due to reduced complexity). But what you seem to have missed is that
GnuPG has native support for exactly this scenario, see the
- --export-secret-subkeys option.
- From the manpage:
--export-secret-keys
--export-secret-subkeys
[...]
The second form of the command has the special property to
render the secret part of the primary key useless; this is a GNU
extension to OpenPGP and other implementations can not be
expected to successfully import such a key. Its intended use is
in generating a full key with an additional signing subkey on a
dedicated machine. This command then exports the key without the
primary key to the main machine.
> There are various workarounds, but all of them are more complex than I
> would like.
>
> What are people’s thoughts on this issue? In the short term, one
> option is to use split-gpg2 as the backend for split-gpg1, which works
> fine. However, split-gpg1 is a maintenance hog with a lot of attack
> surface, so migrating entirely to split-gpg2 is definitely preferred.
>
> [1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2
> [2]: https://github.com/QubesOS/qubes-app-linux-split-gpg>
-----BEGIN PGP SIGNATURE-----
> would like.
>
> What are people’s thoughts on this issue? In the short term, one
> option is to use split-gpg2 as the backend for split-gpg1, which works
> fine. However, split-gpg1 is a maintenance hog with a lot of attack
> surface, so migrating entirely to split-gpg2 is definitely preferred.
>
> [1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2
> [2]: https://github.com/QubesOS/qubes-app-linux-split-gpg>
iQJRBAEBCgA7FiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmLOslMdHHNpbW9uQGlu
dmlzaWJsZXRoaW5nc2xhYi5jb20ACgkQkO9xfO/xly9jWRAApIFhQZ0hrOR7lm3z
ojy0cozG14GMEWmr2dh1rxWCxZEBJRQe4RmQCOBY3agp3jM9w7MGDzNlr3J3vIDm
ZM2rdptqNyOO2r2eT/HooWOMaxJXAj+obmSaNuBh2LL60s3ZI1NaqEWskFTqZt8D
8lNdy5W3/uPJIFIM/N6Tz0Y/n89x/2J7XzopyYw9iV634hYMWzAdgqU76tRNtCTi
xs67WTQNAUMo2KSZBmf/IOvoHEgJJAIXPUbguEiAQq/mLZnHMGkYp23TB5wRSs8w
VKd1zIKkZjfMQF3CWlw/RnnjG090gtYNZjp+uYFcwmAfIaUQwQKoyJ09Tol76Vql
WH2cz0CW8NLYPHaz6RHsz4bFOrLvrSOZHvP13yKUzj63W8v7CwOid9H90lskXL91
bWpcCxW/RNmiop1Zu5cehXR7QL6jGgWEpAyy4CDpL01VBKXIDlb1JINBWUCbmvYq
ITa+7gXn6Rqw9fpkmkQ2m/g+3KQnQ3kxNl6ojfYdBvenmoMVUHg+DTw1bu2zfbVQ
lbZ5L1jCqJ5Rj5jYC+0TyC/S9w4Ysjyty2zpJFWYtkYydiXJ4DBCm6hGelb7p60T
vQEiX4llCnbeG3hIiyHNCeTicXEJ40Kl6HDwmK/3n/wVoMEgRf3K3Ve6QJEp8Gow
qquXnRylc5fEqZeyy6gOQ6Z0TJM=
=5/ah
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
13 de jul. de 2022, 09:35:5113/07/2022
para Simon Gaiser, Qubes OS Development Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
My primary concern is a case like this:
1. Somebody either uses split-gpg1 or simply wants to protect their
private keys from being extracted and used without authorization.
2. With split-gpg2, an attacker controlling client VM can generate own
key and get it signed with your primary key.
3. They can then push new subkeys to some keyserver to have them
distributed.
At this point, it isn't that helpful that you still control your primary
key, attacker have a subkey they fully control and you may be not even
aware of that. If they manage the key distribution part, nobody else
will see anything suspicious.
> > Sadly, split-gpg2 does not have support for this — yet. There is no
> > fundamental reason such support cannot be added, but right now
> > split-gpg2 (like split-gpg1) either allows all access or denies all
> > access.
>
> That's not quite true. Yes they don't provide an option to filter keys,
> beyond not importing them to your GNUPGHOME (I consider that a feature,
> due to reduced complexity). But what you seem to have missed is that
> GnuPG has native support for exactly this scenario, see the
> --export-secret-subkeys option.
recommend. I think we should adjust defaults to make the scenario
described earlier unlikely to happen by mistake.
What about something like this:
1. Make default gpg homedir for split-gpg2 backend something else than
~/.gnupg.
2. In the migration guide include step to generate subkey for signing
(the one for encryption should be already there).
3. In the migration guide include step like:
gpg --export-secret-subkeys | gpg --homedir /default/split-gpg2/gpghome --import
4. Maybe even consider an option (default enabled, but possible to
disable) that does the step 3 automatically. Either if the split-gpg2
homedir doesn't exist or if secret keys in the default keyring are newer
than in split-gpg2's.
I'm not sure about the last point - it may make key management a bit
easier (for example for those preferring to create new subkeys instead
of extending expiration of existing ones). But on the other hand, one
still need to move public part around(*), so it doesn't eliminate all the
manual steps...
(*) Maybe split-gpg2 should include a separate qrexec service that just
exports all the public keys from the backend? It could save the user one
qvm-copy call...
- --
Best Regards,
Marek Marczykowski-Górecki
1ywntwf9Fh6CObD3ZZRFWm08bkXJYld8C4oap2FqVJ2UuHJfO8GG1LWC+l8TDeCi
duXaHxHK/BfCdxhiMDxrpPL63wam64s56PFjSalr51ranEyCLlm+GF3Qgp7PE+av
xgblUBg9IqbqOGyFrcWELa9667OxS5Uq5JTmiisNJfwToBRBVgSfw0rzxcbNpErU
Nej/dO7eCrw0YL9L7unbvyLj/Gk6Z833Tn446wfa0UAd2TK1oB5tvcoF9umLleCn
pXN+RJuoKDYgatsF4txh3+OO8qufn/wPyUmnspFMeOJ+x3NjpUSt+GaTyKdljaBm
pEH3M1mvvmTj2QhRcuHitAtLnACq+Q==
=28dJ
-----END PGP SIGNATURE-----
Hash: SHA256
1. Somebody either uses split-gpg1 or simply wants to protect their
private keys from being extracted and used without authorization.
2. With split-gpg2, an attacker controlling client VM can generate own
key and get it signed with your primary key.
3. They can then push new subkeys to some keyserver to have them
distributed.
At this point, it isn't that helpful that you still control your primary
key, attacker have a subkey they fully control and you may be not even
aware of that. If they manage the key distribution part, nobody else
will see anything suspicious.
> > Sadly, split-gpg2 does not have support for this — yet. There is no
> > fundamental reason such support cannot be added, but right now
> > split-gpg2 (like split-gpg1) either allows all access or denies all
> > access.
>
> That's not quite true. Yes they don't provide an option to filter keys,
> beyond not importing them to your GNUPGHOME (I consider that a feature,
> due to reduced complexity). But what you seem to have missed is that
> GnuPG has native support for exactly this scenario, see the
>
> From the manpage:
>
> --export-secret-keys
> --export-secret-subkeys
> [...]
>
> The second form of the command has the special property to
> render the secret part of the primary key useless; this is a GNU
> extension to OpenPGP and other implementations can not be
> expected to successfully import such a key. Its intended use is
> in generating a full key with an additional signing subkey on a
> dedicated machine. This command then exports the key without the
> primary key to the main machine.
This indeed makes migration easier, and is exactly the thing we should
> From the manpage:
>
> --export-secret-keys
> --export-secret-subkeys
> [...]
>
> The second form of the command has the special property to
> render the secret part of the primary key useless; this is a GNU
> extension to OpenPGP and other implementations can not be
> expected to successfully import such a key. Its intended use is
> in generating a full key with an additional signing subkey on a
> dedicated machine. This command then exports the key without the
> primary key to the main machine.
recommend. I think we should adjust defaults to make the scenario
described earlier unlikely to happen by mistake.
What about something like this:
1. Make default gpg homedir for split-gpg2 backend something else than
~/.gnupg.
2. In the migration guide include step to generate subkey for signing
(the one for encryption should be already there).
3. In the migration guide include step like:
gpg --export-secret-subkeys | gpg --homedir /default/split-gpg2/gpghome --import
4. Maybe even consider an option (default enabled, but possible to
disable) that does the step 3 automatically. Either if the split-gpg2
homedir doesn't exist or if secret keys in the default keyring are newer
than in split-gpg2's.
I'm not sure about the last point - it may make key management a bit
easier (for example for those preferring to create new subkeys instead
of extending expiration of existing ones). But on the other hand, one
still need to move public part around(*), so it doesn't eliminate all the
manual steps...
(*) Maybe split-gpg2 should include a separate qrexec service that just
exports all the public keys from the backend? It could save the user one
qvm-copy call...
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLOyjIACgkQ24/THMrX
-----BEGIN PGP SIGNATURE-----
1ywntwf9Fh6CObD3ZZRFWm08bkXJYld8C4oap2FqVJ2UuHJfO8GG1LWC+l8TDeCi
duXaHxHK/BfCdxhiMDxrpPL63wam64s56PFjSalr51ranEyCLlm+GF3Qgp7PE+av
xgblUBg9IqbqOGyFrcWELa9667OxS5Uq5JTmiisNJfwToBRBVgSfw0rzxcbNpErU
Nej/dO7eCrw0YL9L7unbvyLj/Gk6Z833Tn446wfa0UAd2TK1oB5tvcoF9umLleCn
pXN+RJuoKDYgatsF4txh3+OO8qufn/wPyUmnspFMeOJ+x3NjpUSt+GaTyKdljaBm
pEH3M1mvvmTj2QhRcuHitAtLnACq+Q==
=28dJ
-----END PGP SIGNATURE-----
Demi Marie Obenour
13 de jul. de 2022, 13:38:2013/07/2022
para Simon Gaiser, Qubes OS Development Mailing List, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On Wed, Jul 13, 2022 at 01:56:54PM +0200, Simon Gaiser wrote:
> [ Sorry for the previous mail with broken white space, hopefully fixed
> now. Really annoying that Google Groups still prevents using PGP/MIME. ]
Yeah, *especially* when one wants to attach files.
> now. Really annoying that Google Groups still prevents using PGP/MIME. ]
smartcard will allow using a signing key for decryption or visa versa.
I know that split-gpg2 will.
> For such special cases I would recommend to use neither split-gpg
> variants and instead use a dedicated qrexec service that just does the
> needed operations. This also makes other things like for example an
> audit log much easier. Of course you loose the "gpg drop-in" feature of
> both split-gpg variants.
and RPM packages. I should clean it up and publish it at some point.
It is only 60 lines of Python, and much of that duplicates what qrexec
policy can already do. This *will* require an array of client-side
wrapper scripts to adapt various programs, but this can be worked
around. The wrapper script used for split-gpg1 might be a basis for
some of these.
> > The best solution that I have come up with is to not allow the
> > frontend to use any key it wishes, but only allow it to use a subset
> > of keys.
>
> Exactly!
>
> > Migrating from split-gpg1 to split-gpg2 would involve generating a
> > subkey that is capable of signing data, but is *not* capable of
> > certification (signing other keys, revoking keys, etc). split-gpg2
> > would then be configured to only allow the frontend to use this
> > subkey, *not* the main key. The frontend could still generate
> > signatures of other keys with this subkey, but these signatures are
> > not valid. If a program trusts these signatures, then either it has
> > imported a key controlled by the frontend (in which case the frontend
> > could have just generated its own key) or the program has a security
> > vulnerability.
> >
> > Sadly, split-gpg2 does not have support for this — yet. There is no
> > fundamental reason such support cannot be added, but right now
> > split-gpg2 (like split-gpg1) either allows all access or denies all
> > access.
>
> That's not quite true. Yes they don't provide an option to filter keys,
> beyond not importing them to your GNUPGHOME (I consider that a feature,
> due to reduced complexity). But what you seem to have missed is that
> GnuPG has native support for exactly this scenario, see the
>
> From the manpage:
>
> --export-secret-keys
> --export-secret-subkeys
> [...]
>
> The second form of the command has the special property to
> render the secret part of the primary key useless; this is a GNU
> extension to OpenPGP and other implementations can not be
> expected to successfully import such a key. Its intended use is
> in generating a full key with an additional signing subkey on a
> dedicated machine. This command then exports the key without the
> primary key to the main machine.
I do not consider this an adequate solution for two reasons. First, it
> From the manpage:
>
> --export-secret-keys
> --export-secret-subkeys
> [...]
>
> The second form of the command has the special property to
> render the secret part of the primary key useless; this is a GNU
> extension to OpenPGP and other implementations can not be
> expected to successfully import such a key. Its intended use is
> in generating a full key with an additional signing subkey on a
> dedicated machine. This command then exports the key without the
> primary key to the main machine.
makes migrating from split-gpg1 to split-gpg2 *much* harder than it
would be otherwise. Not only does one need to generate a new subkey,
but one also needs to create a new GNUPGHOME, configure split-gpg2 to
use it, and make sure that only the subkeys have their secret parts in
that GNUPGHOME. Second, I am not sure if --export-secret-subkeys can be
used with keys that are on a (physical) smart card. It may be that in
this case, there is no solution with split-gpg2 as it stands today.
I do think that per-client GNUPGHOME is a good idea, as it makes using a
single backend qube (often necessary anyway, due to memory limits) much
easier and safer. However, I would like to see some built-in filtering.
For instance, split-gpg2 could refuse to allow signing with a key that
is not capable of signing, or which is capable of certification. It
could also refuse to decrypt with a key not capable of decryption. The
necessary information for such filtering is available in the output of
gpg --list-secret-keys --with-colons. split-gpg2 already parses this
output, so it should not be difficult to add such filtering.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLPAwgACgkQsoi1X/+c
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
IsELPxAAsaxznd8SlfzMY0nyjKLJuCEbrNgcYcxhiWkfK7vO9VzlMg7dwQ9Z78O4
1MYmulpwtkGybYK/+O/xGrwZ8VjDFY86CtzLbLi0/jv1gDiQ9iU8FJ8lwEw05zCO
uNSNMfyBMws40dxJZlsAIPj6lvc1FUDb9vkPi5z5G5KOTd6dVsXP1wRxall+6rXj
pXTnS9EMi+9tXjIhpZat3hDHLrQbIoeZRVg7sfsb6S+r+izVMPOXpaT8pnCHXh4T
9cHFzTfmYnVA1S7sWP2Ad5q34UMOMuk9cMMMa+eQeEk6lnT9zbiB0WVdgM6mDImu
3C0U/B8zPUKiFRgnj+KJbKisOXCHTYj0WiQw1SXjNp6IgSu6F1L2fEp6S6E1ZjD+
grdrQ3uwGDxAVy80CT2PfFwk/kWHaeFRyAPylAwnItvR3r0rBsX8M1CeVFjt56A5
2FnGVQvPbmfirngT++QoFoTTE7Sp+NhLApjamT+pHayYSZ16hJj/xwek2+xRreUM
aG/CNipeO/9Q9zIX8XAL3TYbpC9eaabmHDI4ZeZY+HykhAzhKMkzq1h6WgbzTWsI
ky2V5h6IYHBt+iKlFOHkup7wEC1dBFwROkfbcUcUlGN+NFvawPsOYfOdpirNiK3G
4gSB2xg5eR5OAKPCtZSwICp45ZCX0zWYGm9dhsY5um1QnGvCl6c=
=AwAx
-----END PGP SIGNATURE-----
Demi Marie Obenour
19 de jul. de 2022, 19:40:0919/07/2022
para Marek Marczykowski-Górecki, Simon Gaiser, Qubes OS Development Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Moving the public part around can be semi-automated, as you suggest.
Generating the subkey is also easy if the key is stored in software, and
it might even be possible to write a script to do it.
The main problem is smart card support. OpenPGP smart cards typically
have three key slots: one for signing, one for decryption, and the third
for authentication (often SSH). If all three slots are in use, it will
not be possible to generate or use the subkey on the card. Generating
the key in software would work, but it loses the advantages of the smart
card.
To work around this problem, I think we could provide a split-gpg1
variant that only supports a subset of safe operations.
- --list-keys, --list-secret-keys, --export, and --sign (with hex UIDs)
should be safe. --encrypt should also be safe, but it is not very
useful without the (unwanted) --import. That said, these operations
should enough for Thunderbird, which does encryption internally.
Decryption can be handled via split-gpg2, with filtering to prevent
attempts to decrypt with a signing key. Attempts to perform operations
that the split-gpg1 subset does not allow would be handled via
split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set
up.
> (*) Maybe split-gpg2 should include a separate qrexec service that just
> exports all the public keys from the backend? It could save the user one
> qvm-copy call...
It absolutely should for multiple reasons, not least of which being that
it allows for easily maintaining a shared public keyring. One can
maintain a shared collection of public keys in one qube, and other qubes
can import keys from it as needed.
IsFkGxAA2oU4fzUICtSDvk4ukyqPXheYK1MNSZqpBqoYmywQHSiV/yIfqOYLnl3A
prouHrJG8yyA5OYDRVBaodW4QDBfiIhKB7jl1MWyfjqI3QqVjRdxW8YH8QrViLtR
jEIkXtzu7Akg/gAsMX75NzxYO/APbwkOf7u7eiqny/rwUTpxF1i+3Od0tdcZlEeX
/gSoMQ/DHJ2d9dpzhwImSg080iID2jw9ZVQUSPi+MSKgD98WZeCyakIhluKqM1gk
0C455Qp7yg5qGziV+CjeKjyuTWOYDxr4gQRHAbMgUFwL464uYKajVz0V188RQYTZ
fblj5Eyk3kjedCF+9Xe15/5MfEZgaPPKF6vlZ71e0bH+xLskZ/aR6WjTv6hcj7do
tc27W+sT0XTRhkZ5cvaQb0Dwrrd8u0HA+rghBEji5h+fthlAkOZUh9kjGVvy8O3P
A1kJbmpmvHEyPzP3Yw+QlPGr7ie274sojcNOYDWS3uyfmONSoLxyk707BRhtMq5M
Du/FFHBTm4jxKp3n0vvcViqIxxLnMF4va/bGQnpp3aIAKlsKIum8kkmVHvd1iOZF
uTbU7sNwa9aidc1y6fwZQpwmmIXLc+gV3qMZVkfjRkFMNE4ZRykYsgZPHgge/i14
HW6zdxodUFIWWRnkhAtap4whnT3m3KfnSwuCCFt3UfMDaL4wskU=
=ObKN
-----END PGP SIGNATURE-----
Hash: SHA512
Generating the subkey is also easy if the key is stored in software, and
it might even be possible to write a script to do it.
The main problem is smart card support. OpenPGP smart cards typically
have three key slots: one for signing, one for decryption, and the third
for authentication (often SSH). If all three slots are in use, it will
not be possible to generate or use the subkey on the card. Generating
the key in software would work, but it loses the advantages of the smart
card.
To work around this problem, I think we could provide a split-gpg1
variant that only supports a subset of safe operations.
- --list-keys, --list-secret-keys, --export, and --sign (with hex UIDs)
should be safe. --encrypt should also be safe, but it is not very
useful without the (unwanted) --import. That said, these operations
should enough for Thunderbird, which does encryption internally.
Decryption can be handled via split-gpg2, with filtering to prevent
attempts to decrypt with a signing key. Attempts to perform operations
that the split-gpg1 subset does not allow would be handled via
split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set
up.
> (*) Maybe split-gpg2 should include a separate qrexec service that just
> exports all the public keys from the backend? It could save the user one
> qvm-copy call...
it allows for easily maintaining a shared public keyring. One can
maintain a shared collection of public keys in one qube, and other qubes
can import keys from it as needed.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLXQNAACgkQsoi1X/+c
-----BEGIN PGP SIGNATURE-----
IsFkGxAA2oU4fzUICtSDvk4ukyqPXheYK1MNSZqpBqoYmywQHSiV/yIfqOYLnl3A
prouHrJG8yyA5OYDRVBaodW4QDBfiIhKB7jl1MWyfjqI3QqVjRdxW8YH8QrViLtR
jEIkXtzu7Akg/gAsMX75NzxYO/APbwkOf7u7eiqny/rwUTpxF1i+3Od0tdcZlEeX
/gSoMQ/DHJ2d9dpzhwImSg080iID2jw9ZVQUSPi+MSKgD98WZeCyakIhluKqM1gk
0C455Qp7yg5qGziV+CjeKjyuTWOYDxr4gQRHAbMgUFwL464uYKajVz0V188RQYTZ
fblj5Eyk3kjedCF+9Xe15/5MfEZgaPPKF6vlZ71e0bH+xLskZ/aR6WjTv6hcj7do
tc27W+sT0XTRhkZ5cvaQb0Dwrrd8u0HA+rghBEji5h+fthlAkOZUh9kjGVvy8O3P
A1kJbmpmvHEyPzP3Yw+QlPGr7ie274sojcNOYDWS3uyfmONSoLxyk707BRhtMq5M
Du/FFHBTm4jxKp3n0vvcViqIxxLnMF4va/bGQnpp3aIAKlsKIum8kkmVHvd1iOZF
uTbU7sNwa9aidc1y6fwZQpwmmIXLc+gV3qMZVkfjRkFMNE4ZRykYsgZPHgge/i14
HW6zdxodUFIWWRnkhAtap4whnT3m3KfnSwuCCFt3UfMDaL4wskU=
=ObKN
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
19 de jul. de 2022, 21:34:3719/07/2022
para Simon Gaiser, Demi M. Obenour, Qubes OS Development Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
That's a valid point. But also, if you have a smart card, you have
already more or less the functionality of split-gpg2 there. The main
difference being a confirmation prompt, but some security keys provide
this too. So, there is little (not zero, but little) point in combining
split-gpg2 with a smart card. And also, you can avoid the issue
discussed here the very same way - by having separate card with just
subkey(s) - instead of just separate homedirs.
In short - I wouldn't worry about slots availability too much. It is
something we should probably document in the migration guide, together
with workarounds (separate offline storage/card for the primary key, or
software storage for some subkey).
If many users will be affected by this limitation (and unable/unwilling
to use workaround), we may consider some alternative solution. But I
kind of suspect it won't be necessary.
> To work around this problem, I think we could provide a split-gpg1
> variant that only supports a subset of safe operations.
us to the current situation with split-gpg1. Even if a static set of
options will be enough for all the future versions of TB (which I highly
doubt), there are other applications that users expect to work too. Note
the main issue about options filtering is not about the main command
options, but all the auxiliary options.
> > (*) Maybe split-gpg2 should include a separate qrexec service that just
> > exports all the public keys from the backend? It could save the user one
> > qvm-copy call...
>
> It absolutely should for multiple reasons, not least of which being that
> it allows for easily maintaining a shared public keyring. One can
> maintain a shared collection of public keys in one qube, and other qubes
> can import keys from it as needed.
- --
Best Regards,
Marek Marczykowski-Górecki
1ywX+wf/YOC9+ITgbycY3ebCBuH00Pwe1tr13Bs/rxe1eNClwRnBSCdPpSKbYwcQ
2plQXFE7woIqw25diVYCWKnjAc6kQJdhpVCCkTrCOwntKSg/+54YmPXMzXr6Q3SJ
p5uAvU9ej4RvQ+FZnviEQvIFEM5OmEFizabRssEwGrD7R8N5C6pvrRnbVBngMbCF
I9XzVEo4PlgE/+lbm+erSm5AHf24JUvE9qwS6rkH9lO3tyRRARz1bPxxQwJwhybc
EiyoiWqifWlo4CyaOQAs5xUpqlO6/BAOypmhV6Js27Gt2ksVd906iB7BkO6cKpdR
dUhU0cHm5njGb26AEjYJ3Tl8dD9KSg==
=mUrn
-----END PGP SIGNATURE-----
Hash: SHA256
already more or less the functionality of split-gpg2 there. The main
difference being a confirmation prompt, but some security keys provide
this too. So, there is little (not zero, but little) point in combining
split-gpg2 with a smart card. And also, you can avoid the issue
discussed here the very same way - by having separate card with just
subkey(s) - instead of just separate homedirs.
In short - I wouldn't worry about slots availability too much. It is
something we should probably document in the migration guide, together
with workarounds (separate offline storage/card for the primary key, or
software storage for some subkey).
If many users will be affected by this limitation (and unable/unwilling
to use workaround), we may consider some alternative solution. But I
kind of suspect it won't be necessary.
> To work around this problem, I think we could provide a split-gpg1
> variant that only supports a subset of safe operations.
> --list-keys, --list-secret-keys, --export, and --sign (with hex UIDs)
> should be safe. --encrypt should also be safe, but it is not very
> useful without the (unwanted) --import. That said, these operations
> should enough for Thunderbird, which does encryption internally.
> Decryption can be handled via split-gpg2, with filtering to prevent
> attempts to decrypt with a signing key. Attempts to perform operations
> that the split-gpg1 subset does not allow would be handled via
> split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set
> up.
"should enough for Thunderbird" - that's exactly the thinking that got
> should be safe. --encrypt should also be safe, but it is not very
> useful without the (unwanted) --import. That said, these operations
> should enough for Thunderbird, which does encryption internally.
> Decryption can be handled via split-gpg2, with filtering to prevent
> attempts to decrypt with a signing key. Attempts to perform operations
> that the split-gpg1 subset does not allow would be handled via
> split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set
> up.
us to the current situation with split-gpg1. Even if a static set of
options will be enough for all the future versions of TB (which I highly
doubt), there are other applications that users expect to work too. Note
the main issue about options filtering is not about the main command
options, but all the auxiliary options.
> > (*) Maybe split-gpg2 should include a separate qrexec service that just
> > exports all the public keys from the backend? It could save the user one
> > qvm-copy call...
>
> It absolutely should for multiple reasons, not least of which being that
> it allows for easily maintaining a shared public keyring. One can
> maintain a shared collection of public keys in one qube, and other qubes
> can import keys from it as needed.
- --
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLXW6EACgkQ24/THMrX
-----BEGIN PGP SIGNATURE-----
1ywX+wf/YOC9+ITgbycY3ebCBuH00Pwe1tr13Bs/rxe1eNClwRnBSCdPpSKbYwcQ
2plQXFE7woIqw25diVYCWKnjAc6kQJdhpVCCkTrCOwntKSg/+54YmPXMzXr6Q3SJ
p5uAvU9ej4RvQ+FZnviEQvIFEM5OmEFizabRssEwGrD7R8N5C6pvrRnbVBngMbCF
I9XzVEo4PlgE/+lbm+erSm5AHf24JUvE9qwS6rkH9lO3tyRRARz1bPxxQwJwhybc
EiyoiWqifWlo4CyaOQAs5xUpqlO6/BAOypmhV6Js27Gt2ksVd906iB7BkO6cKpdR
dUhU0cHm5njGb26AEjYJ3Tl8dD9KSg==
=mUrn
-----END PGP SIGNATURE-----
Demi Marie Obenour
20 de jul. de 2022, 01:06:5820/07/2022
para Marek Marczykowski-Górecki, Simon Gaiser, Qubes OS Development Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
IMO the main use of split-gpg with a smart card is to avoid having to
expose the smart card to the (untrusted) frontend VM, which might try to
do nasty things to or with it. This is especially true for YubiKeys and
other multi-function devices.
Thunderbird is a special case for two reasons:
- - It uses gpgme, which only uses a small subset of the possible options.
- - It only performs private key operations with GnuPG, and handles the
rest internally.
Therefore, we could support Thunderbird quite easily. I personally have
qubes-gpg-server invoke a Python wrapper that does some additional
filtering, and this wrapper only understands 36 long options and 10
short options. Some of these options are actually not used by
Thunderbird, but by my Mutt configuration, and at least one of them
(--export-options) is not actually understood by split-gpg1 and so is
not usable.
Furthermore, performing only secret key operations remotely means that
lots of options are simply no-ops. This includes stuff like
- --cert-digest-algo and friends.
The simplest way to handle this is a database listing the properties of
each option. I checked the 426-line output of “gpg2 --dump-option-table”,
and got this (assuming I did not make any mistakes):
- - 5 (--help, etc) are added by libgpg-error
- - 7 are not real options, but headings.
- - 3 are in the listing, but always produce an “invalid option” error, as
if they did not exist. These do not appear in the output of
“gpg --dump-options”.
- - 7 (the ones that start with ‘--debug’) should never be used by any
application.
- - 16 are ignored silently.
- - 9 are ignored with a warning stating they are obsolete.
These 47 options should be ignored on the client and rejected on the
server. Of the remaining 379 options, 44 appear to be duplicates (they
are processed identically by GnuPG). That leaves 335 distinct options,
which is better than 426, but admittedly still a lot. 9 of those
produce a deprecation warning, and most of the others appear to
dangerous or irrelevant to what split-gpg1 supports. I counted 153 that
might actually need to be supported on the backend and are not
duplicates of each other. Not all of them actually need to be
supported, and only supporting signing would cut that number down
substantially. I believe only 37 or so (give or take a few) options
matter for that case, which is much easier to deal with.
I might well have made a mistake here, but overall I think that a
sign-only service would be much easier to maintain.
That said, it could well be that ditching split-gpg1 outright is the
best solution. Even better might be finding ways to move some tools
away from GnuPG; it is a horrible program that implements a pretty ugly
standard. Git commit signing, for example, really ought to use SSH.
IsGyww/8Dtf8DbTegSWGs7wLCtf/wsKZawI9W2eh2rhS32UNO4gDFrhBFAo6Tkzb
yC9fifTaeUY8uvClrv5R+s9d1YYxBvKqwNnzT8rkW+xXzwnjDLFj9qpsS4YCSJ6x
jFMU3VSYWVq1533s40gRz14m8VA1+gyYfbmHvPK/l9eg9MUx3vE8GdRskibUQ/+0
6T2p3/onzyinl/MNmqXB4k1dzuppPYB5s+Vcpi1XhtnJ86CjBuKJhKp32ctVPwiN
v0t/uqRKlnadkf4wdKtFhnrqzSvjAu24FYai1/mme1CA+j4/GfcxrHUTbLB6vcSX
OjFlWMbMINeH2qkeT5CJg2zAetv+diwg8w3BbGI/e4ofVfOOqayBaS8wWj0O7guR
0RSlq6KyYzyYw5nDLQWfloJIBmm/jkzwkZTcR3z7WM9BvXqYFIeyL0W0ahBY5D/x
uQCyreV3KtY3EmyfXCzvgAN8NeQzKXDIVi8Xb/3qcWVVSpS1PVWOGSdeANI7Ldte
HKa9+IJmB0hjTfQJMuYsL05dlrxW2kT2yZiTgafnx8XbtD296HtmjgQ9YwJXHgYF
MSyknFrVG3dy0sK1m6vt/MDvv5Shvs+Q2uahMPy8KD4WyzwxsjiQ4dMO5wF3RSlR
Ytt20UaeuyQCKqDSZPID61gqvwBGcbl2ENVFNE2x3GMPjUyXS9A=
=XZjB
-----END PGP SIGNATURE-----
Hash: SHA512
expose the smart card to the (untrusted) frontend VM, which might try to
do nasty things to or with it. This is especially true for YubiKeys and
other multi-function devices.
- - It uses gpgme, which only uses a small subset of the possible options.
- - It only performs private key operations with GnuPG, and handles the
rest internally.
Therefore, we could support Thunderbird quite easily. I personally have
qubes-gpg-server invoke a Python wrapper that does some additional
filtering, and this wrapper only understands 36 long options and 10
short options. Some of these options are actually not used by
Thunderbird, but by my Mutt configuration, and at least one of them
(--export-options) is not actually understood by split-gpg1 and so is
not usable.
Furthermore, performing only secret key operations remotely means that
lots of options are simply no-ops. This includes stuff like
- --cert-digest-algo and friends.
The simplest way to handle this is a database listing the properties of
each option. I checked the 426-line output of “gpg2 --dump-option-table”,
and got this (assuming I did not make any mistakes):
- - 5 (--help, etc) are added by libgpg-error
- - 7 are not real options, but headings.
- - 3 are in the listing, but always produce an “invalid option” error, as
if they did not exist. These do not appear in the output of
“gpg --dump-options”.
- - 7 (the ones that start with ‘--debug’) should never be used by any
application.
- - 16 are ignored silently.
- - 9 are ignored with a warning stating they are obsolete.
These 47 options should be ignored on the client and rejected on the
server. Of the remaining 379 options, 44 appear to be duplicates (they
are processed identically by GnuPG). That leaves 335 distinct options,
which is better than 426, but admittedly still a lot. 9 of those
produce a deprecation warning, and most of the others appear to
dangerous or irrelevant to what split-gpg1 supports. I counted 153 that
might actually need to be supported on the backend and are not
duplicates of each other. Not all of them actually need to be
supported, and only supporting signing would cut that number down
substantially. I believe only 37 or so (give or take a few) options
matter for that case, which is much easier to deal with.
I might well have made a mistake here, but overall I think that a
sign-only service would be much easier to maintain.
That said, it could well be that ditching split-gpg1 outright is the
best solution. Even better might be finding ways to move some tools
away from GnuPG; it is a horrible program that implements a pretty ugly
standard. Git commit signing, for example, really ought to use SSH.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLXjWwACgkQsoi1X/+c
-----BEGIN PGP SIGNATURE-----
IsGyww/8Dtf8DbTegSWGs7wLCtf/wsKZawI9W2eh2rhS32UNO4gDFrhBFAo6Tkzb
yC9fifTaeUY8uvClrv5R+s9d1YYxBvKqwNnzT8rkW+xXzwnjDLFj9qpsS4YCSJ6x
jFMU3VSYWVq1533s40gRz14m8VA1+gyYfbmHvPK/l9eg9MUx3vE8GdRskibUQ/+0
6T2p3/onzyinl/MNmqXB4k1dzuppPYB5s+Vcpi1XhtnJ86CjBuKJhKp32ctVPwiN
v0t/uqRKlnadkf4wdKtFhnrqzSvjAu24FYai1/mme1CA+j4/GfcxrHUTbLB6vcSX
OjFlWMbMINeH2qkeT5CJg2zAetv+diwg8w3BbGI/e4ofVfOOqayBaS8wWj0O7guR
0RSlq6KyYzyYw5nDLQWfloJIBmm/jkzwkZTcR3z7WM9BvXqYFIeyL0W0ahBY5D/x
uQCyreV3KtY3EmyfXCzvgAN8NeQzKXDIVi8Xb/3qcWVVSpS1PVWOGSdeANI7Ldte
HKa9+IJmB0hjTfQJMuYsL05dlrxW2kT2yZiTgafnx8XbtD296HtmjgQ9YwJXHgYF
MSyknFrVG3dy0sK1m6vt/MDvv5Shvs+Q2uahMPy8KD4WyzwxsjiQ4dMO5wF3RSlR
Ytt20UaeuyQCKqDSZPID61gqvwBGcbl2ENVFNE2x3GMPjUyXS9A=
=XZjB
-----END PGP SIGNATURE-----
Responder a todos
Responder ao autor
Encaminhar
0 nova mensagem