Allan Saddi's projects blog
Announcements and ramblings about projects new and old.
Updated: 9 hours 7 min ago
Latest Projects
It seems like I've been working on so many random things the past few weeks. And all on different platforms: C (UNIX/POSIX), Python, Cocoa, iOS.
Anyhow, the only things that are almost ready for public consumption are the security-related libraries/modules. (Each succeeding project builds on the previous.) All are BSD licensed.
sha-asaddi
Everything SHA, from SHA-1 to SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512) to the newest truncated editions (SHA-512/224, SHA-512/256). Also includes HMAC wrappers for each. This is a cleaned up and refactored version of my previous command-line sha project. Still WIP though.
pbkdf2
Implementations of PBKDF2 in C and Python. The C version depends on sha-asaddi, though I suppose it can easily be swapped to use any other SHA/HMAC implementations with similar signatures. The Python version has no dependencies outside of the standard library.
scrypt
Implementations of Colin Percival's scrypt in C and pure Python. This was more of an academic exercise since Mr. Percival's version is far more optimized and is already available under a BSD license. (At least, I'm assuming it's more optimized — I haven't actually looked at his code yet. But he did seem to have assembly/SSE optimized versions.) The Python version is probably too slow to be practical. (A Python wrapper for the original scrypt implementation is already available.) Will gladly take optimization suggestions for the Python version!
Oh, and these three projects represent a general shift in my packaging/building ideals. For now, I've decided to ditch GNU's autotools in favor of CMake for my projects. CMake just seems like a more coherent tool for configuring/building in a platform-independent manner. But, that just, like, my opinion, man...
Anyhow, the only things that are almost ready for public consumption are the security-related libraries/modules. (Each succeeding project builds on the previous.) All are BSD licensed.
sha-asaddi
Everything SHA, from SHA-1 to SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512) to the newest truncated editions (SHA-512/224, SHA-512/256). Also includes HMAC wrappers for each. This is a cleaned up and refactored version of my previous command-line sha project. Still WIP though.
pbkdf2
Implementations of PBKDF2 in C and Python. The C version depends on sha-asaddi, though I suppose it can easily be swapped to use any other SHA/HMAC implementations with similar signatures. The Python version has no dependencies outside of the standard library.
scrypt
Implementations of Colin Percival's scrypt in C and pure Python. This was more of an academic exercise since Mr. Percival's version is far more optimized and is already available under a BSD license. (At least, I'm assuming it's more optimized — I haven't actually looked at his code yet. But he did seem to have assembly/SSE optimized versions.) The Python version is probably too slow to be practical. (A Python wrapper for the original scrypt implementation is already available.) Will gladly take optimization suggestions for the Python version!
Oh, and these three projects represent a general shift in my packaging/building ideals. For now, I've decided to ditch GNU's autotools in favor of CMake for my projects. CMake just seems like a more coherent tool for configuring/building in a platform-independent manner. But, that just, like, my opinion, man...
sha updated
It's strange, but my most ubiquitous work is probably a href=http://www.saddi.com/software/sha/sha/a (or rather, its individual hash implementations). I lost track of the number of random products I've run across that have a copyright/license attribution to me. SHA implementations are a dime a dozen though, and I'm sure the versions in OpenSSL (libcrypto) draw the most users.br /
br /
But I have to wonder, what draws developers to mine? The random portability/optimization knobs? The BSD license?br /
br /
Anyway, I reworked my SHA implementations today. Brought the API to my naming/style standards for this decade. Added SHA-512/224 and SHA-512/256. And, from the work on a href=http://www.saddi.com/software/news/archives/73-pam_oath,-where-art-thou.htmlpam_totp/a, added HMAC wrappers.br /
br /
Of course, with the addition of HMAC, I had to work it into sha (the utility) as well, which I did.br /
br /
So after a little over 7 years, here's a new sha release...br /
br /
a href=http://www.saddi.com/software/sha/dist/sha-1.1.tar.gzsha 1.1 tarball/abr /
CASMiddleware
For anyone not familiar with it, a href=http://www.jasig.org/casCAS/a is an open source single-sign on service. It's implemented in Java, but I have stumbled across a a href=https://bitbucket.org/desmaj/wsgicas/CAS server implemented in Python/a.br /
br /
Anyway, I've been running my own CAS server for a while now (which provides SSO service for all the webapps on my server). I actually have my own Python CAS client and WSGI middleware that I've been using for years. In addition to a number of my Python webapps, I've successfully used it to CASsify MoinMoin. I'm sure I could get it to work with Trac too, but that would probably annoy my Trac users. img src=http://www.saddi.com/software/news/templates/default/img/emoticons/wink.png alt=;-) style=display: inline; vertical-align: bottom; class=emoticon / (It works with any app that simply relies on REMOTE_USER.)br /
br /
casclient and casmiddleware were part of of my 'py-lib' project (if anyone remembers that). Though 'py-lib' was never really a project. It was more like a directory of Python modules I had written for myself mdash; a place to incubate early Python projects (flup's fcgi.py started there, along with the other pre-1.0 flup modules).br /
br /
But when I moved beyond Subversion, py-lib was abandoned.br /
br /
Due to all the work-related CAS work I've been doing lately, I was reminded of the fact that my Python CAS stuff was never really released. JA-SIG has their own Python CAS code, but it seems to be more geared toward CGI. I'm sure a few of the various Python authentication frameworks out there have a CAS module. But anyway, I just wanted to get the ball rolling and get my own CASMiddleware 'out there' mdash; in case anyone else finds it useful.br /
br /
It's pretty small and only depends on Beaker.br /
br /
For now, it's only available at my Hg repo. I'll send it over to PyPI when I get the chance. (Hah! I should have searched PyPI first, so many hits for 'CAS'. Oh well...)br /
br /
a href=http://hg.saddi.com/casmiddleware/casmiddleware/abr /
CASMiddleware
For anyone not familiar with it, CAS is an open source single-sign on service. It's implemented in Java, but I have stumbled across a CAS server implemented in Python. (Which I haven't tried yet.)
Anyway, I've been running my own CAS server for a while now (which provides SSO service for all the webapps on my server). I actually have my own Python CAS client and WSGI middleware that I've been using for years. In addition to a number of my Python webapps, I've successfully used it to CASsify MoinMoin. I'm sure I could get it to work with Trac too, but that would probably annoy my Trac users. (It works with any app that simply relies on REMOTE_USER.)
casclient and casmiddleware were part of of my 'py-lib' project (if anyone remembers that). Though 'py-lib' was never really a project. It was more like a directory of Python modules I had written for myself — a place to incubate early Python projects (flup's fcgi.py started there, along with the other pre-1.0 flup modules).
But when I moved beyond Subversion, py-lib was abandoned.
I was reminded of the fact that my Python CAS stuff was never really released due to all the work-related CAS work I've been doing lately. JA-SIG has their own Python CAS code, but it seems to be more geared toward CGI. I'm sure a few of the various Python authentication frameworks out there have a CAS module. But anyway, I just wanted to get the ball rolling and get my own CASMiddleware 'out there' — in case anyone else finds it useful.
It's pretty small and only depends on Beaker.
For now, it's only available at my Hg repo. I'll send it over to PyPI when I get the chance. (Hah! I should have searched PyPI first, so many hits for 'CAS'. Oh well...)
casmiddleware
Anyway, I've been running my own CAS server for a while now (which provides SSO service for all the webapps on my server). I actually have my own Python CAS client and WSGI middleware that I've been using for years. In addition to a number of my Python webapps, I've successfully used it to CASsify MoinMoin. I'm sure I could get it to work with Trac too, but that would probably annoy my Trac users.
(It works with any app that simply relies on REMOTE_USER.)casclient and casmiddleware were part of of my 'py-lib' project (if anyone remembers that). Though 'py-lib' was never really a project. It was more like a directory of Python modules I had written for myself — a place to incubate early Python projects (flup's fcgi.py started there, along with the other pre-1.0 flup modules).
But when I moved beyond Subversion, py-lib was abandoned.
I was reminded of the fact that my Python CAS stuff was never really released due to all the work-related CAS work I've been doing lately. JA-SIG has their own Python CAS code, but it seems to be more geared toward CGI. I'm sure a few of the various Python authentication frameworks out there have a CAS module. But anyway, I just wanted to get the ball rolling and get my own CASMiddleware 'out there' — in case anyone else finds it useful.
It's pretty small and only depends on Beaker.
For now, it's only available at my Hg repo. I'll send it over to PyPI when I get the chance. (Hah! I should have searched PyPI first, so many hits for 'CAS'. Oh well...)
casmiddleware