Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59
-1 Get an error: Error C2065 'DAV_WALKTYPE_TOLERANT': undeclared identifier mod_dav_fs C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c 1599 Steffen On 2024/04/03 12:26:09 Eric Covener wrote: > Hi all, > > (After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...) > > Please find below the proposed release tarball and signatures: > > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a SHORTENED VOTE to release > this candidate tarball httpd-2.4.59-rc1 as 2.4.59: > [ ] +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: > = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f > = > baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82 > > The SVN candidate source is found at tags/2.4.59-rc1-candidate. >
Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58
For me still -1. > Op 17 okt 2023 om 18:18 heeft Stefan Eissing via dev > het volgende geschreven: > > Just got a reply from a contact that build rc3 on win64 and ran it > successfully. I invited him to participate here, not sure if he will feel > like it. > > I count that as a +1 on win64 unless someone objects. > > Cheers, > Stefan > > >> Am 17.10.2023 um 12:05 schrieb Stefan Eissing via dev : >> >> I am trying to contact another person that builds regularly mod_h2 on >> Windows. >> >>>> Am 17.10.2023 um 11:30 schrieb Steffen : >>> >>> Same error on win64. >>> Yes the reported mod_http2 errors on 32 and 64. >>> Yes, I am not able to tell what is wrong, only I can report the errors. I >>> am not a developer, just building and testing. >>> >>> Regards, Steffen >>> >>>> Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev >>>> het volgende geschreven: >>>> >>>> >>>> >>>>> Am 17.10.2023 um 08:41 schrieb Steffen : >>>>> >>>>> -1 does not build on windows. >>>> >>>> If I understood your reports from yesterday correctly, the situation is >>>> - you can build on win64 >>>> - you get compiler errors on your win32 build >>>> - you are not able to tell us what is wrong >>>> >>>> Correct? >>>> >>>> Cheers, >>>> Stefan >>>> >>>>> >>>>> Steffen >>>>> >>>>>>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev >>>>>>> het volgende geschreven: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> after fixing my merge mistake in rc2 (sorry!), we go again: >>>>>> >>>>>> 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 httpd-2.4.58-rc3 as 2.4.58: >>>>>> [ ] +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: >>>>>> sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6 >>>>>> *httpd-2.4.58-rc3.tar.gz >>>>>> sha512: >>>>>> 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3 >>>>>> *httpd-2.4.58-rc3.tar.gz >>>>>> >>>>>> The SVN candidate source is found at tags/2.4.58-rc3-candidate. >>>>>> >>>>>> Cheers, >>>>>> Stefan >>>>> >>>> >>> >> >
Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58
I think William Rowe can help. He is the guy who helped a lot with windows. > Op 17 okt 2023 om 12:05 heeft Stefan Eissing via dev > het volgende geschreven: > > I am trying to contact another person that builds regularly mod_h2 on > Windows. > >> Am 17.10.2023 um 11:30 schrieb Steffen : >> >> Same error on win64. >> Yes the reported mod_http2 errors on 32 and 64. >> Yes, I am not able to tell what is wrong, only I can report the errors. I am >> not a developer, just building and testing. >> >> Regards, Steffen >> >>>> Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev >>>> het volgende geschreven: >>> >>> >>> >>>> Am 17.10.2023 um 08:41 schrieb Steffen : >>>> >>>> -1 does not build on windows. >>> >>> If I understood your reports from yesterday correctly, the situation is >>> - you can build on win64 >>> - you get compiler errors on your win32 build >>> - you are not able to tell us what is wrong >>> >>> Correct? >>> >>> Cheers, >>> Stefan >>> >>>> >>>> Steffen >>>> >>>>>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev >>>>>> het volgende geschreven: >>>>> >>>>> Hi all, >>>>> >>>>> after fixing my merge mistake in rc2 (sorry!), we go again: >>>>> >>>>> 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 httpd-2.4.58-rc3 as 2.4.58: >>>>> [ ] +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: >>>>> sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6 >>>>> *httpd-2.4.58-rc3.tar.gz >>>>> sha512: >>>>> 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3 >>>>> *httpd-2.4.58-rc3.tar.gz >>>>> >>>>> The SVN candidate source is found at tags/2.4.58-rc3-candidate. >>>>> >>>>> Cheers, >>>>> Stefan >>>> >>> >> >
Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58
Same error on win64. Yes the reported mod_http2 errors on 32 and 64. Yes, I am not able to tell what is wrong, only I can report the errors. I am not a developer, just building and testing. Regards, Steffen > Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev > het volgende geschreven: > > > >> Am 17.10.2023 um 08:41 schrieb Steffen : >> >> -1 does not build on windows. > > If I understood your reports from yesterday correctly, the situation is > - you can build on win64 > - you get compiler errors on your win32 build > - you are not able to tell us what is wrong > > Correct? > > Cheers, > Stefan > >> >> Steffen >> >>>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev >>>> het volgende geschreven: >>> >>> Hi all, >>> >>> after fixing my merge mistake in rc2 (sorry!), we go again: >>> >>> 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 httpd-2.4.58-rc3 as 2.4.58: >>> [ ] +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: >>> sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6 >>> *httpd-2.4.58-rc3.tar.gz >>> sha512: >>> 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3 >>> *httpd-2.4.58-rc3.tar.gz >>> >>> The SVN candidate source is found at tags/2.4.58-rc3-candidate. >>> >>> Cheers, >>> Stefan >> >
Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58
-1 does not build on windows. Steffen > Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev > het volgende geschreven: > > Hi all, > > after fixing my merge mistake in rc2 (sorry!), we go again: > > 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 httpd-2.4.58-rc3 as 2.4.58: > [ ] +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: > sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6 > *httpd-2.4.58-rc3.tar.gz > sha512: > 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3 > *httpd-2.4.58-rc3.tar.gz > > The SVN candidate source is found at tags/2.4.58-rc3-candidate. > > Cheers, > Stefan
Re: svn commit: r1913028 - /httpd/httpd/tags/2.4.58-rc2-candidate/
Yes > Op 16 okt 2023 om 17:02 heeft Ruediger Pluem het volgende > geschreven: > > Windows 64 bit is fine? > > Regards > > Rüdiger > >> On 10/16/23 3:52 PM, SteffenAL wrote: >> No go. All other modules fine, only mod_http2 error. >> >> Recap: >> >> On windows 32: >> >> Generating Code... >> h2_ws.h >> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C2143: syntax >> error: missing ';' before '*' >> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C4430: missing >> type specifier - int assumed. Note: C++ does not support >> default-int >> ... >> ... >> >>> On Monday 16/10/2023 at 15:45, ic...@apache.org wrote: >>> Author: icing >>> Date: Mon Oct 16 13:43:23 2023 >>> New Revision: 1913028 >>> >>> URL: http://svn.apache.org/viewvc?rev=1913028=rev >>> Log: >>> resetting candidate 2.4.58-rc2 >>> >>> Removed: >>> httpd/httpd/tags/2.4.58-rc2-candidate/ >>> >>
Re: build trunk in windows
There is a howto Building Apache and dependencies using CMake at https://www.apachelounge.com/viewtopic.php?t=8609 > Op 24 apr. 2023 om 18:18 heeft jean-frederic clere het > volgende geschreven: > On 4/24/23 13:36, Ruediger Pluem wrote: >> I am not a Windows guy, but I guess the best way to build trunk on Windows >> is to use cmake which is integrated in later versions >> of Visual studio. > > So I need first apr, then apr-util, in apr-util > +++ > -- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the > system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY > OPENSSL_INCLUDE_DIR) > -- Could NOT find EXPAT (missing: EXPAT_LIBRARY EXPAT_INCLUDE_DIR) > CMake Error at CMakeLists.txt:36 (MESSAGE): > APR include directory C:/Program Files (x86)/APR-Util/include is not > correct. > +++ > Are all libraries mandatory? (apr-util needs some and httpd some more). > >> Regards >> Rüdiger >> On 4/24/23 1:05 PM, jean-frederic clere wrote: >>> Hi, >>> I am trying to build httpd on windoze... >>> "The .dsp project files are distributed in Visual Studio 6.0 (98) format. >>> Visual C++ 5.0 (97) will recognize them. Visual Studio >>> 2002 (.NET) and later users must convert Apache.dsw plus the .dsp files >>> into an Apache.sln plus .msproj files. Be sure you >>> reconvert the .msproj file again if its source .dsp file changes! This is >>> really trivial, just open Apache.dsw in the VC++ 7.0 IDE >>> once again and reconvert." >>> Where can I find the VC++ 7.0 IDE to convert the .dsp I can't use? > > -- > Cheers > > Jean-Frederic
Re: [VOTE] Release httpd-2.4.57-rc1 as httpd-2.4.57
Good day, +1 no issues seen on Windows after include ../../server for mod_rewrite test_char.h Steffen > Op 2 apr. 2023 om 18:11 heeft Eric Covener het volgende > geschreven: > 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 httpd-2.4.57-rc1 as 2.4.57: > [ ] +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: > sha256: bc3e7e540b83ec24f9b847c6b4d7148c55b79b27d102e21227eb65f7183d6b45 > *httpd-2.4.57-rc1.tar.gz > sha512: > 730560d4aab3699aa59716bb75858f8432a902aeab3c380b4d3e0f6813e9ae4e278d3b7fdf63a4e94c07b5100933d8684d76f6095f3d60d48ea0f1458c9ed0b4 > *httpd-2.4.57-rc1.tar.gz > > The SVN candidate source is found at tags/2.4.57-rc1-candidate. > > -- > Eric Covener > cove...@gmail.com
Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56
+1 All looks fine on Windows. > Op 5 mrt. 2023 om 22:32 heeft Eric Covener het volgende > geschreven: > > 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 httpd-2.4.56-rc1 as 2.4.56: > [ ] +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: > sha256: db0d4c76007b231fd3ab41b580548dc798ae3844bb7c3d5ce1e4174ca2364698 > *httpd-2.4.56-rc1.tar.gz > sha512: > 68b1e8c3e3436e6947c0ccfeee6fea83254560e4d43bddbc79a4206d804a6dda6662cf5734e0b2f4019ab5c1fff40141a16dd7698e8fe72b7fd343fbebd42724 > *httpd-2.4.56-rc1.tar.gz > > The SVN candidate source is found at tags/2.4.56-rc1-candidate. > > -- > Eric Covener > cove...@gmail.com
Re: [VOTE] Release httpd-2.4.54-rc3 as httpd-2.4.54
+1 All looks fine on Windows. > Op 6 jun. 2022 om 16:25 heeft Stefan Eissing het > volgende geschreven: > > Here we go again! Sorry for the repeats, but that is why we build > candidates, right? > > 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 httpd-2.4.54-rc3 as 2.4.54: > [ ] +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: > sha256: c687b99c446c0ef345e7d86c21a8e15fc074b7d5152c4fe22b0463e2be346ffb > *httpd-2.4.54-rc3.tar.gz > sha512: > e9599df48a73b07b3a11dd44db2c22a671e8a41cdd5021bb434bbcde39d6fc498d165d9b0c4ed2b66a6321d9760b031c1c1c84c23661dbf44c42c52f637ec4dd > *httpd-2.4.54-rc3.tar.gz > > The SVN candidate source is found at tags/2.4.54-rc3-candidate. > > Kind Regards, > Stefan
Re: [VOTE] Release httpd-2.4.54-rc1 as httpd-2.4.54
No apr.h in httpd/include. In APR yes, but not the line you mention. I am going out of town now. Monday again. Maybe Gregg can chime in. > Op 4 jun. 2022 om 13:18 heeft Stefan Eissing het > volgende geschreven: > > How is the definition in your include/apr.h for APR_TCP_NOPUSH_FLAG? On my > macOS it is: > > #define APR_TCP_NOPUSH_FLAG TCP_NOPUSH > > It maybe that the added lines > > #if APR_TCP_NOPUSH_FLAG && !defined(__APPLE__) > > needs a check for Windows too? > >> Am 04.06.2022 um 12:49 schrieb SteffenAL : >> >> r1901201 >
Re: Adding a2md to httpd sources?
Agree no need for it anymore. Ps. You wrote: I have not yet heard any questions or feedback from anyone about it….If I remember correctly, no one was around to make the cmake and Windows builds for it. I had given feedback and was able to build it on windows in 2017. In the beginning some crashes, but Stefan solved. > Op 8 apr. 2022 om 09:14 heeft Stefan Eissing het > volgende geschreven: > > >> Am 07.04.2022 um 13:04 schrieb Rainer Jung : >> >> Hi there, >> >> during my experiments with the nice pytest based test suite against 2.4.x I >> noticed, that many mod_md tests need "a2md". The sources for this >> commandline tool ar in Stefan's GitHub repos for mod_md, but not inside the >> httpd 2.4.x source tree. >> >> I have not really checked, what a2md exactly does, but was wondering, how >> much sense it would make to add it to 2.4.x as another support binary? >> >> From the man page: >> >> The a2md utility can be used to configure and update managed domains with >> the mod_md module for Apache HTTP Server. Managed Domains are virtual hosts >> which automatically obtain and renew TLS certificates from an ACME server. >> >> Is it ready for prime time? Would it interact with a custom build of httpd >> (layout might differ from distros)? What's the expectation? > > Some distros, who package from the github repro, seem to include a2md, but I > have not yet heard any questions or feedback from anyone about it. We > excluded it in the httpd build as, if I remember correctly, no one was around > to make the cmake and Windows builds for it. > > Looking back, I do not see the need to a2md any longer. All can and should be > configured in httpd's config files and information readout is available via > the common status handlers and mod_md's own JSON status handler. > > Kind Regards, > Stefan > >> >> Thanks and regards, >> >> Rainer
Re: svn commit: r1898181 - /httpd/httpd/branches/2.4.x/STATUS
Yep, next week I try PCRE 8.45 with the branche at https://github.com/ylavic/httpd/tree/pcre2_tls On Friday 18/02/2022 at 14:16, Eric Covener wrote: @Steffen Land any chance you can test the pcre8 update on Windows prior to integration in 2.4.x? + https://github.com/apache/httpd/pull/289.diff + (PR: https://github.com/apache/httpd/pull/289) + +1: ylavic, rpluem, covener + ylavic: This backport proposal inludes the PCRE2 backport already accepted, + we can apply this one instead or the original one first and then + this one (I'd have to rebase the github PR first). + ylavic: Can someone test this on Windows too?
Re: [VOTE] Release httpd-2.4.52-rc1 as httpd-2.4.52
+1 for Windows release. Cheers, Steffen > Op 16 dec. 2021 om 15:03 heeft Stefan Eissing het > volgende geschreven: > > 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 httpd-2.4.52-rc1 as 2.4.52: > [ ] +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: > sha256: 296c74a8adde1a8acd6617b21fc3d19719ff4fa39319b2bdbd898aca4d5df97f > *httpd-2.4.52-rc1.tar.gz > sha512: > b9012096d6658f7d34a3c655eac31b39ffd439c11de6f3e6e9f309d55f4186a4fb26134eb97522e416ae8ca10ed008a14e96fa01a3e3105d9e547f72e2dc3bc2 > *httpd-2.4.52-rc1.tar.gz > > The SVN candidate source is found at tags/candidate-2.4.52-rc1. > > Kind Regards, > Stefan
Season Greetings
Happy holidays to all the HTTPD Community developers and users and enjoy the holidays ! We wish for you, your friends 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 2022 as it approaches. For the next weeks, I'll be spending time with my family enjoying Christmas and 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. Steffen
Re: [VOTE] Release httpd-2.4.51-rc1 as httpd-2.4.51
+1 looks ok on Windows On Thursday 07/10/2021 at 15:17, ste...@eissing.org wrote: Hi all, due to found security weaknesses in our 2.4.50 release, the security team feels it is necessary to do a new release on very short notice. We will skip the usual 3 day voting period and close the vote once we feel comfortable with our testing. 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^h^h^h^hhours to release this candidate tarball httpd-2.4.51-rc1 as 2.4.51: [ ] +1: It's not just good, it's hopefully 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: 516128e5acb7311e6e4d32d600664deb0d12e61f *httpd-2.4.51-rc1.tar.gz sha256: c2cedb0b47666bea633b44d5b3a2ebf3c466e0506955fbc3012a5a9b078ca8b4 *httpd-2.4.51-rc1.tar.gz sha512: 507fd2bbc420e8a1f0a90737d253f1aa31000a948f7a840fdd4797a78f7a4f1bd39250b33087485213a3bed4d11221e98eabfaf4ff17c7d0380236f8a52ee157 *httpd-2.4.51-rc1.tar.gz The SVN candidate source is found at tags/candidate-2.4.51-rc1. Kind Regards, Stefan
Re: [VOTE] Release httpd-2.4.50-rc1 as httpd-2.4.50
+1 Windows > Op 1 okt. 2021 om 16:41 heeft ste...@eissing.org het volgende geschreven: > 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 httpd-2.4.50-rc1 as 2.4.50: > [ ] +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: afac1bf6aaa84ea2878c56ed56a49f5efdd7ff73 *httpd-2.4.50-rc1.tar.gz > sha256: feb87f9cc60e02782d795d30cd60a36e918c82fe9a2e7363b0ae28a78be9613a > *httpd-2.4.50-rc1.tar.gz > sha512: > 3b5e06d8428f14bae8173dbb27921496831c7c14c31850d2df0c0d6f69e931bbf0e4e71c6a250b4f5c0d646d1b7da813bbe61711f8a79ab5f80d39dfd176f57c > *httpd-2.4.50-rc1.tar.gz > > The SVN candidate source is found at tags/candidate-2.4.50-rc1. > > Kind Regards, > Stefan
Re: [VOTE] Release httpd-2.4.49-rc1 as httpd-2.4.49
All fine on windows till now. Only waiting for a full-cycle test mod_md. PS. Thanks Stefan, but I hope not a release every month or two/three, cost too much of my cycles/free time. On 10-9-2021 17:23, ste...@eissing.org wrote: 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 httpd-2.4.49-rc1 as 2.4.49: [ ] +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: 525378680b3474ff319b83af76565891f8b98331 *httpd-2.4.49-rc1.tar.gz sha256: 345d3b9b218b1974d1cebd5ae72f6a661d83b52d839310222ff9ec94abb62205 *httpd-2.4.49-rc1.tar.gz sha512: 8efa12f239e1075c0eb8634dde5fa12e73b766a6a8f17882d6bedab8be3e02a1a15be8288413bb6da5be34e58a6e239342cdcb59ebe2d8d88ea4712028b03e5f *httpd-2.4.49-rc1.tar.gz The SVN candidate source is found at tags/candidate-2.4.49-rc1. PS. Some slight change to previous releases: The tarballs carry a prefix '-rc1' but the directory it unpacks to is 'httpd-2.4.49'. This is to make sure that, when you vote on a tarball and it is accepted, that we can release this very thing you voted on. All other things should be the same as in previous releases.
Re: trunk/rc usable with OpenSSL 3.0.0 ?
anticipating also a possible (likely?) OpenSSL 3.0.1, as a common then when releases are done and the test base broadens significantly. +1 for 3.0.1 Steffen On Monday 13/09/2021 at 10:08, ste...@eissing.org wrote: Am 13.09.2021 um 07:23 schrieb Dennis Clarke : ALL : I may receive no reply to this but in general I have been able to build Apache httpd from any release tarball as well as from trunk. When httpd needed to get TLS 1.3 working it was a slam dunk to get that working and it did. However now we have OpenSSL 3.0.0 and it seems that neither the latest RC works nor does trunk. So then ... how to proceed ? The plan is to make a "OpenSSL 3.0" ready release soon after 2.4.49, anticipating also a possible (likely?) OpenSSL 3.0.1, as a common then when releases are done and the test base broadens significantly. That's my understanding. One could argue, that 2.4.49 should do that as well, which would mean delaying it. And there are security relevant changes, not visible in the candidate, that sit on a timeline. My personal opinion is that we need to release every other month and take into it what is ready. The old model of waiting till all stars align - which is nice as a developer - does not work for CVEs. - Stefan -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional PS: trunk 1893292 fails even autoreconf and then more horror follows
vulnerabilities page vs change log
Thanks Christophe for all the work, nice process changes ! See a little one: - at https://httpd.apache.org/security/vulnerabilities_24.html I see under 2.4.48 the CVE 13938 and in the change log under 2.4.47 - in changelog I see under 2.4.48 the CVE 31618 and at the page under 2.4.47 Steffen
Re: [VOTE] Release httpd-2.4.48
Good evening Christophe, +1 for Windows Cheers, Steffen > Op 17 mei 2021 om 23:37 heeft Christophe JAILLET > het volgende geschreven: > > 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
Re: Current branches mod_proxy link error
Thanks MJ, Found that I did not updated my build script for libhttpd.dll Struggling now with the rest. --- Original message --- Subject: Re: Current branches mod_proxy link error From: Marion JAILLET To: , Steffen Land Date: Saturday, 15/05/2021 18:43 Le 15/05/2021 à 16:18, Steffen Land a écrit : Try to build branches revision 1889914 mod_proxy.obj : error LNK2019: unresolved external symbol __imp__ap_ssl_conn_is_ssl@4 referenced in function _ap_proxy_conn_is_https@4 mod_proxy.obj : error LNK2019: unresolved external symbol __imp__ap_ssl_var_lookup@20 referenced in function _ap_proxy_ssl_val@20 Do I miss a (new) include ? Steffen Hi Steffen, this is likely related to r1889793. CJ
Current branches mod_proxy link error
Try to build branches revision 1889914 mod_proxy.obj : error LNK2019: unresolved external symbol __imp__ap_ssl_conn_is_ssl@4 referenced in function _ap_proxy_conn_is_https@4 mod_proxy.obj : error LNK2019: unresolved external symbol __imp__ap_ssl_var_lookup@20 referenced in function _ap_proxy_ssl_val@20 Do I miss a (new) include ? Steffen
Re: [VOTE] Release httpd-2.4.47
+1 for release on Windows. > Op 22 apr. 2021 om 11:25 heeft Christophe JAILLET > het volgende geschreven: > > 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.47: > [ ] +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: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz > sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34 > *httpd-2.4.47.tar.gz > sha512: > de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3 > *httpd-2.4.47.tar.gz > > The SVN tag is '2.4.47' at r1889091. > > -- > Christophe JAILLET
Re: Trunk warnings win64 2-sept-2020
Trunk revision 1881390 02 sept 2020 404 01 sept 2020 405 On Tuesday 01/09/2020 at 16:30, Steffen Land wrote: Trunk revision 1881351 date 1 sept 2020 New layout list, more readable now. 01 sept 2020 405 some solved already by jailletc36 14 May 2020 416 Steffen Warning C4244 util_expr_scan.c1911'=': conversion from '__int64' to 'int', possible loss of data Warning C4267 util_expr_scan.c2349'=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 util_expr_scan.c2383'=': conversion from 'size_t' to 'int', possible loss of data Warning C4244 support\rotatelogs.c185 'return': conversion from '__int64' to 'adjusted_time_t', possible loss of data Warning C4267 support\passwd_common.c 56 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\passwd_common.c 208 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\passwd_common.c 56 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\passwd_common.c 208 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\htcacheclean.c 1171'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\htcacheclean.c 1172'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\htcacheclean.c 1690'=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c1625'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2433'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2436'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2448'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2451'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c839 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4244 support\ab.c1414'function': conversion from 'apr_os_sock_t' to 'int', possible loss of data Warning C4267 support\ab.c1538'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c1625'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2433'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2436'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2448'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 support\ab.c2451'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_script.c334 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_script.c335 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_script.c516 '=': conversion from 'size_t' to 'int', possible loss of data Warning C4244 server\util_script.c851 '=': conversion from '__int64' to 'int', possible loss of data Warning C4267 server\util_regex.c 162 '=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_regex.c 170 '+=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_pcre.c 329 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_pcre.c 331 '=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_expr_eval.c 127 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_expr_eval.c 128 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_expr_eval.c 131 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_expr_eval.c 361 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_expr_eval.c 364 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_expr_eval.c 389 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4090 server\util_expr_eval.c 434 'initializing': different 'const' qualifiers Warning C4267 server\util_expr_eval.c 589 '=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util_expr_eval.c 1463'function': conversion from 'size_t' to 'int', possible loss of data Warning C4267
Trunk warnings win64 1-sept-2020
Trunk revision 1881351 date 1 sept 2020 New layout list, more readable now. 01 sept 2020 405 some solved already by jailletc36 14 May 2020 416 Steffen
Re: Trunk Link error 1 sept 2020
Ah..found it. Was using an old .dsp for libhttpd. Later I post the Win64 warnings On Tuesday 01/09/2020 at 12:21, Steffen Land wrote: I saw that jailletc36 was picking up the warnings ! So to check building trunk from today, revision 1881351 Creating library .\Release\mod_dav_fs.lib and object .\Release\mod_dav_fs.exp repos.obj : error LNK2019: unresolved external symbol __imp_ap_make_etag_ex referenced in function dav_fs_getetag Creating library .\Release\libhttpd.lib and object .\Release\libhttpd.exp core.obj : error LNK2019: unresolved external symbol ap_set_etag_fd referenced in function default_handler All others building fine Steffen
Trunk Link error 1 sept 2020
I saw that jailletc36 was picking up the warnings ! So to check building trunk from today, revision 1881351 Creating library .\Release\mod_dav_fs.lib and object .\Release\mod_dav_fs.exp repos.obj : error LNK2019: unresolved external symbol __imp_ap_make_etag_ex referenced in function dav_fs_getetag Creating library .\Release\libhttpd.lib and object .\Release\libhttpd.exp core.obj : error LNK2019: unresolved external symbol ap_set_etag_fd referenced in function default_handler All others building fine Steffen
Re: [VOTE] Release httpd-2.4.46
WIN32 APR 1.7.0 APR-UTIL 1.6.1 with Analyses Warning C6386 \apr\time\win32\timestr.c 189 Buffer overrun while writing to 'new_format': the writable size is 'max+11' bytes, but 'j' bytes might be written. Warning C26451 \apr\time\win32\time.c 239 Arithmetic overflow: Using operator '+' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '+' to avoid overflow (io.2). Warning C26451 \apr\time\win32\time.c 239 Arithmetic overflow: Using operator '-' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '-' to avoid overflow (io.2). Warning C6248 \apr\threadproc\win32\proc.c320 Setting a SECURITY_DESCRIPTOR's DACL to NULL will result in an unprotected object. Warning C28182 \apr\tables\apr_skiplist.c 516 Dereferencing NULL pointer. 'tmp' contains the same NULL value as 'm->next' did. See line 511 for an earlier location where this can occur Warning C6011 \apr\tables\apr_skiplist.c 570 Dereferencing NULL pointer 'ret'. Warning C6011 \apr\tables\apr_skiplist.c 571 Dereferencing NULL pointer 'li'. See line 570 for an earlier location where this can occur Warning C6011 \apr\tables\apr_hash.c 505 Dereferencing NULL pointer 'new_vals'. Warning C6237 \apr\strings\apr_snprintf.c 819 ( && ) is always zero. is never evaluated and might have side effects. Warning C6285 \apr\strings\apr_snprintf.c 822 ( || ) is always a non-zero constant. Did you intend to use the bitwise-and operator? Warning C6285 \apr\strings\apr_snprintf.c 834 ( || ) is always a non-zero constant. Did you intend to use the bitwise-and operator? Warning C26451 \apr\random\unix\sha2.c 399 Arithmetic overflow: Using operator '<<' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '<<' to avoid overflow (io.2). Warning C6297 \apr\random\unix\sha2.c 399 Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Results might not be an expected value. Warning C26451 \apr\random\unix\sha2.c 406 Arithmetic overflow: Using operator '<<' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '<<' to avoid overflow (io.2). Warning C6297 \apr\random\unix\sha2.c 406 Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Results might not be an expected value. Warning C26451 \apr\random\unix\sha2.c 422 Arithmetic overflow: Using operator '<<' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '<<' to avoid overflow (io.2). Warning C6297 \apr\random\unix\sha2.c 422 Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Results might not be an expected value. Warning C6001 \apr\network_io\win32\sockopt.c 280 Using uninitialized memory 'oobmark'. Warning C6255 \apr\network_io\win32\sendrecv.c118 _alloca indicates failure by raising a stack overflow exception. Consider using _malloca instead. Warning C6287 \apr\network_io\win32\sendrecv.c378 Redundant code: the left and right sub-expressions are identical. Warning C6387 \apr\network_io\win32\sendrecv.c381 'sock->overlapped->hEvent' could be '0': this does not adhere to the specification for the function 'WaitForSingleObject'. Warning C6001 \apr\network_io\unix\inet_pton.c114 Using uninitialized memory 'tmp'. Warning C6001 \apr\mmap\win32\mmap.c 59 Using uninitialized memory '**themmap[BYTE:4]'. Warning C6001 \apr\mmap\win32\mmap.c 59 Using uninitialized memory '*themmap[BYTE:4]'. Warning C28159 \apr\misc\win32\misc.c 32 Consider using 'IsWindows*' instead of 'GetVersionExA'. Reason: Deprecated. Use VerifyVersionInfo* or IsWindows* macros from VersionHelpers. Warning C6011 \apr\misc\win32\misc.c 218 Dereferencing NULL pointer 'sbuf'. Warning C6387 \apr\misc\win32\misc.c 258 'sbuf' could be '0': this does not adhere to the specification for the function 'sprintf'. See line 218 for an earlier location where this can occur Warning C6387 \apr\misc\win32\misc.c 262 'sbuf' could be '0': this does not adhere to the specification for the function 'strlen'. See line 218 for an earlier location where this can occur Warning C6262 \apr\misc\win32\env.c 45 Function uses '16424' bytes of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap. Warning C6262 \apr\misc\win32\env.c 121 Function uses '16412' bytes of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap. Warning C6262 \apr\misc\win32\env.c 163 Function uses '16396' bytes of stack: exceeds
Re: [VOTE] Release httpd-2.4.46
Date in announcement is still : September 21, 2018 > Op 1 aug. 2020 om 16:13 heeft Daniel Ruggeri het > volgende geschreven: > > Hi, all; >Third time is a charm! 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.46: > [ ] +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: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz > sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2 > *httpd-2.4.46.tar.gz > sha512: > 5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15 > *httpd-2.4.46.tar.gz > > The SVN tag is '2.4.46' at r1880505. > > -- > Daniel Ruggeri > >
Re: svn commit: r1880502 - /httpd/httpd/branches/2.4.x/CHANGES
Not agree. Fixes APLOGNO it for all platforms. Only I reported warnings on Windows. Maybe on other platforms it is suppressed. No credit for me, used to it. See also my comment on an other post @dev : Below said : *) mod_proxy_fcgi: Fix build on Windows Not agree, just say what really happened. Better : *) mod_proxy_fcgi: Fix missing macro argument No, not a fix for build on windows only, was/is building fine. APLOGNO is used on all platforms, only a list of warnings from my Windows build was showing a APLOGNO warning. > Op 1 aug. 2020 om 16:06 heeft drugg...@apache.org het volgende geschreven: > > Author: druggeri > Date: Sat Aug 1 14:06:07 2020 > New Revision: 1880502 > > URL: http://svn.apache.org/viewvc?rev=1880502=rev > Log: > Note the one change with 2.4.46 before reroll > > Modified: >httpd/httpd/branches/2.4.x/CHANGES > > Modified: httpd/httpd/branches/2.4.x/CHANGES > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1880502=1880501=1880502=diff > == > --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original) > +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Sat Aug 1 14:06:07 2020 > @@ -1,5 +1,7 @@ > -*- coding: utf-8 -*- > Changes with Apache 2.4.46 > + *) mod_proxy_fcgi: Fix build warnings for Windows platform > + [Eric Covener, Christophe Jaillet] > > Changes with Apache 2.4.45 > > >
Re: Pending fixes or reroll? Was: [RESULT] [VOTE] Release httpd-2.4.45
Below said : *) mod_proxy_fcgi: Fix build on Windows Not agree, just say what really happened. Better : *) mod_proxy_fcgi: Fix missing macro argument No, not a fix for build on windows., was/is building fine. APLOGNO is used on all platforms, only a list of warnings from my Windows build was showing a APLOGNO warning. Begin Message B Group: gmane.comp.apache.devel MsgID: <81701411-6eea-85cb-4f3f-eef114069...@kippdata.de> Since here were lots of "good-to-go, let's roll" one note though: the current CHANGES does not yet a section for 2.4.46, cause normally APLOGNO doesn't get noted on CHANGES. In this case it might be something like *) mod_proxy_fcgi: Fix build on Windows. and credits for Eric (who fixed it on trunk) oand/or Christophe, who backported it. Best regards, Rainer Am 31.07.2020 um 15:36 schrieb Rainer Jung: >Since there wasn't yet any reaction to Daniel's question: Is anybody >right now working on more warnings fixes for Windows? > >The most prominent one (missing APLOGNo number =) >IMHO was already fixed by Christophe in r1880438. Anything else worth >waiting for or are we (is Daniel) good to go for 2.4.46? > >Concerning lua I'd say the fix(es) for 5.4.0 need a bit more testing. > >Regards, > >Rainer > >Am 30.07.2020 um 22:26 schrieb Daniel Ruggeri: >>Hi, all; >>I thank everyone for their testing and quick feedback. While we had >>enough votes and positive feedback, we have some easily fixable warnings >>which have precedence for holding up a release. >> >>To that end, I will close this vote and declare 2.4.45 dead on the >>vine. >> >>I will roll 2.4.46 when we are all buttoned up with the warnings. - End Message -
Re: [VOTE] Release httpd-2.4.45
aplogno warnings on 2.4.40 was a reason to skip. www.apachelounge.com/viewtopic.php?t=8329=aplogno On Thursday 30/07/2020 at 17:10, Jim Jagielski wrote: On Jul 30, 2020, at 5:55 AM, Christophe JAILLET wrote: I wouldn't say it is a show stopper, but I thought that we had a travis job for that. Apparently, it is on trunk only (see r1879370 which is not backported, maybe on purpose) I agree that it's not a show-stopper but it is something that seems easy to fix and, considering that (1) we want to release the best possible version as we can and (2) there is quite a bit of time between releases, I wouldn't be opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.
Re: [VOTE] Release httpd-2.4.45
Thanks for you reply Graham, Indeed apt-util warnings not relevant here. You said below : ... more Windows testing over at APR . For HTTPD enough ? We test HTTPD and APR quite intensive with a few members, even on production level on different configurations. The code is quite good, so we find not that much. I hope you have also concerns about Windows warnings. There is a reason that ms gives code a warning, a sign that code can be better. We had some Windows coders in the community, sadly they left. I shall look around again. Ps. We test also Trunk, issues found I let it know (like in May) and post warnings here. After some commits we test. It is not automated like Travis. > Op 30 jul. 2020 om 11:56 heeft Graham Leggett het volgende > geschreven: > > On 30 Jul 2020, at 11:16, Steffen Land wrote: > >> +1 on Windows. >> >> I am in doubt for a -0 : >> >> Still quite some (more) warnings, now 432, attached Win64 warnings with the >> ones from APR-UTIL. >> >> I think a goal is (must be) that we get warning free on all platforms, now >> it looks bad on Windows. >> >> I reported here a few times. APR is warning free, thanks to Yann. > > Apr-util is a library from the APR project, not httpd, and so warnings from > APR wouldn’t be relevant for an httpd release, or for the httpd project. > > That said there is definite need for more Windows testing over at APR, if you > or members of the Apachelounge community are in the position to contribute > patches this will be very much appreciated. > > Regards, > Graham > — >
Re: [VOTE] Release httpd-2.4.45
HTTPd 2.4.45 Warning C4267 modules\http\http_filters.c 284 '+=': conversion from 'size_t' to 'apr_int32_t', possible loss of data Warning C4267 modules\http\http_filters.c 473 '=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 modules\http\http_filters.c 980 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 modules\http\http_filters.c 1850'return': conversion from 'size_t' to 'long', possible loss of data Warning C4267 modules\http\http_protocol.c942 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 modules\http\http_protocol.c1468'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4312 os\win32\util_win32.c 100 'type cast': conversion from 'int' to 'char *' of greater size Warning C4267 server\config.c 608 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\config.c 609 'initializing': conversion from 'size_t' to 'int', possible loss of data Warning C4311 server\config.c 1474'type cast': pointer truncation from 'void *' to 'long' Warning C4311 server\config.c 1487'type cast': pointer truncation from 'void *' to 'long' Warning C4311 server\config.c 1505'type cast': pointer truncation from 'void *' to 'long' Warning C4311 server\config.c 1516'type cast': pointer truncation from 'void *' to 'long' Warning C4311 server\config.c 1527'type cast': pointer truncation from 'void *' to 'long' Warning C4311 server\config.c 1544'type cast': pointer truncation from 'void *' to 'long' Warning C4018 server\config.c 1745'>=': signed/unsigned mismatch Warning C4311 server\core.c 2999'type cast': pointer truncation from 'void *' to 'long' Warning C4244 server\core.c 4043'return': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\core.c 5277'=': conversion from 'unsigned long' to 'apr_uint16_t', possible loss of data Warning C4018 server\core_filters.c 264 '<': signed/unsigned mismatch Warning C4018 server\core_filters.c 270 '<': signed/unsigned mismatch Warning C4018 server\core_filters.c 295 '<': signed/unsigned mismatch Warning C4267 server\core_filters.c 821 'function': conversion from 'size_t' to 'apr_int32_t', possible loss of data Warning C4244 server\log.c590 'return': conversion from '__int64' to 'int', possible loss of data Warning C4267 server\log.c781 '+=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\log.c1019'+=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\log.c1069'+=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\log.c1551'+=': conversion from 'size_t' to 'int', possible loss of data Warning C4311 server\mpm\winnt\child.c791 'type cast': pointer truncation from 'void *' to 'int' Warning C4312 server\mpm\winnt\child.c1006'type cast': conversion from 'int' to 'void *' of greater size Warning C4090 server\mpm\winnt\mpm_winnt.c364 'function': different 'volatile' qualifiers Warning C4090 server\mpm\winnt\mpm_winnt.c1089'function': different 'volatile' qualifiers Warning C4244 server\protocol.c 643 'return': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\protocol.c 2078'initializing': conversion from '__int64' to 'int', possible loss of data Warning C4267 server\protocol.c 2135'return': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\request.c1468'=': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\scoreboard.c 147 'return': conversion from 'size_t' to 'int', possible loss of data Warning C4267 server\util.c 401 'function': conversion from 'size_t' to 'int', possible loss of data Warning C4244 server\util.c 507 '=': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\util.c 654 '=': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\util.c 686 '=': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\util.c 714 '=': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\util.c 811 'function': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\util.c 821 'function': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\util.c 865 'function': conversion from '__int64' to 'int', possible loss of data Warning C4244 server\util.c 875 'function': conversion from '__int64' to 'int', possible loss of data Warning C4267 server\util.c
Warning free code
Once in a while I post the build warnings in Windows 32/64. Till now this is not really picked up, some times it is solved. Should it not be a goal to get warning free code on all platforms ? What do you think. Steffen
Re: Trunk :: crashes libhttpd.dll (scoreboard.c)
No crashes seen anymore. Thanks!
Regards
Steffen
> Op 20 mei 2020 om 16:38 heeft Ruediger Pluem het volgende
> geschreven:
>
>
>
>>>> On 5/20/20 4:20 PM, Steffen Land wrote:
>> Running production. Get crashes, mostly few times a day:
>> Error log:
>> [mpm_winnt:notice] [pid 11936:tid 744] AH00428: Parent: child process 4980
>> exited with status 3221225477 -- Restarting
>> The thread tried to read from or write to a virtual address for which it
>> does not have the appropriate access.
>
> Thanks for the details. Does the following patch make them go away?
>
> Index: server/scoreboard.c
> ===
> --- server/scoreboard.c(revision 1877790)
> +++ server/scoreboard.c(working copy)
> @@ -381,7 +381,7 @@
> if (pfn_ap_logio_get_last_bytes != NULL) {
> bytes = pfn_ap_logio_get_last_bytes(r->connection);
> }
> -else if (r->method_number == M_GET && r->method[0] == 'H') {
> +else if (r->method_number == M_GET && r->method && r->method[0] == 'H') {
> bytes = 0;
> }
> else {
>
>
> Regards
>
> Rüdiger
Trunk :: crashes libhttpd.dll (scoreboard.c)
Running production. Get crashes, mostly few times a day: Error log: [mpm_winnt:notice] [pid 11936:tid 744] AH00428: Parent: child process 4980 exited with status 3221225477 -- Restarting The thread tried to read from or write to a virtual address for which it does not have the appropriate access. Attached scoreboard.png callstack.png locals.png Steffen
Re: Trunk mod_md MDStoreDir default
“” is fine. Regards, Steffen > Op 18 mei 2020 om 14:05 heeft Joe Orton het volgende > geschreven: > > On Sat, May 16, 2020 at 11:19:58AM +0200, Steffen wrote: >> Current trunk 1877795 Win >> Change with current 2.4.43 : >> MDStoreDire defaults to ServerRoot/logs and not relative to ServerRoot >> Updating 2.4.43 to Trunk : issue my mailserver cannot find certificates. > > As I said in my previous message you need to think about the appropriate > default DEFAULT_REL_STATEDIR for Windows. I set it to logs/ to get your > build working but maybe setting it to "" is better. I don't know, you > should adjust it as you think best. > > http://svn.apache.org/viewvc?view=revision=1877471 > > Regards, Joe
Trunk :: Status Windows
Builds fine on Win32/Win64, on flavor VS16. Revision1877795 This runs fine. Only mod_md stores now his info at an other place, now at logs/md instead of /md. Third party modules need to rebuild and that goes without issues. The modules mod_fcgid, mod_security, mod_watch etc. running fine. Now running at www.apachelounge.com . Steffen
Trunk mod_md MDStoreDir default
Current trunk 1877795 Win Change with current 2.4.43 : MDStoreDire defaults to ServerRoot/logs and not relative to ServerRoot Updating 2.4.43 to Trunk : issue my mailserver cannot find certificates. Steffen
Re: Trunk Win64-warnings
Sorry forget to attach. On 14-5-2020 15:54, Steffen wrote: Trunk r1877740 Win64 builds fine. Attach the warnings, order by module. Steffen SeverityCodeDescription Project FileLineSuppression State Warning C4267 'initializing': conversion from 'size_t' to 'int', possible loss of dataab C:\VC16\Win64\trunk-Win64\support\ab.c 1625 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataab C:\VC16\Win64\trunk-Win64\support\ab.c 2433 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataab C:\VC16\Win64\trunk-Win64\support\ab.c 2436 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataab C:\VC16\Win64\trunk-Win64\support\ab.c 2448 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataab C:\VC16\Win64\trunk-Win64\support\ab.c 2451 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataabs C:\VC16\Win64\trunk-Win64\support\ab.c 839 Warning C4244 'function': conversion from 'apr_os_sock_t' to 'int', possible loss of data abs C:\VC16\Win64\trunk-Win64\support\ab.c 1414 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataabs C:\VC16\Win64\trunk-Win64\support\ab.c 1538 Warning C4267 'initializing': conversion from 'size_t' to 'int', possible loss of dataabs C:\VC16\Win64\trunk-Win64\support\ab.c 1625 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataabs C:\VC16\Win64\trunk-Win64\support\ab.c 2433 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataabs C:\VC16\Win64\trunk-Win64\support\ab.c 2436 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataabs C:\VC16\Win64\trunk-Win64\support\ab.c 2448 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataabs C:\VC16\Win64\trunk-Win64\support\ab.c 2451 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 486 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 488 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 582 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 582 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 735 Warning C4267 'initializing': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 712 Warning C4267 'initializing': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 772 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 905 Warning C4267 'initializing': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 882 Warning C4267 'initializing': conversion from 'size_t' to 'int', possible loss of dataapr_crypto_openssl C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_crypto_openssl.c 942 Warning C4311 'type cast': pointer truncation from 'void *' to 'ULONG' apr_ldap C:\VC16\Win64\trunk-Win64\srclib\apr-util\ldap\apr_ldap_option.c336 Warning C4311 'type cast': pointer truncation from 'void *' to 'ULONG' apr_ldap C:\VC16\Win64\trunk-Win64\srclib\apr-util\ldap\apr_ldap_option.c345 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataaprutil C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_passwd.c 195 Warning C4267 'function': conversion from 'size_t' to 'int', possible loss of dataaprutil C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto\apr_passwd.c 197 Warning C4244 '=': conversion from 'unsigned long' to 'char', possible loss of data aprutil C:\VC16\Win64\trunk-Win64\srclib\apr-util\crypto
Trunk Win64-warnings
Trunk r1877740 Win64 builds fine. Attach the warnings, order by module. Steffen
Re: Trunk does not start :: Failed creating pid file
It starts now: [pid 3984:tid 640] AH00455: Apache/2.5.1-dev (Win32) OpenSSL/1.1.1g configured -- resuming normal operations Warm Regards, Steffen On Monday 11/05/2020 at 12:25, Yann Ylavic wrote: On Mon, May 11, 2020 at 10:24 AM Steffen wrote: Then it did not start: [core:error] [pid 2796:tid 864] (70023)This function has not been implemented on this platform: AH10231: httpd: Failed creating pid file C:/Apache2x/logs/httpd.pid.EnERCx What about the attached patch? Regards; Yann.
Trunk does not start :: Failed creating pid file
Running trunk Windows : cannot start. First with generated httpd conf: [ssl:warn] [pid 1836:tid 636] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later [ssl:warn] [pid 1836:tid 636] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later Then I commented out : #SSLRandomSeed startup builtin #SSLRandomSeed connect builtin Then it did not start: [core:error] [pid 2796:tid 864] (70023)This function has not been implemented on this platform: AH10231: httpd: Failed creating pid file C:/Apache2x/logs/httpd.pid.EnERCx Steffen
Re: Trunk errors
I open a new thread, the build errors reported here are solved. Steffen On Sunday 10/05/2020 at 15:41, Steffen wrote: Running trunk : cannot start. First with generated httpd conf: [ssl:warn] [pid 1836:tid 636] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later [ssl:warn] [pid 1836:tid 636] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later Then I commented out : #SSLRandomSeed startup builtin #SSLRandomSeed connect builtin Then it did not start: [core:error] [pid 2796:tid 864] (70023)This function has not been implemented on this platform: AH10231: httpd: Failed creating pid file C:/Apache2x/logs/httpd.pid.EnERCx Here more work to be done after this VS16 Win64 is tested : VS16 Win64, VC15 Win32/Win64, VC14 Win32/64 and re-build all the third-party modules. And test Win7/10 - Server 2016/2019 Left building issues, with comments from Gregg: Tried revision 1877505. libhttpd : miss in trunk modules\http\http_etag.c. Moved the one from Branches to include, libhttpd builds then, is that ok ? Gregg: Yes to get it to build for now. Question is why isn't it in trunk, modules/http like it is in branches or anywhere (quick look and I can't see it). mod_cache : #include "test_char.h" not found. Copied the generated server/test_char.h to /include, mod_cache builds then, is that ok ? Gregg: Yes to get it to build for now. We may just need to change the location it's generated to, or just point to it's location in the build. If it's not a public header then we do the second option. I'll look at that. Steffen On Sunday 10/05/2020 at 14:36, Yann Ylavic wrote: On Sun, May 10, 2020 at 2:28 PM Steffen wrote: Builds now, Thanks! Thanks for testing, committed in r1877548.
Re: Trunk errors
Running trunk : cannot start. First with generated httpd conf: [ssl:warn] [pid 1836:tid 636] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later [ssl:warn] [pid 1836:tid 636] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later Then I commented out : #SSLRandomSeed startup builtin #SSLRandomSeed connect builtin Then it did not start: [core:error] [pid 2796:tid 864] (70023)This function has not been implemented on this platform: AH10231: httpd: Failed creating pid file C:/Apache2x/logs/httpd.pid.EnERCx Here more work to be done after this VS16 Win64 is tested : VS16 Win64, VC15 Win32/Win64, VC14 Win32/64 and re-build all the third-party modules. And test Win7/10 - Server 2016/2019 Left building issues, with comments from Gregg: Tried revision 1877505. libhttpd : miss in trunk modules\http\http_etag.c. Moved the one from Branches to include, libhttpd builds then, is that ok ? Gregg: Yes to get it to build for now. Question is why isn't it in trunk, modules/http like it is in branches or anywhere (quick look and I can't see it). mod_cache : #include "test_char.h" not found. Copied the generated server/test_char.h to /include, mod_cache builds then, is that ok ? Gregg: Yes to get it to build for now. We may just need to change the location it's generated to, or just point to it's location in the build. If it's not a public header then we do the second option. I'll look at that. Steffen On Sunday 10/05/2020 at 14:36, Yann Ylavic wrote: On Sun, May 10, 2020 at 2:28 PM Steffen wrote: Builds now, Thanks! Thanks for testing, committed in r1877548.
Re: Trunk errors
Builds now, Thanks! On Sunday 10/05/2020 at 14:17, Yann Ylavic wrote: On Sun, May 10, 2020 at 1:30 PM Steffen wrote: Errors, what I did: copied server/core.h to /include You don't need this, my patch missed removing #include "core.h" from "modules/ssl/ssl_engine_io.c", just do that. Cheers, Yann.
Re: Trunk errors
Errors, what I did: copied server/core.h to /include Get: C:\VC16\Win32\httpd-trunk\include\core.h(44,6): error C2373: 'ap_filter_adopt_brigade': redefinition; different type modifiers C:\VC16\Win32\httpd-trunk\include\util_filter.h(631): message : see declaration of 'ap_filter_adopt_brigade' On Sunday 10/05/2020 at 12:10, Yann Ylavic wrote: On Sat, May 9, 2020 at 5:30 PM Steffen wrote: Patch gives errors, but was given me the direction, Thanks! htdbm and htpasswd got it running !! by adding in support/passwd_common.h : #if !defined(WIN32) && !defined(NETWARE) #include "ap_config_auto.h" #endif Your patch not used it is giving other errors, for example ab is not building, get ab.obj : error LNK2001: unresolved external symbol __imp__ap_real_exit_code OK, fair enough. mod_ssl : ssl\ssl_engine_io.c(33,10): fatal error C1083: Cannot open include file: 'core.h' When I copy server/core.h to mod_ssl dir, then error: ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_adopt_brigade referenced in function _char_buffer_insert So on Windows ap_filter_adopt_brigade() needs to be exported to be used by modules, oh well. How about the attached patch then? Regards, Yann.
Re: Trunk errors
Patch gives errors, but was given me the direction, Thanks! htdbm and htpasswd got it running !! by adding in support/passwd_common.h : #if !defined(WIN32) && !defined(NETWARE) #include "ap_config_auto.h" #endif Your patch not used it is giving other errors, for example ab is not building, get ab.obj : error LNK2001: unresolved external symbol __imp__ap_real_exit_code So left issues : mod_ssl : ssl\ssl_engine_io.c(33,10): fatal error C1083: Cannot open include file: 'core.h' When I copy server/core.h to mod_ssl dir, then error: ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_adopt_brigade referenced in function _char_buffer_insert Tried also link with libhttpd.lib, no go. And the ones with Greggs answer. Tried revision 1877505. libhttpd : miss in trunk modules\http\http_etag.c. Moved the one from Branches to include, libhttpd builds then, is that ok ? Gregg: Yes to get it to build for now. Question is why isn't it in trunk, modules/http like it is in branches or anywhere (quick look and I can't see it). mod_cache : #include "test_char.h" not found. Copied the generated server/test_char.h to /include, mod_cache builds then, is that ok ? Gregg: Yes to get it to build for now. We may just need to change the location it's generated to, or just point to it's location in the build. If it's not a public header then we do the second option. I'll look at that. Steffen, trying to be a human Travis :) On Saturday 09/05/2020 at 14:59, Yann Ylavic wrote: On Sat, May 9, 2020 at 1:10 AM Gregg Smith wrote: htdbm and htpasswd : support\passwd_common.h(31,10): fatal error C1083: Cannot open include file: 'ap_config_auto.h': No such file or directory. This gives me a deja vu feeling with what stopped mod_ssl from building in 2.4.42. The winbuilds dsp/mak files generate headers by copying a .h.in file of the same name like ap_config_layout.h.in. This deja vu feeling tells me just feeding it an empty ap_config_auto.h will not do. It might build at least and seem to work but wouldn't be correct. Yann? :) I think we should not #include ap_config_auto.h directly, but ap_config.h instead (which has the necessary #ifnot WINW32..). So how about the attached patch? Regards, Yann.
Re: Trunk errors
Forget mod_ssl error below for now. The first error is: ssl\ssl_engine_io.c(33,10): fatal error C1083: Cannot open include file: 'core.h' When I copy core.h to mod_ssl dir, then I get below error. Tried also link with libhttpd.lib, no go. So first solve the core.h error. On Saturday 09/05/2020 at 01:10, Gregg Smith wrote: Hi Steffen, Assuming your building in the IDE as I know to be your usual; On 5/8/2020 4:59 AM, Steffen wrote: Tried revision 1877505. libhttpd : miss in trunk modules\http\http_etag.c. Moved the one from Branches to include, libhttpd builds then, is that ok ? Yes to get it to build for now. Question is why isn't it in trunk, modules/http like it is in branches or anywhere (quick look and I can't see it). mod_cache : #include "test_char.h" not found. Copied the generated server/test_char.h to /include, mod_cache builds then, is that ok ? Yes to get it to build for now. We may just need to change the location it's generated to, or just point to it's location in the build. If it's not a public header then we do the second option. I'll look at that. htdbm and htpasswd : support\passwd_common.h(31,10): fatal error C1083: Cannot open include file: 'ap_config_auto.h': No such file or directory. This gives me a deja vu feeling with what stopped mod_ssl from building in 2.4.42. The winbuilds dsp/mak files generate headers by copying a .h.in file of the same name like ap_config_layout.h.in. This deja vu feeling tells me just feeding it an empty ap_config_auto.h will not do. It might build at least and seem to work but wouldn't be correct. Yann? :) mod_ssl : ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_adopt_brigade referenced in function _char_buffer_insert AFAIK all ap_* functions are in libhttpd, maybe we're not compiling/linking a new file. It looks to be in util_filters.c and that shows as being compiled/linked to libhttpd. ???Huh??? Looks like all the errors are related to changes in/after 2018. In 2018 I build it without errors. Did not build all yet and only Win32 VS16, so maybe more to come. Let's get it building on one version first, worry about any nuances in the various VC versions second. Gregg
Trunk errors
Tried revision 1877505. libhttpd : miss in trunk modules\http\http_etag.c. Moved the one from Branches to include, libhttpd builds then, is that ok ? mod_cache : #include "test_char.h" not found. Copied the generated server/test_char.h to /include, mod_cache builds then, is that ok ? htdbm and htpasswd : support\passwd_common.h(31,10): fatal error C1083: Cannot open include file: 'ap_config_auto.h': No such file or directory. mod_ssl : ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_adopt_brigade referenced in function _char_buffer_insert Looks like all the errors are related to changes in/after 2018. In 2018 I build it without errors. Did not build all yet and only Win32 VS16, so maybe more to come. Steffen
Re: Trunk DEFAULT_REL_STATEDIR undeclared
Current trunk has not this error anymore, thanks. Later I build the rest. Seen already other errors, I have to do some adjustments here because added includes. For example mod_ssl now needs server/core.h. On Thursday 07/05/2020 at 14:35, Steffen wrote: Please fix in trunk. Then I test it further. You say : whatever. I can act in some way like Travis, even running/testing. I do not know Travis and the goal you want. Some points to consider. - Win32 and Win64 - Monthly updates Windows and Visual Studio - To test ? Is there a test framework for Windows ? - A new module, who add dsp cmake, config etc ? - VC14, VC15 and VS16 at the moment (licenses needed or the community edition). - Perl an NASM needed - awk ? - Build platform/machine : Win7, Win10 or Server 2019 (need license). Also it is not recommended to run VC14, VC15 and VS16 on the same machine. - dsw, dsp files not up to date. - CMake does not build all : config, crypto in APR and more (tried years ago) - To keep/maintain dependencies up to date. - Testing mod_md , firewall must be ok, to communicate with lets-encrypt. Or use the boulder from Stefan - Special OpenSSL (older) versions. Happens that it works on 1.1.1 and not on 1.0.2. — — More... Yes, lot of points to consider. Lot of work. Linux is little easier. Now I build and test quite often when there is a change on branches, with error then I report it on the list or directly tot the author. Op 7 mei 2020 om 13:42 heeft Joe Orton het volgende geschreven: On Thu, May 07, 2020 at 12:55:03PM +0200, Steffen wrote: Tried to build trunk again after 2 years :) server\core.c(5618,58): error C2065: 'DEFAULT_REL_STATEDIR': undeclared identifier That was added in r1842929 (October 2018) and nobody has noticed Windows was broken before now? "Discontinued Integration". Try r1877471 but if Windows MPMs use privilege separation like Unix then the STATEDIR should be a different directory to logs/ so that's not ideal. Can someone who cares about Windows pretty plaseee work out how to get it building in Travis (or appveyor, or whatever)?
Re: Trunk DEFAULT_REL_STATEDIR undeclared
Please fix in trunk. Then I test it further. You say : whatever. I can act in some way like Travis, even running/testing. I do not know Travis and the goal you want. Some points to consider. - Win32 and Win64 - Monthly updates Windows and Visual Studio - To test ? Is there a test framework for Windows ? - A new module, who add dsp cmake, config etc ? - VC14, VC15 and VS16 at the moment (licenses needed or the community edition). - Perl an NASM needed - awk ? - Build platform/machine : Win7, Win10 or Server 2019 (need license). Also it is not recommended to run VC14, VC15 and VS16 on the same machine. - dsw, dsp files not up to date. - CMake does not build all : config, crypto in APR and more (tried years ago) - To keep/maintain dependencies up to date. - Testing mod_md , firewall must be ok, to communicate with lets-encrypt. Or use the boulder from Stefan - Special OpenSSL (older) versions. Happens that it works on 1.1.1 and not on 1.0.2. — — More... Yes, lot of points to consider. Lot of work. Linux is little easier. Now I build and test quite often when there is a change on branches, with error then I report it on the list or directly tot the author. >>>>>> Op 7 mei 2020 om 13:42 heeft Joe Orton het volgende >>>>>> geschreven: >> On Thu, May 07, 2020 at 12:55:03PM +0200, Steffen wrote: >> Tried to build trunk again after 2 years :) >> server\core.c(5618,58): error C2065: 'DEFAULT_REL_STATEDIR': undeclared >> identifier > > That was added in r1842929 (October 2018) and nobody has noticed Windows > was broken before now? "Discontinued Integration". Try r1877471 but if > Windows MPMs use privilege separation like Unix then the STATEDIR should > be a different directory to logs/ so that's not ideal. > > Can someone who cares about Windows pretty plaseee work out how to > get it building in Travis (or appveyor, or whatever)?
Trunk DEFAULT_REL_STATEDIR undeclared
Tried to build trunk again after 2 years :) server\core.c(5618,58): error C2065: 'DEFAULT_REL_STATEDIR': undeclared identifier Steffen
Re: mod_http2 crashes libhttpd.dll in 2.4.43
Tested trunk r1876616. All fine now.
Thanks! for fixing the regression introduced in 2.4.43 GA
Made new Windows binaries of mod_http2 available at AL.
Steffen
On Thursday 16/04/2020 at 19:21, Stefan Eissing wrote:
濫
Fixed in <https://github.com/icing/mod_h2/releases/tag/v1.15.8>
and apache trunk as r1876616 and proposed for backport.
~Stefan
Am 16.04.2020 um 13:51 schrieb Rainer Jung :
If I get this right, there is an element in elts, that has a valid
string key ("H2_STREAM_ID") bis a NULL value (2nd screenshot) and the
condition check in line 527 of the first screen shot checks key
against NULL and empty, but value only against empty but not against
NULL. So the empty check derefences NULL.
Nut sure what the correct fix is:
- make sure the H2_STREAM_IS value is never NULL (but maybe empty)
- add NULL check for the value to the list of checks in 527
- something else
At least the debug info provided by Steffen seems to be a good fit to
the stream id handling changes in the revision in question (but i have
not checked, whether the NULL is new). I think a fix is close :)
Thanks and regards,
Rainer
Am 16.04.2020 um 10:12 schrieb Steffen:
More info.
See CallStack
http://www.apachelounge.com/download/VS16/modules/CallStack.png
and
http://www.apachelounge.com/download/VS16/modules/autos.png
Below we had:
libhttpd!ap_get_server_built+0x5d9
mod_cgi+0x14aa
libhttpd!ap_run_handler+0x35
libhttpd!ap_invoke_handler+0x10f
libhttpd!ap_internal_redirect_handler+0x29a
libhttpd!ap_process_request+0xf
mod_http2+0x188ef
libhttpd!ap_run_process_connection+0x35
mod_http2+0x185ba
mod_http2+0x1c36e
ucrtbase!beginthreadex+0x142
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21
Steffen
On Tuesday 14/04/2020 at 14:13, Eric Covener wrote:
On Tue, Apr 14, 2020 at 8:09 AM Ruediger Pluem
wrote:
On 4/14/20 12:22 PM, Steffen wrote:
This is the post above of backtrace
Thanks.
By accident I've seen that Perl comes with GDB. This might help as
well.
I called httpd.exe from GDB with "-X -e debug" and then called a Perl
URL in the browser.
Excerpt below:
Somehow the below wasn't visible in the original mail.
Thread 100 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4936.0x23e0]
0x7ffbe57515d9 in libhttpd!ap_get_server_built () from
X:\Apps\Apache24\bin\libhttpd.dll
(gdb) bt
#0 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from
X:\Apps\Apache24\bin\libhttpd.dll
#1 0x7ffbe44d14aa in ?? () from
X:\Apps\Apache24\modules\mod_cgi.so
#2 0x7ffbe575ee85 in libhttpd!ap_run_handler () from
X:\Apps\Apache24\bin\libhttpd.dll
#3 0x7ffbe575da7f in libhttpd!ap_invoke_handler () from
X:\Apps\Apache24\bin\libhttpd.dll
#4 0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () from
X:\Apps\Apache24\bin\libhttpd.dll
#5 0x7ffbe575a6af in libhttpd!ap_process_request () from
X:\Apps\Apache24\bin\libhttpd.dll
#6 0x7ffbe22888ef in ?? () from
X:\Apps\Apache24\modules\mod_http2.so
#7 0x7ffbe5761545 in libhttpd!ap_run_process_connection () from
X:\Apps\Apache24\bin\libhttpd.dll
#8 0x7ffbe22885ba in ?? () from
X:\Apps\Apache24\modules\mod_http2.so
#9 0x7ffbe228c36e in ?? () from
X:\Apps\Apache24\modules\mod_http2.so
#10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from
C:\Windows\System32\ucrtbase.dll
#11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from
C:\Windows\System32\kernel32.dll
#12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from
C:\Windows\SYSTEM32\ntdll.dll
#13 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
Unfortunately this stacktrace does not help. One reason might be that
the debugging symbols are missing.
It is very strange that it segfaults in ap_get_server_built, a simple
function just returning a pointer
to a static string constant. Furthermore ap_get_server_built is not
called by mod_cgi.
Can the crash be repeated against a binary with debugging symbols that
are then used to generate the stacktrace?
As I am not a Windows guy, I unfortunately cannot provide any
instructions how to do this.
My experience on windows is that if the PDB's are not 110% right you
will get all kinds of misleading stuff above the first ?? in the
displayed backtrace.
Re: mod_http2 crashes libhttpd.dll in 2.4.43
More info. See CallStack www.apachelounge.com/download/VS16/modules/CallStack.png and www.apachelounge.com/download/VS16/modules/autos.png Below we had: libhttpd!ap_get_server_built+0x5d9 mod_cgi+0x14aa libhttpd!ap_run_handler+0x35 libhttpd!ap_invoke_handler+0x10f libhttpd!ap_internal_redirect_handler+0x29a libhttpd!ap_process_request+0xf mod_http2+0x188ef libhttpd!ap_run_process_connection+0x35 mod_http2+0x185ba mod_http2+0x1c36e ucrtbase!beginthreadex+0x142 kernel32!BaseThreadInitThunk+0x14 ntdll!RtlUserThreadStart+0x21 Steffen On Tuesday 14/04/2020 at 14:13, Eric Covener wrote: On Tue, Apr 14, 2020 at 8:09 AM Ruediger Pluem wrote: On 4/14/20 12:22 PM, Steffen wrote: This is the post above of backtrace Thanks. By accident I've seen that Perl comes with GDB. This might help as well. I called httpd.exe from GDB with "-X -e debug" and then called a Perl URL in the browser. Excerpt below: Somehow the below wasn't visible in the original mail. Thread 100 received signal SIGSEGV, Segmentation fault. [Switching to Thread 4936.0x23e0] 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from X:\Apps\Apache24\bin\libhttpd.dll (gdb) bt #0 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from X:\Apps\Apache24\bin\libhttpd.dll #1 0x7ffbe44d14aa in ?? () from X:\Apps\Apache24\modules\mod_cgi.so #2 0x7ffbe575ee85 in libhttpd!ap_run_handler () from X:\Apps\Apache24\bin\libhttpd.dll #3 0x7ffbe575da7f in libhttpd!ap_invoke_handler () from X:\Apps\Apache24\bin\libhttpd.dll #4 0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () from X:\Apps\Apache24\bin\libhttpd.dll #5 0x7ffbe575a6af in libhttpd!ap_process_request () from X:\Apps\Apache24\bin\libhttpd.dll #6 0x7ffbe22888ef in ?? () from X:\Apps\Apache24\modules\mod_http2.so #7 0x7ffbe5761545 in libhttpd!ap_run_process_connection () from X:\Apps\Apache24\bin\libhttpd.dll #8 0x7ffbe22885ba in ?? () from X:\Apps\Apache24\modules\mod_http2.so #9 0x7ffbe228c36e in ?? () from X:\Apps\Apache24\modules\mod_http2.so #10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from C:\Windows\System32\ucrtbase.dll #11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll #12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll #13 0x in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) Unfortunately this stacktrace does not help. One reason might be that the debugging symbols are missing. It is very strange that it segfaults in ap_get_server_built, a simple function just returning a pointer to a static string constant. Furthermore ap_get_server_built is not called by mod_cgi. Can the crash be repeated against a binary with debugging symbols that are then used to generate the stacktrace? As I am not a Windows guy, I unfortunately cannot provide any instructions how to do this. My experience on windows is that if the PDB's are not 110% right you will get all kinds of misleading stuff above the first ?? in the displayed backtrace.
Re: mod_http2 crashes libhttpd.dll in 2.4.43
All the same. > Op 14 apr. 2020 om 15:46 heeft Stefan Eissing > het volgende geschreven: > > Just to confirm: > > Did you build the r1874909 just like the other releases you tested or did you > use the already built 2.4.43 that crashed originally? > > (I know these should all be the same, but I want to make sure that we are not > looking at some strange side effect.) > > Thanks, Stefan > >> Am 14.04.2020 um 10:13 schrieb Steffen : >> >> >> What do you mean with a clean rebuild ? >> >> r1874909 (1.15.8) is the one from httpd 2.4.43 GA. >> >> >> >>> On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote: >>> In that revision, I see a change in the header file structure. If your >>> build of r1874909 is not clean but somehow was partially using the old >>> header file, things might get misaligned. >>> >>> The other changes in that revision look rather unsuspicious to me. >>> >>> Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to verify? >>> Thanks! >>> >>> Cheers, Stefan >>> >>>> Am 12.04.2020 um 15:57 schrieb mdrmdr : >>>> >>>> With the help of Steffen (he built the Windows binaries for me) I can >>>> report: >>>> >>>> r1861247 - works >>>> r1864126 - works >>>> r1872230 - works >>>> r1873368 - works >>>> r1874286 - works >>>> r1874347 - works >>>> r1874909 (=2.4.43) - fails! >>>> >>>> >>>> >>>> -- >>>> Sent from: >>>> http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html >>> >> >> >
Re: mod_http2 crashes libhttpd.dll in 2.4.43
This is the post above of backtrace By accident I've seen that Perl comes with GDB. This might help as well. I called httpd.exe from GDB with "-X -e debug" and then called a Perl URL in the browser. Excerpt below: Thread 100 received signal SIGSEGV, Segmentation fault. [Switching to Thread 4936.0x23e0] 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from X:\Apps\Apache24\bin\libhttpd.dll (gdb) bt #0 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from X:\Apps\Apache24\bin\libhttpd.dll #1 0x7ffbe44d14aa in ?? () from X:\Apps\Apache24\modules\mod_cgi.so #2 0x7ffbe575ee85 in libhttpd!ap_run_handler () from X:\Apps\Apache24\bin\libhttpd.dll #3 0x7ffbe575da7f in libhttpd!ap_invoke_handler () from X:\Apps\Apache24\bin\libhttpd.dll #4 0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () from X:\Apps\Apache24\bin\libhttpd.dll #5 0x7ffbe575a6af in libhttpd!ap_process_request () from X:\Apps\Apache24\bin\libhttpd.dll #6 0x7ffbe22888ef in ?? () from X:\Apps\Apache24\modules\mod_http2.so #7 0x7ffbe5761545 in libhttpd!ap_run_process_connection () from X:\Apps\Apache24\bin\libhttpd.dll #8 0x7ffbe22885ba in ?? () from X:\Apps\Apache24\modules\mod_http2.so #9 0x7ffbe228c36e in ?? () from X:\Apps\Apache24\modules\mod_http2.so #10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from C:\Windows\System32\ucrtbase.dll #11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll #12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll #13 0x in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) On Tuesday 14/04/2020 at 11:57, Rainer Jung wrote: Hi Steffen, I didn't find a stack either, neither in the mail thread here nor in the one on you forum. Just the error log lines and the clear text for the windows error code. Regards, Rainer Am 14.04.2020 um 11:51 schrieb Steffen: Few posts above there is a GDB back trace. On Tuesday 14/04/2020 at 11:38, Ruediger Pluem wrote: Did I miss it, or isn't there any stacktrace posted from the Windows crashes yet? Regards Rüdiger
Re: mod_http2 crashes libhttpd.dll in 2.4.43
Few posts above there is a GDB back trace. On Tuesday 14/04/2020 at 11:38, Ruediger Pluem wrote: Did I miss it, or isn't there any stacktrace posted from the Windows crashes yet? Regards Rüdiger
Re: mod_http2 crashes libhttpd.dll in 2.4.43
Thanks Rainer, All clean build using the released sources, so a clean build of httpd 2.4.43 GA gives the crash. What header file is Stefan referring ? On Tuesday 14/04/2020 at 11:06, Rainer Jung wrote: Hi Stefen, I think Stefan refers to his "somehow was partially using the old header file". So during the build, there should be no other (from other versions) header files from APR, APR-UTIL oder HTTPD anywhere on the build system where the build process might find and use them. He was assuming, that the build that had the crashes was possibly done on a system, which did not fulfil this requirement. Regards, Rainer Am 14.04.2020 um 10:13 schrieb Steffen: What do you mean with a clean rebuild ? r1874909 (1.15.8) is the one from httpd 2.4.43 GA. On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote: In that revision, I see a change in the header file structure. If your build of r1874909 is not clean but somehow was partially using the old header file, things might get misaligned. The other changes in that revision look rather unsuspicious to me. Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to verify? Thanks! Cheers, Stefan Am 12.04.2020 um 15:57 schrieb mdrmdr : With the help of Steffen (he built the Windows binaries for me) I can report: r1861247 - works r1864126 - works r1872230 - works r1873368 - works r1874286 - works r1874347 - works r1874909 (=2.4.43) - fails! -- Sent from: http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
Re: mod_http2 crashes libhttpd.dll in 2.4.43
Re: mod_http2 crashes libhttpd.dll in 2.4.43
Re: mod_http2 crashes libhttpd.dll in 2.4.43
You advise to try r1861247 r1864126 r1872230 1861247 and 1864126 are already in the working 2.4.41. Begin Message Group: gmane.comp.apache.devel MsgID: >Am 09.04.2020 um 13:17 schrieb mdrmdr : > >I'm the one with the mod_http2 problem... > >The log posted was created by "LogLevel warn http2:trace4" and is complete. >If useful, I can create other logfiles as well. Just tell me the parameters. >Or I can of course try other revisions between .41 and .43... That would bring out the problem the easiest way, I think. Interesting revisions in the 2.4.x branch are: r1861247 r1864126 r1872230 Thanks a lot! - Stefan - End Message -
mod_http2 crashes libhttpd.dll in 2.4.43
Looks like a regression since 2.4.1 www.apachelounge.com/viewtopic.php?p=39012#39012
Re: OpenSSL 1.1.1e New EOF detection breaks session resumption
Thanks Rainer and Rüdiger, When 2.4.43 is GA, I ship it with 1.1.1e. When 1.1.1f is available : test and wait a week to ship it with 2.4.43. Regards, Steffen > Op 27 mrt. 2020 om 20:33 heeft Rainer Jung het > volgende geschreven: > > Am 27.03.2020 um 19:24 schrieb Steffen: >> A discussion started on Apachelounge about an possible issue with OpenSSL >> 1.1.1e ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 ) >> This is the introduced new EOF in 1.1.1e : >> https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a >> Discussion on OpenSSL is at https://github.com/openssl/openssl/issues/11378 >> I dot understand what is going on, but Daniel Stenberg (Curl) states : The >> "poorly-implemented HTTP/1.1 servers" are still out there and are being >> used. How common? Impossible to say. >> OpenSSL has a Patch with description : >> ... possible application breakage caused by a change in behavior introduced >> in 1.1.1e. It affects at least nginx, which logs error messages such as: >> nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error: >> 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while >> keepalive, client: , server: [::]:443 >> So looks that nginx is effected. >> My question is : >> *Is Apache effected ? * Looks not, because till now: Apachelounge has more >> then a week 2.4.41 available with 1.1.1e, which is downloaded over 50.000 >> times and no issues reported like this. > > I did a few hundred test suite runs on 5 platforms for the 2.4.42 release > candidate against OpenSSL 1.1.1e and noticed no special new ssl related > errors. > > So either our tests do not detect it or httpd does not have that problem. > > There will be a new OpenSSL 1.1.1f release next week. > > Regards, > > Rainer
Re: OpenSSL 1.1.1e New EOF detection breaks session resumption
I know. > Op 27 mrt. 2020 om 20:18 heeft William A Rowe Jr het > volgende geschreven: > > > If you want to beat up your server in unusual ways, a good way to do this is > to > run it against https://www.ssllabs.com/ssltest/ from Qualsys with debug > logging > level throughout. I think you'll find we already sanitize all error results. > > > >> On Fri, Mar 27, 2020 at 1:24 PM Steffen wrote: >> >> A discussion started on Apachelounge about an possible issue with OpenSSL >> 1.1.1e ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 ) >> >> This is the introduced new EOF in 1.1.1e : >> https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a >> >> >> Discussion on OpenSSL is at https://github.com/openssl/openssl/issues/11378 >> >> I dot understand what is going on, but Daniel Stenberg (Curl) states : The >> "poorly-implemented HTTP/1.1 servers" are still out there and are being >> used. How common? Impossible to say. >> >> >> OpenSSL has a Patch with description : >> ... possible application breakage caused by a change in behavior introduced >> in 1.1.1e. It affects at least nginx, which logs error messages such as: >> nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error: >> 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while >> keepalive, client: , server: [::]:443 >> >> So looks that nginx is effected. >> >> My question is : >> Is Apache effected ? Looks not, because till now: Apachelounge has more >> then a week 2.4.41 available with 1.1.1e, which is downloaded over 50.000 >> times and no issues reported like this. >> >> Steffen
OpenSSL 1.1.1e New EOF detection breaks session resumption
Re: [VOTE] Release httpd-2.4.43
+1 All fine on Windows. Steffen > Op 26 mrt. 2020 om 15:50 heeft Daniel Ruggeri het > volgende geschreven: > > 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.43: > [ ] +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: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz > sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f > *httpd-2.4.43.tar.gz > sha512: > d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e > *httpd-2.4.43.tar.gz > > The SVN tag is '2.4.43' at r1875715. > > -- > Daniel Ruggeri >
Re: Branches 2.4.12-dev fails mod_ssl
It works. Builds against 1.1.1 and runs with r1874323, Attached the two files, so you can check that the patch is ok ? (With Windows sometimes Patch gets confused) Patch Output mod_ssl.c: patching file modules/ssl/mod_ssl.c Hunk #2 succeeded at 328 (offset -6 lines). patch unexpectedly ends in middle of line Hunk #3 succeeded at 395 with fuzz 1 (offset -9 lines). How to test that the new OPENSSL_init_ssl() API, for OpenSSL = 1.1. is used ? Steffen On Friday 21/02/2020 at 15:38, Yann Ylavic wrote: On Fri, Feb 21, 2020 at 2:39 PM Ruediger Pluem wrote: So we need to have a solution in place that works on Windows and Unix and I believe the solution from Yann does. What about r1874323 ? Using "ap_config.h" would exclude Windows from the new OPENSSL_init_ssl() API, even for OpenSSL >= 1.1. Steffen, would you please try 2.4.x + r1874323 (with OpenSSL 1.1+) and see if it works? Regards, Yann. ssl_private.h Description: Binary data mod_ssl.c Description: Binary data
Re: Branches 2.4.12-dev fails mod_ssl
I run without it. Does that have a draw back ? Steffen > Op 21 feb. 2020 om 13:36 heeft Ruediger Pluem het > volgende geschreven: > > > >> On 02/21/2020 11:14 AM, Yann Ylavic wrote: >> Hi Steffen, >> >>> On Fri, Feb 21, 2020 at 10:23 AM Steffen wrote: >>> >>> Building revision 1874291 failed in Windows. >>> >>> mod_ssl.c(27,10): fatal error C1083: Cannot open include file: >>> 'ap_config_auto.h': No such file or directory >> >> Better if you #include "ap_config.h" instead? >> > > This should work. Care to apply? > BTW: Is there any possibility to have a Travis job run on Windows to catch > these? > > Regards > > Rüdiger
Re: Branches 2.4.12-dev fails mod_ssl
Yesterday it was building fine (before 1874281 ), was no ap_config.. So I removed #include "ap_config_auto.h", builds and runs fine so far. Steffen On Friday 21/02/2020 at 11:14, Yann Ylavic wrote: Hi Steffen, On Fri, Feb 21, 2020 at 10:23 AM Steffen wrote: Building revision 1874291 failed in Windows. mod_ssl.c(27,10): fatal error C1083: Cannot open include file: 'ap_config_auto.h': No such file or directory Better if you #include "ap_config.h" instead? Regards, Yann.
Re: Branches 2.4.12-dev fails mod_ssl
Typo in the subject must be: branches 2.4.x (2.4.42-dev) On Friday 21/02/2020 at 10:23, Steffen wrote: Building revision 1874291 failed in Windows. mod_ssl.c(27,10): fatal error C1083: Cannot open include file: 'ap_config_auto.h': No such file or directory Steffen
Branches 2.4.12-dev fails mod_ssl
Building revision 1874291 failed in Windows. mod_ssl.c(27,10): fatal error C1083: Cannot open include file: 'ap_config_auto.h': No such file or directory Steffen
Re: Time for 2.4.42?
In the branches/2.4/CHANGES there are three entries of mod_md, and one is labeled 2.2.3. Looks better to me just make one combined entry, version number not needed. Now we have the latest mod_md v2.2.7 in branches : Building/Running/Testing all fine. On 12-2-2020 11:17, Steffen wrote: Like to see that mod_md gets a newer version. Running/tested already 2.2.6 (trunk now 2.2.4 and branches 2.2.3) Propose that it is time that mod_md becomes Stable. I do not foresee expanding functions now we have ACMEv2, OCSP stapling, tls-alpn-01, wildcard etc. On 11-2-2020 15:12, Jim Jagielski wrote: Seems like a good time to propose a release... I can RM if desired.
Re: Time for 2.4.42?
Like to see that mod_md gets a newer version. Running/tested already 2.2.6 (trunk now 2.2.4 and branches 2.2.3) Propose that it is time that mod_md becomes Stable. I do not foresee expanding functions now we have ACMEv2, OCSP stapling, tls-alpn-01, wildcard etc. On 11-2-2020 15:12, Jim Jagielski wrote: Seems like a good time to propose a release... I can RM if desired.
Re: Time for 2.4.42?
+1 Good plan. Steffen >> Op 11 feb. 2020 om 15:13 heeft Jim Jagielski het volgende >> geschreven: > Seems like a good time to propose a release... I can RM if desired.
Re: Windows :: mod_md v2.2.3
What is the procedure ? Do we need a separate vote “for stable” topic ? Steffen > Op 13 nov. 2019 om 12:20 heeft Stefan Eissing > het volgende geschreven: > >> Am 13.11.2019 um 11:37 schrieb Steffen : >> >> +1 For me it is time to mark mod_md as "Stable". >> >> I do not foresee expanding functions now we have ACMEv2, OCSP stapling, >> tls-alpn-01, wildcard etc. >> >> The implemented stapling is great, I recommend it over the mod_ssl >> stapling. Also I like the mod_status information. >> >> Tested /branches/v2.2.3 intensive and running in production, no issues seen. > > +1 from me as well. > >> I had some notes at https://bz.apache.org/bugzilla/show_bug.cgi?id=63877 >> They are just to make it a little more user-friendly. > > Still on my list. > >> Thanks! Stephan >> >> Steffen >> >> >> >
Windows :: mod_md v2.2.3
+1 For me it is time to mark mod_md as "Stable". I do not foresee expanding functions now we have ACMEv2, OCSP stapling, tls-alpn-01, wildcard etc. The implemented stapling is great, I recommend it over the mod_ssl stapling. Also I like the mod_status information. Tested /branches/v2.2.3 intensive and running in production, no issues seen. I had some notes at https://bz.apache.org/bugzilla/show_bug.cgi?id=63877 They are just to make it a little more user-friendly. Thanks! Stephan Steffen
Notes mod_md v2.2.0
Mod_md v2.2.0 from trunk did a complete cycle with "renew-window": "86d" and "warn-window": "87d", All looks fine including the stapling renew, but some user notes: The mod_md times are in the log and mod_status in GMT, it should be better the computer/local time zone and not only in GMT, this like mod_status and log does. ===server-status [Sun Oct 20 08:50:46] Activity: Renew in ~4 hours After that ~4hours the renew time has reached but not run yet: ===server-status [Sun Oct 20 16:50] Activity: Ongoing... Maybe better a message that explains what is ongoing ? When the time for the next run has reached, it is renewed : ===server-status [Sun Oct 20 18:56:10] Activity: The certificate for the managed domain has been renewed successfully and can be used from Mon, 21 Oct 2019 15:56:08 GMT on. Next run in ~22 hours It is already valid/usable by restarting Apache and we do not have to wait ~22 hours. It conflicts also with the Valid-From date in the certificate which is a day earlier (the real valid date), that is Sun, 20 Oct 2019 15:56:08 GMT Maybe better to explain more ? After that ~22 hours the Notify command starts my script which restarts Apache, and we have the new certificate running :) In have Logevel info. The only entry from mod_md during the cycle is with the restart : [Mon Oct 21 18:01:54.277303 2019] [md:info] [pid 8656:tid 776] AH10068: apachelounge.com: staged set activated Maybe to consider more log entries for loglevel info. Suggestion log every status change from server-status Activity Also there is a job.json file left in the md/tmp. This file has more info then the copied file to md/domains, namely is contains also at the top: ... "detail": "new certificate successfully saved in domains", "activity": "moving tmp to become new domains" ... "type": "message-installed" I think it is save to delete the md/temp/job.json ? Steffen On 16-10-2019 16:18, Steffen wrote: and Had an issue with v2.1.9-beta : Renew Error :: challenge-mismatch. Looks good now. After upgrading to the trunk version 2.2.0, it is renewing (did not change config and /md folder): server-status Activity: The certificate for the managed domain has been renewed successfully and can be used from Thu, 17 Oct 2019 12:46:49 GMT on. Next run ~22 hours. After a restart got a MDMessageCmd: installed apachelounge.com Closed the issues on github. Steffen On Wednesday 16/10/2019 at 15:37, Stefan Eissing wrote: Thanks! Am 16.10.2019 um 15:26 schrieb Steffen : mod_md.dsp is fine. It builds fine here. Steffen On Wednesday 16/10/2019 at 14:34, Stefan Eissing wrote: Update from github tested mod_md in r1868506. 2 new source files added, you probably need to buildconfig. I added the files to the CMakeLists.txt and modules/md/mod_md.dsp. Hope it works. Would be nice if someone could verify it. Cheers, Stefan
Re: mod_md update
Had an issue with v2.1.9-beta : Renew Error :: challenge-mismatch. Looks good now. After upgrading to the trunk version 2.2.0, it is renewing (did not change config and /md folder): server-status Activity: The certificate for the managed domain has been renewed successfully and can be used from Thu, 17 Oct 2019 12:46:49 GMT on. Next run ~22 hours. After a restart got a MDMessageCmd: installed apachelounge.com Closed the issues on github. Steffen On Wednesday 16/10/2019 at 15:37, Stefan Eissing wrote: Thanks! Am 16.10.2019 um 15:26 schrieb Steffen : mod_md.dsp is fine. It builds fine here. Steffen On Wednesday 16/10/2019 at 14:34, Stefan Eissing wrote: Update from github tested mod_md in r1868506. 2 new source files added, you probably need to buildconfig. I added the files to the CMakeLists.txt and modules/md/mod_md.dsp. Hope it works. Would be nice if someone could verify it. Cheers, Stefan
Re: mod_md update
mod_md.dsp is fine. It builds fine here. Steffen On Wednesday 16/10/2019 at 14:34, Stefan Eissing wrote: Update from github tested mod_md in r1868506. 2 new source files added, you probably need to buildconfig. I added the files to the CMakeLists.txt and modules/md/mod_md.dsp. Hope it works. Would be nice if someone could verify it. Cheers, Stefan
Re: mod_md with no vhosts, sni and ssl only, no go
Thanks! Very good news : build against 2.4.41 a certificate was generated with the domains in MDomain. When no certificate was specified global, the Apache does not start. After adding a valid other certificate a new certificate is created with the domains in MDomain. Then I replaced the certificate (.pem files) with the one generated in the /md folder. So there is a copy step (no problem for me). Ideal should be that it could generate a certificate without first adding adding a certificate. Config: No vhosts. ProtocolsHonorOrder On Protocols h2 http/1.1 acme-tls/1 SSLEngine on MDomain apachelounge.nl www.apachelounge.nl vosadministraties.nl www.vosadministraties.nl land10web.com MDBaseServer on MDPortMap https:443 MDCertificateAgreement accepted MDRenewMode Always MDRenewWindow 85d - Steffen On Thursday 22/08/2019 at 15:58, Stefan Eissing wrote: Hi Steffen, could you check the v2.1.1 I just released? I fixed the recognition of the "amce-tls/1" protocol when using it in the base server. Hope this works for you as well. - Stefan Am 06.08.2019 um 10:48 schrieb Steffen : Forget to attached the log. On 5-8-2019 15:19, Steffen wrote: Thanks, Same, also get again : The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. It is in the protocols directive: ProtocolsHonorOrder On Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl http://www.apachelounge.nl vosadministraties.nl http://www.vosadministraties.nl land10web.com MDBaseServer on MDPortMap https:443 MDCertificateAgreement accepted MDRenewMode Always - Steffen On Monday 05/08/2019 at 14:52, Stefan Eissing wrote: I think mod_md is not particularly suited to server setups without any VirtualHosts. I have at least no tests for this. You can try (with a 2.4.40): # the new, shorter form MDCertificateAgreement accepted # we want the base server to be managed MDBaseServer on # the list of domains, including one from the base server MDomain apachelounge.nl http://www.apachelounge.nl vosadministraties.nlhttp://www.vosadministraties.nl land10web.com # since we have no vhost, we need to say where https requests arrive MDPortMap https:443 # since we have only https, we need to enable the new ACME tls challenge protocol Protocols h2 http/1.1 acme-tls/1 ... - Stefan Am 05.08.2019 um 14:06 schrieb Steffen : I read in the new docu that you can generate a certificate for domains(s) that does not appear in any host. So I did a try to generate one certificate for two domains (in Subject Alternative Name) Configuration SSL only on port 443 No vhosts Listen 443 Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl http://www.apachelounge.nl vosadministraties.nlhttp://www.vosadministraties.nl MDCertificateAgreement https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf MDRenewMode Always ServerName land10web.com SSLEngine on ... ... Apache does not start. It exits with a mod_ssl error, no SSL certificates configured and no other module contributed any See attachment serror1.log When I add to the config a valid certificate SSLCertificateFile conf/land10web.com-chain.pem SSLCertificateKeyFile conf/land10web.com key.pem Then Apache starts but mod_md gives error in the log. See attachment serror2.log See now e.g. : . - server seems not reachable via http: (port 80->80) and reachable via https: (port 443->443) - The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. (it is in the protocols directive). Or what I want is not supported, or I do some wrong. Appreciate some help. - Steffen
Re: [VOTE] Release httpd-2.4.41
+1 No issues/regressions reported by the AL Windows Community. - Steffen On Friday 09/08/2019 at 15:41, Daniel Ruggeri wrote: 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.41: [ ] +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: b713e835aa7cde823a4b7f8e3463164f3d9fe63e *httpd-2.4.41.tar.gz sha256: 3c0f9663240beb0f008acf3b4501c4f339d7467ee345a36c86c46b4d6f3a5461 *httpd-2.4.41.tar.gz -- Daniel Ruggeri
Re: svn commit: r1864701 - /httpd/httpd/branches/2.4.x/STATUS
Are the reported APLOGNO all going to be solved in .41: mod_proxy mod_http2 mod_ssl > Op 8 aug. 2019 om 15:09 heeft Eric Covener het volgende > geschreven: > > CC dev@ I assumed this was safe to just assert. > >> On Thu, Aug 8, 2019 at 9:08 AM wrote: >> >> Author: covener >> Date: Thu Aug 8 13:08:33 2019 >> New Revision: 1864701 >> >> URL: http://svn.apache.org/viewvc?rev=1864701=rev >> Log: >> no votes for APLOGNO commits. >> >> 99% sure but please reply >> >> >> Modified: >>httpd/httpd/branches/2.4.x/STATUS >> >> Modified: httpd/httpd/branches/2.4.x/STATUS >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1864701=1864700=1864701=diff >> == >> --- httpd/httpd/branches/2.4.x/STATUS (original) >> +++ httpd/httpd/branches/2.4.x/STATUS Thu Aug 8 13:08:33 2019 >> @@ -122,6 +122,7 @@ CURRENT RELEASE NOTES: >> . documentation >> . non-Unix build >> . non-Unix, single-platform code >> +. routine APLOGNO() backports >> >> RELEASE SHOWSTOPPERS: >> >> >> > > > -- > Eric Covener > cove...@gmail.com
Re: mod_md with no vhosts, sni and ssl only, no go
Forget to attached the log.
On 5-8-2019 15:19, Steffen wrote:
Thanks,
Same, also get again :
The https: challenge 'tls-alpn-01' is disabled because the Protocols
configuration does not include the 'acme-tls/1' protocol.
It is in the protocols directive:
ProtocolsHonorOrder On
Protocols h2 http/1.1 acme-tls/1
MDomain apachelounge.nl www.apachelounge.nl vosadministraties.nl
www.vosadministraties.nl land10web.com
MDBaseServer on
MDPortMap https:443
MDCertificateAgreement accepted
MDRenewMode Always
- Steffen
On Monday 05/08/2019 at 14:52, Stefan Eissing wrote:
I think mod_md is not particularly suited to server setups without
any VirtualHosts. I have at least no tests for this.
You can try (with a 2.4.40):
# the new, shorter form
MDCertificateAgreement accepted
# we want the base server to be managed
MDBaseServer on
# the list of domains, including one from the base server
MDomain apachelounge.nl http://www.apachelounge.nl
vosadministraties.nlhttp://www.vosadministraties.nl land10web.com
# since we have no vhost, we need to say where https requests arrive
MDPortMap https:443
# since we have only https, we need to enable the new ACME tls
challenge protocol
Protocols h2 http/1.1 acme-tls/1
...
- Stefan
Am 05.08.2019 um 14:06 schrieb Steffen :
I read in the new docu that you can generate a certificate for
domains(s) that does not appear in any host.
So I did a try to generate one certificate for two domains (in
Subject Alternative Name)
Configuration
SSL only on port 443
No vhosts
Listen 443
Protocols h2 http/1.1 acme-tls/1
MDomain apachelounge.nl http://www.apachelounge.nl
vosadministraties.nlhttp://www.vosadministraties.nl
MDCertificateAgreement
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
MDRenewMode Always
ServerName land10web.com
SSLEngine on
...
...
Apache does not start. It exits with a mod_ssl error, no SSL
certificates configured and no other module contributed any
See attachment serror1.log
When I add to the config a valid certificate
SSLCertificateFile conf/land10web.com-chain.pem
SSLCertificateKeyFile conf/land10web.com key.pem
Then Apache starts but mod_md gives error in the log.
See attachment serror2.log
See now e.g. : .
- server seems not reachable via http: (port 80->80) and reachable
via https: (port 443->443)
- The https: challenge 'tls-alpn-01' is disabled because the
Protocols configuration does not include the 'acme-tls/1' protocol.
(it is in the protocols directive).
Or what I want is not supported, or I do some wrong. Appreciate some
help.
- Steffen
[Mon Aug 05 15:02:19.083575 2019] [md:trace1] [pid 13868:tid 212]
mod_md.c(734): AH10070: initializing post config dry run
[Mon Aug 05 15:02:19.083575 2019] [md:trace2] [pid 13868:tid 212]
md_crypt.c(146): initializing RAND
[Mon Aug 05 15:02:19.083575 2019] [md:trace1] [pid 13868:tid 212]
mod_md.c(341): AH10037: server seems not reachable via http: (port 80->80) and
reachable via https: (port 443->443)
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] mod_md.c(386):
AH: apachelounge.nl: no https server_rec found for apachelounge.nl
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] mod_md.c(386):
AH: apachelounge.nl: no https server_rec found for www.apachelounge.nl
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] mod_md.c(386):
AH: apachelounge.nl: no https server_rec found for vosadministraties.nl
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] mod_md.c(386):
AH: apachelounge.nl: no https server_rec found for www.vosadministraties.nl
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] mod_md.c(386):
AH: apachelounge.nl: no https server_rec found for land10web.com
[Mon Aug 05 15:02:19.083575 2019] [md:trace1] [pid 13868:tid 212]
mod_md.c(618): AH10039: Completed MD[apachelounge.nl, CA=(null), Proto=ACME,
Agreement=accepted, renew-mode=2 renew_window=85d, warn_window=10%
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] md_reg.c(747):
sync: found 0 mds in store
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] md_reg.c(228):
md{apachelounge.nl}: incomplete, credentials not all there
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212] md_reg.c(895):
new md apachelounge.nl added
[Mon Aug 05 15:02:19.083575 2019] [md:trace2] [pid 13868:tid 212]
md_reg.c(1092): (OS 3)The system cannot find the path specified. :
apachelounge.nl: nothing staged
[Mon Aug 05 15:02:19.083575 2019] [md:debug] [pid 13868:tid 212]
md_reg.c(1123): (OS 3)The system cannot find the path specified. :
apachelounge.nl: load done
[Mon Aug 05 15:02:19.083575 2019] [ssl:info] [pid 13868:tid 212] AH01887: Init:
Initializing (virtual) servers for SSL
[Mon Aug 05 15:02:19.083575 2019] [ssl:info] [pid 13868:tid 212] AH01914:
Configuring server www.land10web.com:443 for SSL protocol
[Mon Aug 05 15:02:19
Re: mod_md with no vhosts, sni and ssl only, no go
Thanks, Same, also get again : The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. It is in the protocols directive: ProtocolsHonorOrder On Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl www.apachelounge.nl vosadministraties.nl www.vosadministraties.nl land10web.com MDBaseServer on MDPortMap https:443 MDCertificateAgreement accepted MDRenewMode Always - Steffen On Monday 05/08/2019 at 14:52, Stefan Eissing wrote: I think mod_md is not particularly suited to server setups without any VirtualHosts. I have at least no tests for this. You can try (with a 2.4.40): # the new, shorter form MDCertificateAgreement accepted # we want the base server to be managed MDBaseServer on # the list of domains, including one from the base server MDomain apachelounge.nl http://www.apachelounge.nl vosadministraties.nlhttp://www.vosadministraties.nl land10web.com # since we have no vhost, we need to say where https requests arrive MDPortMap https:443 # since we have only https, we need to enable the new ACME tls challenge protocol Protocols h2 http/1.1 acme-tls/1 ... - Stefan Am 05.08.2019 um 14:06 schrieb Steffen : I read in the new docu that you can generate a certificate for domains(s) that does not appear in any host. So I did a try to generate one certificate for two domains (in Subject Alternative Name) Configuration SSL only on port 443 No vhosts Listen 443 Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl http://www.apachelounge.nl vosadministraties.nlhttp://www.vosadministraties.nl MDCertificateAgreement https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf MDRenewMode Always ServerName land10web.com SSLEngine on ... ... Apache does not start. It exits with a mod_ssl error, no SSL certificates configured and no other module contributed any See attachment serror1.log When I add to the config a valid certificate SSLCertificateFile conf/land10web.com-chain.pem SSLCertificateKeyFile conf/land10web.com key.pem Then Apache starts but mod_md gives error in the log. See attachment serror2.log See now e.g. : . - server seems not reachable via http: (port 80->80) and reachable via https: (port 443->443) - The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. (it is in the protocols directive). Or what I want is not supported, or I do some wrong. Appreciate some help. - Steffen
mod_md with no vhosts, sni and ssl only, no go
I read in the new docu that you can generate a certificate for domains(s) that does not appear in any host. So I did a try to generate one certificate for two domains (in Subject Alternative Name) Configuration SSL only on port 443 No vhosts Listen 443 Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl www.apachelounge.nl vosadministraties.nl www.vosadministraties.nl MDCertificateAgreement https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf MDRenewMode Always ServerName land10web.com SSLEngine on ... ... Apache does not start. It exits with a mod_ssl error, no SSL certificates configured and no other module contributed any See attachment serror1.log When I add to the config a valid certificate SSLCertificateFile conf/land10web.com-chain.pem SSLCertificateKeyFile conf/land10web.com key.pem Then Apache starts but mod_md gives error in the log. See attachment serror2.log See now e.g. : . - server seems not reachable via http: (port 80->80) and reachable via https: (port 443->443) - The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. (it is in the protocols directive). Or what I want is not supported, or I do some wrong. Appreciate some help. - Steffen
Re: [VOTE] Release httpd-2.4.40
Runs all fine, no issues seen sofar. +1 On Saturday 03/08/2019 at 15:51, Daniel Ruggeri wrote: 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.40: [ ] +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: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz sha256: 451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0 *httpd-2.4.40.tar.gz -- Daniel Ruggeri
Re: svn commit: r1864425 - in/httpd/httpd/trunk/modules/md:md_acme_acct.c md_acme_order.c md_crypt.cmd_time.c md_version.h mod_md.cmod_md_config.c mod_md_drive.c
75): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(803,58): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(825,30): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(855,65): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(1210,62): warning C4244: 'function': conversion from '__int64' to 'unsigned int', possible loss of data ssl\ssl_engine_io.c(1534,23): warning C4018: '<': signed/unsigned mismatch ssl\ssl_engine_io.c(1552,38): warning C4267: '-=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(1896,19): warning C4018: '>': signed/unsigned mismatch ssl\ssl_engine_kernel.c(2610,19): warning C4018: '<': signed/unsigned mismatch ssl\ssl_engine_log.c(128,25): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_pphrase.c(473,26): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_pphrase.c(565,30): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_pphrase.c(604,26): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_rand.c(154,30): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_rand.c(162,17): warning C4267: 'return': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_vars.c(668,39): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_util_ssl.c(141,28): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_util_stapling.c(159,57): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' On Monday 05/08/2019 at 13:10, Rainer Jung wrote: Hi Steffen, it would help, it you could copy in the warnings here. Not everyone uses a compiler setup that shows these warnings. Being explicit about observations lowers the bar for us to fix them. Thanks and regards, Rainer Am 05.08.2019 um 12:54 schrieb Steffen: Also APLOGNO warnings in: mod_proxy mod_http2 mod_ssl On Monday 05/08/2019 at 12:32, Rainer Jung wrote: Hi Stefan, Am 05.08.2019 um 12:27 schrieb ic...@apache.org: Author: icing Date: Mon Aug 5 10:27:34 2019 New Revision: 1864425 URL: http://svn.apache.org/viewvc?rev=1864425=rev Log: * mod_md: fix compiler warnings thanks for that. Some trailing spaces have now slipped in though (judged on the diff). Did you notice this report by Gregg: mod_md.c(386): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(391): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(601): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(608): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(659): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(702): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(912): warning C4003: not enough actual parameters for macro 'APLOGNO' Thanks and regards, Rainer
Re: svn commit: r1864425 - in /httpd/httpd/trunk/modules/md:md_acme_acct.c md_acme_order.c md_crypt.c md_time.c md_version.h mod_md.cmod_md_config.c mod_md_drive.c
Also APLOGNO warnings in: mod_proxy mod_http2 mod_ssl On Monday 05/08/2019 at 12:32, Rainer Jung wrote: Hi Stefan, Am 05.08.2019 um 12:27 schrieb ic...@apache.org: Author: icing Date: Mon Aug 5 10:27:34 2019 New Revision: 1864425 URL: http://svn.apache.org/viewvc?rev=1864425=rev Log: * mod_md: fix compiler warnings thanks for that. Some trailing spaces have now slipped in though (judged on the diff). Did you notice this report by Gregg: mod_md.c(386): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(391): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(601): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(608): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(659): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(702): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(912): warning C4003: not enough actual parameters for macro 'APLOGNO' Thanks and regards, Rainer
changelog mod_md ssl patch
Changelog says mod_ssl needs patch. That is a typo or where is the patch. *) mod_md: new features - supports the ACMEv2 protocol - new challenge method 'tls-alpn-01' implemented, needs mod_ssl patch to become available
Re: http2 backport
Build branches revision 1864213 (today). Runs http2 v1.15.4 on W -Steffen On Thursday 01/08/2019 at 09:23, Stefan Eissing wrote: This is my last plea for someone to vote for the HTTP/2 proposed backport. It would be great if you could review that changes or even try to compile them. But honestly, I am just after a vote. - Stefan
Some stats Apache Lounge
Some of you asked for it, so here we go, just for your info. Wow.. in 2018 the traffic of http://www.apachelounge.com was 17.798 TB This is excluded the WAMPs which are containing Apache Lounge binaries, Gregg reported me : XAMPP, BitNami, WampServer, EasyPHP, IZ-Wamp, Ampps, VertrigoServ, WampDeveloper and more. There must be a lot users of our Binaries, we have to guess how many. And do not forget the binaries from our friend Apachehaus, Windows is a platform which is important for the HTTPD project. Users of Windows platform has grown a lot the last years. And I see that more and more companies using our builds. More then 15 years ago I started with Apache Windows binaries (for that time Sambar). I am thrilled to see so many folks making now use of Apache Lounge Binaries and visiting the Apache Lounge Forum. For many of users the forum is a big valuable archive and thanks to the moderators Mario, Gregg and Tom we keeping the quality level. It is really rewarding to see that the effort we put into the Apache Server is appreciated so much. I want to ask you all: Please help us (Gregg, Mario, Tom, Steffen) with the forum, we have not all the knowledge. And keep in mind that nowadays the forum members are not only Windows users but also other platforms like Linux (most directives are platform independent). Keep in mind, the fact is that quite some users out there are not willing to use our users maillist. A reason is that they find a list permanent and spreaded/archived all over internet. A forum you can delete/change your post within a minute and Google etc. re-index often. See you in the forum to help us, Steffen
Re: [VOTE] Release httpd-2.4.38
+1 Build and tested by Apache Lounge Community Windows Win32/Win64 VC11, VC14 VC15, no trouble reports received. Build with by Microsoft supported convert with the in the tarball included dsw/dsp/makefile files. Build with dependencies: - httpd.exe with OPENSSL_Applink and VC14/15 SupportedOS Manifest - nghttp2 1.36.0 - jansson 2.12 - VC15 openssl 1.1.1a, VC14/11 1.0.2q - curl 7.63.0 WinSSL - apr 1.6.5 - apr-util 1.6.1 with Crypto OpenSSL enabled - apr-iconv 1.2.2 - zlib 1.2.11 - brotli 1.0.7 - pcre 8.42 with JIT, SUPPORT_UTF, SUPPORT_UNICODE_PROPERTIES, REBUILD_CHARTABLES - libxml2 2.9.9 - lua 5.2.4 with LUA_COMPAT_ALL - expat 2.2.6 Not seen new warnings over I reported here before. Cheers, Steffen On Thursday 17/01/2019 at 19:49, Daniel Ruggeri wrote: 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.38: [ ] +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: 6ee19a7b936a6ddbbf81b313c4a8b38bf232b40e *httpd-2.4.38.tar.gz sha256: 38d0b73aa313c28065bf58faf64cec12bf7c7d5196146107df2ad07541aa26a6 *httpd-2.4.38.tar.gz -- Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.28
See no tarball at https://dist.apache.org/repos/dist/dev/httpd/ Also in SVN and Subject of theis mauk I see 2.4.28 instead of 2.4.28 On 17-01-19 18:13, Daniel Ruggeri wrote: 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.28: [ ] +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: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 *httpd-2.4.28.tar.gz
Re: [VOTE] Release httpd-2.4.28
Sorry make the same mistake :) See no tarball at https://dist.apache.org/repos/dist/dev/httpd/ I was used to see the URL http://httpd.apache.org/dev/dist/ also there no tarball Also in SVN and Subject of this mail I see 2.4.28 instead of 2.4.38 On 17-01-19 18:24, Jim Jagielski wrote: Shouldn't this be 2.4.38?? On Jan 17, 2019, at 12:13 PM, Daniel Ruggeri wrote: 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.28: [ ] +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: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 *httpd-2.4.28.tar.gz -- Daniel Ruggeri
Apache Win crashes with mod_md with no Applink sim
I changed the subject ( was Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c) William A Rowe Jr wrote: ...mod_php or other weirdness What do you mean by weirdness ? Google translate shows it can be a bad word. I never talked about a mod-php, as pointed before applink is needed for phpXapache2_4.dll. The Microsoft PHP team asked (and still) me to use the sim, they had some serious reports. Quote PHP team: Yeah, now it turned out, that the SPKI functionality in PHP requires this shim to be in. The functionality is available since PHP 5.6 and coupled with Apache could result an unexpected process exit without the solution mentioned in the OpenSSL FAQ compiled in. I mentioned already back in 2016, so I cannot stipulate enough to you that applink sim is needed. Of course no reports on AL, because applink is in for years. An other example: mod_md errors when no applink sim, in the past AL has also reports of the issue. Just tested again with AH httpd-2.4.35 with Openssl 110i, and no surprise, is does not even start, see below. Replacing the httpd.exe from AL with the sim all fine. Looks like a module using ssl needs the sim. And for abs.exe, leave it in, does not harm and we are on the save side. Regards, Steffen run with AH: httpd-2.4.35-o110i-x64-vc14.zip, Apache does not start [Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] mod_md.c(1012): AH10070: initializing post config dry run [Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] mod_md.c(357): AH10037: server seems not reachable via http: (port 80->80) and reachable via https: (port 443->443) [Mon Oct 15 15:05:01.883939 2018] [md:warn] [pid 6796:tid 464] AH10045: No VirtualHost matches Managed Domain vosadministraties.nl [Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] mod_md.c(389): AH10039: Completed MD[vosadministraties.nl, CA=https://acme-v01.api.letsencrypt.org/directory, Proto=ACME, Agreement=(null), Drive=1, renew=2134720512] [Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] md_reg.c(706): sync: found 1 mds in store [Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] md_reg.c(793): apachelounge.nl: update renew norm=2109194240, window=2134720512 OPENSSL_Uplink(7FFB73F334C8,08): no OPENSSL_Applink On 17-10-18 18:17, William A Rowe Jr wrote: On Fri, Oct 12, 2018 at 4:54 PM William A Rowe Jr <mailto:wr...@rowe-clan.net>> wrote: Great, I'll proceed with changing ab.c to remove the hack, since it is unneeded when ab.c is compiled by the same toolchain as libcrypto.dll, isn't available in non-openssl distributions, and was deprecated in 1.1.1 again. Note, I'll only proceed to remove the hack from trunk. I see no reason to make any cosmetic or build changes to 2.4.x branch. Any fallout to the trunk change will be uncovered in alpha/beta review. If we are unwilling to support the feature in httpd.exe we should not do so for ab.c either. (IIRC there was some subtle lingering BIO usage from mod_ssl for the initialization phase.) Anyone who wants to enable the applink stub logic for mod_php or other weirdness is welcome to patch that either by 1) adding the applink.c to abs.exe and/or httpd.exe linkage, or the main() source file can #include that "". Anyone interested can proceed to patch both and provision applink.c when working with OpenSSL 1.1.1, so I don't need to raise a ticket at that project. Regression #7396 <https://github.com/openssl/openssl/issues/7396> was fixed with 92ebf6c <https://github.com/openssl/openssl/commit/92ebf6c4c21ff4b41ba1fd69af74b2039e138114> for OpenSSL 1.1.1a. The oversight of dropping applink.c appears to have been unintended. Thanks to you all for your review and re-evaluation of the past and current situations with OpenSSL.
Re: [VOTE] Release httpd-2.4.35
Maybe I overlook it: I miss in the change log: http://svn.apache.org/viewvc?view=revision=date=1840546 Looks it needs special windows test attention. Description: Merge r1801144, r1801148, r1801456 from trunk: mpm_winnt: Factor out a helper function to parse the type of an accept filter and use an appropriate enum for it. This makes the code in winnt_accept() a bit easier to follow. As a minor side effect, it also fixes a small bug where the "unrecognized AcceptFilter '%s'" log entry would always contain "none" instead of the actually unrecognized kind of the accept filter. mpm_winnt: Fix typo in the logged message in winnt_get_connection(). mpm_winnt: Following up on r1801144, use the new accept_filter_e enum values in a couple of missed places in winnt_accept(). Submitted by: kotkov Reviewed by: jailletc36, jim (via inspection), wrowe On 18-09-18 02:56, Daniel Ruggeri wrote: 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.35: [ ] +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: md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c *httpd-2.4.35.tar.gz
Re: [VOTE] Release httpd-2.4.35
All fine here on Windows. > Op 18 sep. 2018 om 02:56 heeft Daniel Ruggeri het > volgende geschreven: > > 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.35: > [ ] +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: > md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz > sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz > sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c > *httpd-2.4.35.tar.gz > > -- > Daniel Ruggeri >
