Re: default conf and ScriptAlias
> Then how do you propose those using it, as lets say in my example, set the > cgi directory for that vhost? They can keep using it, get the equivalent function from a default configuration and never be the wiser, or use/change to Alias + an explicit SetHandler and Options. Most default configurations already have both the ScriptAlias and a Directory section that matches the 2nd argument of the ScriptAlias. > ScriptAlias's purpose is to say hey httpd, our https://domain/cgi-bin/ > directory is really here on the filesystem at /var/www/cgi-bin/ > Its simple and works for decades, if you feel its not sure and needs > replacing with other commands, the code for other commands should be > internally called by ScriptAlias directive As the manual says, ScriptAlias is equivalent to (syntactic sugar for): Alias "/cgi-bin/" "/web/cgi-bin/" SetHandler cgi-script Options +ExecCGI Rather than Alias "/cgi-bin/" "/web/cgi-bin/" SetHandler cgi-script Options +ExecCGI Generically, we tell people to use Directory sections when they think they're working with filesystem content so some unexpected URL to filesystem mapping can't have an unexpected result. ScriptAlias subtly exposes you to this same kind of problem for marking resources to be interpreted as CGI.
Re: default conf and ScriptAlias
On 10/10/2021 11:07, Eric Covener wrote: I'm talking about removing it from the default configuration file and marking it as deprecated. I don't see a negative impact to users with their own configuration (not changed) or users with our default configuration (since the alternative does the same thing aside from unexpected results where the same Location is mapped to a file in an unintended location) This is how every person expects it. So you want to go make that more convoluted? I don't think Alias + "SetHandler cgi-script" in the default configuration is any more convoluted, given there's already a corresponding Directory section. You could even argue it's conceptually simpler. OK... I must be missing something here or interpreting what you are suggesting, well, it is Sunday morning... You want to nuke ScriptAlias which itself is not used in a (not that I've ever seen, and a quick google for 15 mins or so shows all these how to configure isp web servers blogs, and none of them seem to either) Then how do you propose those using it, as lets say in my example, set the cgi directory for that vhost? Which could be any name, in any location depending on how said shared host servers are setup, I use /var/www/vhost/domain/www/cgi-bin but previous employers have used /var/www/domain/cgi or /www/domains/cgi-bin and /vhosts/substr0 domain/substr1 domain/domain/cgi-bin ... We all run it differently, there is no hard set in stone locations for a virtual hosts docroot or scriptalias, it is dangerous to deprecate it, since that essentially implies its gone. ScriptAlias's purpose is to say hey httpd, our https://domain/cgi-bin/ directory is really here on the filesystem at /var/www/cgi-bin/ Its simple and works for decades, if you feel its not sure and needs replacing with other commands, the code for other commands should be internally called by ScriptAlias directive -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message.
Re: default conf and ScriptAlias
On Sat, Oct 9, 2021 at 8:30 PM Noel Butler wrote: > On 10/10/2021 03:39, Eric Covener wrote: > > Relative to the recent CVEs, should we replace ScriptAlias in the > default conf with Alias + SetHandler cgi-script in the corresponding > Directory section? > > And .. should ScriptAlias be deprecated/discouraged in some way if the > expanded version is safer by avoiding the equivalent of setting the > handler in Location vs. Directory? > > I am assuming it is not possible/feasible to make ScriptAlias just > work as if it was in the 2nd arguments Directory config. > > -1 > > You are talking about changing a httpd life long option, thats used in > millions of settings around the world. > I'm talking about removing it from the default configuration file and marking it as deprecated. I don't see a negative impact to users with their own configuration (not changed) or users with our default configuration (since the alternative does the same thing aside from unexpected results where the same Location is mapped to a file in an unintended location) This is how every person expects it. > > So you want to go make that more convoluted? > I don't think Alias + "SetHandler cgi-script" in the default configuration is any more convoluted, given there's already a corresponding Directory section. You could even argue it's conceptually simpler.
Re: default conf and ScriptAlias
… both +1 and -1. A change in version number or major version can imply significant changes in the base configuration, and I see this suggestion as a fit for a httpd-2.5, -3.0 or the likes. Hence, +1. However changing such widely used setting on the existing 10 year old 2.4 tree will cause operators headaches as the one outlined by Noel - more so as this setting is there for way longer than 2.4 and therefore -1. Alex > On Oct 9, 2021, at 20:30, Noel Butler wrote: > > >> >> On 10/10/2021 03:39, Eric Covener wrote: >> >> Relative to the recent CVEs, should we replace ScriptAlias in the >> default conf with Alias + SetHandler cgi-script in the corresponding >> Directory section? >> >> And .. should ScriptAlias be deprecated/discouraged in some way if the >> expanded version is safer by avoiding the equivalent of setting the >> handler in Location vs. Directory? >> >> I am assuming it is not possible/feasible to make ScriptAlias just >> work as if it was in the 2nd arguments Directory config. > > -1 > > > > You are talking about changing a httpd life long option, thats used in > millions of settings around the world. > > Scriptalias setting is not used in any directory setting in my case, its used > in a global way > > DocumentRoot "/var/www/html" > > > AllowOverride None > Options SymlinksIfOwnerMatch > Require all granted > > > Alias /icons/ "/var/www/icons/" > > > AllowOverride None > Require all granted > > > ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" > > > AllowOverride None > Options None > Require all granted > > > > > and more globally used in every service provider i've been at (not all my > doing but end result is identical) inside virtual hosts confs > > > ServerName xxx > ServerAlias www. > DocumentRoot /var/www/vhost/xxx/www/html > ScriptAlias /cgi-bin/ /var/www/vhost/x/www/cgi-bin/ > > ...snip... > > > > This is how every person expects it. > > So you want to go make that more convoluted? > > > > -- > Regards, > Noel Butler > > This Email, including attachments, may contain legally privileged > information, therefore at all times remains confidential and subject to > copyright protected under international law. You may not disseminate this > message without the authors express written authority to do so. If you are > not the intended recipient, please notify the sender then delete all copies > of this message including attachments immediately. Confidentiality, > copyright, and legal privilege are not waived or lost by reason of the > mistaken delivery of this message. > >
Re: default conf and ScriptAlias
On 10/10/2021 03:39, Eric Covener wrote: Relative to the recent CVEs, should we replace ScriptAlias in the default conf with Alias + SetHandler cgi-script in the corresponding Directory section? And .. should ScriptAlias be deprecated/discouraged in some way if the expanded version is safer by avoiding the equivalent of setting the handler in Location vs. Directory? I am assuming it is not possible/feasible to make ScriptAlias just work as if it was in the 2nd arguments Directory config. -1 You are talking about changing a httpd life long option, thats used in millions of settings around the world. Scriptalias setting is not used in any directory setting in my case, its used in a global way DocumentRoot "/var/www/html" AllowOverride None Options SymlinksIfOwnerMatch Require all granted Alias /icons/ "/var/www/icons/" AllowOverride None Require all granted ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" AllowOverride None Options None Require all granted and more globally used in every service provider i've been at (not all my doing but end result is identical) inside virtual hosts confs ServerName xxx ServerAlias www. DocumentRoot /var/www/vhost/xxx/www/html ScriptAlias /cgi-bin/ /var/www/vhost/x/www/cgi-bin/ ...snip... This is how every person expects it. So you want to go make that more convoluted? -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message.
default conf and ScriptAlias
Relative to the recent CVEs, should we replace ScriptAlias in the default conf with Alias + SetHandler cgi-script in the corresponding Directory section? And .. should ScriptAlias be deprecated/discouraged in some way if the expanded version is safer by avoiding the equivalent of setting the handler in Location vs. Directory? I am assuming it is not possible/feasible to make ScriptAlias just work as if it was in the 2nd arguments Directory config. -- Eric Covener cove...@gmail.com
Re: Ineract with travis? (was: Errored: apache/httpd#1888 (trunk - 47e6ece))
On Fri, Oct 8, 2021 at 10:30 AM Joe Orton wrote: > > Did you work out how to do this? I never asked for special rights here > AFAIK, I assumed everybody in the "httpd-committers" group could do it, > but your github user is listed there too: > > https://github.com/orgs/apache/teams/httpd-committers/members Yeah but no :/ I'll create an infra ticket to ask.. Thanks; Yann.
Re: Broken: apache/httpd#2037 (trunk - fa7f375)
On Sat, Oct 9, 2021 at 5:47 PM Travis CI wrote: > > Build #2037 was broken Somehow Travis picked up the wrong Ubuntu version?? All the Ubuntu Focal builds with system's APR failed with: """ Build system information Build language: c Build dist: focal <== what we asked Build id: 239483484 Job id: 542297167 Runtime kernel version: 4.15.0-1098-gcp travis-build version: 267382cc Build image provisioning date and time Sat Oct 9 13:37:27 UTC 2021 Operating System Details Distributor ID: Ubuntu Description: Ubuntu 16.04.7 LTS Release: 16.04 Codename: xenial<== what we got [...] ./buildconf --with-apr=/usr/bin/apr-1-config testing apr-config executable: /usr/bin/apr-1-config using apr-config version 1.5.2 [...] checking for APR... configure: WARNING: APR version 1.6.0 or later is required, found 1.5.2 configure: WARNING: Found APR in /usr/bin/apr-1-config, but we think it is considered unacceptable [...] Done. Your build exited with 1. """
Broken: apache/httpd#2037 (trunk - fa7f375)
Build Update for apache/httpd - Build: #2037 Status: Broken Duration: 3 mins and 24 secs Commit: fa7f375 (trunk) Author: Yann Ylavic Message: mod_proxy_uwsgi: Remove duplicate slashes at the beginning of PATH_INFO. To accommodate for configs like: ProxyPass /uwsgi-pp uwsgi://localhost:8001/ which before r1892805 did not produce a leading double-slash in PATH_INFO. Submitted by: rpluem git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1894074 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/httpd/compare/2baea6bf86a3...fa7f3753066c View the full build log and details: https://app.travis-ci.com/github/apache/httpd/builds/239483484?utm_medium=notification_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://app.travis-ci.com/account/preferences/unsubscribe?repository=16806660_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
