gpg-agent?
martin f krafft
i'll file an ITP unless someone has valid things to say against that.
--
.''`. martin f. krafft <mad...@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
NOTE: The public PGP keyservers are broken!
Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc
Mikhail Sobolev
> where can i find gpg-agent? is it packaged for debian? if not, then
> i'll file an ITP unless someone has valid things to say against that.
which, I think, is the next generation gnupg. :)
--
Misha
al...@syjon.fantastyka.net
> i'll file an ITP unless someone has valid things to say against that.
there are packages by Marcus Brinkmann on ftp.gnupg.org, and I'm working
on adapting those to debian (with Marcus' permission).
alex
--
C _-=-_ H Janusz A. Urbanowicz, stomil at jabber.org, PGP 0x21939169 *
; (_O : ----------------------------------------------------------- --+~|
! &~) ? Płynąć chcę na Wschód, za Suez, gdzie jest dobrem każde zło l_|/
A ~-=-~ O Gdzie przykazań brak dziesięciu, a pić można aż po dno; |
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Colin Walters
> where can i find gpg-agent? is it packaged for debian? if not, then
> i'll file an ITP unless someone has valid things to say against that.
Have you looked at quintuple-agent?
martin f krafft
> > where can i find gpg-agent? is it packaged for debian? if not, then
> > i'll file an ITP unless someone has valid things to say against that.
>
> Have you looked at quintuple-agent?
it's a horrible security threat. i am not going to give my GPG
passphrase to that thing! i've heard that gpg-agent can do better...
Mikhail Sobolev
> On Wed, 2002-11-27 at 09:19, martin f krafft wrote:
> > where can i find gpg-agent? is it packaged for debian? if not, then
> > i'll file an ITP unless someone has valid things to say against that.
>
> Have you looked at quintuple-agent?
But at the first sight, it's very suspicious...
--
Misha
Marco d'Itri
>> where can i find gpg-agent? is it packaged for debian? if not, then
>> i'll file an ITP unless someone has valid things to say against that.
>Have you looked at quintuple-agent?
Yes, it does not work well.
--
ciao,
Marco
Brian May
> > Have you looked at quintuple-agent?
>
> it's a horrible security threat. i am not going to give my GPG
> passphrase to that thing! i've heard that gpg-agent can do better...
What is the security model of each, and why is one better then
the other?
--
Brian May <b...@debian.org>
martin f krafft
> What is the security model of each, and why is one better then
> the other?
quintuple-agent simply echoes the passphrase onto fd0, to be picked up
by another program through a piper.
qagent get gpg | cat
or so reveals your passphrase on stdout. bad.
from what i understood. gpg-agent hooks into gpg like ssh-agent into
ssh and you can't get at the passphrase. correct me if this is wrong.
Joey Hess
> from what i understood. gpg-agent hooks into gpg like ssh-agent into
> ssh and you can't get at the passphrase. correct me if this is wrong.
By this I assume you mean it does something like store the passphrase in
non-swappable memory and then when requested use some form of IPC to
feed it into a /usr/bin/gpg process. I assume it hardcodes the path,
which would prevent you (or someone who has access to your account) from
creating a ~/bin/gpg that asks it for the passphrase and dumps it to
stdout.
That would still let root replace /usr/bin/gpg with such a program
though. So something like this is of some value, but only manages to
narrow the window that lets someone who has temporary access to, say, a
laptop with an agent running and a passphrase entered, to such a laptop
on which you have used sudo in the last 15 minutes. Correct me if I'm
wrong.
q-agent is a PITA to get working with stuff like mutt though, so I do
look forward to using gpg-agent. I just think I'd guard my laptop with
my mail signing key on it about the same no matter which agent I had
running.
--
see shy jo
martin f krafft
> By this I assume you mean it does something like store the passphrase in
> non-swappable memory and then when requested use some form of IPC to
> feed it into a /usr/bin/gpg process. I assume it hardcodes the path,
> which would prevent you (or someone who has access to your account) from
> creating a ~/bin/gpg that asks it for the passphrase and dumps it to
> stdout.
I don't know the details.
> That would still let root replace /usr/bin/gpg with such a program
> though.
root could replace ssh-add with a trojan to get your SSH passphrase.
if you don't trust root, don't use the system.
> So something like this is of some value, but only manages to narrow
> the window that lets someone who has temporary access to, say,
> a laptop with an agent running and a passphrase entered, to such
> a laptop on which you have used sudo in the last 15 minutes. Correct
> me if I'm wrong.
You are right. The same applies to everything else though.
> q-agent is a PITA to get working with stuff like mutt though, so I do
> look forward to using gpg-agent. I just think I'd guard my laptop with
> my mail signing key on it about the same no matter which agent I had
> running.
Right.
Alexander Zangerl
>q-agent is a PITA to get working with stuff like mutt though, so I do
>look forward to using gpg-agent.
<ad type=self>
What for? signing/encrypting stuff? if so, maybe have a look at kuvert.
</ad>
>I just think I'd guard my laptop with
>my mail signing key on it about the same no matter which agent I had
>running.
of course. as soon as you cache with anything you'll have to be as
careful as possible. the point in favour of q-agent, gpg-agent and similar:
if used right, that's the one and only place passwords/phrases are lingering.
(that's why fetchmail on my box mustn't cache, exmh has to use q-agent
etc. pp)
regards
az
--
+ Alexander Zangerl + a...@snafu.priv.at + DSA 42BD645D + (RSA 5B586291)
Hit any user to continue.
Joey Hess
> I find it interesting that you point this out, because I was just
> wondering wether it would be possible to just open(2) the file
> /usr/bin/gpg and exec(2) this file via the file descriptor from this
> open(2) calland not the path name.
Yeah, you could do that (on linux anyway; at the ugliest you might have
to run the link to the fd from /proc). And it'd work, until you upgraded
gpg with a running gpg-agent, at least.
--
see shy jo
Brian May
> That would still let root replace /usr/bin/gpg with such a program
> though. So something like this is of some value, but only manages to
> narrow the window that lets someone who has temporary access to, say, a
> laptop with an agent running and a passphrase entered, to such a laptop
> on which you have used sudo in the last 15 minutes. Correct me if I'm
> wrong.
I am a bit confused with this description, I don't think sudo comes
into it... sudo is rather different in fact (its timeout mechanism
closer, if anything, to that used in Kerberos, rather then ssh-agent).
The protocol in ssh-agent does not allow any process access the the
private key, rather it signs (or decrypts, depending on protocol
version) any data recieved with the users private key and outputs the
result. This is then used in turn by the ssh protocol to authenticate
you at the remote end of the connection[1].
So, while it would be possible for a cracker to use this to logon to a
remote system, it is not possible for him/her to steal your private key.
Yes, somebody could replace ssh-add with a Trojan horse, but also
consider this will only work if the attacker compromises the computer
running the ssh-agent, and not if the attacker compromises another
computer, say one which has a ssh-agent session forwarded from the
first computer. Or if somebody breaks into you user account, not the
root account.
SE-Linux would make this even better, eg. given a secure policy, an
attacker would not even be able to steal your encrypted private key
from .ssh/*
So, I can forward an ssh-agent from computer A to B, and I be sure that
no matter what happens on B, as long as the security on A is maintained,
when I disconnect the session nobody will have been able to copy my
private key (assuming of course the ciphers used are secure).
I would hope that gpg-agent follows similar principles...
This would mean that somebody with access to a gpg-agent could sign
and decrypt data at the time, but still not be able to steal your
private key.
Obviously the quintuple-agent doesn't, so anyone with access to it,
effectively has unrestricted access to your private key.
Notes:
[1] My understanding at least of reading the ssh RFCs. This was years
ago, so I may have some of the details wrong (like signing vs
decrypting).
martin f krafft
> Oh, so it is a running gpg instance with key, and running gpg just
> passes it data. That makes sense. Someone package it, please! :-)
from the current packager i had to hear that it's largely unstable.
many bugs and such. we'll have to wait...
Marco d'Itri
>from the current packager i had to hear that it's largely unstable.
>many bugs and such. we'll have to wait...
I have been using it for weeks without any problem, so I'd say it should
be packaged. (No, I'm not going to do it.)
--
ciao,
Marco