Re: mpm-itk and upstream Apache, once again
On Sun, Jul 22, 2012 at 09:57:18PM +0200, Stefan Fritsch wrote: And if it gets secured to where a code execution exploit does not grant full root rights, I would probably be in favor of including it with httpd. I took a look using seccomp for this, and it would seem it is actually rather hard; you can limit setuid() and setgid() easily enough to a range (so that you'd typically exclude root, daemon and other low-uid stuff), but setgroups() takes in a pointer of supplementary gids to add. I can't find any good ways of looking into that list, so it would seem a rogue process could arbitrarily add any gid (like, 0) to its list. So it seems to be hard to properly restrict gid, but maybe restricting uid would already give a significant win? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: mergeinfo ignorance
I for sure don't use 'svn merge' and am likely guilty (and the orig post clearly indicates) of this... For awhile, svn merge was as wonky as hell, so I simply skipped using it and instead used the svn.merge script which, for the curious, does a simple diff and patch. I'm guessing that things are better now ;) On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote: On 22.07.2012 16:59, Eric Covener wrote: CAUTION: Always merge into a clean branch checkout and commit the whole branch. If you start to only commit parts of the branch after merging, svn will produce additional mergeinfo properties attached to sub directories or files. We don't want that. I might be a culprit here, I use someones svn.merge script in a not so clean checkout but then checkin individual files. Will work on it. No culprit. At least in 2.4.x there is currently only one mergeinfo, all is fine :) Regards, Rainer
Re: mpm-itk and upstream Apache, once again
On Thu, Jul 19, 2012 at 04:17:44PM +0200, Steinar H. Gunderson wrote: Furthermore, Fedora has recently accepted the mpm-itk patch into their Apache packages. For the record, that is not accurate. The Fedora httpd package does not contain the mpm-itk patch, I have repeatedly refused to add it since it makes changes to core httpd which need to go through upstream review. Using such arguments to bully upstream into taking patches is not a great way to build goodwill, IMO. Somebody has apparently added a completely separate httpd-itk package which does include the patch, which is totally dumb IMO, but we (Fedora) apparently don't legislate against that in the review process. Regards, Joe
svnmerge.py (Was: Re: mergeinfo ignorance)
Is this still useful: svnmerge.py ? http://www.orcaware.com/svn/wiki/Svnmerge.py On Jul 23, 2012, at 8:45 AM, Jim Jagielski wrote: I for sure don't use 'svn merge' and am likely guilty (and the orig post clearly indicates) of this... For awhile, svn merge was as wonky as hell, so I simply skipped using it and instead used the svn.merge script which, for the curious, does a simple diff and patch. I'm guessing that things are better now ;) On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote: On 22.07.2012 16:59, Eric Covener wrote: CAUTION: Always merge into a clean branch checkout and commit the whole branch. If you start to only commit parts of the branch after merging, svn will produce additional mergeinfo properties attached to sub directories or files. We don't want that. I might be a culprit here, I use someones svn.merge script in a not so clean checkout but then checkin individual files. Will work on it. No culprit. At least in 2.4.x there is currently only one mergeinfo, all is fine :) Regards, Rainer
Re: svnmerge.py (Was: Re: mergeinfo ignorance)
On 23.07.2012 17:55, Jim Jagielski wrote: Is this still useful: svnmerge.py ? http://www.orcaware.com/svn/wiki/Svnmerge.py A quick check of http://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/svnmerge/ and the mailing list activity suggests, that there isn't much going on for the tools since about 2009. There's a user post asking for differences to svn merge at http://www.orcaware.com/pipermail/svnmerge/2011-May/002144.html So it seems it only has limited use nowadays. The tools seems to go back to very early svn days. svn merge isn't too bad IMHO. But YMMV. Regards, Rainer
Re: svnmerge.py (Was: Re: mergeinfo ignorance)
Nah... obsoleted by merge tracking (svn:mergeinfo) with the svn 1.5 release. Please ignore that script and use svn merge. And also that svn is a TLP sibling nowadays can surely help :-) Cheers, -g On Jul 23, 2012 10:56 AM, Jim Jagielski j...@jagunet.com wrote: Is this still useful: svnmerge.py ? http://www.orcaware.com/svn/wiki/Svnmerge.py On Jul 23, 2012, at 8:45 AM, Jim Jagielski wrote: I for sure don't use 'svn merge' and am likely guilty (and the orig post clearly indicates) of this... For awhile, svn merge was as wonky as hell, so I simply skipped using it and instead used the svn.merge script which, for the curious, does a simple diff and patch. I'm guessing that things are better now ;) On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote: On 22.07.2012 16:59, Eric Covener wrote: CAUTION: Always merge into a clean branch checkout and commit the whole branch. If you start to only commit parts of the branch after merging, svn will produce additional mergeinfo properties attached to sub directories or files. We don't want that. I might be a culprit here, I use someones svn.merge script in a not so clean checkout but then checkin individual files. Will work on it. No culprit. At least in 2.4.x there is currently only one mergeinfo, all is fine :) Regards, Rainer
Re: mergeinfo ignorance
On Mon, Jul 23, 2012 at 08:45:47AM -0400, Jim Jagielski wrote: I for sure don't use 'svn merge' and am likely guilty (and the orig post clearly indicates) of this... For awhile, svn merge was as wonky as hell, so I simply skipped using it and instead used the svn.merge script which, for the curious, does a simple diff and patch. The one I use at http://people.apache.org/~jorton/svn.merge does use svn merge correctly (I hope!), possibly an older version didn't? Regards, Joe
Re: mergeinfo ignorance
On 23.07.2012 19:21, Joe Orton wrote:
On Mon, Jul 23, 2012 at 08:45:47AM -0400, Jim Jagielski wrote:
I for sure don't use 'svn merge' and am likely guilty (and the
orig post clearly indicates) of this... For awhile, svn merge
was as wonky as hell, so I simply skipped using it and instead
used the svn.merge script which, for the curious, does a simple
diff and patch.
The one I use at http://people.apache.org/~jorton/svn.merge does use
svn merge correctly (I hope!), possibly an older version didn't?
Nice.
You can nowadays shortcut
-r${prev}:${rev}
by
-c $rev
and no longer need the prev. That was an svn improvement I found very handy.
Regards,
Rainer
ProxyBlock question
Short question: should ProxyBlock apply to the hostname from the request URI, or the hostname of the next hop? Long question: the way ProxyBlock is documented does not make explicit that it is applied to the next hop; it would be natural to expect it is matched against the request URI hostname. In this configuration: ProxyRequests on ProxyBlock badstuff.com ProxyRemote * http://cache.mycorp.com/ cache.mycorp.com is the next hop, so it is cache.mycorp.com which is checked against the -noproxies list, and in that case would never match. I'm struggling to think how that's useful... feature or bug? Implications: a) if the current implementation is the desired behaviour, that needs to be clear in the docs, and mod_proxy_connect doesn't implement it correctly, but that's all simple enough to fix up. b) if it's not the desired behaviour, that's a lot more messy. Regards, Joe
Re: ProxyBlock question
b) if it's not the desired behaviour, that's a lot more messy. I had assumed this was a bug in the checking but apparently never brought it here correctly.
Re: ProxyBlock question
On Mon, Jul 23, 2012 at 03:41:19PM -0400, Eric Covener wrote: b) if it's not the desired behaviour, that's a lot more messy. I had assumed this was a bug in the checking but apparently never brought it here correctly. Ah ha! I hadn't checked the list archives, sorry - you did indeed post on this, and there's even a patch. Thanks Eric, I will take a further look now. Regards, Joe
Re: svnmerge.py (Was: Re: mergeinfo ignorance)
Jim Jagielski wrote on Mon, Jul 23, 2012 at 11:55:32 -0400: Is this still useful: svnmerge.py ? http://www.orcaware.com/svn/wiki/Svnmerge.py For 1.4 repositories (regardless of server software version) yes. I'd not use both svnmerge.py and 'svn merge' on the same branch, that's just asking for trouble/headaches. http://subversion.apache.org/docs/release-notes/1.5#compatibility
Re: [RELEASE CANDIDATE] Apache-Test 1.38-rc1
I can fix it up easily enough if you want to roll an RC2, otherwise I can fix it up after 1.38 is out since this is nothing new. Sure, go ahead and I'll roll RC2. On Mon, Jul 23, 2012 at 1:38 AM, Steve Hay steve@verosoftware.com wrote: Fred Moyer wrote on 2012-07-20: Please download, test, and report back on this Apache-Test 1.38 release candidate. http://people.apache.org/~phred/Apache-Test-1.38-rc1.tar.gz MD5 (Apache-Test-1.38-rc1.tar.gz) = 6fdf8e7221f3c46e68a3e9ab3595505c =item 1.38-rc1 Remove use of Nullsv as per modperl commit 1362399. [Steve Hay] have Apache::TestConfigPerl::configure_inc set up @INC to include ../blib/lib and ../blib/arch if they exist. The bundled Apache::Reload may fail to load Apache2::Const co otherwise when testing. [Torsten Foertsch] Testing with VC++ 2010, Apache 2.2.22, mod_perl 2.0.7 and Perl 5.17.2, I get the same result as Apache-Test-1.37, namely a fail in t\log_watch.t due to $fn being undefined. It's a filename which comes from t_catfile(), which makes use of Win32::GetLongPathName() on WIN32, but that Win32 function returns the undefined value when passed a path that doesn't exist, which is indeed the case here. (That's not a recent change in perl's Win32 function, btw. I tested back to 5.12.2 and that was the same.) I can fix it up easily enough if you want to roll an RC2, otherwise I can fix it up after 1.38 is out since this is nothing new.
