This patch changes the function random-string to use secure-random:number which is a better random number generator.
Anton Vodonosov**, since secure-random is your package, I would appreciate your review.
Sabra
03.12.2012, 08:52, "Sabra Crolleton" sabra.crolleton@gmail.com:
This patch changes the function random-string to use secure-random:number which is a better random number generator.
Anton Vodonosov, since secure-random is your package, I would appreciate your review.
Sabra
Hello.
This fix would be good if secure-random didn't depended on cl+ssl.
Currently secure-random uses cl+ssl random number generator, so applying this patch will make hunchentoot always unconditionally depend on cl+ssl, but hunchentoot is supposed to be workable without cl+ssl (if :hunchentoot-no-ssl is present in *features*).
If application wants to prevent cl:random from session-secret initialization, than the application can initialize hunchentoot:*session-secret* variable. That is why the variable is exported and why hunchentoot emits a warning in case the variable is not initialized.
So I suggest that applications use secure-random to initialize hunchentoot:*session-secret*.
Or maybe secure-random should be enabled if cl+ssl is enabled with hunchentoot? Opinions?
Best regards, - Anton
On Wed, Dec 5, 2012 at 4:23 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
This fix would be good if secure-random didn't depended on cl+ssl.
[...]
Or maybe secure-random should be enabled if cl+ssl is enabled with hunchentoot? Opinions?
That. The idea is to make the default more secure if possible. The reason why we want to be able to compile without SSL is that this would make compiling Hunchentoot harder on platforms where SSL is not standard.
-Hans
I've just found that ironclad today also offers functions for secure pseudo random numbers (this functionality was absent in ironclad when I created secure-random).
See functions strong-random and related in the ironclad manual http://method-combination.net/lisp/ironclad/