Proper HISTORY file

HISTORY.txt

@@ -0,0 +1,198 b''
+0.7.0
+~~~~~~~~~~~~~~~~~~~
+
+Delaying keyring module import until passwords are really needed. It
+can noticeably improve Mercurial (non pull/push) performance in some
+cases (no longer slow hg status because D-Bus is busy an keyring tries
+to activate KDE Wallet through it…).
+
+0.6.7
+~~~~~~~~~~~~~~~~~
+
+#46 Fixed syntax of smtp.tls configuration setting (current Mercurials
+doesn't handle "true" anymore, TortoiseHG crashed with mercurial
+keyring enabled while currently recommended starttls/smtps/none values
+were in use).
+
+0.6.6
+~~~~~~~~~~~~~~~~~ 
+
+#44 Handling some more mercurial versions in demandimport-detection
+logic.
+
+0.6.5
+~~~~~~~~~~~~~~~~~
+
+#36 Shutting up warning about no logging handlers.
+
+0.6.4
+~~~~~~~~~~~~~~~~~
+
+#44 Pre-2.9.1 Mercurials compatibility (probing for active
+demandimport differently).
+
+0.6.3
+~~~~~~~~~~~~~~~~~
+
+#41 Fix for incorrect demandimport activity check logic, which could
+cause various problems with imports after mercurial_keyring is
+imported.
+
+0.6.2
+~~~~~~~~~~~~~~~~~
+
+#33 Fix for UnicodeDecodeErrors happening on some backends (especially
+Vault) when passwords with non-ascii characters are in use and native
+locale is not utf-8. Passwords are no longer saved to keyring backends
+as-entered, they are now decoded from local encoding (whichever is
+detected by Mercurial), then encoded to unicode.
+
+0.6.1
+~~~~~~~~~~~~~~~~~
+
+#30 Yet another demandimport conflict fixed.
+
+0.6.0
+~~~~~~~~~~~~~~~~~
+
+#28 Disable demandimport completely during keyring import. Mayhaps it
+will resolve (most) demandimport conflict errors.
+
+0.5.7
+~~~~~~~~~~~~~~~~~
+
+#27 Some more demandimport ignores.
+
+0.5.6
+~~~~~~~~~~~~~~~~~
+
+#24, #25 Demandimport fixes (import failures in specific cases).
+
+Better way of demandimport-ignoring modules. In particular, we append
+more of them if gobject happens to be on the list.
+
+0.5.5
+~~~~~~~~~~~~~~~~~
+
+Fix for gnome keyring import problems.
+
+0.5.4
+~~~~~~~~~~~~~~~~~
+
+#22 Some more demandimport ignores (fix import failures).
+
+SMTP password was not cleared properly (after detecting that it is
+invalid).
+
+Clarified license to be modified BSD style license.
+
+0.5.3
+~~~~~~~~~~~~~~~~~
+
+Remove useless import which caused problems on Mercurial 2.3 when
+demandimport was not enabled
+
+0.5.1
+~~~~~~~~~~~~~~~~~
+
+Add help text to output for hg help.
+
+0.5.0
+~~~~~~~~~~~~~~~~~
+
+Improved bad password detection. Internally: extension is now able to
+properly differentiate between an authentication failure and a new
+request to the same url.
+
+Fixes in debug message
+
+Further debug messages patching
+
+Improving debug messages handling.
+
+Mercurial Keyring debug messages are now prefixed with
+[HgKeyring] to make distinguishing them easier
+
+0.4.6
+~~~~~~~~~~~~~~~~~
+
+More compatibility (changed signature of httpconnection.readauthforuri
+, introduced post Mercurial 1.9 - since hg.0593e8f81c71)
+
+Fix compatibility code which did not work due to demandimport issues
+(attempts to catch ImportErrors on "from mercurial.url import
+readauthforuri" were not working properly).
+
+0.4.5
+~~~~~~~~~~~~~~~~~
+
+Mercurial 1.9 compatibility (readauthforuri has been moved into new
+httpconnection module).
+
+0.4.4
+~~~~~~~~~~~~~~~~~
+
+Mercurial 1.8 compatibility (passwordmgr.readauthtoken() has been
+moved into mercurial.url.readauthforuri).
+
+0.4.3
+~~~~~~~~~~~~~~~~~
+
+Keyring fork no longer is needed as keyring releases are available
+again.
+
+Workaround for gnomekeyring mercurial.demandimport incompatibility:
+mercurial.demandimport, which is enabled while in a mercurial
+extensions, prevents the correct import of gobject._gobject and
+consequently doesn't allow the loading of the gnomekeyring module,
+which can be used by keyring. This just adds the proper module to
+demandimport ignore list.
+
+0.4.2
+~~~~~~~~~~~~~~~~~
+
+No longer raising an error when username is specified both in ~/.hgrc
+and <repo>/.hg/hgrc if it is the same in both places.
+
+Docs recommend sborho keyring fork.
+
+0.4.1
+~~~~~~~~~~~~~~~~~
+
+Some tweaks and docs related to prefix handling.
+
+Explicit information that keyring is not used due to lack of username.
+
+0.4.0
+~~~~~~~~~~~~~~~~~
+
+Store and lookup prefix from [auth] so that password is shared amongst
+shared auth entries
+
+0.3.3
+~~~~~~~~~~~~~~~~~
+
+Better error message
+
+0.3.2
+~~~~~~~~~~~~~~~~~
+
+Doc tweaks
+
+0.3.1
+~~~~~~~~~~~~~~~~~
+
+Introduced and documented PyPi package, added setup.py
+
+0.2.0
+~~~~~~~~~~~~~~~~~
+
+Added handling of SMTP passwords (tested on patchbomb extension but
+should work on anything what utilizes mercurial.mail)
+
+Docstrings mention Debian keyring packages.
+
+0.1.1
+~~~~~~~~~~~~~~~~~
+
+Initial public release

README.txt

@@ -1,199 +1,206 b''
 .. -*- mode: rst -*-
 
 =================
 mercurial_keyring
 =================
 
 ``mercurial_keyring`` is a Mercurial_ extension used to securely save
 HTTP and SMTP authentication passwords in password databases (Gnome
 Keyring, KDE KWallet, OSXKeyChain, specific solutions for Win32 and
 command line). This extension uses and wraps services of the keyring_
 library.
 
 .. _keyring: http://pypi.python.org/pypi/keyring
 .. _Mercurial: http://mercurial.selenic.com
 
 How does it work
 ================
 
 The extension prompts for the password on the first pull/push (in case
 of HTTP) or first email (in case of SMTP), just like it is done by
 default, but saves the password. On successive runs it checks for the
 username in ``.hg/hgrc``, then for suitable password in the password
 database, and uses those credentials (if found).
 
 In case password turns out to be incorrect (either because it was
 invalid, or because it was changed on the server) or missing it just
 prompts the user again.
 
 Passwords are identified by the combination of username and remote
 address, so they can be reused between repositories if they access the
 same remote repository (or the same SMTP server).
 
 Installation
 ============
 
 Prerequisites
 -------------
 
 Install the keyring_ library:
 
 ::
 
     easy_install keyring
 
 (or ``pip keyring``). On Debian "Sid" the library can be also
 installed from the official archive (packages ``python-keyring``
 and either ``python-keyring-gnome`` or ``python-keyring-kwallet``).
 
 Note: keyring >= 0.3 is strongly recommended, especially in case text
 backend is to be used.
 
 .. _this keyring fork: https://bitbucket.org/sborho/python-keyring-lib
 
 Extension installation
 ----------------------
 
 There are two possible ways of installing the extension: using PyPi package,
 or using individual file.
 
 To install as a package use ``easy_install``:
 
 ::
 
     easy_install mercurial_keyring
 
 and then enable it in ``~/.hgrc`` (or ``/etc/mercurial/hgrc``) using:
 
 ::
 
     [extensions]
     mercurial_keyring = 
 
 To install using individual file, download the
 `mercurial_keyring.py`_ file, save it anywhere you like, and
 put the following in ``~/.hgrc`` (or ``/etc/mercurial/hgrc``):
 
 ::
 
     [extensions]
     hgext.mercurial_keyring = /path/to/mercurial_keyring.py
 
 .. _the code: 
 .. _mercurial_keyring.py: http://bitbucket.org/Mekk/mercurial_keyring/src/tip/mercurial_keyring.py
 
 Password backend configuration
 ==============================
 
 The library should usually pick the most appropriate password backend
 without configuration. Still, if necessary, it can be configured using
 ``~/keyringrc.cfg`` file (``keyringrc.cfg`` in the home directory of
 the current user). Refer to keyring_ docs for more details.
 
 *I considered handling similar options in hgrc, but decided that
 single user may use more than one keyring-based script. Still, I am
 open to suggestions.*
 
 Repository configuration (HTTP)
 ===============================
 
 Edit repository-local ``.hg/hgrc`` and save there the remote
 repository path and the username, but do not save the password. For
 example:
 
 ::
 
     [paths]
     myremote = https://my.server.com/hgrepo/someproject
 
     [auth]
     myremote.schemes = http https
     myremote.prefix = my.server.com/hgrepo
     myremote.username = mekk
 
 Simpler form with url-embedded name can also be used:
 
 ::
 
     [paths]
     bitbucket = https://[e-mail]/User/project_name/
 
 If prefix is specified, it is used to identify the password (so all
 repositories with the same prefix and the same username will share the
 same password).  Otherwise full repository URL is used for this
 purpose.
 
 Note: if both username and password are given in ``.hg/hgrc``,
 extension will use them without using the password database. If
 username is not given, extension will prompt for credentials every
 time, also without saving the password.
 
 Finally, if you are consistent about remote repository nicknames,
 you can configure the username in your `~/.hgrc` (`.hgrc` in your
 home directory). For example, write there::
 
     [auth]
     acme.prefix = hg.acme.com/repositories
     acme.username = johnny
     acme.schemes = http https
 
 and as long as you will be using alias `acme` for repositories like
 `https://hg.acme.com/repositories/my_beautiful_app`, username
 `johnnny` will be used, and the same password reused.
 
 The advantage of this method is that it works also for `clone`.
 
 Repository configuration (SMTP)
 ===============================
 
 Edit either repository-local ``.hg/hgrc``, or ``~/.hgrc`` and set
 there all standard email and smtp properties, including SMTP
 username, but without SMTP password. For example:
 
 ::
 
     [email]
     method = smtp
     from = Joe Doe <[e-mail]>
 
     [smtp]
     host = smtp.gmail.com
     port = 587
     username = [e-mail]
     tls = true
 
 Just as in case of HTTP, you *must* set username, but *must not* set
 password here to use the extension, in other cases it will revert to
 the default behavior.
 
 Usage
 =====
 
 Configure the repository as above, then just ``hg pull``, ``hg push``,
 etc.  You should be asked for the password only once (per every
 username and remote repository prefix or url combination).
 
 
 Similarly, for email, configure as above and just ``hg email``.
 Again, you will be asked for the password once (per every username and
 email server address combination).
 
 Implementation details
 ======================
 
 The extension is monkey-patching the mercurial ``passwordmgr`` class
 to replace the find_user_password method. Detailed order of operations
 is described in the comments inside `the code`_.
 
+History
+==========
+
+See `HISTORY.txt`_.
+
 Development
 ===========
 
 Development is tracked on BitBucket, see 
 http://bitbucket.org/Mekk/mercurial_keyring/
 
 
 Additional notes
 ================
 
 Information about this extension is also available
 on Mercurial Wiki: http://mercurial.selenic.com/wiki/KeyringExtension
+
+.. _HISTORY.txt: http://bitbucket.org/Mekk/mercurial_keyring/src/HISTORY.txt