Projects/Utils/kwallet/FeaturePlan42 - Revision history

Claus chr: Box template should not be used anymore

2012-08-27T19:31:50Z

Box template should not be used anymore

AnneW at 12:20, 15 July 2012

2012-07-15T12:20:37Z

Sg313d: /* Access Granularity Management */

2011-01-14T13:28:41Z

‎Access Granularity Management

Sg313d: /* General ideas */

2011-01-14T13:28:15Z

‎General ideas

Hualiang.miao: internationalization

2009-05-25T16:11:03Z

internationalization

Lemma at 07:18, 17 June 2008

2008-06-17T07:18:31Z

Lemma: /* Make sure passwords are saved */

2008-06-14T15:07:11Z

‎Make sure passwords are saved

Lemma: Projects/Utils/Projects/Utils/kwallet/FeaturePlan42 moved to Projects/Utils/kwallet/FeaturePlan42

2008-05-29T08:50:12Z

Projects/Utils/Projects/Utils/kwallet/FeaturePlan42 moved to Projects/Utils/kwallet/FeaturePlan42

Lemma: /* Overhaul the interface */

2008-05-29T07:47:09Z

‎Overhaul the interface

Lemma: /* Overhaul the interface */

2008-05-29T06:51:42Z

‎Overhaul the interface

@@ Line 8: / Line 8: @@
 Gnome keyring provide a [http://live.gnome.org/GnomeKeyring/Pam hack] (is it?) for this:
-{{Box|How it works|
+{{Info|2=How it works|
 Upon authenticating the user, or logging into the session, the PAM module checks for the GNOME_KEYRING_SOCKET environment variable. If not present it assumes that gnome-keyring-daemon is not running for that session.
 *If the auto_start argument is present in in the PAM config, it then starts it as a daemon.

← Older revision		Revision as of 12:20, 15 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Projects/Utils/kwallet/FeaturePlan42}}~~	+

	== General ideas ==		== General ideas ==

@@ Line 66: / Line 66: @@
 Possible solutions:
- * Ownership model (application can only read values it has created). Here the problem of how to identify applications arises.
+* Ownership model (application can only read values it has created). Here the problem of how to identify applications arises.
- * If application wants to access data it has not created, the user is presented with the precise keys the application wants to read and can make an informed decision.
+* If application wants to access data it has not created, the user is presented with the precise keys the application wants to read and can make an informed decision.
- * Possibly rights management for keys is required. (For example, to allow the user to configure that subversion and subclipse both can read/write the SVN password).
+* Possibly rights management for keys is required. (For example, to allow the user to configure that subversion and subclipse both can read/write the SVN password).

← Older revision		Revision as of 13:28, 14 January 2011
Line 60:		Line 60:
	* No need to reinvent the wheel, learn from what others have done, eg:		* No need to reinvent the wheel, learn from what others have done, eg:
	** [http://en.wikipedia.org/wiki/Image:Keychainaccess.png Apple Keychain]		** [http://en.wikipedia.org/wiki/Image:Keychainaccess.png Apple Keychain]
		+
		+
		+	=== Access Granularity Management ===
		+	KWallet provides all or nothing access to the password store. This is a security problem, because it enables application A in principle to access keys of application b.
		+
		+	Possible solutions:
		+	* Ownership model (application can only read values it has created). Here the problem of how to identify applications arises.
		+	* If application wants to access data it has not created, the user is presented with the precise keys the application wants to read and can make an informed decision.
		+	* Possibly rights management for keys is required. (For example, to allow the user to configure that subversion and subclipse both can read/write the SVN password).

← Older revision		Revision as of 16:11, 25 May 2009
Line 1:		Line 1:
		+	{{Template:I18n/Language Navigation Bar\|Projects/Utils/kwallet/FeaturePlan42}}
		+
	== General ideas ==		== General ideas ==

← Older revision		Revision as of 07:18, 17 June 2008
Line 37:		Line 37:

	This is already fixed and will be in 4.1. Benchmarking showed that syncing the wallet on every change (with a very small timer) is feasible.		This is already fixed and will be in 4.1. Benchmarking showed that syncing the wallet on every change (with a very small timer) is feasible.
		+
		+	=== Use QCA ===
		+
		+	Currently kwallet uses its own implementations of MD5, SHA-1 and Blowfish to encrypt the wallet. While SHA-1 is probably still safe enough it might not be in the future. Therefore switching to an external library to handle encryption will not only simplify the code but also provide more choices for hashing/encryption algorithms.
		+
		+	=== Save more information ===
		+
		+	This hasn't been talked about yet, but I'd like to additionally store the date of creation and the date of modification for a wallet entry. No API changes are needed for that as all the work could be done by the backend transparently. One thing that would require an API change is commenting on the entries. This could be used to make obscure entries (like the ones by kmail) more transparent to the user.

	=== Overhaul the interface ===		=== Overhaul the interface ===

@@ Line 32: / Line 32: @@
 === Make sure passwords are saved ===
-This relates to Bug {{Bug|105752}}. We should come up with a way to store passwords before a session crashes. Of course shouldn't disturb the user (which is why I ([[User:Lemma|Lemma]]) don't like the timed solution proposed by a comment in this report). Complete rewrites of the kwl file should happen at points in time when the user is used to waiting (ie. opening the wallet after a crash, saving the session).
+<s>This relates to Bug {{Bug|105752}}. We should come up with a way to store passwords before a session crashes. Of course shouldn't disturb the user (which is why I ([[User:Lemma|Lemma]]) don't like the timed solution proposed by a comment in this report). Complete rewrites of the kwl file should happen at points in time when the user is used to waiting (ie. opening the wallet after a crash, saving the session).
-General idea: On adding new passwords, append the encrypted password entries to the kwl file without rewriting it completely. If the session crashes the passwords are still here. The kwl file could be cleaned up upon reopening the wallet. As far as I know this might work. We'll see.
+General idea: On adding new passwords, append the encrypted password entries to the kwl file without rewriting it completely. If the session crashes the passwords are still here. The kwl file could be cleaned up upon reopening the wallet. As far as I know this might work. We'll see.</s>
 === Overhaul the interface ===

@@ Line 45: / Line 45: @@
 * Using model/view classes
 * Improving usability (have a look at various bugreports concerning that)
 * Maybe choose a one-window solution instead of the current two-window solution
 * No need to reinvent the wheel, learn from what others have done, eg:
 ** [http://en.wikipedia.org/wiki/Image:Keychainaccess.png Apple Keychain]