RE: Free MFA hardware tokens for your project

[Arnaud Le Hors]

> > By **2021-12-20** and preferably much sooner, please let me know
> > for HttpCore and HttpClient:
> 
> Wrong mailing list or wrong projects?   The above are d...@hc.apache.org

This is really meant for Httpd. Please, ignore the reference to HttpCore 
and HttpClient in the text. Sorry about the confusion.
--
Arnaud  Le Hors - Senior Technical Staff Member - Open Technologies: 
Blockchain, Edge Computing, Web - IBM

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

[Roy T. Fielding]

> On Dec 14, 2021, at 2:22 PM, Yann Ylavic  wrote:
> 
> On Tue, Dec 14, 2021 at 6:26 PM Roy T. Fielding  wrote:
>> 
>> This is a little confusing. It looks from the comment and code like the
>> change is restricting the request target that can be sent through a proxy,
>> which would be wrong.
> 
> Yeah, the hunk I pointed to in the other message is doing this and I'm
> going to fix it.

Thanks.

>> OTOH, it would make sense that the proxy itself (the thing to which the
>> proxied request is being sent) is limited to http(s) because that is a 
>> feature
>> of HTTP. Is that what was intended?
> 
> And the ap_post_read_request() part of the patch is enforcing that
> yes, so keeping it would be fine right?

Yep, that should be fine, at least until someone implements proxying via some 
other protocol.

Roy

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

[Yann Ylavic]

On Tue, Dec 14, 2021 at 6:26 PM Roy T. Fielding  wrote:
>
> This is a little confusing. It looks from the comment and code like the
> change is restricting the request target that can be sent through a proxy,
> which would be wrong.

Yeah, the hunk I pointed to in the other message is doing this and I'm
going to fix it.

>
> OTOH, it would make sense that the proxy itself (the thing to which the
> proxied request is being sent) is limited to http(s) because that is a feature
> of HTTP. Is that what was intended?

And the ap_post_read_request() part of the patch is enforcing that
yes, so keeping it would be fine right?

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

[Yann Ylavic]

On Tue, Dec 14, 2021 at 6:11 PM Roy T. Fielding  wrote:
>
> I am pretty sure that this isn't correct, or at least seems like overkill.
> We should definitely block unix: from being forwarded, but why would
> we want to block things like a urn: resolver?

Oh I realize now that you are probably talking about the below hunk here:

--- httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c (original)
+++ httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c Tue Dec 14
15:35:56 2021
@@ -775,13 +775,13 @@ static int proxy_detect(request_rec *r)

 /* Ick... msvc (perhaps others) promotes ternary short results to int */

-if (conf->req && r->parsed_uri.scheme) {
+if (conf->req && r->parsed_uri.scheme && r->parsed_uri.hostname) {
 /* but it might be something vhosted */
-if (!(r->parsed_uri.hostname
-  && !ap_cstr_casecmp(r->parsed_uri.scheme, ap_http_scheme(r))
-  && ap_matches_request_vhost(r, r->parsed_uri.hostname,
-
(apr_port_t)(r->parsed_uri.port_str ? r->parsed_uri.port
-   :
ap_default_port(r) {
+if (ap_cstr_casecmp(r->parsed_uri.scheme, ap_http_scheme(r)) != 0
+|| !ap_matches_request_vhost(r, r->parsed_uri.hostname,
+ (apr_port_t)(r->parsed_uri.port_str
+  ? r->parsed_uri.port
+  : ap_default_port(r {

And indeed this breaks a potential forward proxy module which would
handle an "urn:" like scheme.
We'd better check for a hostname in *our* proxy modules only, where it's needed.

Thanks;
Yann.

Re: Free MFA hardware tokens for your project

[Eric Covener]

> By **2021-12-20** and preferably much sooner, please let me know
> for HttpCore and HttpClient:

Wrong mailing list or wrong projects?   The above are d...@hc.apache.org

Free MFA hardware tokens for your project

[Arnaud Le Hors]

Hi!

I work with the Developer Best Practices Working Group of the
Linux Foundation's Open Source Security Foundation (OpenSSF)
 "Great
Multi-Factor Authentication (MFA) Distribution Project"
.

We'd like to give your project *free* MFA hardware tokens from Google
and GitHub, for use by your maintainers.  We'd especially like to give
them to any of your maintainers who aren't already using any.  Our
goal is to help improve the security of open source software
(OSS)/Free Software projects.  For example, these tokens can counter
attacks that release source code updates and/or packages using stolen
passwords.

By **2021-12-20** and preferably much sooner, please let me know
for HttpCore and HttpClient:

1. If you want any tokens, and if so...
2. How many Titan tokens from Google (up to 5 for each, 10 total)
3. How many Yubikey tokens from GitHub (up to 5 for each, 10 total)
4. The *private* email address to send codes to
   (this email must *not* go to the public, as these are use-once
   codes that can be used to get the tokens)
5. If you could use more, how many more.

We would send you coupon codes and validation codes to the private
email address.  You would then distribute those codes to the
maintainers you choose.  The recipients would use the coupon codes and
validation codes to "buy" the tokens from the Google Store and/or
GitHub Shop, who would ship the tokens directly to recipients.  These
codes are use-once, so make sure you can keep the codes private until
they're used by the intended person.

**Important**: The Google coupon codes **must be used by 2021-12-31**
on the Google Store or they expire.

How can you trust us? You don't need to. You would get the MFA tokens
from Google and GitHub; we're simply offering codes to make them
no-cost.  We'll provide some documentation on how to use them, but you
don't need to use our documents.

To qualify, each token recipient must:

1. Be a maintainer or contributor to this critical open source software 
(OSS)
   project, or to another OSS project that this project depends on
   (the dependency may be indirect).
2. Try to use an MFA token once they receive the token.
   We'd like recipients to use MFA tokens from then on, but at least try.
3. Not reuse the token between different people (the token must not be 
shared).
4. Consider providing feedback to us (so we can try to fix problems).

We also need each project that receives coupon codes and/or validation 
codes
to tell us these numbers (preferably within 30 days of getting the codes):

1. How many tokens did you distribute from just Google? From just GitHub?
2. How many people received tokens from just Google? From just GitHub?
   From both?
3. How many people didn’t have hardware tokens they used for OSS who
   received tokens from just Google? From just GitHub? From both?

We ask for this information so we can tell others some simple
measures of success. We don't need nor want the names of any
individuals participating. It's fine to ask the people who got the
codes for that information and provide a best-effort summary.

The MFA tokens are shipped from the US.  They can be shipped
internationally, but there are various limitations on where each
can be shipped.

In particular, we can't ship somewhere if that is forbidden
(sanctioned) under US law.  So at this time we are unable to ship
to individuals in China, Afghanistan, Russia, Ukraine, North Korea,
Iran, Sudan, and Syria.  Sorry about that.  See the Google and
GitHub sites for more shipping information.  More sanction information
is available at
<
https://home.treasury.gov/policy-issues/financial-sanctions/sanctions-programs-and-country-information
>.

For more information including how-tos and other setup information
can be found at the "Great Multi-Factor Authentication (MFA)
Distribution Project" site: .

Please, let me know if you have any questions.
Thank you.
--
Arnaud  Le Hors - Senior Technical Staff Member - Open Technologies, IBM

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

[Yann Ylavic]

I may have messed up, but this change is meant to return 400 early for
requests with a fully qualified URI that is not http/https and that no
forward-proxy module wants to handle (i.e. none did set r->proxyreq =
PROXYREQ_PROXY at post_read_request time, like forward proxy modules
do).

Those requests end up being handled by the http module as if they were
http, which looks wrong to me.

Regards;
Yann.

On Tue, Dec 14, 2021 at 6:26 PM Roy T. Fielding  wrote:
>
> This is a little confusing. It looks from the comment and code like the
> change is restricting the request target that can be sent through a proxy,
> which would be wrong.
>
> OTOH, it would make sense that the proxy itself (the thing to which the
> proxied request is being sent) is limited to http(s) because that is a feature
> of HTTP. Is that what was intended?
>
> Roy
>
> > On Dec 14, 2021, at 9:10 AM, Roy T. Fielding  wrote:
> >
> > I am pretty sure that this isn't correct, or at least seems like overkill.
> > We should definitely block unix: from being forwarded, but why would
> > we want to block things like a urn: resolver?
> >
> > To be clear, I'd rather remove all proxy functionality from httpd than
> > suggest to the world that http(s) schemes are the only names that
> > can be proxied through HTTP. It would break the Web architecture,
> > so -1 to that.
> >
> > Roy
>

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

[Roy T. Fielding]

This is a little confusing. It looks from the comment and code like the
change is restricting the request target that can be sent through a proxy,
which would be wrong.

OTOH, it would make sense that the proxy itself (the thing to which the
proxied request is being sent) is limited to http(s) because that is a feature
of HTTP. Is that what was intended?

Roy

> On Dec 14, 2021, at 9:10 AM, Roy T. Fielding  wrote:
> 
> I am pretty sure that this isn't correct, or at least seems like overkill.
> We should definitely block unix: from being forwarded, but why would
> we want to block things like a urn: resolver?
> 
> To be clear, I'd rather remove all proxy functionality from httpd than
> suggest to the world that http(s) schemes are the only names that
> can be proxied through HTTP. It would break the Web architecture,
> so -1 to that.
> 
> Roy

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

[Roy T. Fielding]

I am pretty sure that this isn't correct, or at least seems like overkill.
We should definitely block unix: from being forwarded, but why would
we want to block things like a urn: resolver?

To be clear, I'd rather remove all proxy functionality from httpd than
suggest to the world that http(s) schemes are the only names that
can be proxied through HTTP. It would break the Web architecture,
so -1 to that.

Roy


> On Dec 14, 2021, at 7:35 AM, yla...@apache.org wrote:
> 
> Author: ylavic
> Date: Tue Dec 14 15:35:56 2021
> New Revision: 1895955
> 
> URL: http://svn.apache.org/viewvc?rev=1895955&view=rev
> Log:
> Merge r1895914, r1895921 from trunk:
> 
>  *) http: Enforce that fully qualified uri-paths not to be forward-proxied
> have an http(s) scheme, and that the ones to be forward proxied have a
> hostname, per HTTP specifications.
> trunk patch: http://svn.apache.org/r1895914
>  http://svn.apache.org/r1895921
> 2.4.x patch: 
> https://patch-diff.githubusercontent.com/raw/apache/httpd/pull/286.patch
> backport PR: https://github.com/apache/httpd/pull/286
> +1: ylavic, minfrin, gbechis
> 
> 
> mod_proxy: Detect unix: scheme syntax errors at load time.
> 
> * modules/proxy/mod_proxy.c(add_pass, add_member, set_proxy_param,
>proxysection):
>  Check return value of ap_proxy_de_socketfy().
> 
> * modules/proxy/proxy_util.c(ap_proxy_get_worker_ex):
>  Check return value of ap_proxy_de_socketfy().
> 
> 
> 
> http: Enforce that fully qualified uri-paths not to be forward-proxied
>  have an http(s) scheme, and that the ones to be forward proxied have a
>  hostname, per HTTP specifications.
> 
> The early checks avoid failing the request later on and thus save cycles
> for those invalid cases.
> 
> 
> Submitted by: ylavic
> Reviewed by: ylavic, minfrin, gbechis
> Closes #286
> 
> Modified:
>httpd/httpd/branches/2.4.x/   (props changed)
>httpd/httpd/branches/2.4.x/CHANGES
>httpd/httpd/branches/2.4.x/include/ap_mmn.h
>httpd/httpd/branches/2.4.x/include/http_protocol.h
>httpd/httpd/branches/2.4.x/modules/http/http_request.c
>httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
>httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c
>httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c
>httpd/httpd/branches/2.4.x/server/protocol.c
> 
> Propchange: httpd/httpd/branches/2.4.x/
> --
>  Merged /httpd/httpd/trunk:r1895914,1895921
> 
> Modified: httpd/httpd/branches/2.4.x/CHANGES
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1895955&r1=1895954&r2=1895955&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
> +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Tue Dec 14 15:35:56 2021
> @@ -1,6 +1,10 @@
>  -*- coding: utf-8 -*-
> Changes with Apache 2.4.52
> 
> +  *) http: Enforce that fully qualified uri-paths not to be forward-proxied
> + have an http(s) scheme, and that the ones to be forward proxied have a
> + hostname, per HTTP specifications.  [Ruediger Pluem, Yann Ylavic]
> +
>   *) OpenSSL autoconf detection improvement: pick up openssl.pc in the
>  specified openssl path. [Joe Orton]
> 
> 
> Modified: httpd/httpd/branches/2.4.x/include/ap_mmn.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_mmn.h?rev=1895955&r1=1895954&r2=1895955&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original)
> +++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Tue Dec 14 15:35:56 2021
> @@ -586,6 +586,7 @@
>  *   dav_find_attr().
>  * 20120211.120 (2.4.51-dev) Add dav_liveprop_elem structure and
>  *   dav_get_liveprop_element().
> + * 20120211.121 (2.4.51-dev) Add ap_post_read_request()
>  * 
>  */
> 
> @@ -594,7 +595,7 @@
> #ifndef MODULE_MAGIC_NUMBER_MAJOR
> #define MODULE_MAGIC_NUMBER_MAJOR 20120211
> #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 120 /* 0...n */
> +#define MODULE_MAGIC_NUMBER_MINOR 121 /* 0...n */
> 
> /**
>  * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
> 
> Modified: httpd/httpd/branches/2.4.x/include/http_protocol.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/http_protocol.h?rev=1895955&r1=1895954&r2=1895955&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/include/http_protocol.h (original)
> +++ httpd/httpd/branches/2.4.x/include/http_protocol.h Tue Dec 14 15:35:56 
> 2021
> @@ -96,6 +96,13 @@ AP_DECLARE(void) ap_get_mime_headers(req
> AP_DECLARE(void) ap_get_mime_headers_core(request_rec *r,
> 

Broken links at https://httpd.apache.org/docs/

[Graham Leggett]

Hi all,

The v1.3 historical docs link at https://httpd.apache.org/docs/ currently leads 
to a 404, is that intentional?

Regards,
Graham
—

Re: travis setup for 2.4.x

[Kay Hohenhaus]

Would you kindly unsubscribe me? Many thanksOn 14 Dec 2021 21:34, Stefan Eissing  wrote:How is the relation between the .travis.yml in trunk and 2.4.x? We have checks for jobs in trunk with

- if: *condition_not_24x

and those jobs do not appear in the 2.4.x/.travis.yml. Is this a leftover? Are these 2 clearly separate or merged somehow?

Thanks for the help!

Kind Regards,
Stefan

Re: travis setup for 2.4.x

[Stefan Eissing]

> Am 14.12.2021 um 12:53 schrieb Joe Orton :
> 
> On Tue, Dec 14, 2021 at 11:34:24AM +0100, Stefan Eissing wrote:
>> How is the relation between the .travis.yml in trunk and 2.4.x? We have 
>> checks for jobs in trunk with
>> 
>> - if: *condition_not_24x
>> 
>> and those jobs do not appear in the 2.4.x/.travis.yml. Is this a leftover? 
>> Are these 2 clearly separate or merged somehow?
> 
> The intent was that .travis.yml (and test/travis*) can be kept the same 
> in 2.4.x as in trunk, with the "if" conditions then used to limit 
> exactly which tests are run in trunk vs 2.4. Then we should write the 
> tests for trunk in a way which should always be fine to backport as-is 
> to 2.4.

Ah, I get it. Thanks.

> In practice it gets a bit hard to disentangle some changes, and the 2.4 
> .travis.yml is a bit stale, so maybe there is a better practice.  e.g. 
> we could simply maintain two completely independent .travis.yml files 
> and copy and paste stuff from trunk where required.
> 
> Not really sure to be honest, welcome any opinions.

For me, I'd like to tinker with things in trunk without any fear
of breaking stuff in our release testing. That is why I prefer copies
of test/modules/* from trunk in 2.4.x that I refresh ideally on backports.

I myself find this easier than version checking in test. ymmv.

> 
> (Also, does anybody know why Travis notifications by e-mail are broken?)

Would be interested in seeing them again, as well.

Kind Regards,
Stefan

> 
> Regards, Joe
> 

Re: travis setup for 2.4.x

[Joe Orton]

On Tue, Dec 14, 2021 at 11:34:24AM +0100, Stefan Eissing wrote:
> How is the relation between the .travis.yml in trunk and 2.4.x? We have 
> checks for jobs in trunk with
> 
> - if: *condition_not_24x
> 
> and those jobs do not appear in the 2.4.x/.travis.yml. Is this a leftover? 
> Are these 2 clearly separate or merged somehow?

The intent was that .travis.yml (and test/travis*) can be kept the same 
in 2.4.x as in trunk, with the "if" conditions then used to limit 
exactly which tests are run in trunk vs 2.4. Then we should write the 
tests for trunk in a way which should always be fine to backport as-is 
to 2.4.

In practice it gets a bit hard to disentangle some changes, and the 2.4 
.travis.yml is a bit stale, so maybe there is a better practice.  e.g. 
we could simply maintain two completely independent .travis.yml files 
and copy and paste stuff from trunk where required.

Not really sure to be honest, welcome any opinions.

(Also, does anybody know why Travis notifications by e-mail are broken?)

Regards, Joe

travis setup for 2.4.x

[Stefan Eissing]

How is the relation between the .travis.yml in trunk and 2.4.x? We have checks 
for jobs in trunk with

- if: *condition_not_24x

and those jobs do not appear in the 2.4.x/.travis.yml. Is this a leftover? Are 
these 2 clearly separate or merged somehow?

Thanks for the help!

Kind Regards,
Stefan