Re: [VOTE] Release httpd 2.5.0-alpha

[William A Rowe Jr]

Based on the copyright/licensing exception I noted earlier today, I have to
vote -1. I'd expect the incubating rat tool could have caught this, but it
is principally invoked against incubating candidates.

Now that the mod_md config changes are in place, I suspect we are ready for
a second attempt.

Thanks for RM'ing!

Bill

On Nov 7, 2017 10:28 PM, "Daniel Ruggeri"  wrote:

> Hi, all;
>
>Please find the proposed 2.5.0-alpha release tarballs and signatures
> at the following location. This release candidate was tagged from trunk
> as of r1814469:
>
> https://dist.apache.org/repos/dist/dev/httpd/
>
>
> I'd like to call a vote to release this alpha candidate. Please do note
> - this is my first attempt at cutting a release and mistakes are likely.
> Therefore, I'll let the vote run at least 10 days (possibly more as I
> will be traveling to Dublin next week) and will greatly appreciate any
> additional scrutiny the release tarball can be given.
>
>
>
> Some notes to share after having executed the process for the first time:
>
> * I'm not 100% sure on the proper syntax for an alpha candidate with the
> release.sh[1] script. I used "./release.sh --tag 2.5.0-alpha alpha
> httpd-2.5 2.5.0 'drugg...@primary.net". This seems to have produced
> desired results.
>
> * I created two scripts[2] to automate the tagging of SVN and minor file
> modifications associated with a release as well as the push of the
> tarballs/signatures to the repo mirror. Unfortunately, I lack the karma
> to commit to site/trunk. How do I obtain this karma?
>
> * I'd like to make some updates to the documentation[3] about how to
> produce releases to point out the existence of the new scripts and make
> the process more clear. Same note about karma to site/ applies.
>
> * The documentation mentioned to AP_SERVER_DEVBUILD_BOOLEAN to 0 for the
> tagged release. I assume this still holds true for an alpha release.
>
> * Blockers for automation really only seem to live around credential
> management (svn password and keyring passphrase) and the conducting of
> the vote itself over email. Kudos to everyone involved for putting
> together the scripting that already exists!
>
> * I'd like to create yet another script that does a pre-flight check for
> a machine to ensure that the host it is run on has the dependencies all
> of the above scripts need. Thing is, other than java for the docs build
> and gpg... I'm not sure what those other things may be (or even if there
> are any). Pointers welcome.
>
>
> [1] http://svn.apache.org/repos/asf/httpd/site/trunk/tools/release.sh
>
> [2] http://people.apache.org/~druggeri/scripts/
>
> [3] http://httpd.apache.org/dev/release.html
>
>
> P.S.
>
> I'll be in Dublin next week if anyone would like to catch up!
>
> --
> Daniel Ruggeri
>
>

Mistaken attributions?

[William A Rowe Jr]

So without diving into why one or another form is more correct,
the ASF's global license header guidance is absolute.

mod_remoteip is an example of getting it 'right' by many
definitions of 'right' across the ASF;

/* Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 *
 * Portions of the input filter code for PROXY protocol support is
 * Copyright 2014 Cloudzilla Inc.
 */

The mod_h2.h and other files in that tree are incorrect by every
ASF definition;

/* Copyright 2015 greenbytes GmbH (https://www.greenbytes.de)
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0

 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

This is not to take anything away from Stefan's and his
employers' contributions to this project.

Please, fix. Thanks,

Bill

Re: 2.4.x STATUS needs you!

[William A Rowe Jr]

On Wed, Dec 13, 2017 at 7:50 PM, Daniel Ruggeri  wrote:
> Aye, I had originally added the support for PROXY in remoteip since... 
> well... it's used to extract remote IP info. The funny part is that I had 
> committed my additions within an hour of the third party code being donated 
> and incorporated without realizing it... so I removed my changes and added 
> this code into remoteip with some small fixes.
>
> I'm a bit confused. I don't recall so much opposition to this being in 
> remoteip. It seems reasonable to me since it's just another way to get remote 
> client IP information from the connection versus an HTTP header. Worth 
> pointing out is that it can be argued that both are operating at layer 7 
> since there doesn't seem to be universal agreement as to whether TLS is layer 
> 6 or 7... one method of IP extraction just happens to be layer 7 data that 
> proceeds TLS while the other is layer 7 data wrapped in TLS inside an HTTP 
> request. Academic discussion of OSI layers aside, it still feels "right" to 
> me as a user and server admin to expect mod_remoteip to be the one place I 
> would go to enable extraction of remote IP info. I'm not exactly firm on 
> this... I would rather just see the functionality in the server... but 
> hopefully that at least clarifies how we wound up in this neighborhood to 
> begin with.

I agree. While I didn't push back on copyright statements as much
as I should have (and this applies as well to confusing copyright
statements in h2 sources hosted @ASF), I didn't care that the code
had landed at mod_remoteip.

Now, I do, but strictly as a matter of protocol vs protocol. Someone
who enables PROXY support absolutely does not care which of the
interfaces the request arrived at, they entirely trust their edge routers
to inform them of the next-hop. It is not expressed as HTTP and isn't
even an HTTP module, it is a rabbit-mq style annotation.

People who choose to enable mod_remoteip (legacy) are interested
in how the request arrived, and who those intermediaries suggest had
initiated the request. It is rarely authoritative, except on the user's own
infrastructure. It is idempotent from request-to-request (thanks in large
part to additional contributors to the module.) It follows HTTP protocol.

As much as the two pieces seem to do the same thing, they are both
entirely dissimilar from a protocol perspective, from thye request vs.
connection-based scope, and from web-of-trust perspectives.

> As for the whitelist/blacklist thoughts, I don't completely follow the 
> preference for enabling specific ranges and also having a blacklist rather 
> than the current "enable for everything except these ranges". Bill, can you 
> add a bit more color here? We're probably closer in thought process than 
> not... I just can't connect the dots. To my knowledge, we are the only server 
> even evaluating something more than just on or off... which I think is pretty 
> cool and a sign of innovation.

We made a big jump when we all acknowledged that you can't
'optionally' enable PROXY, it's a binary toggle. Too easy to fuzz the
input to trick that code into wrong assumptions. So we had agreed
to drop the recognition part and let the admin define which ports are
local/not PROXY and which come from the edge router.

But it is often easier to define the list of edge routers and presume
all other requests are in raw HTTP form, so the enablement directive
can be expressed as the list of IP/subnets that should be treated
exclusively as PROXY protocol connections to httpd. The blacklist
is still very handy for naming a couple of test/heartbeat clients to
avoid PROXY handling.

> Personally, I want to see this in the server... It appears we have either 
> silent opposition to the patch or just a lack of interest from other 
> committers, so I appreciate that Stefan is pointing these things out. I 
> *hope* I can spend some time on it in the coming weeks, but I've been poking 
> at this particular patch for about a year now and have a short attention 
> span. Hopefully enough feedback and work can be done soon to get *someone* 
> comfortable enough for another +1.

Me too, and I'm not trying to overly complicate things. Reading such
hostile accusations on our list doesn't motivate me to complete that
feature myself, even as all of us had agreed that expressing the
PROXY clients as a positive whitelist was a grand idea. I hope I didn't
come across so hostile toward your contribution or to Stefan's plea
for additional eyeballs. I myself am trying not to be that jerk.

In an offhanded aside, it was suggested this might be a distinct mod
from remoteip. That might actually be a really great idea, from the
perspective that people who need remoteip and people who need
PROXY support are often two different audiences, and it is generally
unwise to enable functionality that doesn't serve a purpose for any
given deployment. I'm not nixing the current combination; I don't

Season Greetings

[Steffen]

The year 2017 has been again exciting in terms of growth of the Apache 
community and  the Feature set of the Apache HTTPD server. In 2017 I was 
becoming a HTTPD PMC member. 

In 2017 we celebrated 14 years Apache Lounge, wow.. time is flying. I am  
thrilled to see so many folks making use of Apache Lounge Binaries (more and 
more the binaries are packaged with commercial software) and visiting the 
Apache Lounge, more and more non-windows users are participating. For many of 
users the forum is a big valuable archive and also thanks to the moderators 
Mario, Gregg and Tom we continued the quality level. Also thanks to the PHP 
team (special Pierre, Anatol) and HTTPD dev’s for the help.

It is really rewarding to see that the effort we put into the Apache Server is 
appreciated so much. 

For the next weeks, I'll be spending time with my family enjoying Christmas end 
of year festivities. As exciting as computers and servers can be, this year 
will also forever serve as a reminder of what is really important: family, 
friends and the compassion of strangers.

I wish for you and your families time to reconnect, enjoy traditions, and to 
find some rest during the holiday season. Whatever you celebrate, I hope you 
take a moment to reflect on the year that is closing and on your goals for 2018 
as it approaches. 

Many thanks to all my  friends in the Apache Community and ASF and enjoy the 
holidays !


Steffen

www.apachelounge.com 

Re: 2.4.x STATUS needs you!

[Jim Jagielski]

My own 2c is that I don't really care that much *where* the functionality
exists, just that we actually ship it. It's been almost a year since I
reached out to the orig author and asked about moving/donating the
code to the ASF, and they readily agreed. To have it just sit
around, un-released, for all this time is kind of bad.

mod_md v1.1.1

[Steffen]

See that also added error logging when communication fails with communication 
with a ACME server.  This is in line what I requested in the other thread. 

Not tested yet, waiting for a renew. 

Thanks!

Steffen

> Op 14 dec. 2017 om 12:43 heeft Stefan Eissing  het 
> volgende geschreven:
> 
> Fixed backward compaitbility to ' v1.1.0 versions
> to continue working. Test case added.
> added httpd version checks to test cases that make use of 2.5.0 mod_ssl 
> features. Tests now
> run clean against a 2.4.30 installation.
> —
> You are receiving this because you are subscribed to this thread.
> View it on GitHub or mute the thread.
>