Re: Time for Apache httpd 2.4.3 ??
On 2012-07-11 19:15, Roy T. Fielding wrote: I don't know of any issues with 308, and Julian generally knows what he is doing with regard to HTTP. In general, we should consider Thanks :-) the IANA registry to be authoritative unless it is a known bug, In which case we should fix the registry. which means we should support everything in http://www.iana.org/assignments/http-status-codes/http-status-codes.xml Yes. If we want to get all of these in, I can open a separate ticket and provide another patch. Best regards, Julian
Re: Choosing a stronger password hash algorithm
Away on holidays, late reply, apologies. I would like to see bcrypt introduced, a number of sites seem to be moving that way, would be nice if apache did too! On 6/24/12, Stefan Fritsch s...@sfritsch.de wrote: On Saturday 23 June 2012, William A. Rowe Jr. wrote: On 6/23/2012 3:42 PM, Stefan Fritsch wrote: bcrypt [1] and scrypt [2] seem to be much more difficult to port to hardware or GPUs than sha256/512_crypt [3-5]. We can't make the operation too expensive on normal CPUs or we create a DoS problem if someone does lots of requests with wrong passwords. Therefore I think choosing an algorithm that does not scale well on more specialized hardware is good. Both bcrypt and scrypt can be adjusted in how much CPU time to use. scrypt can also be adjusted in how much RAM it uses. bcrypt uses a 128bit salt, AFAICS scrypt can use arbitrary salt lengths. Bcrypt has seen a lot more review than scrypt, therefore I am somewhat in favor of bcrypt. Crypt_blowfish [6] is an implementation with a very liberal license that we could use. Scrypt has a 2-clause BSD license which would also be OK. Opinions? We already have integration points to openssl, why add yet another dependency? Seems foolish. Openssl is not required, neither for apr nor for httpd. I propose to import either crypt_blowfish or scrypt into apr, just like apr contains some foreign sha1 and md5 code. This way we would not get an additional external dependency.
Re: Time for Apache httpd 2.4.3 ??
++1! On Jul 12, 2012, at 2:34 AM, Julian Reschke wrote: On 2012-07-11 19:15, Roy T. Fielding wrote: I don't know of any issues with 308, and Julian generally knows what he is doing with regard to HTTP. In general, we should consider Thanks :-) the IANA registry to be authoritative unless it is a known bug, In which case we should fix the registry. which means we should support everything in http://www.iana.org/assignments/http-status-codes/http-status-codes.xml Yes. If we want to get all of these in, I can open a separate ticket and provide another patch. Best regards, Julian
Re: mpm-event-optimization
On Jul 11, 2012, at 1:53 PM, Stefan Fritsch wrote: On Wed, 11 Jul 2012, Jim Jagielski wrote: About 4 months ago we moved Paul's event optimization stuff to its own branch, and since then no work as been done on it at all... I'd like for us to consider putting it back into trunk, so we can work out the bugs and issues and getting it up to snuff. This is in conjunction with my effort to reboot 'simple' (which I've been working on externally)... But there have been quite a few bugfixes in trunk's mpm event since the branch. We should get these into 2.4 first before we do radical changes in trunk. There are also the patches from http://mail-archives.apache.org/mod_mbox/httpd-dev/201203.mbox/%3C201203022118.08839.sf%40sfritsch.de%3E but I didn't have enough cycles to finish and commit those, yet. Of course, this should not prevent anyone from committing improvements to the mpm-event-optimization branch. To be clear, yes, the intent was to ensure that all patches from trunk got into 2.4 before we re-merge. My expectation is that the event optimizations will eventually find their way into 2.4.x (and not be part of 2.6.x) and so getting them back into trunk allows people to work them. Except for main branches, most side-branches just don't get worked. So my plan is: 1. We push all trunk event improvements into 2.4.x 2. We release 2.4.3 3. We re-merge the event optims back to trunk.
