[Bug 397466] Re: There is no KWallet PAM integration
Bug Watch Updater
397466 at bugs.launchpad.net
Sun May 20 05:33:28 UTC 2012
Launchpad has imported 123 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=92845.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2004-11-07T13:06:20+00:00 Steffen wrote:
Version: (using KDE KDE 3.3.1)
Installed from: Gentoo Packages
OS: Linux
It should be possible to use PAM with KWallet. This way I think a secure
single-sign-on could be made possible by using the PAM module pam_ssh.
You´d have to setup your /etc/pam.d/system-auth file to use pam_ssh as
an alternative to pam_unix. Then you are able to login to your computer
by entering the passphrase of your private key in ~/.ssh/.
The thing that make single-sign-on possible is that pam_ssh
automatically launches the ssh-agent tool (belongs to OpenSSH) so that
you´ll never have to enter your private key´s passphrase again when it
is needed for example by KWallet.
I do not understand more about this topic than I´ve written down here,
but I think it might satisfy the wish for a passwordless KWallet without
of making it stupidly insecure.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/0
------------------------------------------------------------------------
On 2004-11-08T19:36:32+00:00 Yves Glodt wrote:
*** This bug has been confirmed by popular vote. ***
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/1
------------------------------------------------------------------------
On 2005-01-02T20:26:34+00:00 Praseodym+kdebugzilla wrote:
Something similiar could also be done by storing the user's password in
the wallet, and then have KDM silently login to the wallet (user clicks
his user, and instead of account password types the wallet password) to
get the linux password and log in with that.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/2
------------------------------------------------------------------------
On 2005-01-18T17:10:47+00:00 Jonny Heggheim wrote:
Would be nice to integrate KDM and KWallet!
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/3
------------------------------------------------------------------------
On 2005-02-11T15:19:52+00:00 Gilles Schintgen wrote:
Just in case this gets implemented (and I really hope so...), I'd like to point out that it should be implemented in such a way as to be compatible with pam_mount. Currently I'm using an encrypted home partition that is mounted automatically at login by pam_mount (using the login password). Using information from the user's home could be problematic when it's not yet mounted. So, please consider this point.
It would just be too cool to have single-sign-on for the system login, pam_mount and kwallet. Thanks for listening :-)
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/4
------------------------------------------------------------------------
On 2005-02-11T18:14:34+00:00 L-savernik wrote:
I'd like to have single-sign-on also working with the default login
password. Please also keep in mind that not all people use kdm as their
login manager (or no login manager at all! Runlevel 3, need I say more?
;-) ), so it should not depend on kdm or any graphical login procedure.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/5
------------------------------------------------------------------------
On 2005-02-25T12:51:47+00:00 Brazilian Joe wrote:
what would have to happen then? will kwallet become a frontend/gui for
the 'wallet' cli app, being useable without qt , kde or anything, and
wallet would be a base system / libs for ppl to store their many
passwords, possibly with bindings for other languages to use it,
hopefully with Mozilla, Gnome, Freedesktop.org and possibly other ppl
cooperation, so that we can have a solution which is not kde specific,
but which encompasses the whole desktop? Maybe it should be talked with
other parties which may be interested in the subject. Maybe I am overly
optimistic, but I think this would be the best thing possible to happen:
a unified wallet system with single sign-on useable by any desktop
environment, so that I can use any desktop without having to retype the
passwords in mozilla, konqueror, or foo.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/6
------------------------------------------------------------------------
On 2005-08-28T20:16:26+00:00 flickerfly wrote:
I'm investigating this for the community over at LinuxBiometrics.com. We
have talked a bit about how to most effectively integrate biometrics and
so I'm investigating. We already have work building a PAM bridge and so
Kwallet's attachment to PAM would significantly ease the efforts that
would need to be made.
Just wanted to share that we see this as being a beneficial direction
for our needs also. :-)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/7
------------------------------------------------------------------------
On 2005-09-11T16:34:27+00:00 R2s2-3 wrote:
*** Bug 102465 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/8
------------------------------------------------------------------------
On 2005-09-11T17:25:00+00:00 R2s2-3 wrote:
Wouldn't be a kwallet pam module possible? It would start kwallet as
soon as one logs in. This way it works also for other types of logins
(NX, console, xdm,..) and doens't relay on ssh.
Of course an auto login to kwallet isn't much safer than a kwallet
without password, but it adds an extra little bit of security (e.g.
secure as long as you don't log in) at no cost for the user. So I think
it should be possible.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/9
------------------------------------------------------------------------
On 2005-09-17T20:40:37+00:00 Gilles Schintgen wrote:
If I understand the following page correctly something similar already exists for Gnome:
http://www.flyn.org/projects/pam_keyring/index.html
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/10
------------------------------------------------------------------------
On 2005-09-18T02:19:57+00:00 Bernie Innocenti wrote:
In reply to comment #10 (Gilles Schintgen):
> If I understand the following page correctly something similar already exists for Gnome:
> http://www.flyn.org/projects/pam_keyring/index.html
This looks exactly what we need for KWallet.
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/11
------------------------------------------------------------------------
On 2005-09-18T10:12:56+00:00 L-savernik wrote:
> http://www.flyn.org/projects/pam_keyring/index.html
And it's abandoned, so we can take it over any time :-)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/12
------------------------------------------------------------------------
On 2005-09-18T11:02:41+00:00 R2s2-3 wrote:
Gnome hat it and Mac OS x has it too:
http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/02concepts/chapter_2_section_1.html
So we need it, also! ;-)
The first step we need, is a seperation of the daemon and the gui. Like
gnome does it (gnome keychain daemon/manager). Otherwise the pam module
can't start the daemon because of the gui dependance. Should this be an
own feature request?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/13
------------------------------------------------------------------------
On 2005-09-18T14:39:38+00:00 Staikos wrote:
On Sunday 18 September 2005 05:02, Roland Schulz wrote:
> Gnome hat it and Mac OS x has it too:
> http://developer.apple.com/documentation/Security/Conceptual/keychainServCo
>ncepts/02concepts/chapter_2_section_1.html
>
> So we need it, also! ;-)
>
> The first step we need, is a seperation of the daemon and the gui. Like
> gnome does it (gnome keychain daemon/manager). Otherwise the pam module
> can't start the daemon because of the gui dependance. Should this be an own
> feature request?
Right now the whole thing is very dependent on Qt and actually DCOP. Once
KDE4 development really starts (ie: technology changes in kdelibs begin),
this can be considered.
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/14
------------------------------------------------------------------------
On 2005-09-18T17:48:15+00:00 Brazilian Joe wrote:
Personally, I think teh Best Way Possible® it to get in touch with
Freedesktop.org and Gnome people too, and draft a standard way to do it,
place under teh Freedesktop.org umbrella. You know, avoiding the NIHS
(Not-Invented Here Syndrome), and doing something which can benefit all,
instead of something KDE-centric. AFAIK tehre are already 'standards',
at least in draft form, for things like DE-agnostic themes, clipboard,
and so on. This could be one more thing.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/15
------------------------------------------------------------------------
On 2005-09-19T00:30:09+00:00 Staikos wrote:
On Sunday 18 September 2005 11:48, Tiago Freire wrote:
> ------- Personally, I think teh Best Way Possible® it to get in touch with
> Freedesktop.org and Gnome people too, and draft a standard way to do it,
> place under teh Freedesktop.org umbrella. You know, avoiding the NIHS
> (Not-Invented Here Syndrome), and doing something which can benefit all,
> instead of something KDE-centric.
If there was interest on that side, why didn't they come to us and say they
wanted to co-operate too? KWallet is quite old and I've never seen or heard
of something similar on Linux or Gnome.
That being said, the file format is open and there is a chance to extract
the daemon outside of KDE startup now that dbus is a likely candidate for
KDE4. I don't have any interest in redesigning and reimplementing all of
KWallet though. It works, and there are many other things that need to be
done in KDE4.
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/16
------------------------------------------------------------------------
On 2005-09-19T16:16:02+00:00 L-savernik wrote:
Am Montag, 19. September 2005 00:30 schrieb George Staikos:
> If there was interest on that side, why didn't they come to us and say
> they wanted to co-operate too? KWallet is quite old and I've never seen or
> heard of something similar on Linux or Gnome.
Right you are. It's about time that Gnome incorporates some precedent set by
KDE.
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/17
------------------------------------------------------------------------
On 2005-09-19T21:44:28+00:00 Staikos wrote:
On Monday 19 September 2005 10:16, Leo Savernik wrote:
> Am Montag, 19. September 2005 00:30 schrieb George Staikos:
> > If there was interest on that side, why didn't they come to us and say
> > they wanted to co-operate too? KWallet is quite old and I've never seen
> > or heard of something similar on Linux or Gnome.
>
> Right you are. It's about time that Gnome incorporates some precedent set
> by KDE.
That's not true either. They have and do (see freedesktop). I just don't
buy this argument that KWallet was done at the preclusion of Gnome. It
preceded any other similar project that I could find at the time.
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/18
------------------------------------------------------------------------
On 2005-09-21T13:30:31+00:00 Brazilian Joe wrote:
There are several standards, in draft form or otherwise, being developed or promoted for adoption on freedesktop.org. The 'Single' bit of 'Single Sign-On' only holds completely true if it works on every application. If you only use KDE apps, fine, but I find thinking like this a bit selfish (and I am not implying it is your thinking, just stating my belief). Ithink it is really worth pushing forward the 'Single' part of this idea, and have filed a project-request-bug at freedesktop.org.
https://bugs.freedesktop.org/show_bug.cgi?id=4513
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/19
------------------------------------------------------------------------
On 2005-10-28T04:01:11+00:00 Mustavuohi wrote:
Uh. It would be awesome to use pam_usb (http://www.pamusb.com) with
KWallet, too.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/20
------------------------------------------------------------------------
On 2005-11-15T05:14:44+00:00 Staikos wrote:
*** Bug 114662 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/21
------------------------------------------------------------------------
On 2006-01-31T23:32:40+00:00 mp wrote:
Absolutely fantastic idea. I vote with 20 points!
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/22
------------------------------------------------------------------------
On 2006-04-13T07:32:28+00:00 Somekool-f wrote:
it is really required to have this done using PAM ? I'm don't know. But
the basic idea of having the kwallet automatically open upon login is
strongly wished and I really wish to see this feature in the next
release of KDE.
thanks
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/23
------------------------------------------------------------------------
On 2006-04-13T15:16:45+00:00 Andrei Slavoiu wrote:
Actualy I think it would be possible using Kwallet integration in KDM.
So that the account password is stored inside the wallet, and at logon
time you just enter the password for the wallet. What do you think?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/24
------------------------------------------------------------------------
On 2006-04-13T15:22:28+00:00 Sundance wrote:
Hi Andrei,
This would be excellent, yes! Do you think it is possible technically?
Thanks!
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/25
------------------------------------------------------------------------
On 2006-04-13T15:30:43+00:00 Gilles Schintgen wrote:
> Actualy I think it would be possible using Kwallet integration in
> KDM. So that the account password is stored inside the wallet, and at logon
> time you just enter the password for the wallet. What do you think?
No, the account password should always be the one stored in /etc/shadow.
Everything else would be incoherent. In my opinion, having the login password
depend on how you login (login, ssh, kdm) would be a terrible idea.
The password entered into kdm can already be reused by other PAM modules, such
as pam_mount. kwallet could "simply" integrate with PAM and obtain the
password in the same way.
The kwallet password would then be your login password. If the login password
is changed, decrypting of the wallet will fail and kwallet would inform the
user about it and ask for the old password in order to reencrypt the wallet
with the new password.
What do you think about this idea?
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/26
------------------------------------------------------------------------
On 2006-04-13T16:03:50+00:00 Sundance wrote:
With my apologies, Gilles, I think I disagree with your judgment on
authentication sources: the whole point of pluggable authentication
modules (P.A.M. :)) is precisely to let you authenticate yourself from
different possible sources. I am not sure what invalidates KWallet as
one such source, but I might be overlooking something, of course.
However, would it be possible to simply encrypt the KWallet password
using the user's login password? This way, when the user logs in, he
uses his regular login password; that password is also used to unlock
his KWallet password, and KWallet is then loaded as usual.
Would PAM allow for such a behavior? This way, it would respect Gilles'
misgivings about the previously suggested behavior, while still allowing
for KWallet to be opened automatically at login time, and still allowing
for different login and KWallet passwords.
What do you think?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/27
------------------------------------------------------------------------
On 2006-04-13T16:22:04+00:00 Gilles Schintgen wrote:
> With my apologies, Gilles [...]
I'm sorry if my response sounded a bit harsh, it really wasn't intended that
way.
> However, would it be possible to simply encrypt the KWallet password using
> the user's login password? This way, when the user logs in, he uses his
> regular login password; that password is also used to unlock his KWallet
> password, and KWallet is then loaded as usual.
There's a second reason I don't like this behaviour: I'm using an encrypted
home partition which is automatically decrypted by pam_mount using my login
password. Since the KWallet data is stored inside this partition I don't see
how this scheme could be implemented without breaking this kind of setup.
This same problem also arises for people using pam_mount to mount a remote
home directory. Unfortunately kdm can't rely on (or at least it shouldn't)
the availability of the KWallet data before the user is authenticated by PAM.
Except, of course, if the KWallet were to be stored outside the user's home
directory which, I think, would be a bad idea.
Kind regards,
Gilles
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/28
------------------------------------------------------------------------
On 2006-04-14T03:22:57+00:00 mp wrote:
> This way, when the user logs in, he uses
> his regular login password; that password is also used to unlock his
> KWallet password, and KWallet is then loaded as usual.
I'm not sure about this. This creates a what looks like a bad scenario
where kwallet-stored passwords are available upon request once a user is
logged in. Well, what if I'm a bad guy and somehow get access to your
desktop? I think my first stop is kwallet. It's open right?
Personally, it doesn't bother me that kwallet asks for a password upon
opening after I'm into my desktop.
Below the gui level, PAM and kwallet must remain separate. The kwallet
gui needs to make it appear something like a single wallet though.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/29
------------------------------------------------------------------------
On 2006-04-14T04:59:09+00:00 Kde-org wrote:
> Well, what if I'm a bad guy and somehow get access to your desktop?
Then I should have locked my desktop.
My second act, as a bad guy, is to change your desktop background to a
picture of Tom Welling with his shirt off. Very few people around my
office forget to lock their desktop anymore.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/30
------------------------------------------------------------------------
On 2006-04-14T10:07:25+00:00 Sundance wrote:
Gilles,
Please note that in my last proposal, to my knowledge, KWallet could be
opened only after everything else has been unlocked, i.e. after the
login process has begun and the home partition has been mounted, in the
same way that your home partition is only mounted after your
authentication credentials have been validated. So your setup would not
be prevented from working. If I'm not wrong in this and what I'm
suggesting is indeed possible, would the proposal satisfy you?
Michael,
Would this be different from the usual way KWallet works? Once your
KWallet is opened, some Bad Guy sneaking his way to your desk can access
its passwords as well. The only difference would be that at login time
-- when you're known to be at your desk -- the KWallet would be loaded
as usual, simply without asking for its own password. But you raise a
good point, and the unlocking of KWallet at login time should be an
option. Perhaps it is worth pointing out that, as things currently
stand, many users choose to use no password at all for their KWallet --
incidentally storing all its passwords in clear text -- so as to avoid
the annoyance of unlocking it manually at login time. Our proposal ideas
here would be a significant step up from that behavior in terms of
security.
With kind regards,
-- S.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/31
------------------------------------------------------------------------
On 2006-04-14T12:35:13+00:00 Gilles Schintgen wrote:
> Please note that in my last proposal, to my knowledge, KWallet could be
> opened only after everything else has been unlocked, i.e. after the login
> process has begun and the home partition has been mounted
Now I see that I've misread your last proposal:
> However, would it be possible to simply encrypt the KWallet password using
> the user's login password? This way, when the user logs in, he uses his
> regular login password; that password is also used to unlock his KWallet
> password, and KWallet is then loaded as usual.
I thought it was the same proposal as before, except that now the two
passwords are the same. In other words I interpreted "he uses his regular
login password" as "he types the same password as always but it's first used
to open the wallet in order to retrieve the account password".
> would the proposal satisfy you?
Yes, it would be fine (for me). The only difference to my proposal is that
KWallet doesn't get the password through PAM, but directly from kdm. My
proposal would also work with console logins (but I'm not sure this would be
desirable) and with xdm and gdm.
Since I'm mostly using kdm, I'm not going to insist on this. (And I don't know
how difficult it would be to properly implement the PAM integration.)
In the long term I'd prefer a desktop-independent approach, as already pointed
out in comment #19.
Regards,
Gilles
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/32
------------------------------------------------------------------------
On 2006-04-14T17:05:21+00:00 Somekool-f wrote:
I am not convinced of the PAM thing in this case. I beleive comment #27
is saying about same thing as me and I totally agree with sundance. lets
not change to much and just use the password from kdm to open the
wallet.
actually, if I understand the PAM idea, It's totally different and would
serve a totally different purpose. I think people are fighting for a
different egg.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/33
------------------------------------------------------------------------
On 2006-04-16T08:42:00+00:00 Andrei Slavoiu wrote:
> No, the account password should always be the one stored in /etc/shadow.
> Everything else would be incoherent. In my opinion, having the login password
> depend on how you login (login, ssh, kdm) would be a terrible idea.
Well, of course the password from /etc/shadow (or NIS, whatever is used by the system) will be used to actualy authenticate the user, I was just suggesting that instead of typing the password in KDM it could be taken from the wallet.
> The password entered into kdm can already be reused by other PAM modules,
> such as pam_mount. kwallet could "simply" integrate with PAM and obtain the
> password in the same way.
Not everybody uses PAM, it is possible to configure a system to autenticate directly from /etc/shadow.
> The kwallet password would then be your login password. If the login password
> is changed, decrypting of the wallet will fail and kwallet would inform the
> user about it and ask for the old password in order to reencrypt the wallet
> with the new password.
Probably not everybody likes to have the same password for the account and wallet (the account password could get compromised easier then the wallet since it might also be used remotely).
> There's a second reason I don't like this behaviour: I'm using an encrypted
> home partition which is automatically decrypted by pam_mount using my login
> password. Since the KWallet data is stored inside this partition I don't see
> how this scheme could be implemented without breaking this kind of setup.
With this you are right, I didn't consider this kind of setup. But I suppose you could just encrypt a subdirectory with your personal stuff, not the entire home.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/34
------------------------------------------------------------------------
On 2006-04-16T10:22:32+00:00 Chris Kerr wrote:
> There's a second reason I don't like this behaviour: I'm using an encrypted
> home partition which is automatically decrypted by pam_mount using my login
> password. Since the KWallet data is stored inside this partition I don't see
> how this scheme could be implemented without breaking this kind of setup.
Perhaps there could be a backup/failsafe option to keep the old way of doing things for setups like this.
In any case - if you have an encrypted /home, surely you don't actually need to encrypt the kwallet file (although admittedly you would need to if /home was network mounted and needed your account password)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/35
------------------------------------------------------------------------
On 2006-06-14T19:13:42+00:00 Anarky wrote:
why not have a crypted loop device containing a file with passwords stored in it (no need to change current KWallet config file layout)?
This way, you could either mount this device at login, with pam_mount or mount it every time KWallet is used (depending on user settings).
This should of course be done transparently to the user.
The KWallet password would then be the same as the user password, but is this a problem ? If it is, the filesystem could be crypted with a different password, disabling the auto mount option.
The only drawback I see to this approach is on systems different from linux ...
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/36
------------------------------------------------------------------------
On 2006-11-01T13:54:55+00:00 Petrus69 wrote:
addition to #10, #11, #12:
PAM_KEYRING for GNOME is not dead any more:
http://www.hekanetworks.com/index.php/publisher/articleview/frmArticleID/25/staticId/31/
Personally, I'd like to see a modular, pluggable (multiplatform)
solution using pam.
Currently I'm using pam_ssh, keychain etc. for firing up gpg and ssh
agents for my entire KDE session, which saves me a lot of "enter
passphrase here"/"enter passphrase there" and works like a charm, I'm
using fish:// URLs very often.
That is, as long as I don't change my password/passphrases too often...
It would be cool to have a wallet/keyring opened by some pam_module, and
see (at least all FOSS )browsers, IMs, VoIPs etc use it seamlessly.
If that framework could perform password/passphrase change transactions,
I'd feel like in heaven.
Reply at: https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/37
------------------------------------------------------------------------
On 2006-11-09T13:36:53+00:00 Angel-azrael wrote:
There are ssh-agent and gpg-agent.
So bring up a third agent for wallets(kde), keyrings(gnome) and
passwords(firefox).
This third agent should use kwallet as gui and have a libpam_wallet for
single-sign-on.
Perhaps this agent could also start the other two (ssh and gpg) and
provide them the passphrases.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/38
------------------------------------------------------------------------
On 2007-04-01T09:14:21+00:00 Oswald Buddenhagen wrote:
*** Bug 143687 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/39
------------------------------------------------------------------------
On 2007-04-10T16:30:22+00:00 Ammulder wrote:
I'm currently using a laptop with openSUSE, KDE, and a fingerprint
reader (via PAM). The behavior I have now is that from KDM, I swipe my
finger to login. Then, KWallet immediately prompts me for a password,
because KNetworkManager stores my wireless keys in KWallet and 99% of
time I login (home, work) there's a secure wireless network there to
connect to. So in total, I have to swipe my finger and then enter a
password, which is bothersome.
In this situation, I am required to open KWallet as soon as I login (on
account of KNetworkManager), so it would not bother me if the wallet was
automatically opened upon login. If a bad guy steals my laptop while
I'm logged in, my wallet will almost surely be open as is.
I guess I'm looking for the outcome to be one of these:
* I swipe my finger once to log in, the wallet is automatically opened, and I don't have to take any additional action.
* I swipe my finger once to log in, and then again to open the wallet, but at least no password entry is required. This may mean that KWallet uses the fingerprint reader via PAM to unlock the wallet, or it may mean that KNetworkManager stops using KWallet for storage and instead uses some other mechanism that in turn uses the fingerprint reader via PAM to access the wireless keys.
I will note that I would be far less concerned about this if
KNetworkManager did not use KWallet, but since I'm so reliant on secure
wireless networks, I'm therefore reliant on KWallet.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/40
------------------------------------------------------------------------
On 2007-04-10T17:41:39+00:00 Beatryder wrote:
RE: Comment #40
I have a similar issue on my machine; having to swipe my finger to get
into KDE and then having to enter my password after.
While I see the benefits of not having PAM integration in KWallet, I can
also see the benefit to making it an *option* to use pam for
authentication; at least then by default it can be configured to use
what it uses noe.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/41
------------------------------------------------------------------------
On 2007-04-10T18:32:39+00:00 R2s2-3 wrote:
Do those finger print sensors send some kind of password computed from
the finger profile or just a yes/no? In the later case there is no way
you could safe unlock the wallet with it, because without a password you
can't unencrypt.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/42
------------------------------------------------------------------------
On 2007-04-10T18:57:06+00:00 Ammulder wrote:
I don't know enough about the BioAPI and related stuff to say for sure,
but I don't believe the fingerprint reader stores a password. I think
it's just a yes/no (based on the fact that I don't remember needing to
type a password for it to remember when I first saved the fingerprint
profile). Perhaps Josiah Ritchie (Comment #7) could say more.
However, the user account in question still *has* a password. I'm not
sure whether there's some way to retrieve it if you've successfully
authenticated some other way. Or maybe the fingerprint reader returns
some data on the finger geometry or something that could be used as a
"password" to unencrypt. Or, maybe the fingerprint reader can be
coerced to save some data along with the fingerprint profile and return
that to use as a decrypt key. Hopefully someone who knows more about
the biometric plumbing will speak up. :)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/43
------------------------------------------------------------------------
On 2007-04-10T19:09:26+00:00 Beatryder wrote:
The fingerprint scanners do not in fact store a password. Instead it
store some information about the users fingerprint.
The primary problem here seems to be the encryption of the passwords. I
wonder if a system similar to how the LUKS cryptfs works. Essentially
you can have multiple keys for an encrypted partition, which in turn
decrypt the real key.
Perhaps to get the pam side of it working the user would have to run a
configuration program and effectively "train" KWallet to use the
information provided by PAM.
I am not an expert in any way with PAM, but I do know that it is very
flexible.
Regardless of how one would get the fingerprint scanner to work, if
KWallet worked with PAM, then the biometrics would work as well as they
are just a PAM module.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/44
------------------------------------------------------------------------
On 2007-04-10T19:36:17+00:00 R2s2-3 wrote:
> Regardless of how one would get the fingerprint scanner to work, if KWallet
> worked with PAM, then the biometrics would work as well as they are just a PAM
> module.
Not quite. If the biometrics pam module doesn't provide a password,
Kwallet won't be able to encrypt.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/45
------------------------------------------------------------------------
On 2007-04-16T12:53:36+00:00 Yojoe wrote:
I have a T60p ThinkPad with integrated fingerprint reader using
libthinkfinger for authentication. For simplicity, I would like to use
my fingerprints to open KWallet too, but I don't think this will ever be
possible:
If you want to encrypt someting, you need some kind of secret to feed the encryption algorithm. If you just swipe your finger, the only secret you can supply is your fingerprint. Fingerprints may be OK for authentication but not for encryption. In Germany for instance, every citizen has to deposit all their 10 fingerprints to get a new ID-Card by the end of this year, so fingerprints can't be considered a secret any longer. Even if the bioapi/libthinkfinger libraries would return some kind of password, it would be insecure because this password generator has to be deterministic. So everybody who knows your fingerprints could generate the password, too.
The only way I see, to provide some kind of secret using fingerprints, is a series of fingerprint scans with the different fingers of your hand. The order of the fingers you use is the secret. But I don't think this could be seriously considered secure, because brute-force attacks would success within a second, unless you require the user to provide a series of 200 fingerscans or so ;)
And I think it's even faster to type in your KWallet password than swiping your fingers 10 times or even just 4 times.
So from my point of view, there are just two options:
- Disable encryption in KWallet, so no password/fingerprint/whatever is required by the user (not even for authentication, because he is already authenticated), and hope that nobody can access your KWallet files.
- Live with the fact, that KWallet requires a password to encrypt your stuff.
- (Wait for the first open-source/open-design brain-computer interfaces ;))
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/46
------------------------------------------------------------------------
On 2007-08-05T18:56:50+00:00 Mgraesslin wrote:
I really like the idea of using PAM. At the moment I use pamusb and I still have to type in my password to open kwallet (which happens at every startup because of kopete connecting to the net). Sometimes it gets really annoying. It would be great to have some kind of single-sign-on-system which also integrates Mozilla or other open source software.
Just an idea: why not using a public/private key infrastructure. The private key is stored somewhere in the users .kde directory with read only to the owner. If the user authenticates via PAM kwallet is allowed to use the private key. The user can still close the wallet requiring to authenticate again (no matter how), if he wants to open the wallet.
Of course this does not really protect the wallet. But perhaps it would
be possible that the user defines a passphrase, so he can choose if he
wants to have comfort or security. Nevertheless the content would be
encrypted in both cases.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/47
------------------------------------------------------------------------
On 2007-11-12T20:27:08+00:00 KAi wrote:
There is a discussion about fingerprint integration in KDM right here: http://bugs.kde.org/show_bug.cgi?id=116682 which has some similar points.
As mentioned there, now here to joerg / comment #46 : Everybody should decide for her/himself how secure her/his system should be - we probably can show a warning like "fingerprint login is insecure" :-). And it's "only" your two forefingers for the new passport and the same two fingers whichh they discuss for the ID - so you can use anotherone or a toe ;-).
So PAM would be perfect for KWallet - for me with pam_thinkfinger .
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/48
------------------------------------------------------------------------
On 2007-11-13T00:33:25+00:00 Somekool-f wrote:
if PAM is not the perfect backend for KWallet, why KWallet could not use
multiple backends, the same way as Phonon uses multiple backends?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/49
------------------------------------------------------------------------
On 2008-11-16T12:11:52+00:00 J1n-tobias-xqt wrote:
I think the option proposed in comment #47 is just fine:
* let PAM and the Core-OS do what they are designed for: Authenticate the user & authorize file access (here access to the secret key which is read-only for the authenticated user)
[to me this behaviour would be similar to that of using SSH-Keys for passwordless SSH-authentication]
* kwallet can use this secret key to encrypt/decrypt it's data
You could leave the option up to the user (in kwallets config) whether
to use a secret key in the homedir or an "old-style" password.
>From my point of view (which is the view of a user, not the one of a
KDE/KWallet developer) the changes to kwallet would be small. No pam
integration is needed, because when kwallet starts the user is already
authenticated. The only thing that needs to be done is reading the
secret key file (after assuring correct permissions (400)), and using
the secret stored in this file instead of the password provided by the
user
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/50
------------------------------------------------------------------------
On 2008-11-16T12:36:28+00:00 Michael Leupold wrote:
It's not quite similar. In my opinion it's not useful to store an
encrypted file and the key to decrypt it so close to each other. It
seems like the security you gain by doing this is pretty close to not
encrypting the file at all.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/51
------------------------------------------------------------------------
On 2009-02-16T19:41:34+00:00 Michael Leupold wrote:
*** Bug 184537 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/52
------------------------------------------------------------------------
On 2009-04-07T11:49:11+00:00 Markus-0fjh wrote:
I have an additional idea, which I've posted in the KDE Brainstorming forum.
>Now when a program ask KWallet about credentials KWallet looks into it's >(proposed by me) database for this application. If the application is present, >KWallet checks if it's entitled to get the crential it's asking for, or else >KWallet asking me (graphicly) what I want to do: Give it access once, or >forever, not now, or not forever. If the application is not in the database >KWallet asks me if I would like to add it. (and then the other questions). >(Alternativly, only the application how put the credentials in KWallet can >fetch them from there)
>In this way I don't have to write passwords all the time. KWallet still asks >for permission, I'm in control. Bringing up the KWallet app-database lets me >modify my previous decisions to allow or disallow apps.
>This assumes two things which I really don't know anything about:
> * KWallet have to have the means of making sure that an application really is >what it seems to be... it's really a developer thing, but since every antivirus >program in windows manage it (and the firewall to) I can't be that hard.
> * A program run as a user can't fiddle with another programs memory or windows >or such. IF this would be possible the asking (rouge) app could take control >over KWallet's dialog asking me for permession....
Is it out of scope?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/53
------------------------------------------------------------------------
On 2009-04-10T11:36:52+00:00 Michael Leupold wrote:
@Markus: This is actually already in. I mean not the pam stuff but the
"ask if the application may access the wallet" thing.
There's a caveat though:
* kwalletd doesn't determine the application's identity but trusts the application on providing the name
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/54
------------------------------------------------------------------------
On 2009-06-26T10:28:38+00:00 Michael Leupold wrote:
*** Bug 197788 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/55
------------------------------------------------------------------------
On 2009-10-16T01:01:31+00:00 Christoph-maxiom wrote:
*** Bug 210726 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/61
------------------------------------------------------------------------
On 2010-01-02T18:38:45+00:00 Achim-herwig wrote:
There is a PAM module and a client program available at
http://download.opensuse.org/repositories/home:/hgraeber:/KDE4/
However, it tries to call DBUS method "tryOpen" that does not exists in
any kwalletd that I examined (current KDE 4.3 packages for openSUSE 11.2
and KDE trunk), so it is not usable directly. It could be made to work
with the "pamOpen" dbus method added by Michael
(http://websvn.kde.org/?view=revision&revision=1054213), though.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/64
------------------------------------------------------------------------
On 2010-01-08T23:26:21+00:00 8-herbert wrote:
(In reply to comment #57)
> There is a PAM module and a client program available at
> http://download.opensuse.org/repositories/home:/hgraeber:/KDE4/
This is only a version I tried to test an unfinished port of the KDE3
version of pam_kwallet.
> However, it tries to call DBUS method "tryOpen" that does not exists in any
> kwalletd that I examined (current KDE 4.3 packages for openSUSE 11.2 and KDE
> trunk)
tryOpen is an extension of kwalletd's dcop interface made by SUSE for
KDE3. I had packages for kdebase4 with a similar extension the
kwalletd's DBUS interface.
> so it is not usable directly. It could be made to work with the
> "pamOpen" dbus method added by Michael
> (http://websvn.kde.org/?view=revision&revision=1054213), though.
Now with this extension of kwalletd's DBUS interface pamOpen should be
used. For this the program kwalletclient has to be changed to compute
the has of the password before opening the wallet using pamOpen. The pam
module pam_kwallet isn't needed because a pam module named pam_exec.so
exists, which can do it's job.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/65
------------------------------------------------------------------------
On 2010-03-18T20:23:32+00:00 Mathias-homann wrote:
I would SO like to have a working pam/kwallet integration back.
maybe the one thing from kde3 that I'm missing most in kde4 right now.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/66
------------------------------------------------------------------------
On 2010-03-18T21:42:10+00:00 Michael Leupold wrote:
As there seems to be a lot of interest in getting this working, a little update from my side:
I'm currently working on this, but unfortunately it didn't turn out as easy as I hoped it would be. Currently the main problem is that PAM needs to launch the D-Bus session bus as well as kwalletd for automatically opening the wallet which turned out to be harder than expected.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/67
------------------------------------------------------------------------
On 2010-03-18T23:49:10+00:00 Lameventanas wrote:
(In reply to comment #59)
> I would SO like to have a working pam/kwallet integration back.
> maybe the one thing from kde3 that I'm missing most in kde4 right now.
Mathias, what are you talking about? This never existed in kde3.
This wish has been open for 6 years, with thousands of votes, yet nothing has been done about it. What we got instead in these 6 years is a "semantic desktop".
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/68
------------------------------------------------------------------------
On 2010-03-19T17:19:16+00:00 Malkavian666-r wrote:
(In reply to comment #60)
> I'm currently working on this, but unfortunately it didn't turn out as easy as
> I hoped it would be.
Thank you very much for your effort Michael. Hope you could get it done.
Thanks
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/69
------------------------------------------------------------------------
On 2010-05-31T18:21:43+00:00 Wojciech Ryrych wrote:
(In reply to comment #60)
Hi Michael!
It's almost 6 months since you wrote you were working on this so would be so kind to tell us how are you getting on? Will it be finished on next KDE release?
cheers,
Wojtek
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/70
------------------------------------------------------------------------
On 2010-06-24T16:14:16+00:00 Patrick Nagel wrote:
Great idea! Any news?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/71
------------------------------------------------------------------------
On 2010-06-24T18:09:18+00:00 Michael Leupold wrote:
Unfortunately it won't ship with the next version of KDE. The main
problem is that accessing KWallet at the same time you can access the
password is quite hard. It requires a PAM module that can access the
user's D-Bus session bus which is usually started after login only.
Now, the good thing is I worked around this by implementing a PAM module to launch the bus as well as the module that gets the password and sends it to KWallet and it's already working (well, at least for me). Unfortunately D-Bus developers seem to disagree that what I did was such a good idea. So until things have cleared a bit I won't do a real release of the modules. If you're able to you can however get the modules from here:
- http://code.confuego.org/index.php/p/pamdbuslaunch
- http://websvn.kde.org/trunk/playground/base/pam_kwallet
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/72
------------------------------------------------------------------------
On 2010-06-24T19:17:10+00:00 Malkavian666-r wrote:
Thank you very much for your work Michael! :) Hope to get a the solution
integrated soon.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/73
------------------------------------------------------------------------
On 2010-07-08T09:04:36+00:00 Kde4146 wrote:
I think, not having kwallet opened with user login is a decrease in
security in some cases. pam is running in a non-user-context while any
login attempt in an already running user session runs in user context.
As a result any password sniffing app must run in root context for the
former one while for the second one user context is enough. (In case of
attacking the "open kwallet"-process. Attacking kwallet directly is on
par.)
Secondly. Having to type in a password twice in the login process is
godawful, at least bothersome. Many people will prefer to use an empty
password for kwallet because of this. This results in a _major_ loss in
security.
Even if there is some pam integration for kwallet, every one who wants
can still use different passwords for os login and kwallet. So at least
pam integration won't touch any security concerns for "the real safety-
conscious people" out there. ;-)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/74
------------------------------------------------------------------------
On 2010-07-25T02:24:14+00:00 Yu-valery+bugzilla wrote:
I wonder if it could be possible to make kwallet use ssh private key.
There are already pam_ssh and ssh-agent in the most distributions. And
this approach has no problems with D-Bus, because pam_ssh unlocks
private key and ssh_agent keeps it until kwallet may want to access it.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/75
------------------------------------------------------------------------
On 2010-07-25T11:56:54+00:00 Malte wrote:
Vayu <yu.valery+bugzilla at gmail.com> wrote
> https://bugs.kde.org/show_bug.cgi?id=92845
> --- Comment #68 from Vayu <yu valery+bugzilla gmail com> 2010-07-25
> 02:24:14 --- I wonder if it could be possible to make kwallet use ssh
> private key. There are already pam_ssh and ssh-agent in the most
> distributions.
An approach that sounds nice. But, does kwallet not still need to be made
aware of PAM? I mean, if there is no PAM support at all in kwallet, nothing
will work, no ssh_pam, not libpampoldi with openPGP card? Vice versa, once
kwallet supports PAM, any PAM module would work with kwallet, right?
Regards
Malte
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/76
------------------------------------------------------------------------
On 2010-08-06T11:39:02+00:00 Ralf wrote:
I'm not a developer, but one or two questions come to my mind when
reading this bugreport:
The Gnome-devs seem to fixed this problem a long time ago. You can use
the so called Gnome Keyring, and it will be opened directly when you
login to the computer. So it seems they are using som kind of pam-module
to open the keyring during login. So at last it is possible at all.
Wouldn't it be a good idea to talk to the Gnome devs and ask them how
they did it, instead of reinventing the wheel again? Maybe it is
possible to share some of the code, so it gets a little bit easier.
Or maybe it would be posssible to create a complete new wallet-like
thing together with the Gnome-devs, so there would be only one wallet
used in Gnome and KDE, just with different GUI for both desktop - one
GTK+ and one QT (maybe a plasmoid?). And then create a pam-module
together then can be used by either GDM and KDM to open the wallet, no
matter which desktop is used.
Don't forget I'm not a developer. So it's a little bit hard to say for
my if this is possible at all. At least it seems like a good idea. Maybe
a disscussion at the next Akademy would be good, since it will take
place together with GUADEC, so the perfect "get together" of KDE and
Gnome developers.
Regards,
Ralf
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/77
------------------------------------------------------------------------
On 2010-10-14T10:04:21+00:00 Greeneg wrote:
As someone that uses Kerberos and LDAP a lot, having PAM integration
with KWallet would be a huge win, especially if we could get a plasma
widget that did kinit and tgt renewal requests. :)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/78
------------------------------------------------------------------------
On 2011-01-22T20:50:36+00:00 Robert Simmons wrote:
This feature would be great.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/79
------------------------------------------------------------------------
On 2011-03-03T11:05:31+00:00 Günter Haus wrote:
It would be great to see any forthcoming on this. The current kwallet
situation is absolutely terrible. Any of the above mentioned solutions
would be a BIG improvement.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/80
------------------------------------------------------------------------
On 2011-03-03T11:10:21+00:00 Asraniel wrote:
indeed. Currently i'm forced to set a empty password for kwallet when
i'm installing linux for somebody, simply because of usability reasons.
A more secure solution would really be appreciated.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/81
------------------------------------------------------------------------
On 2011-03-03T11:50:03+00:00 Lameventanas wrote:
This request has been here for 7 years already, it has thousands of
votes, and yet it hasn't even been acknowledged by any developer, its
status is still "NEW" after 7 YEARS!
Every new KDE release comes with more bugs, 4.6.0 in particular was
terrible and I simply lost my motivation to report bugs and wishes that
go ignored for years, this is just a waste of time.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/82
------------------------------------------------------------------------
On 2011-03-03T13:33:50+00:00 Jlayt wrote:
alancio, I don't know how you can say it's been ignored, Michael Leupold
has been working on this as documented above and it's really quite rude
to say otherwise. If Michael says it is harder than it looks, then it
must be hard. Remember, we are all volunteers here giving up our free
time to work on KDE and we just can't do everything.
Something else to consider is that KDE and Gnome are currently working
on a common standard for storing passwords called Secret Service which
will be draining resources as well, and may well offer a common solution
for the problem.
Personally I find KDE 4.6 to be the least buggy KDE ever (yes, even
including KDE3, I think nostalgia makes people forget the bugs we had
there).
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/83
------------------------------------------------------------------------
On 2011-05-22T21:29:43+00:00 Robert Simmons wrote:
I have been hearing about a unified wallet between gnome and KDE, is
this problem not being addressed because of a shift to a unified wallet?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/84
------------------------------------------------------------------------
On 2011-07-19T12:00:18+00:00 Günter Haus wrote:
It is really frustrating that such a badly needed feature hasn't even
been started within 7 years, while dozens of completely useless features
find their way to new KDE releases.
Come on KDE team I'm shure you can do better and please at least update
the status of this bug!
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/85
------------------------------------------------------------------------
On 2011-07-20T13:52:38+00:00 Todd R wrote:
What is "badly needed" and what is "completely useless" is a matter of
personal opinion.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/86
------------------------------------------------------------------------
On 2011-07-20T14:16:06+00:00 Mlohse wrote:
Please stop asking questions like "Do you really need it? Absolutely
sure???" This is only going to frustrate users.
I'm offering 25,- Euro to the guy/team who just gets it working, plus I
can do some coding on the Qt/KDE (kwallet) part. Unfortunately, I don't
know anything about PAM authentication and don't have the time to work
myself in.
Looks like there is just nobody out there having enough knowledge about
PAM, KDM and Kwallet at the same time. So I think this just needs some
coordination and teamwork.
Of course as an alternative we can collect some money to write it out as
a project for a freelancer.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/87
------------------------------------------------------------------------
On 2011-07-20T15:12:22+00:00 Oswald Buddenhagen wrote:
make that 2500€ and somebody *might* bite. just to give you an idea of
what effort we are talking about.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/88
------------------------------------------------------------------------
On 2011-07-20T15:26:19+00:00 Mlohse wrote:
Well, 99 people (offering 25,-Euro) to go... and perhaps some student
picks it up earlier :)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/89
------------------------------------------------------------------------
On 2011-07-20T15:45:05+00:00 Malkavian666-r wrote:
I would pay 10€ more. ¿a good web to collect these award wills and try
to make it real?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/90
------------------------------------------------------------------------
On 2011-07-20T15:47:24+00:00 jiveaxe wrote:
If you're serious I donate 10 euros too!!
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/91
------------------------------------------------------------------------
On 2011-07-20T15:54:54+00:00 Mathias-homann wrote:
will there be a written guarantee from the "KDE Management" or whatever
else the organization that decides what goes in KDE $current+1 calls
itself, to the effect that this feature doesn't get removed in the next
version just after someone came up with the 2500€?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/92
------------------------------------------------------------------------
On 2011-07-20T16:09:46+00:00 Achim Bohnet wrote:
on planetkde a) lightDM was mentioned as a crossdesktop alternative to kdm.
and b) there was (freedesktop?) work goin on to unify
gnomes (that open wallet on login) and kde wallet system.
I hole heartly agree that it's very welcome to open the wallet at login time,
but one should check if kwallet+kdm or lightDM+freedesktop-wallet or something else is the way implement the feature.
Achim
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/93
------------------------------------------------------------------------
On 2011-07-20T20:10:13+00:00 R-clark-01 wrote:
I'll give 10 Euros via Paypal if it gets fixed. The time saving would be
enormous.
Ralph
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/94
------------------------------------------------------------------------
On 2011-07-20T20:14:34+00:00 Asraniel wrote:
i'll chip in too
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/95
------------------------------------------------------------------------
On 2011-07-20T20:55:25+00:00 Msn-gaiatools wrote:
I will give 15 canadian dollars as well. It's been 7 years since this
has been requested, enough is enough.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/96
------------------------------------------------------------------------
On 2011-07-21T06:45:04+00:00 Stefan Feilmeier wrote:
For a serious solution, expect my 25 € as well!
It's one of the bugs I hate the most in KDE.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/97
------------------------------------------------------------------------
On 2011-07-21T08:09:04+00:00 Greeneg wrote:
Please stop using Bugzilla as a pledging-for-work location for this
wish-list item.
Unless the developer WANTS to code this up, understand this is THEIR
prerogative, and criticising the devs by saying they "aren't doing
anything" is both rude and unbecoming of a KDE community member.
Remember, finding an itch and coding it is what F/OSS is all about, and
KDE is driven as a meritocracy. In other words, if you want this, either
hire someone to do it (and not through Bugzilla) or code it up yourself.
With that said, we get to the next gripe I have about all the posts on
this item of late: this is neither the forum, or the mechanism for doing
pledges-for-code. This tool is for triaging bugs and wish-lists for
software. Please do me and all the others that are involved with this
bug a favour and take it to another forum. Thanks.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/98
------------------------------------------------------------------------
On 2011-07-21T08:19:25+00:00 Mathias-homann wrote:
then maybe oswal should not have asked for people to pay to have this feature?
see comment #81.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/99
------------------------------------------------------------------------
On 2011-09-26T17:53:56+00:00 Abtb wrote:
how tenacious can one be
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/100
------------------------------------------------------------------------
On 2011-11-14T12:25:34+00:00 Mathias-homann wrote:
oh for effs sake. kdelibs4 *has* a pam_open dbus call into kwallet, but
no pam module to call it???? wtf?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/101
------------------------------------------------------------------------
On 2011-11-14T13:49:15+00:00 Mathias-homann wrote:
can someone please close this as "worksforme".
there's a "pam_kwallet" in kde/playground/base and a pam_dbus_launch at
http://code.confuego.org/index.php/p/pamdbuslaunch/
With those two modules, single sign on *works*.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/102
------------------------------------------------------------------------
On 2011-11-14T14:05:38+00:00 Todd R wrote:
Until it is out of playground I wouldn't say it can be considered
finished. pam_kwallet doesn't appear to have had any commits in almost
a year and a half.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/103
------------------------------------------------------------------------
On 2011-11-14T14:15:08+00:00 Mathias-homann wrote:
...so?
i've build the stuff just now and tried it, and it works fine.
and the dbus call that it uses has been in kwalletd since 4.4.2, so of course the accompanying pam module is *old*.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/105
------------------------------------------------------------------------
On 2011-11-14T14:17:41+00:00 Michael Leupold wrote:
This is known to work but due to various reasons it has never been
released. Number one of the reasons is that the D-Bus developers don't like the
way of starting the bus using a pam module and think it's plain wrong.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/106
------------------------------------------------------------------------
On 2011-11-14T14:21:46+00:00 Todd R wrote:
If the developers don't think it should be used widely, which is what it
means to be in playground, I think we should listen.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/107
------------------------------------------------------------------------
On 2011-11-14T14:28:05+00:00 Kde-bugger wrote:
Michael, is pam_kwallet your project, too? I didn't even know it
existed and like to have a look at it but it looks like both gitweb.k.o
and anongit.k.o are down and the project isn't on projects.k.o. Any
chance to have this added to projects.k.o?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/108
------------------------------------------------------------------------
On 2011-11-14T14:32:51+00:00 Mathias-homann wrote:
Maybe the dbus developers should think about providing a way to start
the dbus service that is not "plain wrong"?
all I can say is, in this day & age a single-sign-on method for kwallet
is a must have.
The one with the pam modules works.
good enuff for me.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/109
------------------------------------------------------------------------
On 2011-11-14T14:35:26+00:00 Michael Leupold wrote:
@Malte: yeah, I developed both modules to fix this bug quite a while
ago. I haven't worked on it since its last commit. Not sure if it's
actually worth it - when the time is ready it should probably be adapted
to work with the new secret service.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/110
------------------------------------------------------------------------
On 2011-11-14T15:04:01+00:00 Kde-bugger wrote:
Support for Secret Service is pending for two or so years now. That's
not meant as a criticism of your work, I'd just like to have something
which just works now and until the real thing arrives. I have an idea
on how to circumvent the dependency on pam-launch-dbus and might hack
pam-kwallet to make it work in a spare minute.
Ah, gitweb is back. I can see some work happening in ksecretservice.git
but can't find a pam[-_]kwallet.git (anongit is still down).
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/111
------------------------------------------------------------------------
On 2011-11-14T15:14:30+00:00 Mathias-homann wrote:
what is this "ksecretservice" you guys are talking about?
and like Malte already said... pam_kwallet works *now*, not *at some
point in the distant future*.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/112
------------------------------------------------------------------------
On 2011-11-14T15:35:09+00:00 Kde-bugger wrote:
Secret Service is a joint specification by KDE's KWallet and Gnome's
Keychain to have a unified API for unlocking the secrets on logon and
accessing them later on. You can look it up here:
http://standards.freedesktop.org/secret-service/
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/113
------------------------------------------------------------------------
On 2011-11-14T15:42:10+00:00 Mathias-homann wrote:
looks quite intriguing..
...but...
are there actual working implementations yet?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/114
------------------------------------------------------------------------
On 2011-11-14T15:47:07+00:00 Todd R wrote:
Yes, ksecretservice is being released as we speak. They are just trying
to decide where to put it in the git tree.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/115
------------------------------------------------------------------------
On 2011-11-14T15:49:24+00:00 Mathias-homann wrote:
so what do i do with it as of now?
replace kwallet with it?
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/116
------------------------------------------------------------------------
On 2011-11-14T15:53:20+00:00 Todd R wrote:
Nothing, there will be more information once it is decided how it is
going to be handled. At best it will not be available until 4.8, at
worst not until frameworks.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/117
------------------------------------------------------------------------
On 2011-11-14T15:59:43+00:00 Mathias-homann wrote:
that's what I expected.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/118
------------------------------------------------------------------------
On 2011-11-14T17:29:05+00:00 Mathias-homann wrote:
grmbl. seems that pam_kwallet does not want to work in a NIS setup :(
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/119
------------------------------------------------------------------------
On 2011-11-28T03:29:02+00:00 Leon Maurer wrote:
Is there an easy way for regular users such as myself can get this thing
in playground working? The continuing lack of single sign on is absurd.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/120
------------------------------------------------------------------------
On 2012-01-13T21:33:40+00:00 8p-kde wrote:
Having found this ticket (and the lack of action on it!) I wrote myself
a small script for the kde/Autostart folder that simply talks to kwallet
and calls kerberos kinit (with appropriate kdialog prompting if needed).
Seems to work ok for me as a workaround.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/121
------------------------------------------------------------------------
On 2012-01-14T01:10:56+00:00 Mlohse wrote:
Finally, there's light at the end of the tunnel :)
I've just found this in the kde-4.8 RC2 release notes:
"KSecretService optionally enables a shared password storage, therefore making your saved passwords available to many other applicatios, leading to a more secure system and better integration of non-KDE apps into the Plasma Workspaces and KDE apps into non-Plasma workspaces." (see here: http://www.kde.org/announcements/announce-4.8-rc2.php )
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/122
------------------------------------------------------------------------
On 2012-01-14T07:26:46+00:00 8p-kde wrote:
kSecretService was mentioned already in this thread and information is available here
http://techbase.kde.org/Projects/Utils/ksecretsservice
http://standards.freedesktop.org/secret-service/
http://dot.kde.org/2011/12/22/kde-makes-first-48-release-candidate-available-adds-secret-service
However as its still early on in development I did not want to wait
hence writing something that just works now so I have ssh/kerberos
keys/passwords all working from kwallet on login.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/123
------------------------------------------------------------------------
On 2012-01-14T18:20:31+00:00 MrJH wrote:
Hi nick,
Can you please provide your workaround script here ?
I still won't wait until the ksecretservice is ready for use.
Thanks
(In reply to comment #113)
> Having found this ticket (and the lack of action on it!) I wrote myself a small
> script for the kde/Autostart folder that simply talks to kwallet and calls
> kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok
> for me as a workaround.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/124
------------------------------------------------------------------------
On 2012-01-15T15:44:19+00:00 8p-kde wrote:
Hi,
Sure. I will finish up another of my use-cases (I want it to automatically get a kerberos key after a VPN has been activated) and then write it all up.
(In reply to comment #116)
> Hi nick,
>
> Can you please provide your workaround script here ?
> I still won't wait until the ksecretservice is ready for use.
> Thanks
>
>
> (In reply to comment #113)
> > Having found this ticket (and the lack of action on it!) I wrote myself a small
> > script for the kde/Autostart folder that simply talks to kwallet and calls
> > kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok
> > for me as a workaround.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/125
------------------------------------------------------------------------
On 2012-01-15T20:26:21+00:00 8p-kde wrote:
My scripts are here: https://github.com/rnc/kde-scripts
Hope they help - works for me ;-)
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/126
------------------------------------------------------------------------
On 2012-01-15T21:26:54+00:00 Luiz Angelo Daros de Luca wrote:
Hello Nick,
I took a look at your scripts. They use a password stored in kwallet to
initialize kerberos tgt (kinit). Isn't it?
This bug is about the "oposite": open kwallet using the login/pam
password. Maybe others got confused as I did. The idea is that pam could
provide the passoword in order to open kwallet (or ksecretservices)
without asking the user again for a password, just after it has already
provided one for its login process.
BTW, if you want to always use kerberos, why not just use pam_krb5.so?
You will authenticate using the kerberos password and will get the TGT
"for free". If you use kerberos from AD, pam_winbind.so also provides
the TGT (just like kinit) and allow other nice features like offline
authentication.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/127
------------------------------------------------------------------------
On 2012-01-16T08:36:43+00:00 8p-kde wrote:
(In reply to comment #119)
> I took a look at your scripts. They use a password stored in kwallet to
> initialize kerberos tgt (kinit). Isn't it?
Yes true.
> This bug is about the "oposite": open kwallet using the login/pam password.
> Maybe others got confused as I did. The idea is that pam could provide the
> passoword in order to open kwallet (or ksecretservices) without asking the user
> again for a password, just after it has already provided one for its login
> process.
>
> BTW, if you want to always use kerberos, why not just use pam_krb5.so? You will
> authenticate using the kerberos password and will get the TGT "for free". If
> you use kerberos from AD, pam_winbind.so also provides the TGT (just like
> kinit) and allow other nice features like offline authentication.
Ah ok sorry :-) Well not wasted as its useful for me ;-) Thanks for the
hint; might look at it.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/128
------------------------------------------------------------------------
On 2012-03-09T08:11:16+00:00 Mathias-homann wrote:
what happened to KSecretService?
I'm running KDE 4.8.1 on openSUSE 12.1 and there are no packages
available.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/129
------------------------------------------------------------------------
On 2012-03-09T08:18:28+00:00 Mathias-homann wrote:
besides, I don't think that changing from the old system to
ksecretservice would even cover the topic of this request at all...
this request is about how people do not want to enter their password twice in a row.
once to log in on their computer, the second time when kopete or chokoq
gets autostarted.
Reply at:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/comments/130
** Bug watch added: freedesktop.org Bugzilla #4513
https://bugs.freedesktop.org/show_bug.cgi?id=4513
** Bug watch added: KDE Bug Tracking System #116682
https://bugs.kde.org/show_bug.cgi?id=116682
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kde4libs in Ubuntu.
https://bugs.launchpad.net/bugs/397466
Title:
There is no KWallet PAM integration
To manage notifications about this bug go to:
https://bugs.launchpad.net/hundredpapercuts/+bug/397466/+subscriptions
More information about the kubuntu-bugs
mailing list