Re: httpd and letsencrypt

[Greg Stein]

Anything new on this?

On Sep 15, 2016 00:35, "Dale Ghent"  wrote:

>
> Apologies from necro’ing this thread, I’m just catching up.
>
> As a maintainer/user of a lesser-known open source OS (OmniOS, based on
> illumos, which is the carry-on of what you all might remember as
> OpenSolaris after Oracle killed it) I’ve had my own issues around
> attempting to select a suitable letsencrypt client that works on OmniOS and
> maintaining it. I’ve got one working (getssl) and it’s basically a giant
> shell script with modifications to work in our native userland.
>
> The plain matter for people like myself is that most letsencrypt clients
> out there are either Python or Shell script, with the former tending to
> require non-mainstream C modules that don’t play well on anything outside
> of Linux or *BSD, and the latter written with GNU userlands in mind. The
> prospect of having cert management baked in to Apache httpd is tantalizing
> - a perhaps more platform-agnostic approach that replaces the mess of
> scripts and cronjobs that we see today.
>
> Of course it would be an optional module, and anyone turning it on with a
> pre-existing LE setup should do so in an orderly way. Either way,
> facilitating SSL certs in light of HTTP/2 would be something I would be
> happy to see, even if at any other time such a facility would be seen as
> outside the scope of httpd.
>
> /dale
>
> > On Aug 26, 2016, at 5:08 PM, William A Rowe Jr 
> wrote:
> >
> > I think this is great, in concept.
> >
> > My experience with letsencrypt (which was quite good, FWIW) is that
> > the project delivered a contained and trusted environment to sync and
> > deliver new keys and retrieve signed certificates. I'll be interested to
> see
> > what simplification is presented, I don't think we want to get into the
> > business of delivering container-style distributions of httpd.
> >
> >
> >
> > On Fri, Aug 26, 2016 at 9:47 AM, Rich Bowen  wrote:
> > At LinuxCon I spoke with the director of the LetsEncrypt project - whose
> > business card I haven't yet found in unpacking - and he asked whether
> > the httpd project would be interested in LetsEncrypt being "in" httpd.
> > That is, when one installs httpd, letsencrypt would just be a config
> > option. (I have no idea how this would actually work, but that's beside
> > the point really.)
> >
> > Is this something that we'd be interested in, if it were contributed? I
> > note that their software is under the Apache License, so there shouldn't
> > be any difficulty on that front.
> >
> > Naturally, I told him that the next step was to get on this mailing list
> > and talk about implementation details, and he said he'd do that. So that
> > should be coming in the next week, as soon as I find his business card
> > and send him the subscribe info and so on.
> >
> > --
> > Rich Bowen - rbo...@rcbowen.com - @rbowen
> > http://apachecon.com/ - @apachecon
> >
>
>

Hackathon tomorrow?

[Rich Bowen]

If you're around Apachecon Tomorrow please consider dropping by the
hackathon area on floor -2 to work on the items in
https://public.etherpad-mozilla.org/p/aceu-2016-hackathon

Thanks.

Re: apreq release

[Steve Hay]

[Resending from an address that's actually subscribed to the lists...]

The current mod_perl release (2.0.10) is taken from trunk. (The
httpd24 branch was only for development work leading towards the
previous release (2.0.9), and is now obsolete.)

On 17 November 2016 at 09:03, Issac Goldstand  wrote:
> Yes, if we go through with this.  The mod_apreq2 stuff is in httpd.
> However I just realized that although it's been in trunk for years now,
> it's never been backported to the 2.4.x branch.  I'm not sure why, and
> my google-fu isn't finding relevant discussion on dev@httpd.
>
> When I initially took a look yesterday, I thought I'd looked at a 2.4
> release.  Can someone from the mod_perl dev community tell me if new
> releases (intended for httpd 2.4) come from trunk or from the httpd24
> branch?  If it's from the branch, then the apreq stuff could be moved to
> trunk (or a submodule, like Apache::Reload and friends if desired).  If
> trunk, then until mod_apreq is backported to httpd 2.4 (or httpd bumps
> versions and rebranches off of trunk)
>
>
>
> On 11/16/2016 3:40 PM, Brian J. France wrote:
>> This is just merging the perl stuff into mod_perl, right?
>>
>> Not merging mod_apreq2 and all the request cache/re-play bucket, POST 
>> reading, file uploading, etc stuff, right?
>>
>> I really don't want to have to include mod_perl so my C modules can read 
>> POST data and handle file uploads.
>>
>> Cheers,
>>
>> Brian
>>
>>
>>> On Nov 16, 2016, at 4:42 AM, Issac Goldstand  wrote:
>>>
>>> Given that the C was (finally) merged into httpd years ago, and given
>>> that there are no proposed code changes, I'd say that's not such a bad
>>> idea...
>>>
>>> I've become a bit rusty in Perl (and even with apreq) over the years,
>>> but IIRC, all of the Perl glue is in
>>> http://svn.apache.org/repos/asf/httpd/apreq/trunk/glue/perl/
>>>
>>> I'll take a crack at seeing if I can fold it into mod_perl despite the rust.
>>>
>>>
>>> On 11/15/2016 2:45 PM, Andres Thomas Stivalet wrote:
 Good news!! No idea why apreq hasn't just been merged into mod_perl
 after all these years.

 A+++

 On Nov 15, 2016 3:27 AM, "Issac Goldstand" >>> > wrote:

Hi all,

Someone (finally) noticed that apreq's test suite isn't compatible with
Apache 2.4 and requested a change.  Given that we haven't released an
updated apreq in nearly 6 years, I'm inclined to make/test the changes
to the test suite and immediately go to a release cycle.

Does anyone want time to add anything else to libapreq-2.14 before I
start tarring and voting (in the next few days, I hope)?


-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org

For additional commands, e-mail: dev-h...@perl.apache.org


>>>
>>
>

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

[William A Rowe Jr]

On Nov 16, 2016 20:29, "Jacob Champion"  wrote:
>
> On 11/16/2016 05:01 AM, William A Rowe Jr wrote:
>>
>> We need to tolerate their presence. But we should ignore the guidance
that
>> sf originally quoted, that the URI host supersedes the Host header, it
does
>> not, they are two different entities it the proxy case
>
>
> The "different entities" interpretation made sense to me too, but after
re-reading the spec and seeing what the browsers actually do, I'm not so
sure. (I'm a relative noob when it comes to the proxy sides of the spec, so
corrections are appreciated.)
>
> From section 5.4:
>
>A client MUST send a Host header field in all HTTP/1.1 request
>messages.  If the target URI includes an authority component, then a
>client MUST send a field-value for Host that is identical to that
>authority component, excluding any userinfo subcomponent and its "@"
>delimiter (Section 2.7.1).  If the authority component is missing or
>undefined for the target URI, then a client MUST send a Host header
>field with an empty field-value.
>
> That's pretty absolute, and there doesn't seem to be an exception carved
out for proxies. And in practice, after giving Chromium and Firefox a try
with a local netcat "proxy", the Host headers they send are indeed derived
from the target URI, *not* the hostname of the HTTP proxy. I'd like to see
what other browsers do as well.
>
> This would appear to prevent name-based hosting of multiple proxies and
origin servers at the same IP address, which seems strange to me, given
that the Host header would be an appropriate resolution tool in that
case... so I'm hoping there's something I'm missing.
>
> Maybe no one needs to do that? Does anyone have experience with a
client/user-agent that makes use of name-based virtual proxies?
>
> --Jacob

Doh, that's right.

This is why we had such a horrid time with unwarranted TLS SNI host headers
vs Host: headers for proxy requests through httpd:. I will need to review
all three and compare them to the effect of this new patch.

In the interim I suggest we withdraw this comparison, and bring it back up
as a post 2.4.24 change. Thoughts?

Re: apreq release

[Issac Goldstand]

That was my knee-jerk reaction, too, but after digging, I saw that win32
really shouldn't be affected.

On 11/16/2016 4:09 PM, Steve Hay wrote:
> On 15 November 2016 at 09:26, Issac Goldstand  wrote:
>> Hi all,
>>
>> Someone (finally) noticed that apreq's test suite isn't compatible with
>> Apache 2.4 and requested a change.  Given that we haven't released an
>> updated apreq in nearly 6 years, I'm inclined to make/test the changes
>> to the test suite and immediately go to a release cycle.
>>
>> Does anyone want time to add anything else to libapreq-2.14 before I
>> start tarring and voting (in the next few days, I hope)?
>>
> 
> All looks good here on Win32 - the current SVN version passes all
> tests using VC++ 2010, perl-5.25.3, mod_perl-2.0.10 and either
> httpd-2.2.31 or httpd-2.4.23. (Whatever the httpd-2.4 incompatibility
> was seems not to affect anything on Win32!)
> 

Re: apreq release

[Issac Goldstand]

Yes, if we go through with this.  The mod_apreq2 stuff is in httpd.
However I just realized that although it's been in trunk for years now,
it's never been backported to the 2.4.x branch.  I'm not sure why, and
my google-fu isn't finding relevant discussion on dev@httpd.

When I initially took a look yesterday, I thought I'd looked at a 2.4
release.  Can someone from the mod_perl dev community tell me if new
releases (intended for httpd 2.4) come from trunk or from the httpd24
branch?  If it's from the branch, then the apreq stuff could be moved to
trunk (or a submodule, like Apache::Reload and friends if desired).  If
trunk, then until mod_apreq is backported to httpd 2.4 (or httpd bumps
versions and rebranches off of trunk)



On 11/16/2016 3:40 PM, Brian J. France wrote:
> This is just merging the perl stuff into mod_perl, right?
> 
> Not merging mod_apreq2 and all the request cache/re-play bucket, POST 
> reading, file uploading, etc stuff, right?
> 
> I really don't want to have to include mod_perl so my C modules can read POST 
> data and handle file uploads.
> 
> Cheers,
> 
> Brian
> 
> 
>> On Nov 16, 2016, at 4:42 AM, Issac Goldstand  wrote:
>>
>> Given that the C was (finally) merged into httpd years ago, and given
>> that there are no proposed code changes, I'd say that's not such a bad
>> idea...
>>
>> I've become a bit rusty in Perl (and even with apreq) over the years,
>> but IIRC, all of the Perl glue is in
>> http://svn.apache.org/repos/asf/httpd/apreq/trunk/glue/perl/
>>
>> I'll take a crack at seeing if I can fold it into mod_perl despite the rust.
>>
>>
>> On 11/15/2016 2:45 PM, Andres Thomas Stivalet wrote:
>>> Good news!! No idea why apreq hasn't just been merged into mod_perl
>>> after all these years.
>>>
>>> A+++
>>>
>>> On Nov 15, 2016 3:27 AM, "Issac Goldstand" >> > wrote:
>>>
>>>Hi all,
>>>
>>>Someone (finally) noticed that apreq's test suite isn't compatible with
>>>Apache 2.4 and requested a change.  Given that we haven't released an
>>>updated apreq in nearly 6 years, I'm inclined to make/test the changes
>>>to the test suite and immediately go to a release cycle.
>>>
>>>Does anyone want time to add anything else to libapreq-2.14 before I
>>>start tarring and voting (in the next few days, I hope)?
>>>
>>>
>>>-
>>>To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
>>>
>>>For additional commands, e-mail: dev-h...@perl.apache.org
>>>
>>>
>>
>