Rev 3765: Update doc and NEWS. in file:///net/bigmamac/Volumes/home/vila/src/bzr/experimental/pluggable-credential-stores/
Vincent Ladeuil
v.ladeuil+lp at free.fr
Thu Dec 18 15:51:28 GMT 2008
At file:///net/bigmamac/Volumes/home/vila/src/bzr/experimental/pluggable-credential-stores/
------------------------------------------------------------
revno: 3765
revision-id: v.ladeuil+lp at free.fr-20081218155126-kmcxduzmb8dfl5le
parent: v.ladeuil+lp at free.fr-20081218083500-1iz4ff04lgav3mwp
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: pluggable-credential-stores
timestamp: Thu 2008-12-18 16:51:26 +0100
message:
Update doc and NEWS.
* doc/developers/authentication-ring.txt:
Update, including marking the parts not yet implemented.
* NEWS:
Add entries and fix order.
-------------- next part --------------
=== modified file 'NEWS'
--- a/NEWS 2008-12-17 10:21:38 +0000
+++ b/NEWS 2008-12-18 15:51:26 +0000
@@ -20,12 +20,18 @@
NEW FEATURES:
- * ``shelve --list`` can now be used to list shelved changes.
- (Aaron Bentley)
-
* Add support for `bzr tags -r 1..2`, that is we now support showing
tags applicable for a specified revision range. (Marius Kruger)
+ * ``authentication.conf`` now accepts pluggable read-only credential
+ stores. Such a plugin (``netrc_credential_store``) is now included,
+ handles the ``$HOME/.netrc`` file and can server as an example to
+ implement other plugins.
+ (Vincent Ladeuil)
+
+ * ``shelve --list`` can now be used to list shelved changes.
+ (Aaron Bentley)
+
IMPROVEMENTS:
* Add trailing slash to directories in all output of ``bzr ls``, except
@@ -56,6 +62,11 @@
* Give proper error message for diff with non-existent dotted revno.
(Marius Kruger, #301969)
+ * ``$HOME/.netrc`` file is now recognize as a read-only credential store
+ if configured in ``authentication.conf`` with 'password_encoding=netrc'
+ if the appropriate sections.
+ (Vincent Ladeuil, #103029)
+
* Preserve transport decorators while following redirections.
(Vincent Ladeuil, #245964, #270863)
=== modified file 'doc/developers/authentication-ring.txt'
--- a/doc/developers/authentication-ring.txt 2008-05-09 16:40:21 +0000
+++ b/doc/developers/authentication-ring.txt 2008-12-18 15:51:26 +0000
@@ -40,7 +40,7 @@
This specification also proposes a way to describe credentials so that several
remote branches can use the same definition. This is particularily important
-for users handling a lot of passwords who need to update them on a regular
+for users handling a lot of passwords and who need to update them on a regular
basis.
Rationale
@@ -65,7 +65,8 @@
``password``) and, when used with appropriate agents, provide the same kind of
comfort this specification aims to provide for all other schemes. Since ssh
agents provide a safer way to secure the passwords, this specification is
-restricted to providing ``user`` but does not provide ``password``.
+restricted to providing ``user`` but does not provide ``password`` when used
+for ssh.
Authentication definitions
--------------------------
@@ -112,10 +113,10 @@
same scheme), only numerical values are allowed, this should be used only
when the server uses a port different than the scheme standard port,
- * ``path``: can be empty (FTP or SFTP will never user it),
+ * ``path``: can be empty (FTP or SFTP will never use it),
* ``user``: can be empty (``bzr`` will defaults to python's
- ``getpass.get_user()`` and attempt another matching(see below)),
+ ``getpass.get_user()`` for FTP, SFTP and ssh),
* ``password``: can be empty (for security reasons, a user may use the
definitions without storing the passwords but want to be prompted ; or the
@@ -127,7 +128,8 @@
Also note that an optional ``verify_certificates=no`` field will allow the
connection to ``HTTPS`` hosts that provides a self certified certificate (the
-default should be to refuse the connection and inform the user).
+default should be to refuse the connection and inform the user). (Not
+implemented yet)
Multiple definitions can be provided and, for a given URL, bzr will select a
(``user`` [, ``password``]) based on the following rules :
@@ -156,11 +158,14 @@
Encoding passwords in ``base64``, while weak, provides protection against
accidental reading (if an administrator have to look into the file, he will not
-see the passwords in clear).
+see the passwords in clear).(Not implemented yet).
This specification intend to ease the authentication providing, not to secure
it in the best possible way.
+Plugins can provide additional password encodings, the provided
+``netrc_credential_store`` plugin can be used as an example implementation.
+
Future versions of this specification may provide additional
encodings [#password_encoding]_.
@@ -168,8 +173,8 @@
that will rely on external means to store the password which, in these
cases, will not appear anymore in the definition. It is assumed that
additional password encodings will provide a storage outside of the file
- described here. An encoding named ``netrc`` for example will provide
- passwords by retrieving them in the ``.netrc`` file.
+ described here. The ``netrc`` encoding for example provide passwords by
+ retrieving them in the ``.netrc`` file.
File format
-----------
@@ -324,7 +329,7 @@
3. No ``user`` given in the URL (and no ``password``).
Get a user from ``~/.bazaar/authentication.conf`` or prompt for one if none is
- found. Continue as 2.
+ found. Continue as 2. (Not implemented yet)
Note: A user will be queried only if the server requires it for ``HTTP`` or
``HTTPS``, other protocols always require a user.
@@ -356,9 +361,10 @@
a password.
* As this specification proposes a matching between some credentials
- definitions and real urls, the implementation should provide an optional UI
- feedback about which credential definition is used. That will allow the user
- to validate his definitions.
+ definitions and real urls, the implementation provides an optional UI
+ feedback about which credential definition is used. Using ``-Dauth`` will
+ output some traces in the ``.bzr.log`` file metionning the sections
+ used. This allows the user to validate his definitions.
Questions and Answers
---------------------
@@ -372,15 +378,14 @@
* What if a ``.netrc`` file exists ?
- * It will be honored if the definition specifies
- ``password_encoding=netrc`` once the appropriate plugin have been
- written.
+ * It is honored if the definition specifies
+ ``password_encoding=netrc``.
* What mode should the authentication file use ?
* 600 read/write for owner only by default, if another mode (more
permissive) is used, a warning will be issued to inform the users of the
- potential risks.
+ potential risks.(Not implemented yet)
* What about using ``seahorse`` on Ubuntu or ``KeyChain Access`` on Mac OS X ?
@@ -391,8 +396,9 @@
?
* yes and if the user configure a ssh-agent it will not be queried for
- pass-phrase every time we want to query the file for a password. But that
- seems a bit extreme for a first version.
+ pass-phrase every time we want to query the file for a password. But
+ that seems a bit extreme for a first version.(Not implemented yet and
+ may be never)
* Why can't bzr update the authentication file when it queried the user for a
password ?
More information about the bazaar-commits
mailing list