Re: Announce missing - in moderation?

[William A Rowe Jr]

Sebb thank you for your analysis!

Two issues; one, the reply-to field of security announcements was set to
security@, and this is in direct contravention of Apache policy. Security@
is exclusively for reporting undisclosed vulnerabilities, and all other
traffic is ignored. This group of email addresses must never be shared
without context and usage guidance. Please, never do that again.

Two, this announce is still not published to ann@a.o. What is the next step
to cause this to happen? Daniel, could you use a conventional mail agent to
wrap this cycle up?



On Wed, Sep 26, 2018, 18:40 sebb  wrote:

> Also just realised the Message-Id is missing.
>
> Some servers (e.g. GMail) may add it; if they don't it can causes issues
> for mod_mbox and possibly other archivers.
> It also causes problems for mail threading.
> And if the mail is sent to multiple destinations, each generated
> Message-Id will be different.
>
> On 26 September 2018 at 22:04, Noel Butler  wrote:
>
>> On 27/09/2018 05:37, sebb AT ASF wrote:
>>
>>
>> I don't know if this is relevant, but the messages don't have a Date:
>> header.
>>
>>
>> A  this would be because Daniel used curl to send them rather than a
>> sane method :)
>>
>>
>>
>>
>> Also some of the received headers look odd:
>>
>> Received: from Announcement.txt (IP redacted)
>> by mailrelay1-lw-us.apache.org (ASF Mail Server at
>> mailrelay1-lw-us.apache.org) with ESMTPSA id redacted
>> for ; Sat, 22 Sep 2018 11:41:35 +
>> (UTC)
>>
>> and
>>
>> Received: from CVE-2018-11763-h2-dos-by-settings.txt (IP redacted)
>> by mailrelay2-lw-us.apache.org (ASF Mail Server at
>> mailrelay2-lw-us.apache.org) with ESMTPSA id redacted
>> for ; Sat, 22 Sep 2018 11:41:38 +
>> (UTC)
>>
>> --
>>
>> Kind Regards,
>>
>> Noel Butler
>> This Email, including any attachments, may contain legally privileged
>> information, therefore remains confidential and subject to copyright
>> protected under international law. You may not disseminate, discuss, or
>> reveal, any part, to anyone, without the authors express written authority
>> to do so. If you are not the intended recipient, please notify the sender
>> then delete all copies of this message including attachments, immediately.
>> Confidentiality, copyright, and legal privilege are not waived or lost by
>> reason of the mistaken delivery of this message. Only PDF
>>  and ODF
>>  documents accepted, please
>> do not send proprietary formatted documents
>>
>
>

RFC: "persistent state" directory default/config/API

[Joe Orton]

I'd like to add a "persistent state" directory with a hard-coded 
default, config directive and API equivalent to the runtimdir in 
config.layout, DefaultRuntimeDir directive and 
ap_runtime_dir_relative().  The "runtime" directory is used for 
transient state which disappears and can be deleted once the server is 
stopped.  This can be safely stored in tmpfs or even created & deleted 
on the fly.  A "persistent state" directory would be for data which is 
expected to persist across restarts.

Example users are the mod_dav_fs lock database, mod_md's MD data store. 
With an API & default, these can have hard-coded default paths so the 
modules work without needing configuration.  The proxy cache root could 
count here too.

Any thoughts/objections?

I'm not sure about naming, maybe simply:

DefaultStateDir -- ap_state_dir_relative() 

and use "statedir" in config.layout since localstatedir is already used 
and is typically set to /var or $prefix.

For Linux/FHS type layouts, statedir could be set to e.g. /var/lib/httpd 
and for layouts like "Apache", maybe $prefix/state or something like 
that would be fine.

Regards, Joe