the new release?

[alabde...@gmail.com]

hi

when will the new release come? from the  schedule 1.7 should be here 

https://code.google.com/p/passlib/wiki/Roadmap

[Eli Collins]

Sadly the release schedule has slipped a bit from that roadmap.  I should probably update it :)

A number of factors have contributed to the slippage.   Foremost, my day job has been keeping me extremely busy this year, so while I can hop over passlib in a flash if any security issues come up, new feature development has been somewhat sporadic, and for major releases like v1.7, the real release date is basically "when enough new features are ready".   The main reason there haven't been any point releases (e.g. v1.6.2) is that there haven't been any new bugs since then... but I should probably schedule a point release of passlib soon anyways, just to update the default rounds settings and documentation (it's been about a year).

I've blocked out some time later this week when I can sit down and update the roadmap, to account for the status of various new features that are in the pipeline.   But to quickly summarize things:  the two biggest items blocking the 1.7 release are support for peppered hashes, and support for scrypt.   Those are two features which I *strongly* want to include within the next release, but they are requiring quite a bit of legwork to make sure I've got them right, both from a cryptographic- and an API- perspective.

1. Peppered Hashes (issue 38 -- https://code.google.com/p/passlib/issues/detail?id=38) and 2):  I won't consider this feature ready for release until I feel the API is easy to use, but is also an API that also encourages people to use it in a secure manner.  None of the designs I've tried so far have felt right to me and/or secure, so I've spent most of my time on that issue researching the solutions of others.

2. Scrypt (issue 8 -- https://code.google.com/p/passlib/issues/detail?id=8): This feature just requires a lot of hacking until passlib has both a cross-platform CFFI-based C extension (which I'm still at a documentation-hunting stage for), and a pure-python fallback (which exists, but hasn't been scrutinized and tested as much as I'd like).  

Once those and a few other smaller features (such as the password generation & strength checking) are done, there will definitely be a 1.7 release! I'll post a followup to this email later in the week when I've worked out a more accurate timeline, given my dayjob's current workload :)

- Eli

--
You received this message because you are subscribed to the Google Groups "passlib-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to passlib-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sven]

Hi there,

Is there a specific reason why you would want to use CFFI? Cython (http://www.cython.org/) may be very suited to your purpose, and the extension module can be written in near-Python-syntax, making it easy to read and keeping in sync with the pure-Python version. I have some experience with Cython and I can say that it works brilliantly. Cython generates the cross-platform C files for you, and it is those files that you distribute. The end-user that compiles the module for his or her specific system does not need Cython.

-- 

With kind regards,

Sven

[Eli Collins]

I'm using CFFI mainly because I want passlib to have as broad compatibility as possible.   CFFI allows passlib to support both C-Python and PyPy. On the other hand, Cython and the Python C API in general are only usuable with C-Python: PyPy only offers limited support for the Python C API,   and with the advent of CFFI, I doubt PyPy's C API support will improve very quickly, as they seem to be treating CFFI as the way forward (at least for PyPy).   Cython's docs even note (http://docs.cython.org/src/userguide/pypy.html#bugs-and-crashes) that PyPy's C API is unstable and prone to crashes, which is definitely not something I want for a security-oriented library like passlib.

That said, if I get into writing a CFFI wrapper, and discover that it doesn't provide a stable enough bridge to both C-Python and PyPy, I'll probably adandon PyPy support for the initial release of the C extension, and go with Cython or a hand-rolled C extension.    But given that this feature is still in the "read docs and check out sample code" stage of things, I'm still reasonably easy to sway, given the above goals :)

- Eli

--

Eli Collins   el...@assurancetechnologies.com Software Development & I.T. Consulting Assurance Technologies   www.assurancetechnologies.com

[alabde...@gmail.com]

ah! thank you! thank you, and sorry for the delay.

and yes, the lib was good, so no need to make minor updates, now, waiting for major updates ;)