Edit report at http://bugs.php.net/bug.php?id=53789&edit=1
ID: 53789
Comment by: henno at schooljan dot nl
Reported by: richard at blueapex dot co dot uk
Summary: Setting session.hash_function doesn't change hash
function used.
Status: Open
Type: Bug
Package: Session related
Operating System: Freebsd 8.1
PHP Version: 5.3.5
Block user comment: N
Private report: N
New Comment:
It does work when compiling in both hash and session modules into the
main PHP
executable (by use of --enable-hash and --enable-session on the
configure line).
The FreeBSD Ports strategy is to provide a slim PHP base package with a
lot of
extra modules as extra packages to choose. Fine of course, but
apparently the
has_function option breaks when one of the relevant modules are
externally
loaded.
I found this out because I also run a Gentoo machine where this bug does
not
manifest itself, and there the package strategy is to compile everything
into
one big PHP executable.
So a quick temporary workaround for FreeBSD users is adding both
--enable-hash
and --enable-session in the FreeBSD port Makefile for lang/php5 (and
disable the
external modules to prevent 'already loaded' warnings).
To summarize:
Steps to reproduce:
-------------------
Use either hash or session modules as external loadable module, setting
reverts
to 0 when choosing a hash algo.
Workaround:
-----------
Compile both hash and session modules into the main PHP executable.
Previous Comments:
------------------------------------------------------------------------
[2011-02-01 15:11:08] richard at blueapex dot co dot uk
I have the hash extension enabled.
Doing print_r(hash_algos()) gives a fair few hashes. I'm using
hash('SHA512', $foo) for encrypting passwords so it defiantly is
available to PHP.
------------------------------------------------------------------------
[2011-02-01 14:39:16] [email protected]
Do you have the hash extension enabled? Without that extension, hashing
algorithms
other than md5/sha1 will not be available.
------------------------------------------------------------------------
[2011-01-30 14:07:14] datahell at elxis dot org
I face the same problem on PHP 5.2.5 (x64) on my local installation
Windows Vista 64bit.
------------------------------------------------------------------------
[2011-01-19 14:23:34] richard at blueapex dot co dot uk
Description:
------------
This may be an apache bug, though I'll start with putting it down as
php. There is a similar bug: Bug #49469 submitted in 2009 with advice
try the latest snapshot, that was version 5.3.0 and I'm using version
5.3.5 so assuming that advice isn't valid and the bug still exists.
Setting session.hash_function variable in php.ini doesn't change the
value used to generate the hash function.
I've tried sha512, sha1, whirlpool. All of these don't change the hash
delivered to the browser (PHPSESSID) and still the standard md5() hash
is used.
All the hash algos tried are on the system when the output of
hash_algos() is examined.
Specifying 1 does make the system use SHA1 to generate the session
hash.
##############################
Revelant. php.ini
session.save_handler = files
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.bug_compat_42 = On
session.bug_compat_warn = On
session.referer_check =
session.entropy_length = 0
session.entropy_file =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = sha512
session.hash_bits_per_character = 5
url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"
Test script:
---------------
session_start()
Expected result:
----------------
sha512 generated PHPSESSID
Actual result:
--------------
md5 generated PHPSESSID
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=53789&edit=1
