from:"Daniel"

Re: Can't find definition of ap_run_child_stopping

2023-08-22 Thread Daniel Gruno


On 2023-08-23 07:02, Emile Cormier wrote:

Hi Everyone,

I'm studying parts of httpd to help me in the development of a TCP 
server I'm working on. In particular, I'm looking at how httpd handles 
socket errors.


Anyway, I've stumbled upon an ap_run_child_stopping function call within 
the signal_threads function 
(https://github.com/apache/httpd/blob/a834e62ebf6279ce9e35193151aec809f7f58df1/server/mpm/worker/worker.c#L332C5-L332C26 ).


For the life of me, I cannot seem to find the definition of 
ap_run_child_stopping. I've downloaded the source tarballs for httpd, 
APR, and APR-util, and performed a find-in-files to no avail (with no 
file extension filtering).


If someone can point me to where ap_run_child_stopping is defined, it 
would be greatly appreciated.


AIUI, it's from a macro, so you won't find it easily in the code (it 
does not exist by that name in there, as it is combined from ap_run_* 
and child_stopping). Maybe 
https://github.com/apache/httpd/blob/a834e62ebf6279ce9e35193151aec809f7f58df1/include/ap_hooks.h#L84 
will help?




Cheers,
Emile Cormier

Re: [VOTE CLOSED] Switch read/write repository from Subversion to Git

2023-05-11 Thread Daniel Gruno

On 2023-05-11 13:45, Ruediger Pluem wrote:

On 5/11/23 5:40 PM, Daniel Gruno wrote:

On 2023-05-11 10:33, Ruediger Pluem wrote:

On 5/11/23 12:27 PM, Ruediger Pluem wrote:

On 5/4/23 10:34 AM, Ruediger Pluem wrote:

This is a formal vote on whether we should move our read/write repository from
Subversion to Git.
This means that our latest read/write repository will be no longer available
via svn.apache.org. It
will be available via Git at https://gitbox.apache.org/repos/asf/httpd-site.git
and https://github.com/apache/httpd.git.
Github also offers the possibility to use a Subversion client:
https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients

[ ]: Move the read/write repository from Subversion to Git and leverage the
features of Github (for now Actions and PR).
[ ]: Move the read/write repository from Subversion to Git, but I don't want to
work with Github and I will only work with
what gitbox.apache.org offers.
[ ]: Leave everything as is.

After being open for one week I call this vote closed. Thank you for everyone
who participated in this vote by
either voting directly or voicing opinions on the subject.

Result:

Total number of votes: 16

[ ]: Move the read/write repository from Subversion to Git and leverage the
features of Github (for now Actions and PR).

13 votes by jorton, ylavic, icing, gbechis, covener, humbedooh, rjung,
jailletc36, jblond, gstein, rpluem, jim, fielding.

[ ]: Move the read/write repository from Subversion to Git, but I don't want to
work with Github and I will only work with
what gitbox.apache.org offers.

0 votes.

[ ]: Leave everything as is.

3 votes by manu, ivan, minfrin.

Now that the vote is closed in favor of moving to Git what are the next steps?
Do we need to open an INFRA ticket to get this done?
Who will open it?

Anyone on the PMC can open such a ticket, there is a canonical thread here to
prove consensus.

Is there any preferred point of time to do this?

It depends...
The read-only mirror that we currently have _can_ be repurposed as a r/w
repository, which means the cutover could be quite
instant. I'd advise that folks make the necessary checks and ensure that the
git repo has accurate history and contents
(specifically the current state of trunk/2.4/etc). When we are satisfied, we
can ask Infra to switch the mirror over to a
read/write mode. Subversion history will be preserved, and the subversion dir
will be locked to read-only (assuming we don't have
other resources there we need to write to still).

The bigger task comes after that, as all the source links in docs, our web site
etc, will need to be updated, but that can happen
after the fact.

Thanks for the process. What about the commit mails currently going to
c...@httpd.apache.org? Do we need to do something to ensure
that git commits get send there in the future?

All notification schemes and other repository settings for git repos are
handled via the .asf.yaml metadata file[1] and is entirely self-serve.
Each repository we have can have individual settings.

[1] https://s.apache.org/asfyaml

Regards

Rüdiger

Re: [VOTE CLOSED] Switch read/write repository from Subversion to Git

2023-05-11 Thread Daniel Gruno

On 2023-05-11 10:33, Ruediger Pluem wrote:

On 5/11/23 12:27 PM, Ruediger Pluem wrote:

On 5/4/23 10:34 AM, Ruediger Pluem wrote:

After being open for one week I call this vote closed. Thank you for everyone
who participated in this vote by
either voting directly or voicing opinions on the subject.

Result:

Total number of votes: 16

[ ]: Move the read/write repository from Subversion to Git and leverage the
features of Github (for now Actions and PR).

13 votes by jorton, ylavic, icing, gbechis, covener, humbedooh, rjung,
jailletc36, jblond, gstein, rpluem, jim, fielding.

[ ]: Move the read/write repository from Subversion to Git, but I don't want to
work with Github and I will only work with
what gitbox.apache.org offers.

0 votes.

[ ]: Leave everything as is.

3 votes by manu, ivan, minfrin.

Now that the vote is closed in favor of moving to Git what are the next steps?
Do we need to open an INFRA ticket to get this done?
Who will open it?

Anyone on the PMC can open such a ticket, there is a canonical thread
here to prove consensus.

Is there any preferred point of time to do this?

It depends...
The read-only mirror that we currently have _can_ be repurposed as a r/w
repository, which means the cutover could be quite instant. I'd advise
that folks make the necessary checks and ensure that the git repo has
accurate history and contents (specifically the current state of
trunk/2.4/etc). When we are satisfied, we can ask Infra to switch the
mirror over to a read/write mode. Subversion history will be preserved,
and the subversion dir will be locked to read-only (assuming we don't
have other resources there we need to write to still).

The bigger task comes after that, as all the source links in docs, our
web site etc, will need to be updated, but that can happen after the fact.

Regards

Rüdiger

Re: [VOTE] Switch read/write repository from Subversion to Git

2023-05-08 Thread Daniel Gruno

On 2023-05-08 16:18, Christopher Schultz wrote:

Graham,

On 5/8/23 05:29, Graham Leggett via dev wrote:

On 04 May 2023, at 09:34, Ruediger Pluem wrote:

Github also offers the possibility to use a Subversion client:
https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients

[ ]: Move the read/write repository from Subversion to Git and
leverage the features of Github (for now Actions and PR).
[ ]: Move the read/write repository from Subversion to Git, but I
don't want to work with Github and I will only work with

what gitbox.apache.org offers.
[X]: Leave everything as is.

I would rather see proper SVN integration with Github. This is a vote
of no confidence in our own projects.

I don't see it as an anti-NIH vote or anything like that.

git simply has a bunch of superior features, behaviors, etc. that
Subversion simply will never have, regardless of any commitment of their
development team. Sure, the svn team could replicate git, but since git
already exists, why not use it?

-chris

My 2 cents on this is it's not Git vs Subversion here - it's GitHub vs
SubversionHub, and the latter doesn't exist. Given how the majority of
users use GitHub, it really isn't about how Git in any way is
better/worse than Subversion, it's 99% about the tools that GitHub offer.

VHS vs BetaMax anyone? :)

Re: [VOTE] Switch read/write repository from Subversion to Git

2023-05-04 Thread Daniel Gruno


On 2023-05-04 07:48, Eric Covener wrote:

[x]: Move the read/write repository from Subversion to Git and
leverage the features of Github (for now Actions and PR).



[x]: Move the read/write repository from Subversion to Git and
 leverage the features of Github (for now Actions and PR).

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

2023-05-03 Thread Daniel Gruno


On 2023-05-03 14:12, Eric Covener wrote:

On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev
 wrote:


On 25 Apr 2023, at 07:45, Ruediger Pluem  wrote:

2. Switching from Subversion to Git is mostly an emotional problem for me. We 
have some closer ties to Subversion by some
   overlaps in the community and via mod_dav_svn we kind of partially eat our 
very own dogfood here by using Subversion.
   We wouldn't do that any longer with Git. Plus it would switch another of our 
development tools from an Apache license to GPL.
   Apart from technical aspects that this change would create we should check 
if all of the current active committers are fine
   using Github. While people could use Gitbox and thus avoid Github when we 
use Git I would like us to leverage the features of
   Github when we would do this switch and I think this cannot be done if 
active committers would have issues with Github.


+1.

I've always found the fight about “must be git” to be really tedious. Github 
supports both git and svn to this day, and people are free to use what they 
prefer by using the interface they are most familiar with.

While Github is popular today, this is only because the goals of the owners of 
Github are presently aligned with our goals. As Twitter has taught us, goals 
change at any time and without warning.


Hi Graham -- it's a little unclear to me where this would put you
"vote" wise about moving to read/write Git.

Anyone else with a stake have an opinion? It has been since about 2019
since we last discussed it here, I am hoping people have warmed up to
it.


I am +1 on moving. I do not have any particular love for git or svn on 
their own, and I realize that the proposed change does make outside 
contributions and certain workflows easier.

Re: [httpd-site] branch main updated: publishing release httpd-2.4.55

2023-01-17 Thread Daniel Gruno


On 2023-01-17 18:59, Eric Covener wrote:

Something is still subtly wrong here, the 2.4.55 section only has 1
entry instead of 3.
Will chat about it on #httpd on ASF slack.


We have addressed the immediate issue, and the page is rendering as 
intended, but we'll have to talk to the folks in charge of the cve 
process about the proper schema here, as ours may be a bit ... off.


TBD



On Tue, Jan 17, 2023 at 12:17 PM Daniel Gruno  wrote:


I have patched the system to deal with the inconsistencies, but those
should really be looked at. There seems to be a mix of "timeline"
entries that are not consistent throughout the dir (even when accounting
for v4.0 vs v5.0 CVE data), and those were throwing spanners into the
build process.

The CVE page should be back now, however.

On 2023-01-17 17:46, Eric Covener wrote:

Humbedooh is helping.

Note that the SVN repo is dead content, real content is in
g...@github.com:/apache/httpd-site

On Tue, Jan 17, 2023 at 11:39 AM Eric Covener  wrote:


I think it's 
https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/cvejsontohtml.py
it hasn't been updated for the V5 JSON format, I misinterpreted Mark's mail.

I will try to make it tolerant of both.

On Tue, Jan 17, 2023 at 11:29 AM Ruediger Pluem  wrote:




On 1/17/23 5:16 PM, cove...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

covener pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/httpd-site.git


The following commit(s) were added to refs/heads/main by this push:
   new 83e7062  publishing release httpd-2.4.55
83e7062 is described below

commit 83e7062476d4a912f20ab275137b9587d441fdf0
Author: Eric Covener 
AuthorDate: Tue Jan 17 11:16:01 2023 -0500

  publishing release httpd-2.4.55
---
   content/doap.rdf  |   4 +-
   content/download.md   |  24 +++
   content/index.md  |   6 +-
   content/security/json/CVE-2006-20001.json | 110 
++
   content/security/json/CVE-2022-36760.json | 103 
   content/security/json/CVE-2022-37436.json |  88 


Looks like something went wrong as 
https://httpd.apache.org/security/vulnerabilities_24.html now results in a 404.

Regards

Rüdiger




--
Eric Covener
cove...@gmail.com

Re: [httpd-site] branch main updated: publishing release httpd-2.4.55

2023-01-17 Thread Daniel Gruno

I have patched the system to deal with the inconsistencies, but those 
should really be looked at. There seems to be a mix of "timeline" 
entries that are not consistent throughout the dir (even when accounting 
for v4.0 vs v5.0 CVE data), and those were throwing spanners into the 
build process.


The CVE page should be back now, however.

On 2023-01-17 17:46, Eric Covener wrote:

Humbedooh is helping.

Note that the SVN repo is dead content, real content is in
g...@github.com:/apache/httpd-site

On Tue, Jan 17, 2023 at 11:39 AM Eric Covener  wrote:


I think it's 
https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/cvejsontohtml.py
it hasn't been updated for the V5 JSON format, I misinterpreted Mark's mail.

I will try to make it tolerant of both.

On Tue, Jan 17, 2023 at 11:29 AM Ruediger Pluem  wrote:




On 1/17/23 5:16 PM, cove...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

covener pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/httpd-site.git


The following commit(s) were added to refs/heads/main by this push:
  new 83e7062  publishing release httpd-2.4.55
83e7062 is described below

commit 83e7062476d4a912f20ab275137b9587d441fdf0
Author: Eric Covener 
AuthorDate: Tue Jan 17 11:16:01 2023 -0500

 publishing release httpd-2.4.55
---
  content/doap.rdf  |   4 +-
  content/download.md   |  24 +++
  content/index.md  |   6 +-
  content/security/json/CVE-2006-20001.json | 110 ++
  content/security/json/CVE-2022-36760.json | 103 
  content/security/json/CVE-2022-37436.json |  88 


Looks like something went wrong as 
https://httpd.apache.org/security/vulnerabilities_24.html now results in a 404.

Regards

Rüdiger




--
Eric Covener
cove...@gmail.com

Re: [VOTE] Release httpd-2.4.53-rc2 as httpd-2.4.53

2022-03-11 Thread Daniel Gruno


On 11/03/2022 13.14, Stefan Eissing wrote:

While the 72 hours have not all passed yet, the votes so far are positive.


72 hours is a guideline, not a hard rule. If you wanna do it in 48 or 
24, that's fine as long as there's a valid reason.




Given that no -1 vote will come, I call for a vote on the release time:

[ ] +1: release it later today, it needs to get out!
[ ] +0: do not really care
[ ] -1: better do it Monday, Admins have a life, too, you know?




Am 09.03.2022 um 17:19 schrieb Stefan Eissing :

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.53-rc2 as 2.4.53:
[ ] +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: 7a045e8e653aaf931f9667f3a7e1943bd81306bf908f316465f737a854d10c16 
*httpd-2.4.53-rc2.tar.gz
sha512: 
2fa1918aa44eb9984c0a294f416102088ed6874213391acd8c434b062603eb2a9ec64f7b1a218d4fe283d74fc9956650297d0b4dda57dcd8533b075a7321ec78
 *httpd-2.4.53-rc2.tar.gz

The SVN candidate source is found at tags/2.4.53-rc2-candidate.

Kind Regards,
Stefan

Re: opinion poll, stale issues

2022-02-18 Thread Daniel Ferradal

Based on little my experience, an issue I reported in 2015 was
recently fixed in 2.4.50 6 years later, so not sure if WONTFIX is the
ideal thing for something who didn't get attention, as it may get
attention later,  I agree with the "it is rude '' opinion to mark
something not attented as WONTFIX. STALE though sounds ok and
truthful.

Cheers

El jue, 17 feb 2022 a las 10:58, Stefan Eissing () escribió:
>
>
>
> > Am 16.02.2022 um 14:12 schrieb Ruediger Pluem :
> >
> >
> >
> > On 2/16/22 10:32 AM, Stefan Eissing wrote:
> >> How about we close stale issues on our bugzilla after a year without 
> >> changes with
> >>
> >> WONTFIX
> >> We are sorry, but no one found the interest/time to work on this.
> >>
> >> ideally as an automated job somewhere?
> >
> > What is the issue with keeping them open? I guess this would be the most 
> > honest choice. If we decide deliberately that we don't
> > want to do something we can close it explicitly as WONTFIX.
> > Otherwise I think we have no one in our back that forces us to close 
> > tickets within a particular time frame to meet whatever KPI :-)
>
> No KPI in my mind! ;-)
>
> My intention is to free us from collective decisions and let us focus on the 
> work relevant.
> Having a "collective decision to WONTFIX" is exactly what is not happening, 
> because we already
> have enough to do and things that no one bothers about should not take more 
> time. We should
> not spend coordination efforts on things no one wants to work on.
>
> WONTFIX is rarely an individual decision (aside from the occasional Roy 
> veto), so issues
> simply clutter up and rot on bugzilla. How many of us scan the list of open 
> bug reports
> regularly? I had one look when I joined and thought "okyy, this is some 
> Augeas stable
> and I'm not Hercules!"
>
> And "honest", from my view, would be to tell reporters:
> "look, if no one has worked on this by now, it is most likely that no one 
> will just
> by itself. We are volunteers on our free time. It might not have appeared as 
> important
> to us. We may have missed the implications/seriousness.
> If this issue is important to you, here is what we advise you as possible 
> follow ups: ..."
>
> If indeed an auto-wontfix seems to harsh for you, how about:
>
> - add STALE as bug status
> - set reports to STALE after n months of inactivity.
> - anyone can close STALE issues where we wait for a reply
>   from the bug submitter.
>
> Kind Regards,
> Stefan
>
> >
> > Regards
> >
> > Rüdiger
>


-- 
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat

Re: Remove link to "complete list of mirrors" from download page

2022-01-22 Thread Daniel Gruno


I've culled what is no longer relevant here.

With regards,
Daniel.

On 22/01/2022 19.37, Daniel Sahlberg wrote:

Hi,

Due to ASF's migration to the new Download Content Delivery System, the 
"complete list of mirrors" ([1]) no longer exists om www.apache.org.


Can someone with commit access update the download script (I'm assuming 
it would actually be download.mdtext) and remove this link?


Do note that the download script provided by ASF is, depending on your 
location, adding the https://dlcdn.apache.org both to the [http] and to 
the [backup] lists and thus, for some users, the Other mirrors display 
the same site as both the primary and the backup download site. I have 
tried to work around this but didn't manage (see for example [3]). I'm 
not sure if Infra consider it to be a bug that dlcdn is in both lists [4].


Kind regards,

Daniel Sahlberg

(Hangaround in the Subversion project).


[1] https://www.apache.org/mirrors/

[2] https://httpd.apache.org/download.cgi

[3] https://lists.apache.org/thread/0hrtsyc1bj7nv8qqj8jl0gnn49l0fhwz

[4] https://lists.apache.org/thread/ws49tpb8dqzpk2652qsf4ndwoq5y5v3c 
(require authentication)

Remove link to "complete list of mirrors" from download page

2022-01-22 Thread Daniel Sahlberg


Hi,

Due to ASF's migration to the new Download Content Delivery System, the 
"complete list of mirrors" ([1]) no longer exists om www.apache.org.


Can someone with commit access update the download script (I'm assuming 
it would actually be download.mdtext) and remove this link?


Do note that the download script provided by ASF is, depending on your 
location, adding the https://dlcdn.apache.org both to the [http] and to 
the [backup] lists and thus, for some users, the Other mirrors display 
the same site as both the primary and the backup download site. I have 
tried to work around this but didn't manage (see for example [3]). I'm 
not sure if Infra consider it to be a bug that dlcdn is in both lists [4].


Kind regards,

Daniel Sahlberg

(Hangaround in the Subversion project).


[1] https://www.apache.org/mirrors/

[2] https://httpd.apache.org/download.cgi

[3] https://lists.apache.org/thread/0hrtsyc1bj7nv8qqj8jl0gnn49l0fhwz

[4] https://lists.apache.org/thread/ws49tpb8dqzpk2652qsf4ndwoq5y5v3c 
(require authentication)

Re: mod_tls as experimental module?

2021-11-25 Thread Daniel Ferradal

For me it is a +1,

I didn´t say anything because I am not knowledgeable enough.

Stefan, if noone answers it is not because of lack of interest but
probably because you are several steps ahead :)

El jue, 25 nov 2021 a las 11:26, Greg Stein () escribió:
>
> On Thu, Nov 25, 2021 at 3:42 AM ste...@eissing.org  wrote:
> >...
>>
>> In its development, the arrival of mod_tls has caused changes in our server 
>> core. Not in any way related to Rust itself. But we added the capability to 
>> have more than one SSL/TLS provider in our server. So people can use 
>> whatever fits best for the parts they need it.
>>
>> Future improvements in this area would be done easiest, if mod_tls is a 
>> module in our source base next to mod_ssl. API dependencies are managed 
>> better if we release enhanced versions together. I see no benefit for anyone 
>> involved in making it a separate Apache httpd subproject. It has a home on 
>> github with all its infrastructure.
>
>
> +1 on including mod_tls (or mod_rustls) in our tree as experimental. That is 
> *precisely* why we have the experimental label. Historically, the concept of 
> "subproject" has been ... suboptimal, to put it nicely.
>
> The changes to the core can/should be made regardless of adoption of this 
> module.
>
> Cheers,
> -g
>


-- 
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat

Re: Download page appears to be broken

2021-10-31 Thread Daniel Gruno


On 31/10/2021 19.11, Craig Russell wrote:

Hi,

I'm looking at the download page https://httpd.apache.org/download


It's https://httpd.apache.org/download.cgi - the other page is the template.



I tried the link  httpd-2.4.51.tar.bz2 
https://httpd.apache.org/%5Bpreferred%5D/httpd/httpd-2.4.51.tar.bz2
but it gives me a 404.

This may be due to the recent change to use dldcn instead of mirrors...

Or my browser might be acting up.

Best regards,
Craig

Craig L Russell
c...@apache.org

Re: 2.4.49 release report

2021-09-19 Thread Daniel Ferradal

...And congratulations on a job well done!

El dom, 19 sept 2021 a las 11:09, ste...@eissing.org
() escribió:
>
> Compiling the release experience.
>
> Apache httpd 2.4.49 was released on September 15/16 20201.
> There were changes to the release process and some resulting
> hickups, but it went through.
>
> New in the release process were:
> - a switch from always incrementing version numbers to
>   release candidate numberings.
> - adaptations of our process to the general apache security
>   CVE handling from cveprocess.apache.org
>
> The switch away from incrementing version numbers before
> a release voting led in the past to confusions to our users
> and extra work on our part. Users, for example, overlooked
> CHANGES reported on unreleased versions. CVEs were reported
> on versions the users never saw.
>
> With the new release candidate numbers, we can keep the next
> release number stable (whatever source revision will be selected).
> We can now communicate "this will be fixed in 2.4.50" and this
> will be the version that users get.
>
> The CVE handling via cveprocess.apache.org is seen as an
> overall improvements to the process. However, lacking an
> API usable for automation, it still involves manual steps
> which we would like to automate more.
>
> For example, since we cannot download CVE JSON data, release
> and "readiness" scripts could not do a full status check. This
> led to missing fields being unnoticed during release. As
> a result, vulnerability pages became 404s on our site and
> we needed manual intervention to get it right.
>
> We will adjust our processes to have a minimum of manual
> steps here and check data completeness before release. We hope
> that mid-term, the cveprocess site can offer non-browser access
> to features. Maybe apache infra can be of help. This should
> be beneficial to all apache projects.
>
> Then we had some things fumbled by our new release manager (myself):
> - the RMs PGP key was kept in the KEYS file, but not registered
>   in the directories and as its apache committers pgp key. This
>   led to irritations for folks that verified our tarballs.
> - The general announcement emails did not go through for
>   annou...@apache.org, moderators did not see it. The issue,
>   as it turned out later, was that the RM was not subscribed to
>   that list with his apache email id. The list silently dropped
>   the mails.
> - A twitter announcement for @apache_httpd was not generated.
>   We need to handshake with the holder of that handle on how to
>   get this out in the future.
>
> This should serve as a record for things to improve in the next
> release - while memory of this one is still fresh. Please add to
> this anything I might have missed or additional things you like
> us to tackle in the next release.
>
> Thanks,
> Stefan
>
>


-- 
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat

Re: sending announcement mail

2021-09-16 Thread Daniel Gruno


it's on announce@httpd.a.o already. I modded it through.

You need to send it to annou...@apache.org as well.

On 16/09/2021 06.03, ste...@eissing.org wrote:




Am 16.09.2021 um 12:40 schrieb Greg Stein :

Fails, how? ... email to annou...@apache.org needs to come from your 
@apache.org account and include a Reply-To. The moderators may have bounced 
your message, if it didn't include some key aspects (eg. download links, where 
to find KEYs, etc)


Yes, exactly. It did not fail on send, it did just not appear and Mark Thomas 
as moderator of announce@a.o did not see it. But now it appeared and I did a 
retry on the announce@httpd.a.o a minute ago.

Maybe my initial attempts triggered some spammer detected and blackholed the 
correct mails afterwards. Or there was a queue stuck somewhere. I cannot tell 
and thus I opened a ticket at infra 
https://issues.apache.org/jira/browse/INFRA-22338.

Cheers,
Stefan



Cheers,
-g


On Thu, Sep 16, 2021 at 4:26 AM ste...@eissing.org  wrote:
...is failing for me. The method from the old announce.sh script
does not give any error on curl upload, but no mail appears.

Anyone got a suggestion?

- Stefan

Re: release roll soon?

2021-09-10 Thread Daniel Ferradal

Indeed it kind of sounds too early to go with OpenSSL 3 yet to consider for
a stable release of apache. (Too fresh out of the oven?)


El vie., 10 sept. 2021 9:42, ste...@eissing.org 
escribió:

>
>
> > Am 10.09.2021 um 09:02 schrieb Joe Orton :
> >
> > On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote:
> >> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
> >> would be nice to have r1891138 backported for those wishing to try it
> out.
> >> What you say?
> >
> > I'd say it's better to try to get a successful release out, then try to
> > get new features in the stable branch.  (In fact, I'd be quite happy if
> > we had 2.5.x/2.6 released and stopped trying new features in 2.4 :)
> >
> > That revision is not sufficient, I have a hopefully-complete set of
> > OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258
>
> Do you want that in 2.4.49? (we can always to a 2.4.50 OpenSSL3 release
> shortly afterwards, imo)
>
> - Stefan

Re: release?

2021-08-31 Thread Daniel Ruggeri


On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org
>>  wrote:
>>> In what state is our release handling? Given someone holding my
>>> hand, could I do it? Or is it better to look someone over the
>>> shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along.  I
>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
>
> I can give another try with my limited experience.
>
> I definitively would like to add a --dry-run option for all scripts so
> that they can be run for learning purpose without the fear of
> un-expected impact on svn.

FWIW, the announce.sh script which collates all the security "stuff" and
sends the announce emails drops the user to a shell to inspect/examine
what WILL happen before actually doing anything. Any non-zero return
code of that shell will abort the process. I used the heck out of that
several times :-)


>
> Existing scripts are not that easy to read at first, but are
> understanbdable and following
> http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a
> lot. The scripts should also be tweaked because of the latest changes
> in several places (at least web site update (now on github) and CVE
> announcement (if any) now that part of the process is handled elsewhere).
>

+1

To my knowledge, the publishing of the site and overhaul of the new CVE
process are the things requiring updates.

-- 
Daniel Ruggeri

> The CVE announcement should be much easier, now that we have a "Send
> these Emails" on cveprocess.a.o. This should simplify part of the
> process where we were preparing some scripts to send the announcement
> emails.
>
> I've been lacking time for httpd since many weeks, but I should be
> able to RM next week if needed.
>
> CJ
>
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>>

Re: disallow HTTP 0.9 by default?

2021-07-22 Thread Daniel Ferradal

I know for a fact that this will bring me some headaches at work with
a few F5 "ping" checks, but still, to heck with it!

+1

El jue, 22 jul 2021 a las 12:39, Daniel Gruno () escribió:
>
> On 22/07/2021 10.02, Ruediger Pluem wrote:
> >
> >
> > On 7/21/21 10:04 PM, Eric Covener wrote:
> >> I was chasing an unrelated thread about close_notify alerts and
> >> reminded me -- is it time to change the default for
> >> HttpProtocolOptions from Allow0.9 to Require1.0?
> >>
> >> As the manual says, the requirement was dropped in RFC 7230. It seems
> >> like the kind of potential gadget in future desynch/smuggling kind of
> >> attacks that shouldn't be on by default today.
> >
> > +1 for Require1.0 on 2.4. Typically I would not agree because it can break 
> > existing applications, but are there really setups out
> > there that work with HTTP 0.9? I don't believe so. Hence my +1.
>
> In which case one can just manually switch back to Allow0.9, right? :)
>
> +1 for Require1.0
>
> >
> > Regards
> >
> > Rüdiger
> >
>


-- 
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat

Re: disallow HTTP 0.9 by default?

2021-07-22 Thread Daniel Gruno


On 22/07/2021 10.02, Ruediger Pluem wrote:



On 7/21/21 10:04 PM, Eric Covener wrote:

I was chasing an unrelated thread about close_notify alerts and
reminded me -- is it time to change the default for
HttpProtocolOptions from Allow0.9 to Require1.0?

As the manual says, the requirement was dropped in RFC 7230. It seems
like the kind of potential gadget in future desynch/smuggling kind of
attacks that shouldn't be on by default today.


+1 for Require1.0 on 2.4. Typically I would not agree because it can break 
existing applications, but are there really setups out
there that work with HTTP 0.9? I don't believe so. Hence my +1.


In which case one can just manually switch back to Allow0.9, right? :)

+1 for Require1.0



Regards

Rüdiger

Re: migration of the HTTPD project website

2021-07-16 Thread Daniel Gruno


On 16/07/2021 22.45, Christophe JAILLET wrote:

Hi,
when a PULL request is generated, it is forwarded to @dev. Same when it 
is accepted.

This is just fine for me.

However, when one directly modify within apache/httpd-site on GitHub, 
apparently, no notification is sent.


I think that is would be useful to also have these changes sent 
somewhere so that others know that there is some activity (and 
potentially fix/improve things, should it be only typo)


Is it possible?
Do you share this point of view?


Yeah, this was actually added by Dave already, but not applied due to a 
timing issue. I've prodded the .asf.yaml file now, and things should be 
good.




CJ


Regards,
Dave



Regards

Rüdiger

Re: migration of the HTTPD project website

2021-07-07 Thread Daniel Gruno


On 07/07/2021 14.14, Eric Covener wrote:

https://bz.apache.org/bugzilla/show_bug.cgi?id=65439

whoops, looks like the manual links from for the following are not working:

https://httpd.apache.org/mod_ftp/
https://httpd.apache.org/mod_cgid/

Daniel, do you recall how this worked before? Maybe we lost some of
this extra content when you moved where httpd.apache.org points?


I know where it originally pointed too, and I'll try to weave that into 
the new site checkout. Should apply within 30 minutes.





On Mon, Jul 5, 2021 at 4:15 AM Yann Ylavic  wrote:


On Mon, Jul 5, 2021 at 9:56 AM Ruediger Pluem  wrote:


I don't think that we want to release them. I am fine with omitting trunk from 
the path. Anyone objected to

svn mv https://svn.apache.org/repos/asf/httpd/site/trunk/tools 
https://svn.apache.org/repos/asf/httpd/dev-tools/

?


+1

Regards;
Yann.




--
Eric Covener
cove...@gmail.com

Re: Security features of Github

2021-06-25 Thread Daniel Gruno


On 25/06/2021 09.23, Ruediger Pluem wrote:

I would like to leverage the "security features" of GitHub like Dependabot 
alerts and Code scanning alerts.

First question: Do we want this? Does anyone object?

Second question: Is this possible with our GitHub setup? I known that this 
question might be better suited for the infra list, but
OTOH I know that some infra guys are here as well.
While Dependabot seems to be only a matter of activating which might be easy I 
understand that The Code scanning alerts run as
GitHub actions and I am not sure if we can use GitHub actions or what the 
limits are as for the CI stuff we use Travis.

Regards

Rüdiger



Dependabot unfortunately is not a viable option, as that would start 
leaking potential issues into public space due to how our and their 
infra works.

Re: migration of the HTTPD project website

2021-06-18 Thread Daniel Gruno


On 18/06/2021 14.33, Eric Covener wrote:

On Fri, Jun 18, 2021 at 8:20 AM Daniel Gruno  wrote:


On 18/06/2021 14.16, Eric Covener wrote:

I reviewed Christophes old post, I think we should proceed with the
ASF template and migration process. Worst case Christophe can still
apply what he has learned to further refine the output of the
migration.

I'll create an infra ticket to ask for the repo and migration on
Monday unless someone objects.


repo request is done via selfserve.apache.org


Since we do not use gitbox yet: So this would result in e.g.
github.com/apache/httpd-site and users can then choose to interact
with github or gitbox.a.o, right?


Yep.




migrating the site (and using pelican/jbake/hugo??) is done also
self-serve-y via .asf.yaml - s.apache.org/asfyaml


A lot of info there, I see the pelican config stuff but can you give a
hint about the migration aspect there?



The migration would largely just happen automatically once .asf.yaml is 
in place and working. There is some httpd docs aliasing that infra needs 
to figure out, but that's tangential to this.

Re: migration of the HTTPD project website

2021-06-18 Thread Daniel Gruno


On 18/06/2021 14.16, Eric Covener wrote:

I reviewed Christophes old post, I think we should proceed with the
ASF template and migration process. Worst case Christophe can still
apply what he has learned to further refine the output of the
migration.

I'll create an infra ticket to ask for the repo and migration on
Monday unless someone objects.


repo request is done via selfserve.apache.org
migrating the site (and using pelican/jbake/hugo??) is done also 
self-serve-y via .asf.yaml - s.apache.org/asfyaml





On Thu, Jun 17, 2021 at 9:34 AM Andrew Wetmore  wrote:


To avoid confusion because of the bad title for my previous email, here is what 
I wrote concerning your project website:

The Apache CMS system is going out of service and we really need to get the
last couple of projects off it.

I know that Christophe was working on a migration path to Pelican some
months ago, so perhaps all is well. If not, we now have an "ASF-Pelican"
template and migration process available that could speed things along.

Please let me know today where things stand with your website. Information
about the Pelican template is at https://infra.apache.org/asf-pelican.html.

(please do a reply-all, as I am not subscribed to your dev@ list.)

Thank you!

--
Andrew Wetmore
Technical Writer-Editor
Infra
Apache Software Foundation
andr...@apache.org




--
Eric Covener
cove...@gmail.com

Re: Contribution to Apache HTTPD

2021-05-27 Thread Daniel Ferradal

Hello and welcome!

I'm sure others may give better advice than me since I'm no dev but
have you checked http://httpd.apache.org/dev/ yet?

There is a lot of info there that I think it is worth checking to get started.

Cheers!

El jue, 27 may 2021 a las 14:52, Nikita Popov
() escribió:
>
> Hello. I'm a senior C developer working for CloudLinux. I would like
> to participate in the HTTPD project. Are there any unassigned tasks
> which I can take? And how to proceed with it? Thanks in advance.



-- 
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat

Re: Build warnings in 2.4.48

2021-05-20 Thread Daniel Ferradal

 support a version whose latest release was 5 years ago?

I recall when running configure seeing a message that looks for
OpenSSL>0.9.8 though, but still...


El jue., 20 may. 2021 14:57, Rainer Jung  escribió:

> Am 20.05.2021 um 14:07 schrieb Noel Butler:
> > On 20/05/2021 21:19, Rainer Jung wrote:
> >
> >> Hi there,
> >>
> >> I saw the following build warnings in 2.4.48:
> >>
> >> modules/md/md_crypt.c:1382: warning: passing argument 1 of
> >> ‘BIO_new_mem_buf’ discards qualifiers from pointer target type
> >> [-Wdiscarded-qualifiers]
> >>
> >> => happens only when building against OpenSSL 1.0.2 (initial release,
> >> no letter suffix).
> > But in openssl 1.0.2, was that not EOL'd back in late 2019?
>
> I think until now httpd 2.4.x still officially supports being build with
> OpenSSL starting at 0.9.8.
>
> Best Regards,
>
> Rainer
>

Re: [VOTE] Release httpd-2.4.48

2021-05-19 Thread Daniel Ferradal

Hello,

I tested in RHEL 6.10 and Centos 7.9
along with manually compiled:
openssl-1.1.1k
expat-2.2.10
apr-1.7.0
apr-util-1.6.1
pcre-8.44
nghttp2-1.43.0 (and to compile this , compiled Python-3.9.5)
bonus: tested loading weblogic plugin too (WebLogic Server Plugin
version 12.2.1.4.0 )

Results: no issues.


+1 for me.

El lun, 17 may 2021 a las 23:37, Christophe JAILLET
() escribió:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.48:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz
> sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e
> *httpd-2.4.48.tar.gz
> sha512:
> 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb
> *httpd-2.4.48.tar.gz
>
> The SVN tag is '2.4.48' at r1889975.
>
> --
> Christophe JAILLET



-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

Re: [VOTE] Release httpd-2.4.47

2021-04-23 Thread Daniel

Hello,

I tested it compiling in RHEL 6.9 (a bit legacy I know) along with
also manually compiled:
openssl-1.1.1k
expat-2.2.10
apr-1.7.0
apr-util-1.6.1
pcre-8.44
nghttp2-1.43.0 (and to compile this , compiled Python-3.9.4)
bonus: tested loading weblogic plugin too (WebLogic Server Plugin
version 12.2.1.4.0 )

Results: no issues.

I also tested the same scenario as above with CentOS 7.9.

Results: No issues either.

So FWIW although the setup I mention may not be orthodox at all:

+1 for me.

El jue, 22 abr 2021 a las 11:25, Christophe JAILLET
() escribió:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.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



-- 
Daniel

Re: libcurl dependency version fix for mod_md

2020-10-15 Thread Daniel Gruno


On 15/10/2020 15.50, Stefan Eissing wrote:




Am 15.10.2020 um 15:28 schrieb Alexander Gerasimov 
:

Dear httpd devs,

Please apply a small patch that fixes a minimal curl version (so mod_md can be 
built on CentOS 7).

I made a pull request https://github.com/apache/httpd/pull/108/ and filed a 
bugzilla bug with a patch, but there was no reply for 6 months.


Sorry to hear that. Alas, the httpd github repro is a readonly mirror of our 
subversion repository and not monitored for PRs. Which we should do.


It wasn't monitored six months ago, but it is now (as of two months ago 
I think), at notificati...@httpd.apache.org - people are encouraged to 
join that list and help out :)




I brought your change into the subversion repository and also on my actively 
maintained mod_md repository at . If you ever 
want to bring another PR to the module, that is a good place.

Thanks a lot,

Stefan



Thanks a lot.


Best regards,
Alexander Gerasimov
Chief Technical Officer
CodeIT LLC

M: +380 68 891 17 99
S: codeguard
E: alexander.gerasi...@codeit.pro
W: codeit.pro

Re: [VOTE] Release httpd-2.4.46

2020-08-08 Thread Daniel Ruggeri

Hi, Bill;
   I wondered about this myself. I agree that we allow for ambiguity
when we say an issue is fixed in 2.4.44 and 2.4.45 (which weren't
released). Perhaps we should just bump the 'fixed' version up to the
released version... but then we should also add to the 'affected'
versions the version numbers we burned during QA. That's odd, too,
because we didn't release those versions so they aren't really 'affected'.

   I could go either way... the vulnerability reporting is enough "after
work" for a release that makes it a prime candidate for processing it
with announce.sh, so I'm happy to encode whatever we consider the best
way forward into that script.

-- 
Daniel Ruggeri

On 8/7/2020 8:56 AM, William A Rowe Jr wrote:
> Following the announcement link, it isn't clear that 
>
> https://httpd.apache.org/security/vulnerabilities_24.html 
>
> fixes issues in 2.4.46.
>
> Should the fixed-in be promoted to the revision of Apache HTTP Server
> actually published (released) by the project? It almost reads like
> "fixed in
> 2.4.46-dev" (which 0-day disclosures are described as, until a release
> is actually published.)
>
> On Wed, Aug 5, 2020 at 6:32 AM Daniel Ruggeri  <mailto:dan...@bitnebula.com>> wrote:
>
> Hi, all;
>
>    With 12 binding PMC +1 votes, two additional +1 votes from the
> community, and no -1 votes, I'm pleased to report that the vote has
> PASSED to release 2.4.46. I will begin the process of pushing to the
> distribution mirrors which should enable us for a Friday
> announcement -
> a great way to wrap up the week!
>
> Here are the votes I recorded during the thread:
> PMC
> jailletc36, steffenal, elukey, jorton, jfclere, ylavic, covener,
>     gbechis, gsmith, druggeri, jblond, rjung
>
> Community
> Noel Butler, wrowe
>
> -- 
> Daniel Ruggeri
>
> On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
> > 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.
> >
>

Re: svn commit: r40863 - /dev/httpd/ /release/httpd/

2020-08-05 Thread Daniel Ruggeri

Hi, Rainer;
   Right - this file gets rewritten by the announce.sh script just before the 
notification goes out. This is done to ensure that the date is correct and to 
ensure the type of release (bug, security, enhancement) is correct. It appears 
as though the file was just changed, but really it's just because the text was 
bumped as-is from the 'dev' location to the 'dist' location.
-- 
Daniel Ruggeri

On August 5, 2020 7:23:33 AM CDT, Rainer Jung  wrote:
>Could you fix the date (September 21, 2018 sems wrong).
>
>Thanks!
>
>Rainer
>
>Am 05.08.2020 um 13:32 schrieb drugg...@apache.org:
>> Author: druggeri
>> Date: Wed Aug  5 11:32:51 2020
>> New Revision: 40863
>> 
>> Log:
>> Push 2.4.46 up to the release directory
>> 
>> Added:
>>  release/httpd/CHANGES_2.4.46
>>- copied unchanged from r40862, dev/httpd/CHANGES_2.4.46
>>  release/httpd/httpd-2.4.46.tar.bz2
>>- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.bz2
>>  release/httpd/httpd-2.4.46.tar.bz2.asc
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.asc
>>  release/httpd/httpd-2.4.46.tar.bz2.md5
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.md5
>>  release/httpd/httpd-2.4.46.tar.bz2.sha1
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.sha1
>>  release/httpd/httpd-2.4.46.tar.bz2.sha256
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.sha256
>>  release/httpd/httpd-2.4.46.tar.bz2.sha512
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.sha512
>>  release/httpd/httpd-2.4.46.tar.gz
>>- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz
>>  release/httpd/httpd-2.4.46.tar.gz.asc
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.asc
>>  release/httpd/httpd-2.4.46.tar.gz.md5
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.md5
>>  release/httpd/httpd-2.4.46.tar.gz.sha1
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.sha1
>>  release/httpd/httpd-2.4.46.tar.gz.sha256
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.sha256
>>  release/httpd/httpd-2.4.46.tar.gz.sha512
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.sha512
>> Removed:
>>  dev/httpd/CHANGES_2.4
>>  dev/httpd/CHANGES_2.4.46
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.asc
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.md5
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.sha512
>>  dev/httpd/httpd-2.4.46-deps.tar.gz
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.asc
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.md5
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.sha1
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.sha256
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.sha512
>>  dev/httpd/httpd-2.4.46.tar.bz2
>>  dev/httpd/httpd-2.4.46.tar.bz2.asc
>>  dev/httpd/httpd-2.4.46.tar.bz2.md5
>>  dev/httpd/httpd-2.4.46.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.46.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.46.tar.bz2.sha512
>>  dev/httpd/httpd-2.4.46.tar.gz
>>  dev/httpd/httpd-2.4.46.tar.gz.asc
>>  dev/httpd/httpd-2.4.46.tar.gz.md5
>>  dev/httpd/httpd-2.4.46.tar.gz.sha1
>>  dev/httpd/httpd-2.4.46.tar.gz.sha256
>>  dev/httpd/httpd-2.4.46.tar.gz.sha512
>> Modified:
>>  release/httpd/Announcement2.4.html
>>  release/httpd/Announcement2.4.txt
>>  release/httpd/CHANGES_2.4
>> 
>> Modified: release/httpd/Announcement2.4.html
>>
>==
>> --- release/httpd/Announcement2.4.html (original)
>> +++ release/httpd/Announcement2.4.html Wed Aug  5 11:32:51 2020
>> @@ -49,27 +49,27 @@
>>   
>>   
>>   
>> -   Apache HTTP Server 2.4.43 Released
>> +   Apache HTTP Server 2.4.46 Released
>>   
>>   
>> -   April 01, 2020
>> +   September 21, 2018
>>   
>>   
>>  The Apache Software Foundation and the Apache HTTP Server
>Project are
>>  pleased to href="https://www.apache.org/dist/httpd/Announcement2.4.html;>announce
>> -   the release of version 2.4.43 of the Apache
>> +   the release of version 2.4.46 of the Apache
>

Re: Your project's website

2020-08-05 Thread Daniel Gruno


On 05/08/2020 14.17, Andrew Wetmore wrote:

Hi:

I am part of the Infrastructure team, and am writing to ask whether your 
project is still using the Apache CMS for your project website. As you 
know, the CMS is reaching end-of-life, and we need projects to move 
their websites onto a different option within the next few weeks.


There are several alternatives available, including those listed on this 
page [1] on managing project websites. Infra is assembling a Wiki page 
[2] on migrating a website from the CMS, and is looking forward to 
helping projects with this transition.


Please let me know whether your site is still on the Apache CMS and, if 
so, who will be the project point-of-contact with Infra for the migration.


Thank you!


We do use it, and it *should* be trivial for us to switch to something 
like pelican instead, for the main site (docs are another thing 
entirely). While I'll be happy to assist with that, I don't want to put 
on too many hats here, so if someone would volunteer to be the liaison, 
that would be wonderful.


With regards,
Daniel.






[1] https://infra.apache.org/project-site.html 
<https://infra.apache.org/project-site.html>


[2] 
https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS 
<https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS>




--
Andrew Wetmore
Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org <mailto:andr...@apache.org>

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> 
	Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release httpd-2.4.46

2020-08-05 Thread Daniel Ruggeri

Hi, all;

   With 12 binding PMC +1 votes, two additional +1 votes from the
community, and no -1 votes, I'm pleased to report that the vote has
PASSED to release 2.4.46. I will begin the process of pushing to the
distribution mirrors which should enable us for a Friday announcement -
a great way to wrap up the week!

Here are the votes I recorded during the thread:
PMC
jailletc36, steffenal, elukey, jorton, jfclere, ylavic, covener,
gbechis, gsmith, druggeri, jblond, rjung

Community
Noel Butler, wrowe

-- 
Daniel Ruggeri

On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
> 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.
>

Re: [VOTE] Release httpd-2.4.46

2020-08-03 Thread Daniel Ruggeri

For my own +1... tested under the following versions:

system:
  kernel:
    name: Linux
    release: 4.19.0-10-amd64
    version: #1 SMP Debian 4.19.132-1 (2020-07-24)
    machine: x86_64

  libraries:
    openssl: "1.1.1g"
    openldap: "2.4.50"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.41.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.8"
    lua: "5.3.5"
    curl: "7.71.1"

-- 
Daniel Ruggeri

On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
> 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.
>

Re: svn commit: r1880502 - /httpd/httpd/branches/2.4.x/CHANGES

2020-08-01 Thread Daniel Ruggeri

Sure - I'll commit the following:
  *) mod_proxy_fcgi: Fix missing APLOGNO macro argument

Straight forward enough. Thanks for the correction.

-- 
Daniel Ruggeri

On 8/1/2020 9:14 AM, Steffen wrote:
> 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
>>
>>
>>

[VOTE] Release httpd-2.4.46

2020-08-01 Thread Daniel Ruggeri

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: Pending fixes or reroll? Was: [RESULT] [VOTE] Release httpd-2.4.45

2020-08-01 Thread Daniel Ruggeri

Agreed - thank you (everyone) for the quick rally to fix this and for
confirming we don't have other work needing to be done. I apologize for
taking almost 24 hours to ACK and get us moving again.

I've updated CHANGES and will send a VOTE shortly

-- 
Daniel Ruggeri

On 7/31/2020 1:28 PM, Rainer Jung wrote:
> 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 = missing macro
>> argument) 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.

[RESULT] [VOTE] Release httpd-2.4.45

2020-07-30 Thread 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.

-- 
Daniel Ruggeri

On 7/29/2020 10:26 AM, 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.45:
> [ ] +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: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
> sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
> *httpd-2.4.45.tar.gz
> sha512:
> 8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
> *httpd-2.4.45.tar.gz
>
> The SVN tag is '2.4.45' at r1880411.
>

Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Daniel Ruggeri


On 7/30/2020 2:41 PM, William A Rowe Jr wrote:
> On Thu, Jul 30, 2020 at 10:10 AM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
>
>
> > On Jul 30, 2020, at 5:55 AM, Christophe JAILLET
>  <mailto:christophe.jail...@wanadoo.fr>> 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.
>
>  
> Agreed. And Steffen points out there is precedence.
>

Aye - and I'd hate to appear inconsistent :-)

Version numbers are cheap - I'll re-roll when we have confirmation all
is good in the 2.4 branch.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.45

2020-07-29 Thread Daniel Ruggeri

For my own vote:   +1

Tested platform info follows. Same note as yesterday where lua was kept
back to 5.3 rather than 5.4.

system:
  kernel:
    name: Linux
    release: 4.19.0-9-amd64
    version: #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
    machine: x86_64

  libraries:
    openssl: "1.1.1g"
    openldap: "2.4.50"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.41.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.8"
    lua: "5.3.5"
    curl: "7.71.1"

-- 
Daniel Ruggeri

On 7/29/2020 10:26 AM, 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.45:
> [ ] +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: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
> sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
> *httpd-2.4.45.tar.gz
> sha512:
> 8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
> *httpd-2.4.45.tar.gz
>
> The SVN tag is '2.4.45' at r1880411.
>

[VOTE] Release httpd-2.4.45

2020-07-29 Thread Daniel Ruggeri

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.45:
[ ] +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: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
*httpd-2.4.45.tar.gz
sha512:
8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
*httpd-2.4.45.tar.gz

The SVN tag is '2.4.45' at r1880411.

-- 
Daniel Ruggeri

[RESULT] [VOTE] Release httpd-2.4.44

2020-07-29 Thread Daniel Ruggeri



On 7/28/2020 12:51 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.44:
> [ ] +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: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
> *httpd-2.4.44.tar.gz
> sha512:
> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
> *httpd-2.4.44.tar.gz
>
> The SVN tag is '2.4.44' at r1880378.
Hi, all - apologies for the false start. A backport into 2.4 was missed
just before I rolled the release. Since version numbers are cheap and
we've only just begun the testing cycle, I'll close this vote and will
soon roll a 2.4.45 release as replacement.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.44

2020-07-29 Thread Daniel Ruggeri

Hi, Stefan;
   Since version numbers are cheap and we've had only one vote on this
one, I don't see harm in incorporating the change and rerolling. Doubly
so since votes are already in for the change and all that. I'll re-roll
the release tarball once you confirm.

-- 
Daniel Ruggeri

On 7/29/2020 7:02 AM, Stefan Eissing wrote:
> -1.
>
> I have to apologise. I missed an important change in HTTP/2 that I like to 
> get in the release. This is about removing support for an abandoned http-wg 
> draft that we do not want any longer in our server.
>
> Will do the changes right away and let you know when I am done.
>
> Again, sorry to everyone for the wasted cycles. :(
>
> - Stefan
>
>> Am 28.07.2020 um 19:51 schrieb Daniel Ruggeri :
>>
>> 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.44:
>> [ ] +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: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
>> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
>> *httpd-2.4.44.tar.gz
>> sha512:
>> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
>> *httpd-2.4.44.tar.gz
>>
>> The SVN tag is '2.4.44' at r1880378.
>>
>> -- 
>> Daniel Ruggeri
>>
>>

Re: [VOTE] Release httpd-2.4.44

2020-07-28 Thread Daniel Ruggeri

+1 from me based on below results

NOTE: httpd does not build against the latest version of LUA (5.4), but
that major bump was just released a few weeks ago.

system:
  kernel:
    name: Linux
    release: 4.19.0-9-amd64
    version: #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
    machine: x86_64

  libraries:
    openssl: "1.1.1g"
    openldap: "2.4.50"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.41.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.8"
    lua: "5.3.5"
    curl: "7.71.1"

-- 
Daniel Ruggeri

On 7/28/2020 12:51 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.44:
> [ ] +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: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
> *httpd-2.4.44.tar.gz
> sha512:
> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
> *httpd-2.4.44.tar.gz
>
> The SVN tag is '2.4.44' at r1880378.
>

[VOTE] Release httpd-2.4.44

2020-07-28 Thread Daniel Ruggeri

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.44:
[ ] +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: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
*httpd-2.4.44.tar.gz
sha512:
f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
*httpd-2.4.44.tar.gz

The SVN tag is '2.4.44' at r1880378.

-- 
Daniel Ruggeri

Re: NOTICE: Intent to T late this week

2020-07-28 Thread Daniel Ruggeri


On 7/28/2020 7:41 AM, Eric Covener wrote:
> On Tue, Jul 28, 2020 at 4:30 AM Christophe JAILLET
>  wrote:
>> Le 27/07/2020 à 14:11, Daniel Ruggeri a écrit :
>>>
>>> On July 27, 2020 2:12:45 AM CDT, Stefan Eissing 
>>>  wrote:
>>>>
>>>>> Am 25.07.2020 um 00:14 schrieb Daniel Ruggeri :
>>>>>
>>>>> Hi, all;
>>>>>FYI, I came across an unexpected set of diffs when rebuilding docs
>>>> before tagging this morning. Haven't forgotten about T, but would
>>>> like to figure out the origin of the docs changes (likely my
>>>> environment). I've started a conversation on docs@ about what I'm
>>>> seeing.
>>>>
>>>> Sorry about your troubles. Do we need to look for someone else doing
>>>> the RMing or what's your status?
>>> Hi, Stefen;
>>> I'm still good to go. I just need clarity on what encoding behavior we 
>>> expect in the docs. More info is on docs@. Either way works for me... just 
>>> need to know what the consensus is.
>>>
>>>>>
>>>>> On 2020/07/22 23:32:05, Daniel Ruggeri  wrote:rance 
>>>>> :))
>>>>>> Hi, all;
>>>>>>It's been a while since we've rolled a release and gotten
>>>> fixes/etc in our community's hands. Apologies for not suggesting this
>>>> sooner. How about a T Friday? That will let vote run through the
>>>> weekend.
>>>>>> --
>>>>>> Daniel Ruggeri
>> Hi,
>>
>> I don't have access to my PC these days (side effect from being on
>> vacation in the south of France :)), however, have a look at r1878788 on
>> trunk which should fixed once and for all the issue.
>>
>> This commit switches the en doc files into utf8 which works great with
>> older and newer versions of Java.
>>
>> To be consistent with the other language, the files themselves should be
>> renamed to have a trailing .utf8, as explained in the commit description.
>>
>> I've not done it on trunk because it is painful (at least for me) to
>> synch all the news .utf8 files with svn. If s.o. feels like making the
>> change, please do.
>>
>> CJ
> Thanks Christophe.  I backported it but did not do the .utf8 extension
> due to the amount of spam it would create.
> I also put some java checks in docs-build
>
> Daniel -- I say proceed w/ release and we can revisit the .utf8 extension 
> later.
>
Excellent! I've performed my prechecks and everything is looking pretty
good. I'll get this moving now.

-- 
Daniel Ruggeri

Re: NOTICE: Intent to T late this week

2020-07-27 Thread Daniel Ruggeri




On July 27, 2020 2:12:45 AM CDT, Stefan Eissing  
wrote:
>
>
>> Am 25.07.2020 um 00:14 schrieb Daniel Ruggeri :
>> 
>> Hi, all;
>>   FYI, I came across an unexpected set of diffs when rebuilding docs
>before tagging this morning. Haven't forgotten about T, but would
>like to figure out the origin of the docs changes (likely my
>environment). I've started a conversation on docs@ about what I'm
>seeing.
>
>Sorry about your troubles. Do we need to look for someone else doing
>the RMing or what's your status?

Hi, Stefen;
I'm still good to go. I just need clarity on what encoding behavior we expect 
in the docs. More info is on docs@. Either way works for me... just need to 
know what the consensus is.

>
>> 
>> 
>> On 2020/07/22 23:32:05, Daniel Ruggeri  wrote: 
>>> Hi, all;
>>>   It's been a while since we've rolled a release and gotten
>fixes/etc in our community's hands. Apologies for not suggesting this
>sooner. How about a T Friday? That will let vote run through the
>weekend.
>>> -- 
>>> Daniel Ruggeri

Re: NOTICE: Intent to T late this week

2020-07-24 Thread Daniel Ruggeri

Hi, all;
   FYI, I came across an unexpected set of diffs when rebuilding docs before 
tagging this morning. Haven't forgotten about T, but would like to figure out 
the origin of the docs changes (likely my environment). I've started a 
conversation on docs@ about what I'm seeing.

On 2020/07/22 23:32:05, Daniel Ruggeri  wrote: 
> Hi, all;
>It's been a while since we've rolled a release and gotten fixes/etc in our 
> community's hands. Apologies for not suggesting this sooner. How about a T 
> Friday? That will let vote run through the weekend.
> -- 
> Daniel Ruggeri

Re: NOTICE: Intent to T late this week

2020-07-24 Thread Daniel Ruggeri

Hey there, Chris;

   Fair question - and I don't think I have a handy link describing the
flow of patch -> trunk -> STATUS backport proposal -> branch commit ->
release

   Generally speaking, the code goes into trunk and is proposed for
backport into a stable branch via the STATUS file (at the root of the
branch - ex
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?view=markup).
A lot of times, patches are proposed for discussion/refined and
tweaked/etc before being committed in trunk, which seems to fit the
conversation in your reference BZ item. From there, we need three
committer +1s to backport. Once all three are in place, the proposer (or
release manager) commits the change to the branch. So, for this one, I
think we're not quite ready to incorporate.

P.S.
I hope all is well - long time no chat!

-- 
Daniel Ruggeri

On 7/23/2020 1:33 PM, Christopher Schultz wrote:
> Daniel,
>
> On 7/22/20 19:32, Daniel Ruggeri wrote:
> > Hi, all; It's been a while since we've rolled a release and gotten
> > fixes/etc in our community's hands. Apologies for not suggesting
> > this sooner. How about a T Friday? That will let vote run through
> > the weekend.
>
> If I clean-up my patch for
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64338 is there a chance
> it could make it into this release?
>
> I'm super-ignorant about the httpd release process so I apologize if
> that's a ridiculous question.
>
> -chris

NOTICE: Intent to T late this week

2020-07-22 Thread Daniel Ruggeri

Hi, all;
   It's been a while since we've rolled a release and gotten fixes/etc in our 
community's hands. Apologies for not suggesting this sooner. How about a T 
Friday? That will let vote run through the weekend.
-- 
Daniel Ruggeri

Re: RFC: Documenting changes in the CHANGES file

2020-06-02 Thread Daniel Ruggeri

On 6/1/2020 6:23 AM, Yann Ylavic wrote:
> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem  wrote:
>> Reviewing our backport process I noticed that in many cases a clean merge 
>> via svn merge fails due to conflicts in CHANGES. While
>> these are easy to solve it puts IMHO unnecessary extra work on the backport 
>> process, both for reviewing and for actually doing the
>> backport. How about if we change the way we document changes the following 
>> way:
>>
>> 1. We create a changes-fragments directory (name to be determined) at the 
>> top level.
>> 2. For each release we create a subdirectory such that we end up with the 
>> following structure:
>>
>>changes-fragments/
>>  2.4.41/
>>  2.4.42/
>>  2.4.43/
>>  2.4.44/
>>
>> 3. Each directory contains the changes for each release and each change 
>> entry is a single file.
>> 4. We have a script that builds our current CHANGES file from the content in 
>> changes-fragments directories with the help of
>>a template or at least some sort of header / footer that is static.
>> 5. This script can be called either manually and we commit the resulting 
>> CHANGES file as we like just like the x-forms commits
>>for documentation plus this script is called by the release scripts from 
>> Daniel as part of the preparation of rolling a
>>release.
> +1 from me, I don't volonteer for the scripts though :)
>
> Regards;
> Yann.

Hi, Yann;

I'm open to whatever... and don't mind writing or tweaking scripts once
we decide on an approach :-)

While we are discussing ideas in this neighborhood, one thing to keep in
mind is that during release of security fixes, sometimes there are items
added to CHANGES and sometimes CHANGES is modified to add CVE
information. There have been minor bumps in the road where these patches
don't always apply cleanly. So, if possible, it would be great to
consider. There may be nothing to do, though, since that happens way
after backport.

-- 
Daniel Ruggeri

Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

2020-04-29 Thread Daniel Gruno


On 29/04/2020 10.52, Daniel Gruno wrote:

On 29/04/2020 10.22, Daniel Gruno wrote:




I recommend using selfserve.apache.org <http://selfserve.apache.org> 
to create notifications@httpd (the typical name/pattern for this 
stuff), then to use .asf.yaml to sort out the various emails.


Once we are in agreement on a name here, I can get this processed with 
my VP hat on, and task infra to figure out how to relay notifications 
there :)


Going to JFDI here... notifications@httpd coming right up :p


And done, plus we have GH notifications going there now :)







Cheers,
-g

Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

2020-04-29 Thread Daniel Gruno


On 29/04/2020 10.22, Daniel Gruno wrote:




I recommend using selfserve.apache.org <http://selfserve.apache.org> 
to create notifications@httpd (the typical name/pattern for this 
stuff), then to use .asf.yaml to sort out the various emails.


Once we are in agreement on a name here, I can get this processed with 
my VP hat on, and task infra to figure out how to relay notifications 
there :)


Going to JFDI here... notifications@httpd coming right up :p





Cheers,
-g

Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

2020-04-29 Thread Daniel Gruno

On 29/04/2020 10.11, Greg Stein wrote:
On Wed, Apr 29, 2020 at 8:19 AM Joe Orton > wrote:

On Tue, Apr 28, 2020 at 05:19:09PM +0200, Ruediger Pluem wrote:
 > +1 g...@httpd.apache.org  (I declare
the naming discussion for the list name opened :-)).
 > This offers an easy opt-in for those who are interested in these
updates.

+1 from me, does anybody know if it's actually technically possible to
do though?  AFAICT there is not github project setting to do this kind
of thing specifically so we'd either need to use the API somehow?  Or
add whate...@httpd.apache.org  to
a personal github account and have
notifications through that, which seems ugly.

Solved.
https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Notificationsettingsforrepositories 

This unfortunately won't work since httpd.git is a mirror repository.
I'm sure we can solve the PR notifications one way or the other, but it 
can't be done through .asf.yaml until such a point where httpd is using 
git as its main VCS.

I recommend using selfserve.apache.org  to 
create notifications@httpd (the typical name/pattern for this stuff), 
then to use .asf.yaml to sort out the various emails.

Once we are in agreement on a name here, I can get this processed with 
my VP hat on, and task infra to figure out how to relay notifications 
there :)

Cheers,
-g

Odd vulnerabilities_24.html output

2020-04-04 Thread Daniel Ruggeri

Hi, all;
   I'm not sure what mechanism is used to generate
https://httpd.apache.org/security/vulnerabilities_24.html from
https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/vulnerabilities-httpd.xml,
but an anomaly has been reported to me in response to the security
announcements from last release.

   For both CVE-2020-1934 and CVE-2020-1927, the source file says
"Apache HTTP Server versions 2.4.0 to 2.4.41" in the description, but
the rendered result is "Apache HTTP Server versions 2.4.0 to 2.41". If
anyone has pointers on how the site build happens, I can look into it
further.

   If it's too complicated a fix, I'm OK with removing that line from
the description. The CVE reports must include the version vulnerability
info in the description, but it's not really a requirement for the site
(I was just keeping them consistent).

-- 
Daniel Ruggeri

[RESULT - PASS][VOTE] Release httpd-2.4.43

2020-03-30 Thread Daniel Ruggeri



On 3/26/2020 9:50 AM, 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.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.
>

Hi, all;
   I am pleased to report that the vote to release httpd-2.4.43 has
PASSED with the following +1 votes recorded:
PMC
jorton, ylavic, icing, jfclere, jim, steffenal, jailletc36, covener,
gsmith, druggeri, rjung

Community
gbechis

... and zero -1 votes.

I will begin the process of promoting to the mirror system and will prep
for announcement in the next day or two.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Daniel Ruggeri

On 3/27/2020 12:58 PM, William A Rowe Jr wrote:
> On Fri, Mar 27, 2020 at 12:34 PM Steffen  <mailto:i...@apachelounge.com>> wrote:
>
> +1 All fine on Windows.
>
>
> Your's are still the .dsp based builds, right? I can confirm also on
> the CMake flavor.

Thanks, Bill. Shall this response be considered a +1 for the purposes of
the release vote?

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Daniel Ruggeri

On 3/26/2020 9:50 AM, 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.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.


For my own vote:

[X] +1: It's not just good, it's good enough!

system:
  kernel:
    name: Linux
    release: 4.9.0-8-amd64
    version: #1 SMP Debian 4.9.144-3.1 (2019-02-19)
    machine: x86_64

  libraries:
    openssl: "1.1.1e"
    openldap: "2.4.49"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.40.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.4"
    lua: "5.3.5"
    curl: "7.69.1"

-- 
Daniel Ruggeri

[VOTE] Release httpd-2.4.43

2020-03-26 Thread Daniel Ruggeri

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: [VOTE] Release httpd-2.4.42

2020-03-23 Thread Daniel Ruggeri

Hi, all;
   Per the issues surfaced/fixed, I'll go ahead and declare this release
as dead-on-the vine. I'll target another T later this week, hopefully
after the discussion around OpenSSL versioning plays out.

   How about Thursday?

-- 
Daniel Ruggeri

On 3/19/2020 9:45 AM, 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.42:
> [ ] +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: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
> sha256:
> cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed
> *httpd-2.4.42.tar.gz
> sha512:
> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
> *httpd-2.4.42.tar.gz
>
> The SVN tag is '2.4.42' at r1875427.
>

[VOTE] Release httpd-2.4.42

2020-03-19 Thread Daniel Ruggeri


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.42:

[ ] +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: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed 
*httpd-2.4.42.tar.gz
sha512: 
09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837 *httpd-2.4.42.tar.gz


The SVN tag is '2.4.42' at r1875427.

--
Daniel Ruggeri

[NOTICE] Intenet to T 2.4.42 in the next 36 hours.

2020-03-17 Thread Daniel Ruggeri


Hi, all;
   It looks like we're in a good place to do a release so I will aim to 
T 2.4.42 tomorrow. Please feel free to shout loudly if any issues are 
found.


--
Daniel Ruggeri

Re: 2.4.42 soon?

2020-03-17 Thread Daniel Ruggeri


Sure - happy to oblige!
--
Daniel Ruggeri

On 2020-03-13 07:51, Eric Covener wrote:

Looks like STATUS is in good shape.

Any cycles Daniel or Jim?
--
Eric Covener
cove...@gmail.com

Re: svn commit: r1866035 - /httpd/httpd/branches/2.4.x/STATUS

2020-02-07 Thread Daniel Ruggeri




On February 7, 2020 4:59:39 AM CST, Joe Orton  wrote:
>On Thu, Feb 06, 2020 at 07:52:18AM -0600, Daniel Ruggeri wrote:
>> Hey there, Joe; No idea how I didn't detect this much sooner. I have 
>>access to hardware security modules with PKCS11 interfaces for key
>
>>operations and would be happy to put this through it's paces. The 
>>2.5 docs are fairly light (note, this 2.4 patch seems to be
>missing 
>>docs) on how to test this out. Pointers appreciated if you have a 
>>working recipe.
>
>That would be awesome.  The stuff I'm not really sure about & could use
>
>better docs is:
>
>a) how to identify the right PKCS#11 URI for the key/cert objects, and
>b) how to set up the OpenSSL pkcs11 engine correctly so this works
>
>On recent Fedora/RHEL (b) works OOTB but I imagine this may take some 
>effort on other systems or from-scratch builds.
>
>For testing locally I used a USB smartcard reader, setting up the card 
>following https://github.com/OpenSC/OpenSC/wiki/Quick-Start-with-OpenSC
>
>If you can store a cert & private key on the token, mod_ssl will use 
>both, but I think not all HSMs can store the cert, so you can load that
>
>from a PEM file if required and list the key only as a pkcs11: URI in 
>SSLCertificateKeyFile.
>
>Beyond that it should "just work" if you configure per the mod_ssl
>docs, 
>running "p11tool --list-tokens" listed the URI for the token, and I 
>used:
>
>SSLCertificateFile
>"pkcs11:model=PKCS%2315;manufacturer=OpenSC%20Project;serial=0001C9540200;token=Joe%20Orton%20%28OpenSC%20Card%29"
>
>Regards, Joe

Sweet - this is a good starting point. I'll also get in touch with the 
manufacturer to see if there are any gotchas to worry about. For all I know, it 
may be a non-starter with this particular gear. Hopefully more to come soon!

-- 
Daniel Ruggeri
>
>> 
>> On 2019/08/28 12:15:02 jor...@apache.org wrote:
>> > Author: jorton
>> > Date: Wed Aug 28 12:15:01 2019
>> > New Revision: 1866035
>> > 
>> > URL: http://svn.apache.org/viewvc?rev=1866035=rev
>> > Log:
>> > Proposed mod_ssl PKCS#11 cert/key support.
>> > 
>> > 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=1866035=1866034=1866035=diff
>> >
>==
>> > --- httpd/httpd/branches/2.4.x/STATUS (original)
>> > +++ httpd/httpd/branches/2.4.x/STATUS Wed Aug 28 12:15:01 2019
>> > @@ -160,6 +160,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>> >rpluem says: -1 for now. See further discussion at
>> >
>https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
>> >  
>> > +   *) mod_ssl: Add support for loading certs & keys from PKCS#11
>URLs via the
>> > +   OpenSSL pkcs11 engine.  Includes related minor
>cleanups and
>> > +   simplification to mod_ssl internals.
>> > +  trunk patch: http://svn.apache.org/r1830819
>> > +   http://svn.apache.org/r1830912
>> > +   http://svn.apache.org/r1830913
>> > +   http://svn.apache.org/r1830927
>> > +   http://svn.apache.org/r1831168
>> > +   http://svn.apache.org/r1831173
>> > +   http://svn.apache.org/r1835240
>> > +   http://svn.apache.org/r1835242
>> > +   http://svn.apache.org/r1835615
>> > +  2.4.x patch:
>http://people.apache.org/~jorton/mod_ssl_pkcs11.patch
>> > +  +1: jorton, 
>> > +
>> >  PATCHES/ISSUES THAT ARE BEING WORKED
>> >[ New entries should be added at the START of the list ]
>> >  
>> > 
>> > 
>> > 
>> -- 
>> Daniel Ruggeri

2.4.next coming?

2020-02-06 Thread Daniel Ruggeri

Hi, all. It's been a few months since we've rolled a release and there are a 
few bug fixes that seem like A Good Thing to get out there.

Thoughts on rolling soon-ish?

As always, I volunteer to either RM or mentor someone new through the RM 
process.
-- 
Daniel Ruggeri

RE: svn commit: r1866035 - /httpd/httpd/branches/2.4.x/STATUS

2020-02-06 Thread Daniel Ruggeri

Hey there, Joe;
   No idea how I didn't detect this much sooner. I have access to hardware 
security modules with PKCS11 interfaces for key operations and would be happy 
to put this through it's paces. The 2.5 docs are fairly light (note, this 2.4 
patch seems to be missing docs) on how to test this out. Pointers appreciated 
if you have a working recipe.

On 2019/08/28 12:15:02 jor...@apache.org wrote:
> Author: jorton
> Date: Wed Aug 28 12:15:01 2019
> New Revision: 1866035
> 
> URL: http://svn.apache.org/viewvc?rev=1866035=rev
> Log:
> Proposed mod_ssl PKCS#11 cert/key support.
> 
> 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=1866035=1866034=1866035=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Wed Aug 28 12:15:01 2019
> @@ -160,6 +160,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>rpluem says: -1 for now. See further discussion at
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
>  
> +   *) mod_ssl: Add support for loading certs & keys from PKCS#11 URLs via the
> +   OpenSSL pkcs11 engine.  Includes related minor cleanups and
> +   simplification to mod_ssl internals.
> +  trunk patch: http://svn.apache.org/r1830819
> +   http://svn.apache.org/r1830912
> +   http://svn.apache.org/r1830913
> +   http://svn.apache.org/r1830927
> +   http://svn.apache.org/r1831168
> +   http://svn.apache.org/r1831173
> +   http://svn.apache.org/r1835240
> +   http://svn.apache.org/r1835242
> +   http://svn.apache.org/r1835615
> +  2.4.x patch: http://people.apache.org/~jorton/mod_ssl_pkcs11.patch
> +  +1: jorton, 
> +
>  PATCHES/ISSUES THAT ARE BEING WORKED
>[ New entries should be added at the START of the list ]
>  
> 
> 
> 
-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.41

2020-01-18 Thread Daniel Ruggeri



On 8/9/2019 8:50 AM, sebb wrote:
> On Fri, 9 Aug 2019 at 14:40, 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
> I think it would be helpful to include the SVN repo tag and revision.
> This is needed to show provenance for the archive contents.
Sure - easy to handle. I've updated the email template in r1872960 for
the site repo

-- 
Daniel Ruggeri

>
>> --
>> Daniel Ruggeri

Re: svn commit: r1865191 - /httpd/site/trunk/tools/announce.sh

2020-01-18 Thread Daniel Ruggeri



On 8/30/2019 4:57 AM, Ruediger Pluem wrote:
>
> On 08/14/2019 11:01 PM, drugg...@apache.org wrote:
>> Author: druggeri
>> Date: Wed Aug 14 21:01:56 2019
>> New Revision: 1865191
>>
>> URL: http://svn.apache.org/viewvc?rev=1865191=rev
>> Log:
>> Try to be more accomodating
>>
>> Modified:
>> httpd/site/trunk/tools/announce.sh
>>
>> Modified: httpd/site/trunk/tools/announce.sh
>> URL: 
>> http://svn.apache.org/viewvc/httpd/site/trunk/tools/announce.sh?rev=1865191=1865190=1865191=diff
>> ==
>> --- httpd/site/trunk/tools/announce.sh (original)
>> +++ httpd/site/trunk/tools/announce.sh Wed Aug 14 21:01:56 2019
>> @@ -93,30 +93,29 @@ echo "Checking $dir..."
>>#Flip the bit
>>is_security_release=1
>>  
>> -  #If this is in the section not-yet-ready for announce, apply the
>> -  # patch before moving on to announcement generation
>> -  if echo "$SHORT_STATUS" | sed -n '/CHANGES READY FOR REPLACEMENT/,/##/p' 
>> | grep "$dir" >/dev/null;then
>> -#Apply our CHANGES updates via CHANGES.diff or CHANGES
>> -#TODO: Verify that one and only one of the two options will be present 
>> at all times
>> -if test -f "$private_base"/SECURITY/$dir/CHANGES.diff;then
>> -  patch -p0 -d "$branch_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> -  patch -p0 -d "$release_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> -elif test -f "$private_base"/SECURITY/$dir/CHANGES;then
>> -  for UPDATE_FILE in "$branch_base"/CHANGES "$release_base"/CHANGES;do
>> -VERSION="$version" UPDATE_FILE="$UPDATE_FILE" STATUS_UPDATE=`cat 
>> "$private_base"/SECURITY/$dir/CHANGES` perl -e '
>> -  $ENV{STATUS_UPDATE} =~ s/^\s*$//g;
>> -  die "Status update not found!" if !$ENV{STATUS_UPDATE};
>> -  open(CHANGES, "$ENV{UPDATE_FILE}"); my @content=; 
>> close(CHANGES);
>> -  foreach my $line (@content) {
>> -print "$line";
>> -if (!$added && $line =~ /Changes with Apache $ENV{VERSION}/i) {
>> -  print "\n$ENV{STATUS_UPDATE}\n";
>> -}
>> +  #Opportunisticly apply patches to CHANGES regardless of section (announce 
>> ready vs changes ready)
>> +  #because sometimes things are placed in announce ready even though they 
>> haven't had the CHANGES fix applied
>> +  if test -f "$private_base"/SECURITY/$dir/CHANGES.diff;then
>> +patch -p0 -d "$branch_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> +patch -p0 -d "$release_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> +  elif test -f "$private_base"/SECURITY/$dir/CHANGES;then
>> +for UPDATE_FILE in "$branch_base"/CHANGES "$release_base"/CHANGES;do
>> +  VERSION="$version" UPDATE_FILE="$UPDATE_FILE" STATUS_UPDATE=`cat 
>> "$private_base"/SECURITY/$dir/CHANGES` perl -e '
>> +$ENV{STATUS_UPDATE} =~ s/^\s*$//g;
>> +die "Status update not found!" if !$ENV{STATUS_UPDATE};
>> +open(CHANGES, "$ENV{UPDATE_FILE}"); my @content=; 
>> close(CHANGES);
>> +foreach my $line (@content) {
>> +  print "$line";
>> +  if (!$added && $line =~ /Changes with Apache $ENV{VERSION}/i) {
> What is the purpose of the $added variable?

Yikes! This fell between the cracks. Sorry for the really slow reply.

The $added variable was intended to use as a failsafe signal. If we
attempt to add the CHANGES entry, but didn't do so for some reason, the
perl script should fail. I somehow crossed my wires and missed the
important part of bailing out when that happens.

This has been fixed in r1872959

-- 
Daniel Ruggeri

>
>> +print "\n$ENV{STATUS_UPDATE}\n";
>>}
>> -' > "$scratch"/tmp_status
>> -mv "$scratch"/tmp_status "$UPDATE_FILE"
>> -  done
>> -else
>> +}
>> +  ' > "$scratch"/tmp_status
>> +  mv "$scratch"/tmp_status "$UPDATE_FILE"
>> +done
>> +  else
>> +#Fail if this is in the changes ready section, but we didn't find a 
>> change
>> +if echo "$SHORT_STATUS" | sed -n '/CHANGES READY FOR 
>> REPLACEMENT/,/##/p' | grep "$dir" >/dev/null;then
>>echo "Missing CHANGES.diff or CHANGES file for $dir"
>>exit 1
>>  fi
>>
> Regards
>
> Rüdiger
>

Countdown to 25 years - has httpd changed your life?

2020-01-17 Thread Daniel Gruno


Hi wonderful apache people!

As we count down to the 25th anniversary of the Apache Group, founded 
February 27th 1995 (first release of the apache webserver was in April 
1995), I'd like to put some extra effort into the quarterly board report 
I, as chair of the project, have to present to the board of directors at 
the Apache Software Foundation in February.


So I thought to myself, it would be fun to get some testimonials to 
showcase how this project has survived, grown, and remained in the top 
for 25 years, helping people achieve their goals and in the process 
helping people grow. Personally, I would not be where I am today without 
this project - I owe so much to it, and it has helped me reach many a goal.


If you too have been affected by httpd, or if you just think this is a 
really nifty piece of software because it helps you do X, Y or Z, please 
let us know on this thread. I'll later collate the responses, shorten 
them a tad, and compile a shortened list of testimonials for the board 
report.


You can tell us about your experience with the product (httpd), the 
project (the apache http server project), or just your interactions with 
the people involved. Please keep it concise, as we wouldn't want to 
force the board to go through 150 pages :)


With very warm regards,
Daniel.

Ignore the GitHub email...

2019-12-10 Thread Daniel Gruno


That was me trying to get travis notifications working...

Re: Travis CI failures

2019-12-09 Thread Daniel Gruno


On 08/12/2019 20.12, Luca Toscano wrote:

Il giorno dom 1 dic 2019 alle ore 12:05 Luca Toscano
 ha scritto:


Travis seems not able to deliver emails to dev@, I opened a jira to
Infra: https://issues.apache.org/jira/browse/INFRA-19508


It was suggested to ask a moderator of httpd-dev@ to approve one of
the Travis emails as way to fix this issue. I am not aware of who is a
moderator, but if anybody is I'd ask to follow up when possible :)

Thanks in advance,

Luca



Looks like dev@httpd has to be verified somehow...I'll see what I can find.

Re: modify bugzilla resolved statuses?

2019-11-12 Thread Daniel Gruno


On 12/11/2019 13.57, Eric Covener wrote:

On Tue, Nov 12, 2019 at 7:47 AM Daniel Gruno  wrote:


On 12/11/2019 13.29, Eric Covener wrote:

Is there a way to add new sub-statuses under Resolved in our bugzilla?

It would be nice to have something kind of neutral for things that are
essentially answered questions rather than "invalid" or
"worksforsome".  I think "invalid" is kind of impolite and invites
argumentation.



Yes, how about 'INFORMATIONPROVIDED' ?


That helps, or even "CLOSED"



Added both for good measure :)

Re: modify bugzilla resolved statuses?

2019-11-12 Thread Daniel Gruno


On 12/11/2019 13.29, Eric Covener wrote:

Is there a way to add new sub-statuses under Resolved in our bugzilla?

It would be nice to have something kind of neutral for things that are
essentially answered questions rather than "invalid" or
"worksforsome".  I think "invalid" is kind of impolite and invites
argumentation.



Yes, how about 'INFORMATIONPROVIDED' ?

Re: Migrate to git?

2019-10-14 Thread Daniel Gruno


On 14/10/2019 09.51, Stefan Sperling wrote:

On Mon, Oct 14, 2019 at 03:27:31PM +0100, Joe Orton wrote:

At the moment I think we have a quality control problem for 2.4.x, yet I
find it hard to justify spending much time on writing test cases because
that stuff is run so rarely.  How many tests proposed in 2.4.x STATUS
have had a full test suite run?  I certainly don't always do it.  But if
we get the tests running all the time automatically it's much easier to
see a return on investment for improving test coverage.


I see there's already a buildbot job for httpd trunk:
https://ci.apache.org/waterfall?tag=httpd-trunk
It seems this build job is configured to run a compile but it does not
run the test suite? Putting Github/Travis questions aside, an easy way
to get automated tests going with minimal effort today could be to run
the existing tests inside httpd's existing buildbot job.


Infra is in the midst of setting up a new buildbot 2 service with 
automated builds sort of like what travis does. It's not ready for prime 
time just yet, but within a month or so, we should be able to directly 
configure and trigger dynamic builds/tests via a yaml file in our repo.




The Subversion project has been doing this for years.
See https://subversion.apache.org/buildbot/all

Re: Migrate to git?

2019-10-07 Thread Daniel Gruno


On 07/10/2019 14.48, Ruediger Pluem wrote:



On 10/06/2019 06:51 PM, Roy T. Fielding wrote:

On Oct 5, 2019, at 1:09 PM, Jim Jagielski  wrote:

Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)


I don't like git. I don't like isolating work on branches. If we want to work 
on it as a base,
we need to agree on how to manage the release branches first and their names 
(so that
the existing history can be merged accordingly).

I hate our existing bugzilla blackhole and manual process of PRs.

I do like Github. I like the flexibility and openness of Github issues and 
tracking with commits.
I like the PRs and review mechanisms.  I am not sure what to do about security 
issues.


Working on other projects recently I was impressed how much of the contribution 
legwork
that we do manually today can be done by Github processes and I was impressed by
the review process possibilities via PR.
This is a big plus over how we have to handle contributions today.
But this also means we can only really benefit if we fully leverage PR and GH 
issues for our workflows.

Apart from Github I still like Subversion more than git, especially the lean 
working copies and the immutable
history.


I don't know how to handle folks who don't have Github IDs already (or don't 
want them).

Currently, I am +0 on the idea, but +1 if the way forward is worked out and the 
process
of migrating history is extensively automated/tested first.  I did that for 
httpwg and it was
a pain in the ass even with only five committers.  But it can be done.


Did I get it correct from Daniel, that this issue is already solved?
But looking at one of my recent Subversion commits (r1866078 / 
cb8c40c581d17382cba338b3d90c67b914648984)
that happened after I joined the Apache Org on Github does not show my Github 
user as committer
(it only mentions my full name, so there is some connection).


To me, when I look at the commit[1], it links to your github account[2] 
if you click on the user avatar.



@Daniel: Is this the issue to be fixed on Oct 12th?
All in all I am currently +0.


What is being fixed on october 12th is the live sync of the git mirror 
after the catastrophic data center failure we had in september[3].



[1] 
https://github.com/apache/httpd/commit/cb8c40c581d17382cba338b3d90c67b914648984

[2] https://github.com/rpluem
[3] https://blogs.apache.org/infra/entry/subversion-to-git-service-git

Re: Migrate to git?

2019-10-07 Thread Daniel Gruno

On 06/10/2019 17.59, Nick Kew wrote:

On 6 Oct 2019, at 04:06, Daniel Gruno wrote:

On 05/10/2019 19.30, Nick Kew wrote:

If it moves to github, how and at what level is history preserved? Github can do
alarming things with history even for a project that's always been there!

We would have the exact same level of history as before (one might even say
we'll get more history, as you can specify committer and author separately in
git). If you look at https://github.com/apache/httpd which is our current git
mirror, it should have the exact same commits going back to 1996 as the
subversion repository. There is a bit of a lag on the mirror right now, but
that is a separate issue that will be fixed on October 12th.

OK, I've just dug up an example in an Apache/Github project. A simple renaming
of a source file, that with "svn mv" would have preserved history, seems to have
essentially wiped its past. 'History' is highly misleading, 'Blame' is 100%
wrong!

It would be 100% wrong in svn as well if the same operation had been
performed there, as it wasn't a move - the number of lines don't match
up. There is a `git mv` just like `svn mv` that preserves history, AIUI.
A file where `svn mv` was actually used [1] shows that the history is
preserved through the mv operation and blame works as intended, even in git.

https://github.com/apache/trafficserver/blob/master/plugins/experimental/stream_editor/stream_editor.cc

And that's within git: no actual change-of-repos involved.

Regarding httpd, we have the git mirror, so access is available through whatever
a contributor prefers. How is that not best-of-both-worlds?

As Eric alluded to, it's much less about svn versus git than it is about
tapping into the community on GitHub. If there was an svnhub, I'd be all
for that as an easier way to do this, but alas no.

[1]
https://github.com/apache/httpd/blame/dc8ed8a7df9edbe9340a1bc5f01501dbd60e8366/server/mpm/beos/config5.m4

Re: Migrate to git?

2019-10-05 Thread Daniel Gruno


On 05/10/2019 19.30, Nick Kew wrote:




On 5 Oct 2019, at 21:09, Jim Jagielski  wrote:

Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)

Cheers!


[apologies if this appears twice.  Just sent with wrong from: address so I 
expect
apache to bounce it.  I'm still on limited 'net connectivity since my house 
move -
ISP due on Oct 14th to install proper connection].

If it moves to github, how and at what level is history preserved? Github can do
alarming things with history even for a project that's always been there!


We would have the exact same level of history as before (one might even 
say we'll get more history, as you can specify committer and author 
separately in git). If you look at https://github.com/apache/httpd which 
is our current git mirror, it should have the exact same commits going 
back to 1996 as the subversion repository. There is a bit of a lag on 
the mirror right now, but that is a separate issue that will be fixed on 
October 12th.


There is also, as you mention, the risk of force-pushing to rewrite 
history, but as I understand it, we can disable this by requiring PRs 
for each change to the canonical branch(es).


The old subversion history would also be retained on the svn master.



Don't we have an svn-git gateway?  If that's not best-of-both-worlds, why not?

Re: Migrate to git?

2019-10-05 Thread Daniel Ferradal

Hello,

Although I am not precisely active now using the repos due to time
constraints I would also feel it would be a good move. So FWIW, +1 if
I may.

El sáb., 5 oct. 2019 a las 22:36, Rich Bowen () escribió:
>
> With my community development hat on, a big +1 even though I hate Git.
>
> Shosholoza,
> Rich
>
>
> On Sat, Oct 5, 2019, 16:09 Jim Jagielski  wrote:
>>
>> Various PMCs have made their default/de-facto SCM git and have seen an 
>> increase in contributions and contributors...
>>
>> Is this something the httpd project should consider? Especially w/ the 
>> foundation officially supporting Github, it seems like time to have a 
>> discussion about it, especially as we start thinking about the next 25 years 
>> of this project :)
>>
>> Cheers!



-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

Re: Migrate to git?

2019-10-05 Thread Daniel Gruno


On 05/10/2019 15.09, Jim Jagielski wrote:

Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)

Cheers!



I'd be quite okay with this move - it was IIRC proposed a year or two 
ago as well, but didn't gain much traction.


On a related note (sorry for the segue), we should probably also look at 
the web site repo, perhaps split that into a separate git repo if we do 
make the move, as the CMS system will go away at some point.

Re: Integration tests running on Docker

2019-09-25 Thread Daniel Ferradal

+1's!

Thanks Luca, looking great!

El mié., 25 sept. 2019 a las 12:44, Stefan Eissing
() escribió:
>
> +1
>
> I like this a lot. Having a maintained docker setup at hand to run tests in 
> controlled setups is super good.
>
> If you get this going for the main test suite, I will be more than happy to 
> contribute with setups for the mod_h2 and mod_md test suites. Those are part 
> of the github repros only.
>
> Cheers, Stefan
>
> > Am 25.09.2019 um 11:52 schrieb Luca Toscano :
> >
> > Does the above make sense or it is completely out of scope for our
> > project? In the former case I could spend some time on figuring out
> > how to create what I proposed above, otherwise I'll stop and drop the
> > idea :)
> >
>


-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

Re: CVE-2019-10097 vs. CHANGEs entry

2019-08-17 Thread Daniel Ruggeri

Ah, yes... Not sure how I made that error. Just fixed!
-- 
Daniel Ruggeri

On August 17, 2019 9:41:42 AM CDT, Stefan Fritsch  wrote:
>Hi,
>
>Shouldn't CVE-2019-10097 be listed under 2.4.41, too?
>
>Cheers,
>Stefan
>
>--- httpd/httpd/branches/2.4.x/CHANGES 2019/08/14 20:43:00 1865188
>+++ httpd/httpd/branches/2.4.x/CHANGES 2019/08/14 20:52:45 1865189
>@@ -1,8 +1,39 @@
>  -*- coding:
>utf-8 -*-
> Changes with Apache 2.4.42
>
>+  *) SECURITY: CVE-2019-10097 (cve.mitre.org)
>+ mod_remoteip: Fix stack buffer overflow and NULL pointer
>deference
>+ when reading the PROXY protocol header.  [Joe Orton,
>+ Daniel McCarney ]
>+
> Changes with Apache 2.4.41
>
>+  *) SECURITY: CVE-2019-9517 (cve.mitre.org)
>+ mod_http2: a malicious client could perform a DoS attack by
>flooding
>+a connection with requests and basically never reading
>responses
>+on the TCP connection. Depending on h2 worker dimensioning, it
>was
>+possible to block those with relatively few connections.
>[Stefan Eissing]
>+

[RESULT][VOTE] Release httpd-2.4.41

2019-08-12 Thread Daniel Ruggeri

Hi, all;
   It is my pleasure to confirm that we have received enough votes to
PASS the release of httpd-2.4.41! As always, I thank everyone for their
diligence in testing this release and am very happy we caught the minor
regression during 2.4.40 validation cycles to prevent a potentially
impacting situation for users. Awesome, y'all!

I detected the following +1 votes:
PMC
jailletc36, druggeri, humbedooh, icing, steffenal, jim, covener, jorton,
rjung

Community
Dennis Clarke, Noel Butler

No -1 votes were recorded.

I will begin the process of promoting the release to the dist locations
and will prep for announcement in 48-ish hours.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.41

2019-08-10 Thread Daniel Gruno


+1 From me as well.
A few snags with lua, but that's very platform specific and doesn't 
affect the vote. I should probably look into better compat with 5.3 later :)



On 8/9/19 11:25 PM, Daniel Ruggeri wrote:



On 2019/08/09 13:40:38, 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


+1 from me.

Tested under the following conditions...

system:
   kernel:
 name: Linux
 release: 4.9.0-8-amd64
 version: #1 SMP Debian 4.9.144-3 (2019-02-02)
 machine: x86_64

   libraries:
 openssl: "1.1.1c"
 openldap: "2.4.48"
 apr: "1.7.0"
 apr-util: "1.6.1"
 iconv: "1.2.2"
 brotli: "1.0.7"
 nghttp2: "1.39.1"
 zlib: "1.2.11"
 pcre: "8.43"
 libxml2: "2.9.9"
 php: "7.3.8"
 lua: "5.3.5"
 curl: "7.65.3"

Re: [VOTE] Release httpd-2.4.41

2019-08-09 Thread Daniel Ruggeri




On 2019/08/09 13:40:38, 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

+1 from me.

Tested under the following conditions...

system:
  kernel:
name: Linux
release: 4.9.0-8-amd64
version: #1 SMP Debian 4.9.144-3 (2019-02-02)
machine: x86_64

  libraries:
openssl: "1.1.1c"
openldap: "2.4.48"
apr: "1.7.0"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.7"
nghttp2: "1.39.1"
    zlib: "1.2.11"
pcre: "8.43"
libxml2: "2.9.9"
php: "7.3.8"
lua: "5.3.5"
curl: "7.65.3"

-- 
Daniel Ruggeri

[VOTE] Release httpd-2.4.41

2019-08-09 Thread Daniel Ruggeri

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: [NOTICE] Intent to T 2.4.41 in ~24 hrs

2019-08-08 Thread Daniel Ruggeri

Yessir. I'll send a notification when ready.
-- 
Daniel Ruggeri

On August 8, 2019 11:54:18 AM CDT, Dennis Clarke  wrote:
>On 8/8/19 7:41 AM, Daniel Ruggeri wrote:
>> Hi, all;
>> As the subject says, I'd like to get on with our 2.4.new release now
>> that we're good to go. Will kick things off in about 24 hours
>
>Tarballs will be in the usual places ??
>
>
>
>-- 
>Dennis Clarke
>RISC-V/SPARC/PPC/ARM/CISC
>UNIX and Linux spoken
>GreyBeard and suspenders optional

Re: svn commit: r1864701 - /httpd/httpd/branches/2.4.x/STATUS

2019-08-08 Thread Daniel Ruggeri

+1
-- 
Daniel Ruggeri

On August 8, 2019 8:09:57 AM CDT, Eric Covener  wrote:
>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

[NOTICE] Intent to T 2.4.41 in ~24 hrs

2019-08-08 Thread Daniel Ruggeri

Hi, all;
   As the subject says, I'd like to get on with our 2.4.new release now that 
we're good to go. Will kick things off in about 24 hours
-- 
Daniel Ruggeri

[RESULT] [VOTE] Release httpd-2.4.40

2019-08-05 Thread Daniel Ruggeri

Hi, All;
   As discussed on this list, a minor regression has been detected with a fix 
in flight. I'll go ahead and terminate this release vote and will plan to T 
again in the near future with the fix in place.

Thanks to all who prepped for testing. Keep those testing rigs warm - we'll be 
back again soon!
-- 
Daniel Ruggeri

On August 3, 2019 8:51:07 AM CDT, 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: [VOTE] Release httpd-2.4.40

2019-08-05 Thread Daniel Ruggeri

Thanks, Jan;
   I'm afraid I have no way to verify or dig into Windows-specific issues. Can 
you share more information or errors that can help, or is this related to the 
things already discussed on the list?
-- 
Daniel Ruggeri

On August 4, 2019 6:33:58 AM CDT, Jan Ehrhardt  wrote:
>Gregg Smith in gmane.comp.apache.devel (Sat, 3 Aug 2019 08:43:21
>-0700):
>>Opps, looks like the APLOGNO's didn't get filled in. I'm still ok with
>
>>releasing .40 w/o them.
>>
>>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'
>
>My conclusion after testing a lot of Visual Studio builds: mod_md.so is
>broken. At least on Windows, but probably on any other OS as well. Do
>not release this version.
>-- 
>Jan

Re: svn commit: r1856807 - /httpd/test/framework/trunk/t/security/CVE-2019-0215.t

2019-08-04 Thread Daniel Ruggeri



On 8/4/2019 3:30 AM, Rainer Jung wrote:
> Hi there,
>
> this one fails for me when the server uses OpenSSL 1.1.1 (no other
> variant tested yet) but the client uses something before 1.1.1. In
> this case I get Status 500 instead of the expected 403 in the client.
>
> Another older test t/security/CVE-2005-2700.t uses
>
> ok !t_cmp($r->code, 200, "...
>
> instead of
>
> ok t_cmp($r->code, 403, "...
>
> used in the new test. Do others observe the same problem? Should we
> relax the condition on 403 or 500, or is it necessary to only relax if
> client isn't using 1.1.1 (or maybe depending on effective TLS version)?

I also see the same problem. The 500 must be coming from the LWP client
rather than httpd, though, as httpd does log the 403. I would prefer to
skip the test for non-compatible clients rather than for the internal
client error to be treated as a "pass" of a test it cannot run.

-- 
Daniel Ruggeri

>
> Regards,
>
> Rainer
>
> Am 02.04.2019 um 12:44 schrieb jor...@apache.org:
>> Author: jorton
>> Date: Tue Apr  2 10:44:12 2019
>> New Revision: 1856807
>>
>> URL: http://svn.apache.org/viewvc?rev=1856807=rev
>> Log:
>> Add test case for CVE-2019-0215.
>>
>> Added:
>>  httpd/test/framework/trunk/t/security/CVE-2019-0215.t
>>
>> Added: httpd/test/framework/trunk/t/security/CVE-2019-0215.t
>> URL:
>> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/security/CVE-2019-0215.t?rev=1856807=auto
>> ==
>>
>> --- httpd/test/framework/trunk/t/security/CVE-2019-0215.t (added)
>> +++ httpd/test/framework/trunk/t/security/CVE-2019-0215.t Tue Apr  2
>> 10:44:12 2019
>> @@ -0,0 +1,26 @@
>> +use strict;
>> +use warnings FATAL => 'all';
>> +
>> +use Apache::Test;
>> +use Apache::TestUtil;
>> +use Apache::TestRequest;
>> +
>> +my $vars = Apache::Test::vars();
>> +
>> +plan tests => 2, need $vars->{ssl_module_name}, need_lwp,
>> +    qw(LWP::Protocol::https);
>> +
>> +Apache::TestRequest::user_agent_keepalive(1);
>> +Apache::TestRequest::scheme('https');
>> +Apache::TestRequest::module('ssl_optional_cc');
>> +
>> +my $r;
>> +
>> +$r = GET "/require/any/";
>> +
>> +ok t_cmp($r->code, 403, "first access denied without ccert");
>> +
>> +$r = GET "/require/any/";
>> +
>> +ok t_cmp($r->code, 403, "second access denied without ccert");
>> +

[VOTE] Release httpd-2.4.40

2019-08-03 Thread Daniel Ruggeri

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: Vote thread for 2.4.40 not started yet?

2019-08-03 Thread Daniel Ruggeri

Ahhh! I did send a VOTE email, but it looks like it never made it
through to the list!

I will retry from my ASF address through the ASF mail relay...

Date: Fri, 02 Aug 2019 15:18:57 -0500
From: Daniel Ruggeri 
To: dev@httpd.apache.org
Subject: [VOTE] Release httpd-2.4.40
Message-ID: 
X-Sender: drugg...@primary.net
User-Agent: Roundcube Webmail/0.9.2

-- 
Daniel Ruggeri

On 8/3/2019 6:43 AM, Rainer Jung wrote:
> Hi Daniel,
>
> did you forget to start the vote thread or are the uploads not ready yet?
>
> Thanks and regards,
>
> Rainer
>
> Am 02.08.2019 um 22:18 schrieb drugg...@apache.org:
>> Author: druggeri
>> Date: Fri Aug  2 20:18:19 2019
>> New Revision: 35120
>>
>> Log:
>> Add 2.4.40 files
>>
>> Added:
>>  dev/httpd/CHANGES_2.4
>>  dev/httpd/CHANGES_2.4.40
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2   (with props)
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.asc
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.md5
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.40-deps.tar.gz   (with props)
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.asc
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.md5
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.sha1
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.sha256
>>  dev/httpd/httpd-2.4.40.tar.bz2   (with props)
>>  dev/httpd/httpd-2.4.40.tar.bz2.asc
>>  dev/httpd/httpd-2.4.40.tar.bz2.md5
>>  dev/httpd/httpd-2.4.40.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.40.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.40.tar.gz   (with props)
>>  dev/httpd/httpd-2.4.40.tar.gz.asc
>>  dev/httpd/httpd-2.4.40.tar.gz.md5
>>  dev/httpd/httpd-2.4.40.tar.gz.sha1
>>  dev/httpd/httpd-2.4.40.tar.gz.sha256
>> Modified:
>>  dev/httpd/Announcement2.4.html
>>  dev/httpd/Announcement2.4.txt
>>
>> Modified: dev/httpd/Announcement2.4.html
>> ==
>>
>> --- dev/httpd/Announcement2.4.html (original)
>> +++ dev/httpd/Announcement2.4.html Fri Aug  2 20:18:19 2019
>> @@ -49,7 +49,7 @@
>>   
>>     
>> -   Apache HTTP Server 2.4.39 Released
>> +   Apache HTTP Server 2.4.40 Released
>>   
>>   
>>  September 21, 2018
>> @@ -57,7 +57,7 @@
>>   
>>  The Apache Software Foundation and the Apache HTTP Server
>> Project are
>>  pleased to > href="https://www.apache.org/dist/httpd/Announcement2.4.html;>announce
>> -   the release of version 2.4.39 of the Apache
>> +   the release of version 2.4.40 of the Apache
>>  HTTP Server ("Apache").  This version of Apache is our latest GA
>>  release of the new generation 2.4.x branch of Apache HTTPD and
>>  represents fifteen years of innovation by the project, and is
>> @@ -69,7 +69,7 @@
>>  encourage users of all prior versions to upgrade.
>>   
>>   
>> -   Apache HTTP Server 2.4.39 is available for download from:
>> +   Apache HTTP Server 2.4.40 is available for download from:
>>   
>>   
>>     https://httpd.apache.org/download.cgi;
>> @@ -77,7 +77,7 @@
>>   
>>   
>>  Please see the CHANGES_2.4 file,
>> linked from the download page, for a
>> -   full list of changes.  A condensed list, > href="./CHANGES_2.4.39">CHANGES_2.4.39 includes only
>> +   full list of changes.  A condensed list, > href="./CHANGES_2.4.40">CHANGES_2.4.40 includes only
>>  those changes introduced since the prior 2.4 release.  A summary
>> of all
>>  of the security vulnerabilities addressed in this and earlier
>> releases
>>  is available:
>>
>> Modified: dev/httpd/Announcement2.4.txt
>> ==
>>
>> --- dev/httpd/Announcement2.4.txt (original)
>> +++ dev/httpd/Announcement2.4.txt Fri Aug  2 20:18:19 2019
>> @@ -1,9 +1,9 @@
>> -    Apache HTTP Server 2.4.39 Released
>> +    Apache HTTP Server 2.4.40 Released
>>    September 21, 2018
>>    The Apache Software Foundation and the Apache HTTP Server Project
>> -   are pleased to announce the release of version 2.4.39 of the Apache
>> +   are pleased to announce the release of version 2.4.40 of the Apache
>>  HTTP Server ("Apache").  This version of Apache is our latest GA
>>  release of the new generation 2.4.x branch of Apache HTTPD and
&g

Re: NOTICE: Intent to T Friday

2019-08-01 Thread Daniel Ruggeri

Hrm... I see this never made it to the list! Retrying from my apache.org 
address...
-- 
Daniel Ruggeri
Director, VP Fundraising, member, httpd PMC
The Apache Software Foundation

On July 31, 2019 8:18:41 AM CDT, Daniel Ruggeri  wrote:
>Hi, all
>I see we have a number of backports ready to go for 2.4.next. I would
>like to go ahead and tag and roll a release Friday morning. Assuming
>there are no objections, I will aim to do this in the morning Central
>us time.
>
>Feel free to start gearing up your test environments!
>-- 
>Daniel Ruggeri

Re: libcrurl

2019-06-20 Thread Daniel Ferradal

It seems there may have been certain misunderstanding.

Daniel Stenberg published this tweet linking to googler apologizing
for the mess in his twitter account:
https://twitter.com/bagder/status/1141653215685087232
And the link of the apology: https://news.ycombinator.com/item?id=20228237

El mié., 19 jun. 2019 a las 22:37, Dennis Clarke
() escribió:
>
> On 6/19/19 10:13 AM, Stefan Eissing wrote:
> > I just want to mention that I have no plans to adapt the upcoming Chrome 
> > library libcrurl (see 
> > https://daniel.haxx.se/blog/2019/06/19/google-to-reimplement-curl-in-libcrurl/
> >  ).
> >
> > And, boy, do I hope they have no plans to do the same with our product 
> > names.
> >
>
> If one waits long enough we get to see the same behavior repeat itself
> over and over and over. Same as the '90s with Microsoft where they would
> adopt some defacto standard, extend it well out beyond what the original
> standard ever did and then kill the original.  However MS were unable to
> kill TCP/IP and failed in many ways with many of their little ideas. So
> this behavior by Google is just ... silly. At best. Stupid would be a
> better word.  It may be time to stop using Chrome everywhere and just be
> good open source humans and focus on the upstream FireFox which works
> just awesome everywhere.  My 0.02bt worth.
>
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional



-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

[COMPLETED] Migrating our wiki

2019-05-22 Thread Daniel Gruno

Our wiki was successfully transferred to the confluence service, and is 
available at: https://cwiki.apache.org/confluence/display/HTTPD


All httpd committers should have write access to it, and I'll look into 
how we lock down the old wiki.


With regards,
Daniel.

On 21/05/2019 13.13, Dennis Clarke wrote:

On 5/21/19 1:00 PM, Daniel Gruno wrote:

On 21/05/2019 12.51, Dennis Clarke wrote:

On 5/21/19 12:32 PM, Daniel Gruno wrote:

Hi folks,
looks like we have to migrate our moin wiki to confluence in the 
coming weeks. Unless there are objections, I'll file a self-serve 
request to start migration tomorrow, and within a day or two, we 
should have it all moved to confluence, with LDAP permissions for us.


Does this imply that jira is used for task tracking also?  That usually
travels hand in hand with confluence.



We do not have any current plans to migrate from bugzilla.



Thank you for that !  As much as I love jira for tasks and projects it
is over kill for bug tracking.

dc

Re: Migrating our wiki

2019-05-21 Thread Daniel Gruno


On 21/05/2019 12.51, Dennis Clarke wrote:

On 5/21/19 12:32 PM, Daniel Gruno wrote:

Hi folks,
looks like we have to migrate our moin wiki to confluence in the 
coming weeks. Unless there are objections, I'll file a self-serve 
request to start migration tomorrow, and within a day or two, we 
should have it all moved to confluence, with LDAP permissions for us.


Does this imply that jira is used for task tracking also?  That usually
travels hand in hand with confluence.



We do not have any current plans to migrate from bugzilla.

Migrating our wiki

2019-05-21 Thread Daniel Gruno


Hi folks,
looks like we have to migrate our moin wiki to confluence in the coming 
weeks. Unless there are objections, I'll file a self-serve request to 
start migration tomorrow, and within a day or two, we should have it all 
moved to confluence, with LDAP permissions for us.

DRuggeri has a new PGP key

2019-05-11 Thread Daniel Ruggeri

Hi, all;
   As signers or users of my GPG pubkey, I wanted to inform you that I
have generated a new PGP key (DC55C003). I will no longer use my
previous PGP key (1AD84DFF) after this message and am deleting the
private component. Please find the details of the new key below.

pub   4096R/DC55C003 2019-05-11
  Key fingerprint = E348 0043 5956 21FE 5610  5F11 2AB1 2A7A DC55 C003
uid  Daniel Ruggeri (http://home.apache.org/~druggeri/)

uid  Daniel Ruggeri 
uid  [jpeg image of size 13027]
sub   4096R/14FF4720 2019-05-11


It would be appreciated if you could sign the new key *if you trust the
following measures to establish identity*:
 - This message is signed with the previous PGP private key
 - The new key is signed by the previous key and is published to
pgp.mit.edu
 - I committed the new pubkey to
https://dist.apache.org/repos/dist/release/httpd/KEYS in r33993
 - The new key has been added to my ASF LDAP listing (and will be
visible in the next 24 hours) at
https://home.apache.org/keys/committer/druggeri
 - This message was sent through The ASF's mail relay system

Thanks!
-- 
Daniel Ruggeri
Director, VP Fundraising, member, httpd PMC
The Apache Software Foundation





signature.asc
Description: OpenPGP digital signature

1 2 3 4 5 6 7 8 9 >

1 - 100 of 887 matches

Mail list logo