[MERGE] Authentication Ring spec

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> Aaron Bentley has voted resubmit.
> Status is now: Resubmit
> Comment:
> You seem not to have noticed my mailing-list comments:
> 
> Vincent Ladeuil wrote:
>> +.. [#ignored_realm] The true purpose of realms is to allow the same
> credentials
>> +   to be reused for disjoint hierarchies. Ignoring them in this
> specifications
>> +   aims to simplify the user experience.
> 
> I don't really see a simplification in ignoring realm.  I think it would
> be a much better identifier than "path".

I actually disagree with you here, and agree with Vincent's statement.

There is no realm for "ftp", and for http it isn't obvious what realm would be.
And while I'm sure it is possible to set it up. I think for *users* they know a
URL, which makes path blatantly obvious. As long as "/foo" works for "/foo" and
"/foo/bar" I think it covers 95+% of what we need.


> 
>> +  * while ``locations.conf`` is intended to describe *local* branches,
>> +    ``authentication.conf`` is intended to describe *remote* branches or
>> +    servers.
> 
> locations.conf is intended to describe both local and remote branches.
> In particular, it provides a way to override the branch.conf settings in
> a remote branch that you do not have write access to.

Sure, that should be fixed. I think we can just take it out entirely. I think
the biggest reason is that having a single file with passwords in it, separate
from the rest is a lot better than mixing them.

I can be more verbose about it.


> 
>> +  * What about using ``seahorse`` on Ubuntu or ``KeyChain Access`` on
> Mac OS X ?
>> +
>> +    * ``svn`` use some native APIs to encode its cached credentials,
> that may
>> +      provides examples on how this can be done for bzr, then these
> services
>> +      could be used to encrypt the passwords and define a new
>> +      ``password_encoding``.
> 
> It seems worth investigating the seahorse or KeyChain Access APIs before
> finalizing this spec.  Such analysis would ensure that our spec is
> compatible with them, and reading about their APIs could reveal issues
> that we need to address.

I think it is worthwhile to look into them. This spec seems to mostly cover the
possible file format spec, more than the internal apis. It does discuss how the
api would be used. But that doesn't mean a lot about the specific calls, etc.
Which would effect how seahorse/keychain apis would be connected. It even
mentions looking at them as part of implementing this spec.

Further, this is mostly a guideline about how we would do it, and as such, I
think it is worthy of pulling in as is.


So I'm willing to do:
=== modified file 'doc/developers/authentication-ring.txt'
- --- doc/developers/authentication-ring.txt      2007-07-27 18:52:38 +0000
+++ doc/developers/authentication-ring.txt      2007-07-27 19:11:16 +0000
@@ -153,10 +153,6 @@
   * allow the user to protect the content of one file only, relaxing security
     constraints on the others,

- -  * while ``locations.conf`` is intended to describe *local* branches,
- -    ``authentication.conf`` is intended to describe *remote* branches or
- -    servers.
- -
 ``~/.bazaar/authentication.conf`` will use the same file format than
 ``~/.bazaar/bazaar.conf``.


If you are happy enough with that. I'm not sure how else I would describe it.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqkRpJdeBCYSNAAMRAkwNAKCKvAiCzKgj+0/4pkacm1DyiEjueACfT5KK
/+XiUiBole7YEHbsWqfhaoA=
=NA1F
-----END PGP SIGNATURE-----