Re: SHA-256

Thank you for the response. On 2017-02-24 23:45, William A Rowe Jr wrote: > They are useful for file completeness/error checking only. I'd agree > there is zero purpose in retaining SHA1 when SHA256 is in place. Unfortunately a lot of people do not know this. They compare the hashes instead,

Re: SHA-256

On Fri, Feb 24, 2017 at 12:02 PM, Yann Ylavic wrote: > On Fri, Feb 24, 2017 at 6:52 PM, Jim Jagielski wrote: >> I think we should start, in addition to "signing" w/ md5 and sha-1, >> using sha-256 as well. >> >> Sound OK? > > Our "true" signing has and

Re: SHA-256

On Fri, Feb 24, 2017 at 2:30 PM, Helmut K. C. Tessarek wrote: > On 2017-02-24 12:52, Jim Jagielski wrote: >> I think we should start, in addition to "signing" w/ md5 and sha-1, >> using sha-256 as well. > > I have a question: why are you still using md5/sha1 for generating

Re: [users@httpd] Problem when using nested if statements in apache 2.4

Hi everybody, the following users@ question is interesting in my opinion: 2017-02-20 18:17 GMT+01:00 Mike Schlottman : > > The problem comes when I combine these 2 so that all users except those > coming from 127.*.*.* or 192.168.*.* see the nice error page. > > > > > >

Re: SHA-256

On 02/24/2017 10:02 AM, Yann Ylavic wrote: Our "true" signing has and will always be PGP. Though SHA-256 is often asked by users@, so, +1 +1 --Jacob

Re: SHA-256

On 2017-02-24 12:52, Jim Jagielski wrote: > I think we should start, in addition to "signing" w/ md5 and sha-1, > using sha-256 as well. I have a question: why are you still using md5/sha1 for generating file hashes in the first place? Noone with knowledge of hashing algos would use these hashes

Re: release v1.9.0

Hi Yann, here we go: (gdb) p *ipsub $1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295, 4294967295, 4294967295, 4294967295}} (gdb) p *sa $2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102 , servname = 0x17d01040405 , port = 770, family = 554829073, salen =

Re: SHA-256

On Fri, Feb 24, 2017 at 6:52 PM, Jim Jagielski wrote: > I think we should start, in addition to "signing" w/ md5 and sha-1, > using sha-256 as well. > > Sound OK? Our "true" signing has and will always be PGP. Though SHA-256 is often asked by users@, so, +1

Re: SHA-256

On 24 Feb 2017, at 18:52, Jim Jagielski wrote: > > I think we should start, in addition to "signing" w/ md5 and sha-1, > using sha-256 as well. > > Sound OK? That seems to match the advice of NIST, E-CRYPT and the BSI on

SHA-256

I think we should start, in addition to "signing" w/ md5 and sha-1, using sha-256 as well. Sound OK?

Re: mod_remoteip and mod_http2 combined

On 02/20/2017 07:48 PM, William A Rowe Jr wrote: > On Sat, Feb 18, 2017 at 4:25 PM, Daniel Ruggeri wrote: >> On 2017-02-15 09:07 (-0600), William A Rowe Jr wrote: >>> On Wed, Feb 15, 2017 at 9:02 AM, Sander Hoentjen wrote:

Re: release v1.9.0

On Fri, Feb 24, 2017 at 5:39 PM, Stefan Priebe - Profihost AG wrote: > No we don't use IPv6 at all. Do you still need those values? Yes please. Regards, Yann.

Re: release v1.9.0

No we don't use IPv6 at all. Do you still need those values? Greets, Stefan Excuse my typo sent from my mobile phone. > Am 24.02.2017 um 14:18 schrieb Yann Ylavic : > > Hi Stefan (Priebe), > > Is IPv6 (really) involved in your network? > > Could you please show up the

Re: release v1.9.0

Hi Stefan (Priebe), Is IPv6 (really) involved in your network? Could you please show up the gdb output of the below ? On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic wrote: > > 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub, > apr_sockaddr_t *sa) > 1079 { >

Re: release v1.9.0

On Fri, Feb 24, 2017 at 1:35 PM, Stefan Eissing wrote: > Meh. > > Stefan: once during the last 2 days or several? > > > This is accessing r->useragent_addr by mod_access_compat which is, for h2 > slaves, initialized with c->client_addr. > > Since c->client_addr is

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On Fri, 24 Feb 2017, Yann Ylavic wrote: On Thu, Feb 23, 2017 at 8:50 PM, Jacob Champion wrote: Going off on a tangent here: For those of you who actually know how the ssl stuff really works, is it possible to get multiple threads involved in doing the encryption, or do

Re: release v1.9.0

Meh. Stefan: once during the last 2 days or several? This is accessing r->useragent_addr by mod_access_compat which is, for h2 slaves, initialized with c->client_addr. Since c->client_addr is always initialized by the master connection, I did not see any race issues with sharing this across

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On Fri, 24 Feb 2017, Yann Ylavic wrote: The issue is potentially the huge (order big-n) allocations which finally may hurt the system (fragmentation, OOM...). Is this a real or theoretical problem? Both. Fragmentation is a hard issue, but a constant is: the more you ask for big allocs, the

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On Thu, Feb 23, 2017 at 7:48 PM, Yann Ylavic wrote: > On Wed, Feb 22, 2017 at 8:55 PM, Daniel Lescohier wrote: > > > > IOW: > > read():Three copies: copy from filesystem cache to httpd read() buffer to > > encrypted-data buffer to kernel socket buffer. > > Not really, "copy

Re: release v1.9.0

Hi Yann, Hi Stefan, new trace: Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070, sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090 #0