← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/authentication-ring.txt

(vila) Open 2.4.3 for bug fixes (Vincent Ladeuil)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/authentication-ring.txt
61
61
This specification describes a way to provide user and passwords to bzr while
62
62
storing them in a relatively safe way.
63
63
 
64
 
Note that ssh servers can be configured to use keys instead of (``user``,
 
64
Note that SSH servers can be configured to use keys instead of (``user``,
65
65
``password``) and, when used with appropriate agents, provide the same kind of
66
 
comfort this specification aims to provide for all other schemes. Since ssh
 
66
comfort this specification aims to provide for all other schemes. Since SSH 
67
67
agents provide a safer way to secure the passwords, this specification is
68
68
restricted to providing ``user`` but does not provide ``password`` when used
69
 
for ssh.
 
69
for SSH.
70
70
 
71
71
Authentication definitions
72
72
--------------------------
77
77
1. user and password
78
78
 
79
79
``FTP`` and ``SFTP`` needs a (``user``, ``password``) to authenticate against a
80
 
``host`` (SFTP can use ssh keys too, but we don't talk about that in this
81
 
specification as ssh agents provide a better solution).
 
80
``host`` (SFTP can use SSH keys too, but we don't talk about that in this
 
81
specification as SSH agents provide a better solution).
82
82
 
83
83
2. user, realm and password
84
84
 
88
88
really needed is (``user``, ``password``, ``host``, ``path``). The ``realm``
89
89
can be ignored [#ignored_realm]_ as long as it is still presented to the user
90
90
when prompting for the password (unless someone found a way to declare two
91
 
different realms for the same path). 
 
91
different realms for the same path).
92
92
 
93
93
``HTTP proxy`` can be handled as ``HTTP`` (or ``HTTPS``) by explicitly
94
94
specifying the appropriate port.
115
115
 
116
116
  * ``path``: can be empty (FTP or SFTP will never use it),
117
117
 
118
 
  * ``user``: can be empty (``bzr`` will defaults to python's
119
 
    ``getpass.get_user()`` for FTP, SFTP and ssh),
 
118
  * ``user``: can be empty (``bzr`` will defaults to Python's
 
119
    ``getpass.get_user()`` for FTP, SFTP and SSH),
120
120
 
121
121
  * ``password``: can be empty (for security reasons, a user may use the
122
122
    definitions without storing the passwords but want to be prompted ; or the
260
260
        host=r.hobby.net
261
261
        user=jim
262
262
        password=obvious1234
263
 
        
 
263
 
264
264
        # Home server
265
265
        [home]
266
266
        scheme=https
269
269
        password='c2VjcmV0LXBhc3M='
270
270
        password_encoding=base64
271
271
        verify_certificates=no # Still searching a free certificate provider
272
 
        
 
272
 
273
273
        [DEFAULT]
274
274
        # Our local user is barbaz, on all remote sites we're known as foobar
275
275
        user=foobar
276
 
        
 
276
 
277
277
  * an HTTP server and a proxy::
278
278
 
279
279
        # development branches on dev server
283
283
        path=/dev
284
284
        user=user1
285
285
        password=pass1
286
 
        
 
286
 
287
287
        # toy branches
288
288
        [localhost]
289
289
        scheme=http
291
291
        path=/
292
292
        user=user2
293
293
        password=pass2
294
 
        
 
294
 
295
295
        # proxy
296
296
        [proxy]
297
297
        scheme=http
303
303
  * source hosting provider declaring sub-domains for each project::
304
304
 
305
305
        [sfnet domain]
306
 
        # we use sftp, but ssh is the scheme used for authentication
 
306
        # we use SFTP, but SSH is the scheme used for authentication
307
307
        scheme=ssh
308
308
        # The leading '.' ensures that 'sf.net' alone doesn't match
309
309
        host=.sf.net
347
347
* No assumptions should be made about the clients of this service
348
348
  (i.e. Transport is the primary target but plugins must be able to use it as
349
349
  well, the definitions used: (``scheme, host, [port,] path``) are general
350
 
  enough to described credentials for ``svn`` servers or LaunchPad xmlrpc
 
350
  enough to described credentials for ``svn`` servers or LaunchPad XML-RPC
351
351
  calls).
352
352
 
353
353
* Policies regarding default users may be taken into account by the
361
361
  a password.
362
362
 
363
363
* As this specification proposes a matching between some credentials
364
 
  definitions and real urls, the implementation provides an optional UI
 
364
  definitions and real URLs, the implementation provides an optional UI
365
365
  feedback about which credential definition is used. Using ``-Dauth`` will
366
366
  output some traces in the ``.bzr.log`` file metionning the sections
367
367
  used. This allows the user to validate his definitions.
392
392
    * plugins can be written and registered to handle the associated
393
393
      ``password_encoding``.
394
394
 
395
 
  * Could it be possible to encode the whole authentication file with a ssh key
 
395
  * Could it be possible to encode the whole authentication file with an SSH key
396
396
    ?
397
397
 
398
398
    * yes and if the user configure a ssh-agent it will not be queried for