Improve programattic access to hashes

Issue #37 open
Eli Collins repo owner created an issue

(Imported from Google Code)

Various applications which need to dynamically look up hashes, and have taken various routes - trapping calls to {{{getattr(passlib.hash, name)}}}, access through the clunkily-named passlib.registry methods, etc.

For 1.7, would like to clean this up. Current ideas...

  1. expose schemes() and handler() methods similar to CryptContext, placed in the passlib.hash module. This is where people would expect, but need to be sure it won't confusingly pollute the namespace.

  2. expose similar methods to (1), but put them in passlib.registry. Don't like having an extra module if it's not needed, but this might be cleaner.

  3. expose a "master" CryptContext instance which supports all hashes. would have to work out lazy-loading issues.

Additionally, this probably needs some custom functions such as fuzzy_identify() from the cmdline-dev branch, etc.

Need to study current uses of passlib some more.

Comments (1)

  1. Eli Collins reporter
    • edited description
    • changed milestone to 1.8

    Bumping this to 1.8, have enough deprecations and changes happening in 1.7; and 1.8 will see the removal of the CryptPolicy api, freeing up some flexibility in the internals.

  2. Log in to comment