4:22 p.m.
Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 problem
for me:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
I'll push an update shortly.
Installing pam_keyring isn't enough though, it still requires manual
edition of /etc/pam.d/gdm to make it work. I was hoping to start some
discussions on what needs to happen to make its behavior enabled
automatically upon installation, especially since this is on the F-8
wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in
%post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
Or add a patch to the gdm package and make it require pam_keyring ? Or
do we want to make this feature optional from authconfig ?
Another issue is how do we update the keyring password when the user
changes his/her password ?
denis
4:31 p.m.
Denis Leroy <denis <at> poolshark.org> writes:
Installing pam_keyring isn't enough though, it still requires
manual
edition of /etc/pam.d/gdm to make it work. I was hoping to start some
discussions on what needs to happen to make its behavior enabled
automatically upon installation, especially since this is on the F-8
wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in
%post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
Or add a patch to the gdm package and make it require pam_keyring ? Or
do we want to make this feature optional from authconfig ?
What about /etc/pam.d/kdm and /etc/pam.d/kdm-np? Not every gnome-keyring-using
application necessarily always runs inside a GDM session. ;-)
Kevin Kofler
4:45 p.m.
On Fri, 2007-06-15 at 21:31 +0000, Kevin Kofler wrote:
Denis Leroy <denis <at> poolshark.org> writes:
> Installing pam_keyring isn't enough though, it still requires manual
> edition of /etc/pam.d/gdm to make it work. I was hoping to start some
> discussions on what needs to happen to make its behavior enabled
> automatically upon installation, especially since this is on the F-8
> wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in
> %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
> Or add a patch to the gdm package and make it require pam_keyring ? Or
> do we want to make this feature optional from authconfig ?
What about /etc/pam.d/kdm and /etc/pam.d/kdm-np? Not every gnome-keyring-using
application necessarily always runs inside a GDM session. ;-)
wow proposed mixed desktop relations. How risque.
Probably if we write this into authconfig we should think how this
should work. Maybe an advanced option. I have definitely had e-mails
from very upset kde people that were very upset that pam_keyring was
starting up gnome_keyring_daemon in their session. Just something to
keep in mind.
Jon
4:50 p.m.
Jon Nettleton <jon.nettleton <at> gmail.com> writes:
wow proposed mixed desktop relations. How risque.
Probably if we write this into authconfig we should think how this
should work. Maybe an advanced option. I have definitely had e-mails
from very upset kde people that were very upset that pam_keyring was
starting up gnome_keyring_daemon in their session. Just something to
keep in mind.
This is indeed a problem, if people don't have anything using
gnome_keyring_daemon, they'll hate having it autostarted, if they do have
something using it, they'll complain if it doesn't get autostarted. You can't
win. :-(
Well, maybe pam_keyring could be taught to just do nothing (not error or
anything) if gnome_keyring is not installed and the package not made to require
it. It might still get dragged in due to some wacky indirect dependencies and
end up autostarted even where not needed that way though.
Or maybe the hack of having the pam_keyring scriptlet change the pam
configuration is really the way to go, then users could just install it when
needed and leave it off where not needed or wanted, it does sound like a pretty
hackish solution to me though.
Kevin Kofler
4:40 p.m.
On Fri, 2007-06-15 at 23:22 +0200, Denis Leroy wrote:
Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7
problem
for me:
okay this isn't a release, release. It is a pre-release that fixes the
F-7 problems.
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
I'll push an update shortly.
Installing pam_keyring isn't enough though, it still requires manual
edition of /etc/pam.d/gdm to make it work. I was hoping to start some
discussions on what needs to happen to make its behavior enabled
automatically upon installation, especially since this is on the F-8
wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in
%post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
Or add a patch to the gdm package and make it require pam_keyring ? Or
do we want to make this feature optional from authconfig ?
I have a mostly functional addition to authconfig for enabling and
disabling it. I am wondering if the architecture for this app needs to
be extended to make it easy for each pam_package to add an xml file
somewhere to add support for it in authconfig.
Another issue is how do we update the keyring password when the user
changes his/her password ?
The release above has 95% of the code for support of pam_sm_chauthtok.
It has a couple of small bugs that I plan on fixing for full
functionality in supporting changing the keyring password in the
pam_stack.
This will change partially again in 2.20 when we add support for a
on_login keyring in gnome-keyring. I just got wiki write access and
will create a page about it this weekend.
Jon
4:46 p.m.
On 6/15/07, Denis Leroy <denis(a)poolshark.org> wrote:
Should it use a scriptlet that modifies /etc/pam.d/gdm in
%post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
It should just work for default desktop installs moving forward. I
frankly don't care how.
Or add a patch to the gdm package and make it require pam_keyring ?
uhm should avoid making this a hard requirement for gdm. Can pam deal
with a scenario
where pam_keyring is referenced as an optional rule in the auth stack
but the pam_keyring module is not actually installed? And don't we at
least have to also consider this being used in the pam stack for kdm,
since kdm can start a gnome desktop session?
Or do we want to make this feature optional from authconfig ?
I'm not sure if this makes much sense. Since the keyring isn't
referencing any systemwide or networkwide resources when doing the
authing and is inherently a per user thing I'm not sure I see a clear
use case where this needs to be configurable (other than spite.)
Another issue is how do we update the keyring password when the user
changes his/her password ?
Do you really want to automate this for all users? Some users might
want a deliberately separate password.
-jef
11:10 a.m.
On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote:
On 6/15/07, Denis Leroy <denis(a)poolshark.org> wrote:
> Should it use a scriptlet that modifies /etc/pam.d/gdm in
> %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
It should just work for default desktop installs moving forward. I
frankly don't care how.
> Or add a patch to the gdm package and make it require pam_keyring ?
uhm should avoid making this a hard requirement for gdm. Can pam deal
with a scenario
where pam_keyring is referenced as an optional rule in the auth stack
but the pam_keyring module is not actually installed? And don't we at
least have to also consider this being used in the pam stack for kdm,
since kdm can start a gnome desktop session?
Pam deals with it fine (allows login
for nonexistent 'optional'
modules), but it will issue a nasty warning in syslog. I think that
editing gdm config within a %post script is fine.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
11:52 a.m.
On Mon, 2007-06-18 at 18:10 +0200, Tomas Mraz wrote:
On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote:
> On 6/15/07, Denis Leroy <denis(a)poolshark.org> wrote:
> > Should it use a scriptlet that modifies /etc/pam.d/gdm in
> > %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
>
> It should just work for default desktop installs moving forward. I
> frankly don't care how.
>
> > Or add a patch to the gdm package and make it require pam_keyring ?
>
> uhm should avoid making this a hard requirement for gdm. Can pam deal
> with a scenario
> where pam_keyring is referenced as an optional rule in the auth stack
> but the pam_keyring module is not actually installed? And don't we at
> least have to also consider this being used in the pam stack for kdm,
> since kdm can start a gnome desktop session?
Pam deals with it fine (allows login for nonexistent 'optional'
modules), but it will issue a nasty warning in syslog. I think that
editing gdm config within a %post script is fine.
Editing pam configs in package scriptlets strikes me as a really bad
idea... it's not something that's ever been done and so a lot of people
are going to get very surprised by it. Especially if they've customized
their configs at all. And doing it once is going to set the precedent
for it to be done more...
Jeremy
12:20 p.m.
On Mon, 18 Jun 2007, Jeremy Katz wrote:
Editing pam configs in package scriptlets strikes me as a really bad
idea... it's not something that's ever been done and so a lot of people
are going to get very surprised by it. Especially if they've customized
their configs at all. And doing it once is going to set the precedent
for it to be done more...
+1.
I always add pam_access to pam configs in my %post of kickstarts and I'd
not want that mucked with.
-sv
1:26 p.m.
Jeremy Katz wrote:
On Mon, 2007-06-18 at 18:10 +0200, Tomas Mraz wrote:
> On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote:
>> On 6/15/07, Denis Leroy <denis(a)poolshark.org> wrote:
>>> Should it use a scriptlet that modifies /etc/pam.d/gdm in
>>> %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
>> It should just work for default desktop installs moving forward. I
>> frankly don't care how.
>>
>>> Or add a patch to the gdm package and make it require pam_keyring ?
>> uhm should avoid making this a hard requirement for gdm. Can pam deal
>> with a scenario
>> where pam_keyring is referenced as an optional rule in the auth stack
>> but the pam_keyring module is not actually installed? And don't we at
>> least have to also consider this being used in the pam stack for kdm,
>> since kdm can start a gnome desktop session?
> Pam deals with it fine (allows login for nonexistent 'optional'
> modules), but it will issue a nasty warning in syslog. I think that
> editing gdm config within a %post script is fine.
Editing pam configs in package scriptlets strikes me as a really bad
idea... it's not something that's ever been done and so a lot of people
are going to get very surprised by it. Especially if they've customized
their configs at all. And doing it once is going to set the precedent
for it to be done more...
I tend to agree, but what's the alternative ?
1:47 p.m.
Denis Leroy (denis(a)poolshark.org) said:
>Editing pam configs in package scriptlets strikes me as a really
bad
>idea... it's not something that's ever been done and so a lot of people
>are going to get very surprised by it. Especially if they've customized
>their configs at all. And doing it once is going to set the precedent
>for it to be done more...
I tend to agree, but what's the alternative ?
Add support in authconfig, set it up by default but require existing
users to run authconfig once?
Bill
9:23 a.m.
On Fri, 15 Jun 2007 23:22:42 +0200
Denis Leroy <denis(a)poolshark.org> wrote:
Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7
problem for me:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
I'll push an update shortly.
A friend scanning this mailing list asked me to pose a question; is
there any thought to being able to manage ssh-agent passphrases
within gnome-keyring as well? This would cut down on the number of
times a password has to be entered. Are there known challenges to using
gnome-keyring for ssh-agent as well?
--
Jesse Keating
Release Engineer: Fedora
9:46 a.m.
Hi.
On Tue, 17 Jul 2007 10:23:40 -0400, Jesse Keating wrote:
A friend scanning this mailing list asked me to pose a question; is
there any thought to being able to manage ssh-agent passphrases
within gnome-keyring as well? This would cut down on the number of
times a password has to be entered. Are there known challenges to
using gnome-keyring for ssh-agent as well?
That ought to work. SSH just calls a helper process, which has to print
the keyphrase to stdout. Where it gets the keyphrase is irrelevant.
The current helpers come from openssh-askpass (which is built from
the main ssh package), so we'd have to add gnome-keyring-ssh-askpass
there.
To be honest, such a helper has been somewhere on my to-do-list
for two years at least :)
9:53 a.m.
Jesse Keating wrote:
On Fri, 15 Jun 2007 23:22:42 +0200
Denis Leroy <denis(a)poolshark.org> wrote:
> Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7
> problem for me:
>
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
>
> I'll push an update shortly.
A friend scanning this mailing list asked me to pose a question; is
there any thought to being able to manage ssh-agent passphrases
within gnome-keyring as well? This would cut down on the number of
times a password has to be entered. Are there known challenges to using
gnome-keyring for ssh-agent as well?
Speaking of gpg/ssh integration...
I've been asked to enable ssh support in gpg-agent,
http://bugzilla.redhat.com/247616
any comment/feedback on how to best make this work?
Haven't done much testing myself yet, but would it be worth exploring the
idea of augmenting or possibly replacing ssh-agent?
-- Rex
10:22 a.m.
On 17/07/07, Rex Dieter <rdieter(a)math.unl.edu> wrote:
Speaking of gpg/ssh integration...
I've been asked to enable ssh support in gpg-agent,
http://bugzilla.redhat.com/247616
any comment/feedback on how to best make this work?
Haven't done much testing myself yet, but would it be worth exploring the
idea of augmenting or possibly replacing ssh-agent?
I felt someone should also mention Seahorse at this point, which
handles both GPG and ssh keys and is well integrated into gnome:
http://www.gnome.org/projects/seahorse/
... so I just did.
J.
10:02 a.m.
Jesse Keating wrote:
A friend scanning this mailing list asked me to pose a question; is
there any thought to being able to manage ssh-agent passphrases
within gnome-keyring as well? This would cut down on the number of
times a password has to be entered. Are there known challenges to
using gnome-keyring for ssh-agent as well?
While this isn't quite an answer to the question, it may be useful to
the friend that asked...
With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar to
what you do to use pam_keyring), you can enter your password once and
be done. That is, at the gdm login screen you enter your username and
password and your ssh keys get loaded. This requires your login
password and the password on your ssh key(s) to match.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I advise you to go on living solely to enrage those who are paying
your annuities. It is the only pleasure I have left.
-- Voltaire
10:31 a.m.
On 17/07/07, Todd Zullinger <tmz(a)pobox.com> wrote:
With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar
to
what you do to use pam_keyring), you can enter your password once and
be done. That is, at the gdm login screen you enter your username and
password and your ssh keys get loaded. This requires your login
password and the password on your ssh key(s) to match.
That requirement isn't something that should be encouraged, though,
IMO. There's a reason that ssh uses passphrases.
J.
10:42 a.m.
Jonathan Underwood wrote:
On 17/07/07, Todd Zullinger <tmz(a)pobox.com> wrote:
> With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar
> to what you do to use pam_keyring), you can enter your password
> once and be done. That is, at the gdm login screen you enter your
> username and password and your ssh keys get loaded. This requires
> your login password and the password on your ssh key(s) to match.
That requirement isn't something that should be encouraged, though,
IMO.
Yes, there's a benefit to keeping the passphrases separate. This
also affect pam_keyring. Anything that intends to unlock a keyring
with one passphrase pretty much requires that the passphrases match.
There is always a tradeoff between security and convenience. Are you
suggesting that there not be a way for users to enable their login to
unlock their various keyrings? Or are there better tools to make this
both convenient and more secure?
There's a reason that ssh uses passphrases.
You say that like we don't all use passphrases for login. ;)
My fault for saying password when I should have said passphrase.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intaxication (n.) Euphoria at getting a tax refund, which lasts until
you realize it was your money to start with.
11:54 a.m.
On 17/07/07, Todd Zullinger <tmz(a)pobox.com> wrote:
Yes, there's a benefit to keeping the passphrases separate.
This
also affect pam_keyring. Anything that intends to unlock a keyring
with one passphrase pretty much requires that the passphrases match.
You were arguing for the login password/phrase matching the ssh
password/phrase - that seems like a bad idea and really unecessary.
Surely, what you mean is that it's required for the login
password/phrase to be the same password/phrase as for whatever
application stores the various passphrases for ssh/gpg etc.
There is always a tradeoff between security and convenience. Are
you
suggesting that there not be a way for users to enable their login to
unlock their various keyrings?
Nope. But that in no way requires login password/phrase == ssh key
password/phrase.
J.
12:24 p.m.
Jonathan Underwood wrote:
You were arguing for the login password/phrase matching the ssh
password/phrase - that seems like a bad idea and really unecessary.
It's necessary for using pam_ssh at the moment. It is also needed
for pam_keyring. I'm not arguing that this is the best way. I was
only passing on this info that may help the Jesse's friend find a
workable solution with the current tools.
> There is always a tradeoff between security and convenience.
Are
> you suggesting that there not be a way for users to enable their
> login to unlock their various keyrings?
Nope. But that in no way requires login password/phrase == ssh key
password/phrase.
At present for pam_ssh it does. I'm not sure how much of a risk this
really is. Say that gnome-keyring gets support for unlocking ssh
keys. Then I could have my ssh passphrase stored in gnome-keyring,
which would be using the same passphrase as my login. My ssh
passphrase is now only as secure as gnome-keying is. How secure is
gnome-keying?
I'm not suggesting that gnome-keying is inherently insecure, as I've
not looked at it (nor am I really qualified to assess it properly).
But I'm not sure that having gnome-keyring -- using the same
passphrase as my login -- protecting my ssh passphrase is that much
different than using the same passphrase as login for the ssh key. Am
I missing something really obvious?
For those that want much stronger security, not using any sort of
automated passphrase store and using different passphrases for login,
ssh keys, etc. is the only way to go. That's not the target audience
for the features an automated pam_keyring would provide, as far as I
can tell.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The average woman would rather be beautiful than smart because the
average man can see better than he can think.
2:18 p.m.
Jesse Keating schrieb:
A friend scanning this mailing list asked me to pose a question; is
there any thought to being able to manage ssh-agent passphrases
within gnome-keyring as well? This would cut down on the number of
times a password has to be entered. Are there known challenges to using
gnome-keyring for ssh-agent as well?
Hi Jesse,
we have keychain in Fedora, which exactly does this.
Alexander
2:23 p.m.
On Tue, 17 Jul 2007 21:18:11 +0200
Alexander Dalloz <ad+lists(a)uni-x.org> wrote:
Hi Jesse,
we have keychain in Fedora, which exactly does this.
Is that a second UI prompt though for a passphrase? My friend's main
concern is that multiple password/phrase prompts from multiple UIs is
pretty gross and they should all be the same UI, potentially a single
prompt.
--
Jesse Keating
Release Engineer: Fedora
2:54 p.m.
Jesse Keating schrieb:
On Tue, 17 Jul 2007 21:18:11 +0200
Alexander Dalloz <ad+lists(a)uni-x.org> wrote:
> Hi Jesse,
>
> we have keychain in Fedora, which exactly does this.
Is that a second UI prompt though for a passphrase? My friend's main
concern is that multiple password/phrase prompts from multiple UIs is
pretty gross and they should all be the same UI, potentially a single
prompt.
Yes, just the same kind of UI prompts for SSH and GPG keys.
I have several SSH keys I load into ssh-agent at first login and thus
get several UI input popups initiated by keychain. As well the keyring
request for my wireless WPA key. Can't think of a way a single
application would reduce the onetime amount of passphrase requests.
Alexander
3:21 p.m.
On Tue, 17 Jul 2007 21:54:22 +0200
Alexander Dalloz <ad+lists(a)uni-x.org> wrote:
Yes, just the same kind of UI prompts for SSH and GPG keys.
I have several SSH keys I load into ssh-agent at first login and thus
get several UI input popups initiated by keychain. As well the keyring
request for my wireless WPA key. Can't think of a way a single
application would reduce the onetime amount of passphrase requests.
Well, theoretically you'd allow gnome-keyring to save all those
passphrases and then you'd have a master passphrase (different from the
rest) that would allow gnome-keyring to dole them out as needed. But
yes, that puts all your eggs in the gnome-keyring basket and relying on
the strength of your master keyring. I always make sure my login
password/phrase is different than that of my master keyring phrase, and
that is different from any of the passphrases in my ring.
--
Jesse Keating
Release Engineer: Fedora
4:59 p.m.
On Tue, 2007-07-17 at 16:21 -0400, Jesse Keating wrote:
On Tue, 17 Jul 2007 21:54:22 +0200
Alexander Dalloz <ad+lists(a)uni-x.org> wrote:
> Yes, just the same kind of UI prompts for SSH and GPG keys.
>
> I have several SSH keys I load into ssh-agent at first login and thus
> get several UI input popups initiated by keychain. As well the keyring
> request for my wireless WPA key. Can't think of a way a single
> application would reduce the onetime amount of passphrase requests.
Well, theoretically you'd allow gnome-keyring to save all those
passphrases and then you'd have a master passphrase (different from the
rest) that would allow gnome-keyring to dole them out as needed. But
yes, that puts all your eggs in the gnome-keyring basket and relying on
the strength of your master keyring. I always make sure my login
password/phrase is different than that of my master keyring phrase, and
that is different from any of the passphrases in my ring.
It is not particularly elegant as such but I made a package based on
code from this page that Works for Me...
http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases
8:38 a.m.
On 17/07/07, Gawain Lynch <lists-gawain(a)felicity-group.com> wrote:
It is not particularly elegant as such but I made a package based on
code from this page that Works for Me...
http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases
To my very pleasant surprise, the updated seahorse packages that Seth
just pushed to updates-testing actually takes care of the integration
of gnome-keyring and ssh-agent seemlessly. I encourage all interested
parties to try this (it's just a yum install seahorse away).
J.
8:49 a.m.
On Fri, 2007-07-20 at 14:38 +0100, Jonathan Underwood wrote:
On 17/07/07, Gawain Lynch <lists-gawain(a)felicity-group.com>
wrote:
> It is not particularly elegant as such but I made a package based on
> code from this page that Works for Me...
> http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases
To my very pleasant surprise, the updated seahorse packages that Seth
just pushed to updates-testing actually takes care of the integration
of gnome-keyring and ssh-agent seemlessly. I encourage all interested
parties to try this (it's just a yum install seahorse away).
Good! I'm glad they're working for you. Are they ready to go to final
update?
-sv
11:32 a.m.
On 20/07/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
Good! I'm glad they're working for you. Are they ready to go
to final
update?
Well, I've been using it for a day or so without problems. The only
thing I did notice is when clicking on the applet, I see this message
at the bottom of the popup box:
Warning: Your system is not configured to cache passphrases in secure memory.
I suspect this is about keys being stored in memory that can be
swapped out - I am not sure we have the infrastructure in place to do
anything about that yet, though?
J.
11:44 a.m.
Jonathan Underwood (jonathan.underwood(a)gmail.com) said:
Warning: Your system is not configured to cache passphrases in secure
memory.
I suspect this is about keys being stored in memory that can be
swapped out - I am not sure we have the infrastructure in place to do
anything about that yet, though?
Well, it's just using mlock(). Why is it getting that error, though - is
it trying to allocate more than the current default?
Bill
12:15 p.m.
On 20/07/07, Bill Nottingham <notting(a)redhat.com> wrote:
Jonathan Underwood (jonathan.underwood(a)gmail.com) said:
> Warning: Your system is not configured to cache passphrases in secure
> memory.
>
> I suspect this is about keys being stored in memory that can be
> swapped out - I am not sure we have the infrastructure in place to do
> anything about that yet, though?
Well, it's just using mlock(). Why is it getting that error, though - is
it trying to allocate more than the current default?
Am not sure how I would tell? I am seeing that message even though no
PGP keys are cached, only an ssh one is. I am not sure if ssh-agent
keeps keys in mlock'ed memory or not.
12:19 p.m.
On 20/07/07, Jonathan Underwood <jonathan.underwood(a)gmail.com> wrote:
On 20/07/07, Bill Nottingham <notting(a)redhat.com> wrote:
> Jonathan Underwood (jonathan.underwood(a)gmail.com) said:
> > Warning: Your system is not configured to cache passphrases in secure
> > memory.
> >
> > I suspect this is about keys being stored in memory that can be
> > swapped out - I am not sure we have the infrastructure in place to do
> > anything about that yet, though?
>
> Well, it's just using mlock(). Why is it getting that error, though - is
> it trying to allocate more than the current default?
>
Am not sure how I would tell? I am seeing that message even though no
PGP keys are cached, only an ssh one is. I am not sure if ssh-agent
keeps keys in mlock'ed memory or not.
Yes, as I suspected looking at /proc/pid/status of the ssh-agent, I see:
VmLck: 0 kB
and so ssh-agent isn't using mlock'd memory, which is probably what
seahorse is grumbling about.
[As an aside, I wonder if that constitutes a security hole in ssh-agent].
J.
11:48 a.m.
On Fri, 2007-07-20 at 17:32 +0100, Jonathan Underwood wrote:
On 20/07/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
> Good! I'm glad they're working for you. Are they ready to go to final
> update?
Well, I've been using it for a day or so without problems. The only
thing I did notice is when clicking on the applet, I see this message
at the bottom of the popup box:
Warning: Your system is not configured to cache passphrases in secure memory.
I suspect this is about keys being stored in memory that can be
swapped out - I am not sure we have the infrastructure in place to do
anything about that yet, though?
yah - that's the same message gpg occasionally barks about.
-sv
6118
days inactive
6153
days old
31 comments
15 participants
participants (15)
-
Alexander Dalloz -
Bill Nottingham -
Denis Leroy -
Gawain Lynch -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
Jon Nettleton -
Jonathan Underwood -
Kevin Kofler -
Ralf Ertzinger -
Rex Dieter -
seth vidal -
Todd Zullinger -
Tomas Mraz