Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c
On 02/19/2008 08:15 PM, Paul Querna wrote: André Malo wrote: * [EMAIL PROTECTED] wrote: Author: pquerna Date: Tue Feb 19 09:05:26 2008 New Revision: 629164 URL: http://svn.apache.org/viewvc?rev=629164&view=rev Log: Improve generation of the seed to rand, by using apr_generate_random_bytes, rather than the current time as a seed. Wouldn't it make more sense to drop all that seed and rand hassle and just use the apr-random bytes directly as salt (alphabet[byte % len(alphabet)]) I guess so apr-random though has this nasty habit of using really random sources, and using all entropy on a system, and I'd prefer to not use it more than needed. As this has been the source of pain and several bug reports in the past True. Thats why I normally compile with --with-devrandom=/dev/urandom. But this may not be suitable for all situations. Maybe there should be a apr_generate_urandom_bytes. But this is a story for the apr list. Regards Rüdiger
Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c
Ruediger Pluem wrote:
On 02/19/2008 06:05 PM, [EMAIL PROTECTED] wrote:
+static apr_status_t seed_rand()
+{
+int seed = 0;
+apr_status_t rv;
+rv = apr_generate_random_bytes((unsigned char*) &seed,
sizeof(seed));
+if (rv) {
+apr_file_printf(errfile, "Unable to generate random bytes:
%pm" NL, rv);
This creates the following compiler warning:
htpasswd.c:135: warning: format '%p' expects type 'void *', but argument
3 has type 'apr_status_t'
Sorry, fixed that in r629218.
Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c
On 02/19/2008 06:05 PM, [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Tue Feb 19 09:05:26 2008
New Revision: 629164
URL: http://svn.apache.org/viewvc?rev=629164&view=rev
Log:
Improve generation of the seed to rand, by using apr_generate_random_bytes,
rather than the current time as a seed.
PR: 31440
Modified:
httpd/httpd/trunk/support/htpasswd.c
Modified: httpd/httpd/trunk/support/htpasswd.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/support/htpasswd.c?rev=629164&r1=629163&r2=629164&view=diff
==
--- httpd/httpd/trunk/support/htpasswd.c (original)
+++ httpd/httpd/trunk/support/htpasswd.c Tue Feb 19 09:05:26 2008
@@ -126,6 +126,18 @@
}
}
+static apr_status_t seed_rand()
+{
+int seed = 0;
+apr_status_t rv;
+rv = apr_generate_random_bytes((unsigned char*) &seed, sizeof(seed));
+if (rv) {
+apr_file_printf(errfile, "Unable to generate random bytes: %pm" NL,
rv);
This creates the following compiler warning:
htpasswd.c:135: warning: format '%p' expects type 'void *', but argument 3 has
type 'apr_status_t'
Regards
Rüdiger
Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c
André Malo wrote: * [EMAIL PROTECTED] wrote: Author: pquerna Date: Tue Feb 19 09:05:26 2008 New Revision: 629164 URL: http://svn.apache.org/viewvc?rev=629164&view=rev Log: Improve generation of the seed to rand, by using apr_generate_random_bytes, rather than the current time as a seed. Wouldn't it make more sense to drop all that seed and rand hassle and just use the apr-random bytes directly as salt (alphabet[byte % len(alphabet)]) I guess so apr-random though has this nasty habit of using really random sources, and using all entropy on a system, and I'd prefer to not use it more than needed. As this has been the source of pain and several bug reports in the past -Paul
Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c
On 02/19/2008 07:48 PM, André Malo wrote: * [EMAIL PROTECTED] wrote: Author: pquerna Date: Tue Feb 19 09:05:26 2008 New Revision: 629164 URL: http://svn.apache.org/viewvc?rev=629164&view=rev Log: Improve generation of the seed to rand, by using apr_generate_random_bytes, rather than the current time as a seed. Wouldn't it make more sense to drop all that seed and rand hassle and just use the apr-random bytes directly as salt (alphabet[byte % len(alphabet)]) This was also my first thought on this patch. Regards Rüdiger
Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c
On Feb 19, 2008, at 1:48 PM, André Malo wrote: * [EMAIL PROTECTED] wrote: Author: pquerna Date: Tue Feb 19 09:05:26 2008 New Revision: 629164 URL: http://svn.apache.org/viewvc?rev=629164&view=rev Log: Improve generation of the seed to rand, by using apr_generate_random_bytes, rather than the current time as a seed. Wouldn't it make more sense to drop all that seed and rand hassle and just use the apr-random bytes directly as salt (alphabet[byte % len(alphabet)]) Most likely simpler...
Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c
* [EMAIL PROTECTED] wrote: > Author: pquerna > Date: Tue Feb 19 09:05:26 2008 > New Revision: 629164 > > URL: http://svn.apache.org/viewvc?rev=629164&view=rev > Log: > Improve generation of the seed to rand, by using > apr_generate_random_bytes, rather than the current time as a seed. Wouldn't it make more sense to drop all that seed and rand hassle and just use the apr-random bytes directly as salt (alphabet[byte % len(alphabet)]) nd -- package Hacker::Perl::Another::Just;print [EMAIL PROTECTED] split/::/ =>__PACKAGE__]}~; # André Malo # http://www.perlig.de #
Re: ping on mod_dns
William A. Rowe, Jr. wrote: Mads Toftum wrote: On Tue, Feb 19, 2008 at 09:30:30AM -0500, Jim Jagielski wrote: I propose mod_domain to match the IANA port number assignment. Seems more confusing than mod_named. I didn't care for mod_named (we haven't been suffixing the 'd'aemon most of the time), was actually thinking of mod_cname or similar, but mod_domain looks suitably unique and descriptive. +1 to mod_domain from me. Fair warning to everyone (just FYI while we're talking about the name): The module is itself modular, with only "core" DNS recordtypes built-in - at the moment, that's A, CNAME and MX and will probably include at least SOA and NS too before a version 1 is released. So we're potentially going to see modules like mod_domain_mx and mod_domain_txt or mod_domain_msad (for active directory extensions), etc. Also, do we want to change the internals to start using the new name or not - most notably the public bits of the API that are there to allow extensibility, like DNS_DECLARE(type), DNS_DECLARE_NONSTD(type) and DNS_DECLARE_DATA macros, etc? Issac Issac
Re: Linux build portability
Nick Gearls wrote: Can we move a build from one Linux machine to another one (same OS version, CPU, etc.), or are there some hard-coding in the binaries linked to the origin platform ? Under normal circumstances, yes you can move from one machine to another. I'm obviously asking the question because I tried and I have a problem on the target computer: Apache does not seem to correctly bind addresses (mod_proxy cannot resolve target machine name). That sounds like you have a DNS problem on the target machine. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Linux build portability
Can we move a build from one Linux machine to another one (same OS version, CPU, etc.), or are there some hard-coding in the binaries linked to the origin platform ? I'm obviously asking the question because I tried and I have a problem on the target computer: Apache does not seem to correctly bind addresses (mod_proxy cannot resolve target machine name). -- Thanks, Regards, Nick
Re: ping on mod_dns
Mads Toftum wrote: On Tue, Feb 19, 2008 at 09:30:30AM -0500, Jim Jagielski wrote: I propose mod_domain to match the IANA port number assignment. Seems more confusing than mod_named. I didn't care for mod_named (we haven't been suffixing the 'd'aemon most of the time), was actually thinking of mod_cname or similar, but mod_domain looks suitably unique and descriptive. +1 to mod_domain from me.
[PATCH #21563] support/list_hooks.pl does not parse declarations that span multiple lines
Hi, support/list_hooks.pl does not parse declarations that span multiple lines. The attached version does. See also bug #44453. Torsten list_hooks.pl Description: Perl program
Re: ping on mod_dns
On Tue, Feb 19, 2008 at 09:30:30AM -0500, Jim Jagielski wrote: > I propose mod_domain to match the IANA port number > assignment. > Seems more confusing than mod_named. vh Mads Toftum -- http://soulfood.dk
Re: ping on mod_dns
On Tue, Feb 19, 2008 at 09:30:30AM -0500, Jim Jagielski wrote: > I propose mod_domain to match the IANA port number > assignment. +1, especially since that way we don't have to listen to Paul Vixie ;) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: ping on mod_dns
I propose mod_domain to match the IANA port number assignment. On Feb 18, 2008, at 5:49 PM, Jorge Schrauwen wrote: true but like Roy said if mod_dns is allready in use a new name will need to be found no? On Feb 18, 2008 8:42 PM, Issac Goldstand <[EMAIL PROTECTED]> wrote: Jorge Schrauwen wrote: If the mod_dns mentioned before is different from the code... may I sugest mod_named? since a lot of people would be famileir with a name like htat. True, but that would break naming conventions: mod_smtp mod_ftp (mod_proxy_ajp, mod_proxy_http, mod_proxy_ftp) and even the included http module that handles http... -0 Issac -- ~Jorge
Re: board report due tomorrow
On Feb 18, 2008, at 9:56 PM, Jim Jagielski wrote: Eli Marmor, CEO / Representing Netmask (El-Mar) Internet Technologies, Ltd. "Mod_dns" So it's been rec'd for awhile (since ApacheCon in fact) Right. I can dig up a scan and resend to secretary@ if it's been misplaced and someone wants it. No need. I'm sure we have the scan, it's just not committed yet. Once noted in the file, it's golden. Jim - otherwise just let me know an md5, version number or URL that was on the Fax - so I/we can take that very version and import it. Or given that Issac now has commit - he can do the deed himself; perhaps with a few 'diff before commit' if there are questions, Dw.
