Re: opinion poll, stale issues
Based on little my experience, an issue I reported in 2015 was recently fixed in 2.4.50 6 years later, so not sure if WONTFIX is the ideal thing for something who didn't get attention, as it may get attention later, I agree with the "it is rude '' opinion to mark something not attented as WONTFIX. STALE though sounds ok and truthful. Cheers El jue, 17 feb 2022 a las 10:58, Stefan Eissing () escribió: > > > > > Am 16.02.2022 um 14:12 schrieb Ruediger Pluem : > > > > > > > > On 2/16/22 10:32 AM, Stefan Eissing wrote: > >> How about we close stale issues on our bugzilla after a year without > >> changes with > >> > >> WONTFIX > >> We are sorry, but no one found the interest/time to work on this. > >> > >> ideally as an automated job somewhere? > > > > What is the issue with keeping them open? I guess this would be the most > > honest choice. If we decide deliberately that we don't > > want to do something we can close it explicitly as WONTFIX. > > Otherwise I think we have no one in our back that forces us to close > > tickets within a particular time frame to meet whatever KPI :-) > > No KPI in my mind! ;-) > > My intention is to free us from collective decisions and let us focus on the > work relevant. > Having a "collective decision to WONTFIX" is exactly what is not happening, > because we already > have enough to do and things that no one bothers about should not take more > time. We should > not spend coordination efforts on things no one wants to work on. > > WONTFIX is rarely an individual decision (aside from the occasional Roy > veto), so issues > simply clutter up and rot on bugzilla. How many of us scan the list of open > bug reports > regularly? I had one look when I joined and thought "okyy, this is some > Augeas stable > and I'm not Hercules!" > > And "honest", from my view, would be to tell reporters: > "look, if no one has worked on this by now, it is most likely that no one > will just > by itself. We are volunteers on our free time. It might not have appeared as > important > to us. We may have missed the implications/seriousness. > If this issue is important to you, here is what we advise you as possible > follow ups: ..." > > If indeed an auto-wontfix seems to harsh for you, how about: > > - add STALE as bug status > - set reports to STALE after n months of inactivity. > - anyone can close STALE issues where we wait for a reply > from the bug submitter. > > Kind Regards, > Stefan > > > > > Regards > > > > Rüdiger > -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat
Re: mod_tls as experimental module?
For me it is a +1, I didn´t say anything because I am not knowledgeable enough. Stefan, if noone answers it is not because of lack of interest but probably because you are several steps ahead :) El jue, 25 nov 2021 a las 11:26, Greg Stein () escribió: > > On Thu, Nov 25, 2021 at 3:42 AM ste...@eissing.org wrote: > >... >> >> In its development, the arrival of mod_tls has caused changes in our server >> core. Not in any way related to Rust itself. But we added the capability to >> have more than one SSL/TLS provider in our server. So people can use >> whatever fits best for the parts they need it. >> >> Future improvements in this area would be done easiest, if mod_tls is a >> module in our source base next to mod_ssl. API dependencies are managed >> better if we release enhanced versions together. I see no benefit for anyone >> involved in making it a separate Apache httpd subproject. It has a home on >> github with all its infrastructure. > > > +1 on including mod_tls (or mod_rustls) in our tree as experimental. That is > *precisely* why we have the experimental label. Historically, the concept of > "subproject" has been ... suboptimal, to put it nicely. > > The changes to the core can/should be made regardless of adoption of this > module. > > Cheers, > -g > -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat
Re: 2.4.49 release report
...And congratulations on a job well done! El dom, 19 sept 2021 a las 11:09, ste...@eissing.org () escribió: > > Compiling the release experience. > > Apache httpd 2.4.49 was released on September 15/16 20201. > There were changes to the release process and some resulting > hickups, but it went through. > > New in the release process were: > - a switch from always incrementing version numbers to > release candidate numberings. > - adaptations of our process to the general apache security > CVE handling from cveprocess.apache.org > > The switch away from incrementing version numbers before > a release voting led in the past to confusions to our users > and extra work on our part. Users, for example, overlooked > CHANGES reported on unreleased versions. CVEs were reported > on versions the users never saw. > > With the new release candidate numbers, we can keep the next > release number stable (whatever source revision will be selected). > We can now communicate "this will be fixed in 2.4.50" and this > will be the version that users get. > > The CVE handling via cveprocess.apache.org is seen as an > overall improvements to the process. However, lacking an > API usable for automation, it still involves manual steps > which we would like to automate more. > > For example, since we cannot download CVE JSON data, release > and "readiness" scripts could not do a full status check. This > led to missing fields being unnoticed during release. As > a result, vulnerability pages became 404s on our site and > we needed manual intervention to get it right. > > We will adjust our processes to have a minimum of manual > steps here and check data completeness before release. We hope > that mid-term, the cveprocess site can offer non-browser access > to features. Maybe apache infra can be of help. This should > be beneficial to all apache projects. > > Then we had some things fumbled by our new release manager (myself): > - the RMs PGP key was kept in the KEYS file, but not registered > in the directories and as its apache committers pgp key. This > led to irritations for folks that verified our tarballs. > - The general announcement emails did not go through for > annou...@apache.org, moderators did not see it. The issue, > as it turned out later, was that the RM was not subscribed to > that list with his apache email id. The list silently dropped > the mails. > - A twitter announcement for @apache_httpd was not generated. > We need to handshake with the holder of that handle on how to > get this out in the future. > > This should serve as a record for things to improve in the next > release - while memory of this one is still fresh. Please add to > this anything I might have missed or additional things you like > us to tackle in the next release. > > Thanks, > Stefan > > -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat
Re: release roll soon?
Indeed it kind of sounds too early to go with OpenSSL 3 yet to consider for a stable release of apache. (Too fresh out of the oven?) El vie., 10 sept. 2021 9:42, ste...@eissing.org escribió: > > > > Am 10.09.2021 um 09:02 schrieb Joe Orton : > > > > On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote: > >> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it > >> would be nice to have r1891138 backported for those wishing to try it > out. > >> What you say? > > > > I'd say it's better to try to get a successful release out, then try to > > get new features in the stable branch. (In fact, I'd be quite happy if > > we had 2.5.x/2.6 released and stopped trying new features in 2.4 :) > > > > That revision is not sufficient, I have a hopefully-complete set of > > OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258 > > Do you want that in 2.4.49? (we can always to a 2.4.50 OpenSSL3 release > shortly afterwards, imo) > > - Stefan
Re: disallow HTTP 0.9 by default?
I know for a fact that this will bring me some headaches at work with a few F5 "ping" checks, but still, to heck with it! +1 El jue, 22 jul 2021 a las 12:39, Daniel Gruno () escribió: > > On 22/07/2021 10.02, Ruediger Pluem wrote: > > > > > > On 7/21/21 10:04 PM, Eric Covener wrote: > >> I was chasing an unrelated thread about close_notify alerts and > >> reminded me -- is it time to change the default for > >> HttpProtocolOptions from Allow0.9 to Require1.0? > >> > >> As the manual says, the requirement was dropped in RFC 7230. It seems > >> like the kind of potential gadget in future desynch/smuggling kind of > >> attacks that shouldn't be on by default today. > > > > +1 for Require1.0 on 2.4. Typically I would not agree because it can break > > existing applications, but are there really setups out > > there that work with HTTP 0.9? I don't believe so. Hence my +1. > > In which case one can just manually switch back to Allow0.9, right? :) > > +1 for Require1.0 > > > > > Regards > > > > Rüdiger > > > -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat
Re: Contribution to Apache HTTPD
Hello and welcome! I'm sure others may give better advice than me since I'm no dev but have you checked http://httpd.apache.org/dev/ yet? There is a lot of info there that I think it is worth checking to get started. Cheers! El jue, 27 may 2021 a las 14:52, Nikita Popov () escribió: > > Hello. I'm a senior C developer working for CloudLinux. I would like > to participate in the HTTPD project. Are there any unassigned tasks > which I can take? And how to proceed with it? Thanks in advance. -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat
Re: Build warnings in 2.4.48
support a version whose latest release was 5 years ago? I recall when running configure seeing a message that looks for OpenSSL>0.9.8 though, but still... El jue., 20 may. 2021 14:57, Rainer Jung escribió: > Am 20.05.2021 um 14:07 schrieb Noel Butler: > > On 20/05/2021 21:19, Rainer Jung wrote: > > > >> Hi there, > >> > >> I saw the following build warnings in 2.4.48: > >> > >> modules/md/md_crypt.c:1382: warning: passing argument 1 of > >> ‘BIO_new_mem_buf’ discards qualifiers from pointer target type > >> [-Wdiscarded-qualifiers] > >> > >> => happens only when building against OpenSSL 1.0.2 (initial release, > >> no letter suffix). > > But in openssl 1.0.2, was that not EOL'd back in late 2019? > > I think until now httpd 2.4.x still officially supports being build with > OpenSSL starting at 0.9.8. > > Best Regards, > > Rainer >
Re: [VOTE] Release httpd-2.4.48
Hello, I tested in RHEL 6.10 and Centos 7.9 along with manually compiled: openssl-1.1.1k expat-2.2.10 apr-1.7.0 apr-util-1.6.1 pcre-8.44 nghttp2-1.43.0 (and to compile this , compiled Python-3.9.5) bonus: tested loading weblogic plugin too (WebLogic Server Plugin version 12.2.1.4.0 ) Results: no issues. +1 for me. El lun, 17 may 2021 a las 23:37, Christophe JAILLET () escribió: > > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.48: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz > sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e > *httpd-2.4.48.tar.gz > sha512: > 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb > *httpd-2.4.48.tar.gz > > The SVN tag is '2.4.48' at r1889975. > > -- > Christophe JAILLET -- Daniel Ferradal HTTPD Project #httpd help at Freenode
Re: Migrate to git?
Hello, Although I am not precisely active now using the repos due to time constraints I would also feel it would be a good move. So FWIW, +1 if I may. El sáb., 5 oct. 2019 a las 22:36, Rich Bowen () escribió: > > With my community development hat on, a big +1 even though I hate Git. > > Shosholoza, > Rich > > > On Sat, Oct 5, 2019, 16:09 Jim Jagielski wrote: >> >> Various PMCs have made their default/de-facto SCM git and have seen an >> increase in contributions and contributors... >> >> Is this something the httpd project should consider? Especially w/ the >> foundation officially supporting Github, it seems like time to have a >> discussion about it, especially as we start thinking about the next 25 years >> of this project :) >> >> Cheers! -- Daniel Ferradal HTTPD Project #httpd help at Freenode
Re: Integration tests running on Docker
+1's! Thanks Luca, looking great! El mié., 25 sept. 2019 a las 12:44, Stefan Eissing () escribió: > > +1 > > I like this a lot. Having a maintained docker setup at hand to run tests in > controlled setups is super good. > > If you get this going for the main test suite, I will be more than happy to > contribute with setups for the mod_h2 and mod_md test suites. Those are part > of the github repros only. > > Cheers, Stefan > > > Am 25.09.2019 um 11:52 schrieb Luca Toscano : > > > > Does the above make sense or it is completely out of scope for our > > project? In the former case I could spend some time on figuring out > > how to create what I proposed above, otherwise I'll stop and drop the > > idea :) > > > -- Daniel Ferradal HTTPD Project #httpd help at Freenode
Re: libcrurl
It seems there may have been certain misunderstanding. Daniel Stenberg published this tweet linking to googler apologizing for the mess in his twitter account: https://twitter.com/bagder/status/1141653215685087232 And the link of the apology: https://news.ycombinator.com/item?id=20228237 El mié., 19 jun. 2019 a las 22:37, Dennis Clarke () escribió: > > On 6/19/19 10:13 AM, Stefan Eissing wrote: > > I just want to mention that I have no plans to adapt the upcoming Chrome > > library libcrurl (see > > https://daniel.haxx.se/blog/2019/06/19/google-to-reimplement-curl-in-libcrurl/ > > ). > > > > And, boy, do I hope they have no plans to do the same with our product > > names. > > > > If one waits long enough we get to see the same behavior repeat itself > over and over and over. Same as the '90s with Microsoft where they would > adopt some defacto standard, extend it well out beyond what the original > standard ever did and then kill the original. However MS were unable to > kill TCP/IP and failed in many ways with many of their little ideas. So > this behavior by Google is just ... silly. At best. Stupid would be a > better word. It may be time to stop using Chrome everywhere and just be > good open source humans and focus on the upstream FireFox which works > just awesome everywhere. My 0.02bt worth. > > > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > GreyBeard and suspenders optional -- Daniel Ferradal HTTPD Project #httpd help at Freenode
Re: Is it interesting to add some filepath checks to apachectl -t ?
but httpd is invoked from it and already checks if document root exists and if does not it does not start, and log directory is always writable unless selinux is involved because those are written with root. So I am not sure what is the gain here. El dom., 2 sept. 2018 13:41, Yann Ylavic escribió: > Hi Stéphane, > > sorry for the delay. > > > > > On 03/07/2018 22:57, Stéphane Blondon wrote: > > > Hello, > > > > > > `apachectl -t` checks the configuration files. The documentation > > > explains it's not complete. > > > It seems paths (for DocumentRoot for example) or the write access for > > > log directory are not checked. (tested with apache v.2.4.25.) > > > > > > Are you interested by such a feature? > > Sure, improvements are always welcome! > > > > If I understand the code properly, the check is done by > > > ap_run_test_config(), called in main.c. However, I don't find the > > > definition of the function in the httpd-2.4.33 archive. > > apr_run_*() functions run the hooks registered with ap_hook_*(), so > you may want to search for "test_config" in the sources and see how > such functions are implemented/hooked (and how hooks mechanism work in > general for that case). > Then possibly add your code in one of the hooks or create a new hook > if that fits better. > > > > > > > I have no idea if I have the skills to implement that in C but I can > > > look for it. > > Thanks! > > Regards, > Yann. >
Re: Host header checking too strict?
This was implemented last year in 2.4.24. Much has happened and just a few strugglers including I, had to deal with it, it seems. I remember I mentioned the CVE at work and that seemed enough for everyone to accept the change and nobody proposes _ in new names since then. IIRC "httpprocotoloptions unsafe" could override this already. Hey Eric, we even had a discussion about this at IRC, remember? :) So what is the option we would offer instead? El mar., 26 jun. 2018 a las 0:19, Roy T. Fielding () escribió: > > On Jun 25, 2018, at 8:57 AM, William A Rowe Jr wrote: > > On Mon, Jun 25, 2018 at 5:31 AM, Joe Orton wrote: >> >> On Fri, Jun 22, 2018 at 05:21:08PM -0400, Eric Covener wrote: >> > After CVE-2016-8743 we only accept hostnames that are valid in DNS, >> > which notably excludes underscores. But it seems like 7230 does not >> > require HTTP Host: to use a DNS registry, and excluding '_' should >> > have broken IDN (punycode) international domain names. >> > >> > Meanwhile I have seen several reports of e.g. departmental servers or >> > proxypreservehost=off-like failures with hostnames w/ underscores. >> > >> > Should we be more tolerant here, or offer an option? >> > >> > [ ] No >> > [X] Just underscores, which seems to come up alot? >> >> Yup, we had Fedora users complain about this as well after 2.6.25, +1 >> for underscores in hostnames allowed by default. > > > I'll concur, I see no problem "violating" the spec in this single respect. > Note that the same is not true of, say, http field names. There, ambiguity > between - and _ due to CGI is an actual problem. > > > The spec is at > > https://tools.ietf.org/html/rfc3986#section-3.2.2 > > and > > > https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#header.host > > Whatever we are doing, underscore is allowed by the spec. DNS is irrelevant > here > because hostnames are not limited to DNS names. > > It is reasonable for us to limit Host to be the set of allowed virtual hosts > we are > willing to match, so we can certainly exclude the weird delimiters, but we > don't want to prevent access to hosts we allow to be configured. > > BTW, note that the second link above is to the current editors' draft of HTTP, > which is being revised now. If anyone wants to reduce the grammar here or > elsewhere, now is the time to make it an issue at > > https://github.com/httpwg/http-core > > Cheers, > > Roy > -- Daniel Ferradal HTTPD Project #httpd help at Freenode
complete changelog missing 2.4.29 changes
Sorry to bug, but I noticed complete changelog is missing 2.4.29 changes. Not something too bothersome but I bet we want to correct this. http://www.apache.org/dist/httpd/CHANGES_2.4 -- Daniel Ferradal HTTPD #httpd help at Freenode
Re: [POLL] Final status of 2.2.x branch
+1 2018-02-22 7:40 GMT+01:00 Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>: > > >> -Ursprüngliche Nachricht- >> Von: Eric Covener [mailto:cove...@gmail.com] >> Gesendet: Mittwoch, 21. Februar 2018 16:51 >> An: Apache HTTP Server Development List <dev@httpd.apache.org> >> Betreff: Re: [POLL] Final status of 2.2.x branch >> >> > In the absence of three active contributors, I volunteer to clean up >> > the website, www dist site and svn in the coming days (see the current >> > state of 2.0.x resources for examples), based on original consensus. >> >> +1 > > +1 > > Regards > > Rüdiger -- Daniel Ferradal HTTPD Docs. I translate to Spanish. #httpd help at Freenode
