As described in apache issue 49838 mod_remoteip may cause segfaults when used together with .htaccess files and allow/deny statements. https://issues.apache.org/bugzilla/show_bug.cgi?id=49838 The bugzilla report also mentions the two official bugfixes r990745: http://svn.apache.org/viewvc?view=revision&revision=990745 and r990746: http://svn.apache.org/viewvc?view=revision&revision=990746 These two small bugfixes can be applied without any further changes to this FreeBSD port as well to avoid apache httpd segfaults. Although Apache 2.4 should be preferred over Apache 2.2, some people might still have to use Apache 2.2 for compatibility reasons together with some kind of load balancer or reverse proxy in front. In such situations this backport of mod_remoteip gets very handy. Please consider adding these two bugfixes.
Asking for maintainer feedback.
This timed out weeks ago. I don't see any activity from the maintainer since 2010, so I think the port should be reset. However, David, you didn't do yourself any favors by not providing a patch as an attachment. Had you done this, I would have moved this to patch-ready status. If you do it now, I'll move it to patch-ready status and it will be fast-tracked to be added. But don't ask volunteer committers that don't care about this particular port to do extra work to create patches and expect it to happen. Make your own luck.
I'm fine with applying the patches. I just haven't had a chance to actually turn them into a patch for this ticket.
Created attachment 148835 [details] Modified patch including upstream bugfix
I really appreciate the work of all FreeBSD volunteers and my aim was certainly not to let things get done by other people. Though I administrate several FreeBSD servers with pleasure I do not have any experiences with the ports tree from a developers point of view. Hence I hoped that someone being familiar with the ports tree might pick this up (most like the maintainer of this port). I did not receive an explicit notification from bugzilla about a timeout of this PR (if there is such a timeout notification). I am very sorry about that. However, to provide you something useful, I have attached a final patch which could be submitted to the ports tree without any further modifications. The port www/mod_remoteip already contains a patch files/patch-modules__metadata__mod_remoteip.c. I have extended this patch so it also includes the bugfix mentioned here. Someone could replace the existing patch file with the one I have attached. Is this fine for you to declare it as patch-ready or do you need anything else?
okay, this is better but not really ideal. You provide a patch to the software, but this should have been a patch to the port. In other words, your patch should have created a file that inserts a patch file at www/mod_remoteip/files. So the committer that takes this will have to download the attachment, rename it something like patch-modules_metadata_mod__remoteip.c and then move it into patch instead of using something like "svn patch". anyway, now that Jim has piped up, I'll give him more time to approve this the attachment.
(In reply to David Froehlich from comment #5) > I did not receive an explicit notification from bugzilla about a > timeout of this PR (if there is such a timeout notification). I am very > sorry about that. Hi David, the "time out" is marked against the maintainer, not you. He had two weeks to reply. > files/patch-modules__metadata__mod_remoteip.c. I have extended this patch so > it also includes the bugfix mentioned here. Someone could replace the > existing patch file with the one I have attached. Is this fine for you to > declare it as patch-ready or do you need anything else? Well, now the maintainer has to approve and we'd really like a patch against the port -- something that shows how the existing patch gets modified. The maintainer could also submit it.
Created attachment 148882 [details] svn diff against ports tree
Much better. For a perfect "ten", the diff would have also had a patch for the Makefile to bump the PORTREVISION by one. (this change requires a revbump). However, the committer can do also do it
I see, thanks for your explanations, John. I tried myself in creating a svn diff containing my suggested changes (cf. attachment 148882 [details]). I checked out the ports tree using svn like described in the FreeBSD svn handbook, modified the file, and created a diff using 'svn diff'. So the resulting patch should now be ready to use with 'svn patch' by someone who can commit this to the official ports repository. (I myself do not have an account and/or write permissions to the repository.) PS: Good hint regarding the revbump which of course makes sense. At least now I know how to provide proper patches for the next time. Thank you.
i think I meant to promote this, doing it now.
A commit references this bug: Author: marino Date: Sun Nov 9 08:15:15 UTC 2014 New revision: 372343 URL: https://svnweb.freebsd.org/changeset/ports/372343 Log: www/mod_remoteip: fix segfault with .httaccess and allow/deny As described in Apache issue 49838, mod_remoteip may cause segfaults when used together with .htaccess files and allow/deny statements The existing patch was modified to backport fixes from Apache svn r990745 and r990746. PR: 193507 Submitted by: David Froehlich Approved by: maintainer (Jim Riggs) Changes: head/www/mod_remoteip/Makefile head/www/mod_remoteip/files/patch-modules__metadata__mod_remoteip.c
I regenerated the patch with "make makeplist" to get the standard "UTC" headers and the "diff -up" format. No content difference of course. This PR is done, thanks.