https://bugs.kde.org/show_bug.cgi?id=486474
Odin Vex <odin....@ethicalexploiting.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |LATER
Status|RESOLVED |VERIFIED
--- Comment #12 from Odin Vex <odin....@ethicalexploiting.com> ---
(In reply to Alexander Reinholdt from comment #11)
> I thought about the serialized approach and possible alternatives.
>
> I don't like serialized one, because you squeeze all login credentials into
> one entry and you either have to read it once and store all credentials in
> memory (i.e. in a hash or map) or you have to read everything each time the
> program asks for credentials. In any case you have to implement some search
> logic to pick the right credentials. Similar things are true for
> writing/saving. This is too much overhead for me.
That already happens just because we're using credentials.
> Another way would be to store the username and password for each server or
> share separately, but have a list of all network items in the secure
> storage. After starting to implement this, I did not like it and also
> decided against it.
So it's back to storing everything in a file?
> I implemented to possibility to edit the authentication information long
> time ago. Looking back, I almost never used it except defining the default
> login credentials. If the username or password for a server or share need to
> be changed, you can do this with/in the password dialog withou even opening
> the configuration dialog. The default credentials can still be defined
> there. And when you want to clean up, you can do this with the GUI of the
> password manager.
You might not have used it but others may very well have (myself, for example).
> So, for the time being, I will leave the code as it is now. If QtKeychains
> API allows for accessing the list of all login credentials in the future, I
> will maybe reimplement the functionality.
I'd rather see the credentials clear-text in an rc file than this decision. I
think I'll just privately fork it and address it using serialization.
--
You are receiving this mail because:
You are watching all bug changes.
