[haiku-development] Re: RFC: password roster API
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 28 Jan 2011 19:52:51 +0100
scott mc <scottmc2@xxxxxxxxx> wrote:
> On Mon, Jan 24, 2011 at 2:46 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > wrote:
> > I have drafted an API for a KWallet/GNOME keyring like
> > functionality.
> This would be a very welcome addition. If it covers most or all of
> what is in the GNOME keyring app and seahorse project I think that'd
> cover most of what we'd need, at least in the short term.
Seahorse is a bit beyond of what I will be working on, I think (at
least I'm not entirely sure how it's used anyway).
Stephan Aßmus <superstippi@xxxxxx> wrote:
> I would define global types in the file "enum BPasswordType" with
> values
> "B_PASSWORD_WEB" or "B_PASSWORD_TYPE_WEB". In BControlLook I did it
> like
> you here, but I find my solution with BCursorID better/more
> convenient.
Okay, you convinced me, I'm using this method in my next draft.
"Clemens Zeidler" <clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> what is Password and what is OriginalPassword?
It was supposed to store the original passord in case it had been
converted. But since an application will likely need to test different
methods to convert a password, I've changed that now.
Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
> I think having a user or application definable password type might
> also be good. This speaks to extending Stephan's BPasswordType idea
> into a full (but small) class maybe.
I guess optionally giving the password a name should be sufficient -
there is always the problem of localization with names defined by
applications.
> It seems like to me that the service should be the top-level domain
> and the subService the more specific URL, but either way I think the
> names are reasonable.
I think of renaming them to {primary|secondary}Identifier instead where
you can choose if only the primary or both must be fulfilled when
looking for a password. That would also make it clearer that the less
specific URL would end up in the primaryIdentifier then.
> While the primary purpose should be for passwords, the Mac OS X
> Keychain at least also supports certificates.
I'm not yet sure what would be the objective to put those there, since
the access to certificates is usually not restricted. It is security
related, and could be managed by the same application, but I don't
really think that BKeyStore would be the right place for it.
> I'm not positive it should live in the registrar, mainly because if
> the registrar crashes Haiku is pretty much screwed.
I think the password stuff fits well in there, much more than its
current MIME sniffing duties, at least :-)
Since it shouldn't be that much code, I don't think its stability will
be compromised (much).
> As for secure storage, when researching this I was planning on using
> code from your DriveEncryption utility so I assume you are
> considering
> the same, like AES encryption of the password database?
Not yet sure, but that is definitely an option.
> Here is the Mac OS X Keychain Services API:
Thanks, also to Michael for looking that up!
I'm now working on the second draft after which I will then continue to
implement it.
Bye,
Axel.
Other related posts:
