Re: gpg-agents all over the place
by Roberto Ragusa
On 12/23/20 1:56 PM, Oron Peled wrote:
> More problematic, but possible.
>
> The key is using "--pinentry-mode=loopback" (I don't have my scripts in front of me for further details)
There are simple use cases that are very problematic.
Consider this:
[me@localhost tmp]$ date >date.txt
[me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt ### this asks for a passphrase
[me@localhost tmp]$ ls -l
total 8
-rw-rw-r-- 1 me me 32 Dec 24 16:59 date.txt
-rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
[me@localhost tmp]$ rm date.txt
[me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg ### this does not ask!
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: AES encrypted data
gpg: encrypted with 1 passphrase
[me@localhost tmp]$ ls -l
total 8
-rw-rw-r-- 1 me me 32 Dec 24 17:00 date.txt
-rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
that would be a very simple tutorial about symmetric encryption and it is
absolutely surprising, since decryption happens without any need to supply
the passphrase.
Because an agent was forked and it remembers the symmetric
passphrase I've used! Crazy.
So let's see if we can use --batch: using it on encryption conflicts with pineentry,
using it on decryption doesn't disable the gpg-agent usage.
We should try to avoid the agent, let's see in the man page:
--use-agent
--no-use-agent
This is dummy option. gpg always requires the agent.
Wow, the option you want, but with a dummy implementation.
There is a --no-autostart, let's try it: more wasted time.
The use case I care about is for a script that reads some data
from an encrypted file, asking me the passphrase when necessary.
Something like:
token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)"
# use $token
The passphrase should not be hardcoded in the script or remembered by
a magic gpg-agent forked behind my back.
My only solution has been:
dnf install gnupg1
Regards.
--
Roberto Ragusa mail at robertoragusa.it
3 years, 4 months
Re: gpg-agents all over the place
by Jiri Kucera
Hello Roberto,
----- Original Message -----
> From: "Roberto Ragusa" <mail(a)robertoragusa.it>
> To: devel(a)lists.fedoraproject.org
> Sent: Thursday, December 24, 2020 5:20:38 PM
> Subject: Re: gpg-agents all over the place
>
> On 12/23/20 1:56 PM, Oron Peled wrote:
>
> > More problematic, but possible.
> >
> > The key is using "--pinentry-mode=loopback" (I don't have my scripts in
> > front of me for further details)
> There are simple use cases that are very problematic.
> Consider this:
>
> [me@localhost tmp]$ date >date.txt
> [me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt ### this asks
> for a passphrase
> [me@localhost tmp]$ ls -l
> total 8
> -rw-rw-r-- 1 me me 32 Dec 24 16:59 date.txt
> -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
> [me@localhost tmp]$ rm date.txt
> [me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg ### this does
> not ask!
> gpg: WARNING: no command supplied. Trying to guess what you mean ...
> gpg: AES encrypted data
> gpg: encrypted with 1 passphrase
> [me@localhost tmp]$ ls -l
> total 8
> -rw-rw-r-- 1 me me 32 Dec 24 17:00 date.txt
> -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
>
> that would be a very simple tutorial about symmetric encryption and it is
> absolutely surprising, since decryption happens without any need to supply
> the passphrase.
> Because an agent was forked and it remembers the symmetric
> passphrase I've used! Crazy.
>
> So let's see if we can use --batch: using it on encryption conflicts with
> pineentry,
> using it on decryption doesn't disable the gpg-agent usage.
>
> We should try to avoid the agent, let's see in the man page:
> --use-agent
> --no-use-agent
> This is dummy option. gpg always requires the agent.
> Wow, the option you want, but with a dummy implementation.
>
> There is a --no-autostart, let's try it: more wasted time.
>
> The use case I care about is for a script that reads some data
> from an encrypted file, asking me the passphrase when necessary.
> Something like:
>
> token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)"
> # use $token
>
> The passphrase should not be hardcoded in the script or remembered by
> a magic gpg-agent forked behind my back.
>
> My only solution has been:
> dnf install gnupg1
did you try `--no-symkey-cache` option? It disables password caching during the session:
# date > date.txt
# gpg --pinentry-mode=loopback --no-symkey-cache -c date.txt
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
# gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: AES.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
# gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: AES.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
# gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: AES.CFB encrypted data
gpg: encrypted with 1 passphrase
File 'date.txt' exists. Overwrite? (y/N) N
Enter new filename: date2.txt
# diff date.txt date2.txt
# rpm -q gnupg2
gnupg2-2.2.23-1.fc33.x86_64
Regards
Jiri
>
> Regards.
>
> --
> Roberto Ragusa mail at robertoragusa.it
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
3 years, 4 months
Re: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)
by Kevin Fenzi
On Thu, 03 Apr 2014 14:29:16 +0200
Miroslav Suchý <msuchy(a)redhat.com> wrote:
> On 04/03/2014 03:46 AM, Toshio Kuratomi wrote:
...snip...
> > For whoever is going to approach infra about signing the packages in
> > copr it probably makes more sense to either talk about enhancing
> > sigul to work with copr or getting obs-sign to be able to sign
> > packages from koji. We'd probably also want to ask bressers or
> > someone else from the security team to do some sort of evaluation
> > of the code bases that we're looking at.
>
> That would be probably me. I mean the guy who will be implementing
> signing of packages in Copr.
>
> I investigated several possibilities and talked to several people.
> But you are correct that I did not send conclusion to mailing list
> yet. Maybe it is right time to do it now.
>
> One of the guy to who I talked to is Miroslav Trmac, who is current
> maintainer and main author of Sigul since 2009. The conclusion from
> discussion with him is that:
> * we would need need different instance, because to use the same
> instance for main distribution and for relaxed ring (Copr,
> Playground...) is not best idea. Neither from security POV nor for
> technical implementation. (*)
> * we would need to do some development of Sigul before deploying new
> instance
> * and we would likely should migrate to gpg2 (from gpg1)
> * Sigul have very restricted network setup, which is probably not
> needed for Copr
>
> On the other hand obs-sign:
> * is actively maintained
> * is more simple
> * used in OBS as well (which mean community and so on)
> * have security model and network setup good enough for Copr (I
> arranged meeting of Adrian Shröter from OBS and Mirek Trmač during
> DevConf.cz where they discussed technical details and none of them
> seen any blocker).
So, one consideration here is that we also are looking at trying to
sign rawhide packages and perhaps scratch builds and/or official
builds. It would be very nice to not duplicate a bunch in solutions for
signing copr and for the above too. It would be nice to reuse things
that make sense there.
> Yes, obs-sign is not packaged for Fedora (yet), but the spec exists
> and I can get it in Fedora withing week. I do not see that as problem.
>
> If I sum it up, then obs-sign is clear winner to me. Therefore this
> is the way I would like to go in Copr.
>
> But it still does not bubble up in my TODO list. So we have plenty of
> time for discussion :)
Sure. obs-sign could perhaps work for the other use cases with a koji
plugin to talk to it as desired. See
https://fedorahosted.org/rel-eng/ticket/5870 for more discussion.
> (*) You suggested that having one signing server is better as "The
> more signing servers we have the greater the
> > attack surface infrastructure has to protect." I disagree.
Well, it means two things to update, two things to protect.
obs-signd also stores private key and passphrase on local disk right?
> First: it is not technical possible. Because Koji and current Sigul
> is in different networks and I'm not sure if we want to change it.
Sure, but thats not a problem. We could have a server listening to
fedmsg do the signing. That won't work for copr tho, because the sigul
server doesn't have access to the copr packages to write out a
signature.
> Likely not. Second: if you compromise Copr signing server then you
> have compromised main distribution. Therefore even from security POV
> is better to have different signing server for main distribution and
> for Copr.
Well, it's not that black and white. To compromise sigul you need both
access to the keystore and passphrase(s) to each key to unlock the
private key. If you just have access to the keystore you can't still
get access to the private key. If you just have a passphrase for a key
you can't do anything without access to the server or the keystore.
kevin
10 years, 1 month
Re: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)
by Miroslav Suchý
On 04/03/2014 03:46 AM, Toshio Kuratomi wrote:
> I saw that this got voted on in the meeting even though it didn't get
> recorded as such for the meeting minutes. The proposal seemed to be:
> use obs-sign to sign packages. That's not actually a proposal that we
> can approve here. The proposal here should probably be: "is signing
> of packages a blocker for making the playground repo, nice to have, or
> optional?"
>
> In terms of how to get the packages signed, that's something that the
> infrastructure team has to decide. IIRC past conversations correctly,
> adding another signing server (meaning a different code base) to
> infrastructure is at the bottom of their list of ways to sign packages
> in copr (and by extension in the playground repo).
>
> When I saw the vote in the meeting logs I mentioned it to nirik. In
> turn he told me that he hadn't heard anything about this and had only
> glanced briefly at obs-sign (mentioning that it wasn't even packaged
> for Fedora yet). As I related to tjanez on IRC today, I think lack of
> packaging probably slows down infra's ability to deploy it but is only
> a foottnote to the real problems. Compromising signing servers and
> gaining access to the private keys on them is a very high value target
> for an attacker. The more signing servers we have the greater the
> attack surface infrastructure has to protect. probably in the ideal
> scenario infra would run a single signing server and everything
> needing signing would be sent to that. (Jesse Kating had that use in
> mind when he designed sigul but I don't know if that design goal
> actually became part of the software that we are currently running).
> A step down from there might be running multiple instances of the same
> signing software to handle the various needs as infra would then have
> to protect the keys on these multiple hosts. At the bottom of the
> list is running separate signing software as that places the
> additional burden of auditing and protecting the software stack of the
> multiple signing servers.
>
> For whoever is going to approach infra about signing the packages in
> copr it probably makes more sense to either talk about enhancing sigul
> to work with copr or getting obs-sign to be able to sign packages from
> koji. We'd probably also want to ask bressers or someone else from
> the security team to do some sort of evaluation of the code bases that
> we're looking at.
That would be probably me. I mean the guy who will be implementing signing of packages in Copr.
I investigated several possibilities and talked to several people. But you are correct that I did not send conclusion to
mailing list yet. Maybe it is right time to do it now.
One of the guy to who I talked to is Miroslav Trmac, who is current maintainer and main author of Sigul since 2009.
The conclusion from discussion with him is that:
* we would need need different instance, because to use the same instance for main distribution and for relaxed ring
(Copr, Playground...) is not best idea. Neither from security POV nor for technical implementation. (*)
* we would need to do some development of Sigul before deploying new instance
* and we would likely should migrate to gpg2 (from gpg1)
* Sigul have very restricted network setup, which is probably not needed for Copr
On the other hand obs-sign:
* is actively maintained
* is more simple
* used in OBS as well (which mean community and so on)
* have security model and network setup good enough for Copr (I arranged meeting of Adrian Shröter from OBS and Mirek
Trmač during DevConf.cz where they discussed technical details and none of them seen any blocker).
Yes, obs-sign is not packaged for Fedora (yet), but the spec exists and I can get it in Fedora withing week. I do not
see that as problem.
If I sum it up, then obs-sign is clear winner to me. Therefore this is the way I would like to go in Copr.
But it still does not bubble up in my TODO list. So we have plenty of time for discussion :)
(*) You suggested that having one signing server is better as "The more signing servers we have the greater the
> attack surface infrastructure has to protect." I disagree.
First: it is not technical possible. Because Koji and current Sigul is in different networks and I'm not sure if we want
to change it. Likely not.
Second: if you compromise Copr signing server then you have compromised main distribution. Therefore even from security
POV is better to have different signing server for main distribution and for Copr.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
10 years, 1 month
Re: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)
by Marcela Mašláňová
On 04/03/2014 02:29 PM, Miroslav Suchý wrote:
> On 04/03/2014 03:46 AM, Toshio Kuratomi wrote:
>> I saw that this got voted on in the meeting even though it didn't get
>> recorded as such for the meeting minutes. The proposal seemed to be:
>> use obs-sign to sign packages. That's not actually a proposal that we
>> can approve here. The proposal here should probably be: "is signing
>> of packages a blocker for making the playground repo, nice to have, or
>> optional?"
>>
>> In terms of how to get the packages signed, that's something that the
>> infrastructure team has to decide. IIRC past conversations correctly,
>> adding another signing server (meaning a different code base) to
>> infrastructure is at the bottom of their list of ways to sign packages
>> in copr (and by extension in the playground repo).
>>
>> When I saw the vote in the meeting logs I mentioned it to nirik. In
>> turn he told me that he hadn't heard anything about this and had only
>> glanced briefly at obs-sign (mentioning that it wasn't even packaged
>> for Fedora yet). As I related to tjanez on IRC today, I think lack of
>> packaging probably slows down infra's ability to deploy it but is only
>> a foottnote to the real problems. Compromising signing servers and
>> gaining access to the private keys on them is a very high value target
>> for an attacker. The more signing servers we have the greater the
>> attack surface infrastructure has to protect. probably in the ideal
>> scenario infra would run a single signing server and everything
>> needing signing would be sent to that. (Jesse Kating had that use in
>> mind when he designed sigul but I don't know if that design goal
>> actually became part of the software that we are currently running).
>> A step down from there might be running multiple instances of the same
>> signing software to handle the various needs as infra would then have
>> to protect the keys on these multiple hosts. At the bottom of the
>> list is running separate signing software as that places the
>> additional burden of auditing and protecting the software stack of the
>> multiple signing servers.
>>
>> For whoever is going to approach infra about signing the packages in
>> copr it probably makes more sense to either talk about enhancing sigul
>> to work with copr or getting obs-sign to be able to sign packages from
>> koji. We'd probably also want to ask bressers or someone else from
>> the security team to do some sort of evaluation of the code bases that
>> we're looking at.
>
> That would be probably me. I mean the guy who will be implementing
> signing of packages in Copr.
>
> I investigated several possibilities and talked to several people. But
> you are correct that I did not send conclusion to mailing list yet.
> Maybe it is right time to do it now.
>
> One of the guy to who I talked to is Miroslav Trmac, who is current
> maintainer and main author of Sigul since 2009.
> The conclusion from discussion with him is that:
> * we would need need different instance, because to use the same
> instance for main distribution and for relaxed ring (Copr,
> Playground...) is not best idea. Neither from security POV nor for
> technical implementation. (*)
> * we would need to do some development of Sigul before deploying new
> instance
> * and we would likely should migrate to gpg2 (from gpg1)
> * Sigul have very restricted network setup, which is probably not needed
> for Copr
>
> On the other hand obs-sign:
> * is actively maintained
> * is more simple
> * used in OBS as well (which mean community and so on)
> * have security model and network setup good enough for Copr (I arranged
> meeting of Adrian Shröter from OBS and Mirek Trmač during DevConf.cz
> where they discussed technical details and none of them seen any blocker).
>
> Yes, obs-sign is not packaged for Fedora (yet), but the spec exists and
> I can get it in Fedora withing week. I do not see that as problem.
>
> If I sum it up, then obs-sign is clear winner to me. Therefore this is
> the way I would like to go in Copr.
>
> But it still does not bubble up in my TODO list. So we have plenty of
> time for discussion :)
>
>
> (*) You suggested that having one signing server is better as "The more
> signing servers we have the greater the
> > attack surface infrastructure has to protect." I disagree.
> First: it is not technical possible. Because Koji and current Sigul is
> in different networks and I'm not sure if we want to change it. Likely not.
> Second: if you compromise Copr signing server then you have compromised
> main distribution. Therefore even from security POV is better to have
> different signing server for main distribution and for Copr.
>
The summary of Mirek's notes was for a long time in Open Questions
section [1]. I removed it yesterday, because it was voted for obs-signd.
Mirek is member of infra, so I leave the discussion up to him.
[1]
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28dr...
Marcela
10 years, 1 month