Re: svn commit: r1904638 - in /httpd/httpd/trunk: changes-entries/DAVLockDiscovery.txt modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c

2022-10-27 Thread Greg Stein
On Thu, Oct 27, 2022 at 8:22 AM Emmanuel Dreyfus  wrote:

> On Thu, Oct 27, 2022 at 01:58:58AM -0500, Greg Stein wrote:
> > With that said, I'm not a fan of [DAV or svn] locks. Anything that can be
> > done to avoid a workflow that encompasses locks would be ideal.
>
> For DAV filesystem, we cannot spare locks when clients use LOCK/UNLOCK
> methods. Lock discovery by PROPFIND is another story, I cannot see
> a use case for that.


Agree.


> If you want to see less locks, then you must be great fan of my
> DAVLockDiscovery contribution, especially now it has been updated
> as a flag directive.


Yeup!


> Any chance we get it into 2.4 branch?
>

I'll let others throw in on this. I haven't worked on httpd for quite a
long time.

Cheers,
-g


Re: svn commit: r1904638 - in /httpd/httpd/trunk: changes-entries/DAVLockDiscovery.txt modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c

2022-10-27 Thread Emmanuel Dreyfus
On Thu, Oct 27, 2022 at 01:58:58AM -0500, Greg Stein wrote:
> With that said, I'm not a fan of [DAV or svn] locks. Anything that can be
> done to avoid a workflow that encompasses locks would be ideal.

For DAV filesystem, we cannot spare locks when clients use LOCK/UNLOCK 
methods. Lock discovery by PROPFIND is another story, I cannot see
a use case for that. 

If you want to see less locks, then you must be great fan of my 
DAVLockDiscovery contribution, especially now it has been updated
as a flag directive. Any chance we get it into 2.4 branch?

-- 
Emmanuel Dreyfus
m...@netbsd.org


Re: FasterXML jackson-databind version 2.13.3 vulnerabilities

2022-10-27 Thread Eric Covener
On Thu, Oct 27, 2022 at 3:43 AM Payyavula, Manjula Vani via dev
 wrote:
>
> Hi Team,
>
> Please reply to my below  query.
> We are using FasterXML jackson-databind version 2.13.3 but facing 
> vulnerabilities like CVE-2022-42003
> So we have used FasterXML jackson-databind version 2.14.0-rc1but 
> vulnerabilities hasn't fixed.
> Latest release 2.14.0-rc2 will have fix for these vulnerabilities?
>
> Team, could you please let us know when/which version of future releases 
> these vulnerabilities will have fixed.

Doesn't sound like a problem for dev@httpd.apache.org


FasterXML jackson-databind version 2.13.3 vulnerabilities

2022-10-27 Thread Payyavula, Manjula Vani via dev
Hi Team,

Please reply to my below  query.
We are using FasterXML jackson-databind version 2.13.3 but facing 
vulnerabilities like CVE-2022-42003
So we have used FasterXML jackson-databind version 2.14.0-rc1but 
vulnerabilities hasn't fixed.
Latest release 2.14.0-rc2 will have fix for these vulnerabilities?

Team, could you please let us know when/which version of future releases these 
vulnerabilities will have fixed.

Kindly confirm.

-Original Message-
From: dev-h...@httpd.apache.org 
Sent: Thursday, October 27, 2022 1:02 PM
To: Payyavula, Manjula Vani 
Subject: [External] Already subscribed to dev@httpd.apache.org

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.

Hi! This is the ezmlm program. I'm managing the dev@httpd.apache.org mailing 
list.

Acknowledgment: The address

   manjula.v.payyav...@accenture.com

was already on the dev mailing list when I received your request, and remains a 
subscriber.


--- Administrative commands for the dev list ---

I can handle administrative requests automatically. Please do not send them to 
the list address! Instead, send your message to the correct command address:

To subscribe to the list, send a message to:
   

To remove your address from the list, send a message to:
   

Send mail to the following for info and FAQ for this list:
   
   

Similar addresses exist for the digest list:
   
   

To get messages 123 through 145 (a maximum of 100 per request), mail:
   

To get an index with subject and author for messages 123-456 , mail:
   

They are always returned as sets of 100, max 2000 per request, so you'll 
actually get 100-499.

To receive all messages with the same subject as message 12345, send a short 
message to:
   

The messages should contain one line or word of text to avoid being treated as 
sp@m, but I will ignore their content.
Only the ADDRESS you send to is important.

You can start a subscription for an alternate address, for example 
"john@host.domain", just add a hyphen and your address (with '=' instead of 
'@') after the command word:


To stop subscription for this address, mail:


In both cases, I'll send a confirmation message to that address. When you 
receive it, simply reply to it to complete your subscription.

If despite following these instructions, you do not get the desired results, 
please contact my owner at dev-ow...@httpd.apache.org. Please be patient, my 
owner is a lot slower than I am ;-)

--- Enclosed is a copy of the request I received.

Return-Path: 
Received: (qmail 2616923 invoked by uid 116); 27 Oct 2022 07:32:29 -
Received: from spamproc1-he-de.apache.org (HELO spamproc1-he-de.apache.org) 
(116.203.196.100)  by apache.org (qpsmtpd/0.94) with ESMTP; Thu, 27 Oct 2022 
07:32:29 +
Authentication-Results: apache.org; auth=none
Received: from localhost (localhost [127.0.0.1])
by spamproc1-he-de.apache.org (ASF Mail Server at 
spamproc1-he-de.apache.org) with ESMTP id EBDD71FF65B
for 
;
 Thu, 27 Oct 2022 07:32:28 + (UTC)
X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=6.31
tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001,
SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled
Authentication-Results: spamproc1-he-de.apache.org (amavisd-new);
dkim=pass (2048-bit key) header.d=accenture.com
Received: from mx1-ec2-va.apache.org ([116.203.227.195])
by localhost (spamproc1-he-de.apache.org [116.203.196.100]) 
(amavisd-new, port 10024)
with ESMTP id tHB0FseOkHUC
for 
;
Thu, 27 Oct 2022 07:32:27 + (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=40.107.236.100; 
helo=nam11-bn8-obe.outbound.protection.outlook.com; 
envelope-from=manjula.v.payyav...@accenture.com; receiver=
Received: from NAM11-BN8-obe.outbound.protection.outlook.com 
(mail-bn8nam11on2100.outbound.protection.outlook.com [40.107.236.100])
by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) 
with ESMTPS id 50DCBBBC94
for 
;
 Thu, 27 Oct 2022 07:32:27 + (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;  
b=iF9oAtGlomqo664EPyaP1m7/MNFQ9dML1JbTBZz6HT+Q01DlfpGHdk/sOUPaHwJoQTCyTEUVzMqTVPRZ/gUtiWMv/9cxyIaHOx5uYfMfRI5ZNTgAkN4OQ7KJykwDv1YuQUmXpiTh9DS90L9xdlJOFtZQFsfWM5bvmY/Lfi3N6W9gDsE5a4A1zXKFxhTWBuqpaajantLm91JJVDh6fXsSMWi9abBbP3VeqNC1K7f1DQFRaidBeeo42N81njgso9nP4mM7S5hQbRSVx1XbWPtKX3DvRND4Mec12L1RVauxUmg2rGGNinvkTyaHLdg0+PXrbYcRUvtTKEDygKXWhwkCxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  
s=arcselector9901;  
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 

Re: svn commit: r1904638 - in /httpd/httpd/trunk: changes-entries/DAVLockDiscovery.txt modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c

2022-10-27 Thread Greg Stein
On Wed, Oct 26, 2022 at 1:59 PM Emmanuel Dreyfus  wrote:

> On Tue, Oct 18, 2022 at 05:03:48PM +, Emmanuel Dreyfus wrote:
> > dbm is fast once you have it open. mod_dav_fs opens DAVLockDB on each
> > HTTP request, then it acquire a filesystem level lock on it. This is
> > where contenton occurs.
>

Gotcha. Yes, that makes total sense.


> I have been thinking about how Apache could open DAVLockDB once, instead
> of for each HTTP request. The workers should share a file descriptor
> on the file, and a mutex to avoid concurent access.
>
> That does not fit well with the prefork model. Opending DAVLockDB
> and creating the mutex (a sysV mutex?) should be done in the master
> process. Should it be done when processing the configuration directive?
>
> We would also need to take care of closing the previous file descriptor on
> reloads.
>

That's gonna get very tricky across the various MPMs. dbm wasn't really
designed for this.

When I wrote mod_dav way back when, SQLite was not available. That is where
I'd go today for the lock database (and properties). It handles
multi-process, multi-thread, and is very efficient. If you are sufficiently
motivated, that would be an excellent path forward.

With that said, I'm not a fan of [DAV or svn] locks. Anything that can be
done to avoid a workflow that encompasses locks would be ideal.

Cheers,
-g


Re: svn commit: r1904638 - in /httpd/httpd/trunk: changes-entries/DAVLockDiscovery.txt modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c

2022-10-27 Thread Ruediger Pluem



On 10/26/22 8:51 PM, Emmanuel Dreyfus wrote:
> On Mon, Oct 17, 2022 at 12:04:55PM +0200, Ruediger Pluem wrote:
>> Why do we need to use an Apache expression here? Wouldn't it be sufficient 
>> to have
>> DAVLockDiscovery as a flag (On/Off)
> 
> I posted a patch for that change, along with documentation, on
> https://bz.apache.org/bugzilla/show_bug.cgi?id=66313
> 
> Is it fine for you?
> 


Looks good. Thanks.

Regards

RĂ¼diger