sending announcement mail

[ste...@eissing.org]

...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: sending announcement mail

[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)

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: sending announcement mail

[ste...@eissing.org]

> 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: sending announcement mail

[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: sending announcement mail

[ste...@eissing.org]

> Am 16.09.2021 um 13:46 schrieb 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.

I got the mail from annou...@apache.org, but not from annou...@httpd.apache.org

Alternate realities?

> 
> 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: sending announcement mail

[ste...@eissing.org]

> Am 16.09.2021 um 13:50 schrieb ste...@eissing.org:
> 
> 
> 
>> Am 16.09.2021 um 13:46 schrieb 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.
> 
> I got the mail from annou...@apache.org, but not from 
> annou...@httpd.apache.org
> 
> Alternate realities?

Hmm, maybe my MacOS mail client confuses me...

> 
>> 
>> 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: sending announcement mail

[ste...@eissing.org]

> Am 16.09.2021 um 13:57 schrieb ste...@eissing.org:
> 
> 
> 
>> Am 16.09.2021 um 13:50 schrieb ste...@eissing.org:
>> 
>> 
>> 
>>> Am 16.09.2021 um 13:46 schrieb 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.
>> 
>> I got the mail from annou...@apache.org, but not from 
>> annou...@httpd.apache.org
>> 
>> Alternate realities?
> 
> Hmm, maybe my MacOS mail client confuses me...

I give up. Could you mail 
 to the 
list where it missing?

>>> 
>>> 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: [httpd-site] branch main updated: publishing release httpd-2.4.49

[Ruediger Pluem]

On 9/16/21 12:33 PM, ic...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> icing 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 51476c4  publishing release httpd-2.4.49
> 51476c4 is described below
> 
> commit 51476c4d2261ea5b68951054a50c08a249ea1306
> Author: Stefan Eissing 
> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
> 
> publishing release httpd-2.4.49
> ---
>  content/doap.rdf|  4 ++--
>  content/download.md | 24 
>  content/index.md|  6 +++---
>  3 files changed, 17 insertions(+), 17 deletions(-)

The vulnerabilties page is not updated yet. I guess this can be fixed by 
copying the respective json files
to https://github.com/apache/httpd-site/tree/main/content/security/json
Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the JSON 
from the tool such that this can be scripted?

Regards

Rüdiger

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

[ste...@eissing.org]

> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/16/21 12:33 PM, ic...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> icing 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 51476c4  publishing release httpd-2.4.49
>> 51476c4 is described below
>> 
>> commit 51476c4d2261ea5b68951054a50c08a249ea1306
>> Author: Stefan Eissing 
>> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
>> 
>>publishing release httpd-2.4.49
>> ---
>> content/doap.rdf|  4 ++--
>> content/download.md | 24 
>> content/index.md|  6 +++---
>> 3 files changed, 17 insertions(+), 17 deletions(-)
> 
> The vulnerabilties page is not updated yet. I guess this can be fixed by 
> copying the respective json files
> to https://github.com/apache/httpd-site/tree/main/content/security/json
> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the 
> JSON from the tool such that this can be scripted?

With links such as these it looks unguessable

blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574

(involuntarily learning about 'blob:' url schemes...aaah!)

> 
> Regards
> 
> Rüdiger
> 
> 

Re: sending announcement mail

[Jeff McKenna]

Can you also post this news to Twitter?  https://twitter.com/apache_httpd


Thanks,

-jeff



On 2021-09-16 5:26 a.m., 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




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/

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

[ste...@eissing.org]

> Am 16.09.2021 um 14:14 schrieb ste...@eissing.org:
> 
>> 
>> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem :
>> 
>> 
>> 
>> On 9/16/21 12:33 PM, ic...@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> icing 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 51476c4  publishing release httpd-2.4.49
>>> 51476c4 is described below
>>> 
>>> commit 51476c4d2261ea5b68951054a50c08a249ea1306
>>> Author: Stefan Eissing 
>>> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
>>> 
>>>   publishing release httpd-2.4.49
>>> ---
>>> content/doap.rdf|  4 ++--
>>> content/download.md | 24 
>>> content/index.md|  6 +++---
>>> 3 files changed, 17 insertions(+), 17 deletions(-)
>> 
>> The vulnerabilties page is not updated yet. I guess this can be fixed by 
>> copying the respective json files
>> to https://github.com/apache/httpd-site/tree/main/content/security/json
>> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the 
>> JSON from the tool such that this can be scripted?
> 
> With links such as these it looks unguessable
> 
> blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574
> 
> (involuntarily learning about 'blob:' url schemes...aaah!)

And analyzing the page, the JSON data is embedded in the Javascript embedded in 
the HTML. Hmm...

> 
>> 
>> Regards
>> 
>> Rüdiger

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

[ste...@eissing.org]

Rüdiger, you are also probably looking at this. Who runs he shell scripts to 
generate the mds? It seems we need to do that on changing the cves?

Also, the converter script stumbles on CVEs without "timeline".

Are you on it or should I?

> Am 16.09.2021 um 14:17 schrieb ste...@eissing.org:
> 
> 
> 
>> Am 16.09.2021 um 14:14 schrieb ste...@eissing.org:
>> 
>>> 
>>> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem :
>>> 
>>> 
>>> 
>>> On 9/16/21 12:33 PM, ic...@apache.org wrote:
 This is an automated email from the ASF dual-hosted git repository.
 
 icing 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 51476c4  publishing release httpd-2.4.49
 51476c4 is described below
 
 commit 51476c4d2261ea5b68951054a50c08a249ea1306
 Author: Stefan Eissing 
 AuthorDate: Thu Sep 16 09:58:23 2021 +0200
 
  publishing release httpd-2.4.49
 ---
 content/doap.rdf|  4 ++--
 content/download.md | 24 
 content/index.md|  6 +++---
 3 files changed, 17 insertions(+), 17 deletions(-)
>>> 
>>> The vulnerabilties page is not updated yet. I guess this can be fixed by 
>>> copying the respective json files
>>> to https://github.com/apache/httpd-site/tree/main/content/security/json
>>> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the 
>>> JSON from the tool such that this can be scripted?
>> 
>> With links such as these it looks unguessable
>> 
>> blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574
>> 
>> (involuntarily learning about 'blob:' url schemes...aaah!)
> 
> And analyzing the page, the JSON data is embedded in the Javascript embedded 
> in the HTML. Hmm...
> 
>> 
>>> 
>>> Regards
>>> 
>>> Rüdiger

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

[Ruediger Pluem]

On 9/16/21 2:14 PM, ste...@eissing.org wrote:
> 
>> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem :
>>
>>
>>
>> On 9/16/21 12:33 PM, ic...@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> icing 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 51476c4  publishing release httpd-2.4.49
>>> 51476c4 is described below
>>>
>>> commit 51476c4d2261ea5b68951054a50c08a249ea1306
>>> Author: Stefan Eissing 
>>> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
>>>
>>>publishing release httpd-2.4.49
>>> ---
>>> content/doap.rdf|  4 ++--
>>> content/download.md | 24 
>>> content/index.md|  6 +++---
>>> 3 files changed, 17 insertions(+), 17 deletions(-)
>>
>> The vulnerabilties page is not updated yet. I guess this can be fixed by 
>> copying the respective json files
>> to https://github.com/apache/httpd-site/tree/main/content/security/json

I just downloaded the files manually and commited them in 
645a263259cad97a39f1ba0e0689ec2476d429da. But this breaks the site.
Hence I reverted. Looks like that the downloaded json misses data.

>> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the 
>> JSON from the tool such that this can be scripted?
> 
> With links such as these it looks unguessable
> 
> blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574
> 
> (involuntarily learning about 'blob:' url schemes...aaah!)
> 
>>

Regards

Rüdiger

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

[Ruediger Pluem]

On 9/16/21 2:25 PM, ste...@eissing.org wrote:
> Rüdiger, you are also probably looking at this. Who runs he shell scripts to 
> generate the mds? It seems we need to do that on changing the cves?

These are run on github side when you commit.

> 
> Also, the converter script stumbles on CVEs without "timeline".

Yes, CVE-2021-34798 CVE-2021-39275  CVE-2021-40438 are missing the timeline

Regards

Rüdiger

> 
> Are you on it or should I?

Are you able to update the timeline in 3 ones above?

Regards

Rüdiger

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

[ste...@eissing.org]

Just pushed and it updated.

Summary:
- the "optional" timeline needs to contain an entry "2.4.49 released" or the 
conversion fails
- the "version_affected" combobox field in the UI needs a selection other than 
default or the conversion fails

Something to improve in the cveprocess and our release scripts.

> Am 16.09.2021 um 14:38 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/16/21 2:25 PM, ste...@eissing.org wrote:
>> Rüdiger, you are also probably looking at this. Who runs he shell scripts to 
>> generate the mds? It seems we need to do that on changing the cves?
> 
> These are run on github side when you commit.
> 
>> 
>> Also, the converter script stumbles on CVEs without "timeline".
> 
> Yes, CVE-2021-34798 CVE-2021-39275  CVE-2021-40438 are missing the timeline
> 
> Regards
> 
> Rüdiger
> 
>> 
>> Are you on it or should I?
> 
> Are you able to update the timeline in 3 ones above?
> 
> Regards
> 
> Rüdiger
> 

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

[ste...@eissing.org]

And thanks, Rüdiger, for noticing and the quick fixes.\o/

> Am 16.09.2021 um 14:53 schrieb ste...@eissing.org:
> 
> Just pushed and it updated.
> 
> Summary:
> - the "optional" timeline needs to contain an entry "2.4.49 released" or the 
> conversion fails
> - the "version_affected" combobox field in the UI needs a selection other 
> than default or the conversion fails
> 
> Something to improve in the cveprocess and our release scripts.
> 
>> Am 16.09.2021 um 14:38 schrieb Ruediger Pluem :
>> 
>> 
>> 
>> On 9/16/21 2:25 PM, ste...@eissing.org wrote:
>>> Rüdiger, you are also probably looking at this. Who runs he shell scripts 
>>> to generate the mds? It seems we need to do that on changing the cves?
>> 
>> These are run on github side when you commit.
>> 
>>> 
>>> Also, the converter script stumbles on CVEs without "timeline".
>> 
>> Yes, CVE-2021-34798 CVE-2021-39275  CVE-2021-40438 are missing the timeline
>> 
>> Regards
>> 
>> Rüdiger
>> 
>>> 
>>> Are you on it or should I?
>> 
>> Are you able to update the timeline in 3 ones above?
>> 
>> Regards
>> 
>> Rüdiger
>> 
> 

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

[Ruediger Pluem]

On 9/16/21 2:59 PM, ste...@eissing.org wrote:
> And thanks, Rüdiger, for noticing and the quick fixes.\o/

And thanks to you for all the release and scripting work.

Regards

Rüdiger

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

[ste...@eissing.org]

> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/16/21 2:59 PM, ste...@eissing.org wrote:
>> And thanks, Rüdiger, for noticing and the quick fixes.\o/
> 
> And thanks to you for all the release and scripting work.

I think we should request some download url feature from the cveprocess, so 
that we can automate that part as well. The timeline entry should be added 
automatically. The "affected_by" we can at least check and report.


> 
> Regards
> 
> Rüdiger
> 

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

[Eric Covener]

On Thu, Sep 16, 2021 at 9:07 AM ste...@eissing.org  wrote:
>
>
>
> > Am 16.09.2021 um 15:01 schrieb Ruediger Pluem :
> >
> >
> >
> > On 9/16/21 2:59 PM, ste...@eissing.org wrote:
> >> And thanks, Rüdiger, for noticing and the quick fixes.\o/
> >
> > And thanks to you for all the release and scripting work.
>
> I think we should request some download url feature from the cveprocess, so 
> that we can automate that part as well. The timeline entry should be added 
> automatically. The "affected_by" we can at least check and report.

I'm not sure we have Mark watching here, best to take it to the two
security lists.

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

[Ruediger Pluem]

On 9/16/21 3:16 PM, Eric Covener wrote:
> On Thu, Sep 16, 2021 at 9:07 AM ste...@eissing.org  wrote:
>>
>>
>>
>>> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem :
>>>
>>>
>>>
>>> On 9/16/21 2:59 PM, ste...@eissing.org wrote:
 And thanks, Rüdiger, for noticing and the quick fixes.\o/
>>>
>>> And thanks to you for all the release and scripting work.
>>
>> I think we should request some download url feature from the cveprocess, so 
>> that we can automate that part as well. The timeline entry should be added 
>> automatically. The "affected_by" we can at least check and report.
> 
> I'm not sure we have Mark watching here, best to take it to the two

I fear that as well, but I wanted to avoid crosposts on dev@ and security@ at 
the same time due to their different visibility.
In general I think improvements to the CVE tool can be discussed in public, but 
I am not sure what the correct venue aka list is
for this topic.
@Mark: Can you give us a hint what is the correct forum to talk about 
improvements of the CVE tool?

> security lists.
> 

Regards

Rüdiger

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

[Mark J Cox]

Hi; at the moment the ASF customisation to the tool is tracked in my github
fork along with issues.  There's no specific place to discuss it other than
secur...@apache.org.  That's all just because there's only me having worked
on it.

There are going to be some big changes needed to the tool and running
instance in the coming months to support the new CVE Project v5.0 JSON
schema, as that is required for more of the future CVE project automation
(such as live submission to their database), so that will likely take up
all the time I can personally spend updating the tool in the near future.

Issues:
https://github.com/iamamoose/Vulnogram/issues

ASF changes from the upstream Vulnogram code:
https://github.com/Vulnogram/Vulnogram/compare/master...iamamoose:asfmaster

Regards, Mark J Cox
ASF Security


On Thu, Sep 16, 2021 at 4:57 PM Ruediger Pluem  wrote:

>
>
> On 9/16/21 3:16 PM, Eric Covener wrote:
> > On Thu, Sep 16, 2021 at 9:07 AM ste...@eissing.org 
> wrote:
> >>
> >>
> >>
> >>> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem :
> >>>
> >>>
> >>>
> >>> On 9/16/21 2:59 PM, ste...@eissing.org wrote:
>  And thanks, Rüdiger, for noticing and the quick fixes.\o/
> >>>
> >>> And thanks to you for all the release and scripting work.
> >>
> >> I think we should request some download url feature from the
> cveprocess, so that we can automate that part as well. The timeline entry
> should be added automatically. The "affected_by" we can at least check and
> report.
> >
> > I'm not sure we have Mark watching here, best to take it to the two
>
> I fear that as well, but I wanted to avoid crosposts on dev@ and security@
> at the same time due to their different visibility.
> In general I think improvements to the CVE tool can be discussed in
> public, but I am not sure what the correct venue aka list is
> for this topic.
> @Mark: Can you give us a hint what is the correct forum to talk about
> improvements of the CVE tool?
>
> > security lists.
> >
>
> Regards
>
> Rüdiger
>

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

[Eric Covener]

On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
>
> Hi; at the moment the ASF customisation to the tool is tracked in my github 
> fork along with issues.  There's no specific place to discuss it other than 
> secur...@apache.org.  That's all just because there's only me having worked 
> on it.
>
> There are going to be some big changes needed to the tool and running 
> instance in the coming months to support the new CVE Project v5.0 JSON 
> schema, as that is required for more of the future CVE project automation 
> (such as live submission to their database), so that will likely take up all 
> the time I can personally spend updating the tool in the near future.

For the sake of discussion/argument: Do we want/need to reproduce this
information on the website or is linking to the changelog sufficient?
We lose our pseudo-scoring and the range of affected versions.  We
could bake them into our changelog-entry authoring/review.

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

[Ruediger Pluem]

On 9/16/21 7:13 PM, Eric Covener wrote:
> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
>>
>> Hi; at the moment the ASF customisation to the tool is tracked in my github 
>> fork along with issues.  There's no specific place to discuss it other than 
>> secur...@apache.org.  That's all just because there's only me having worked 
>> on it.
>>
>> There are going to be some big changes needed to the tool and running 
>> instance in the coming months to support the new CVE Project v5.0 JSON 
>> schema, as that is required for more of the future CVE project automation 
>> (such as live submission to their database), so that will likely take up all 
>> the time I can personally spend updating the tool in the near future.
> 
> For the sake of discussion/argument: Do we want/need to reproduce this
> information on the website or is linking to the changelog sufficient?
> We lose our pseudo-scoring and the range of affected versions.  We
> could bake them into our changelog-entry authoring/review.

I like to keep our current vulnerabilities page. On the contrary. I would like 
to see it extended with the revision numbers that
fixed the actual issue.
I like the vulnerabilities page we and Tomcat has very much as it eases the 
search and doesn't force me to got through changelogs
or other information not that quickly available.

Regards

Rüdiger

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

[ste...@eissing.org]

> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/16/21 7:13 PM, Eric Covener wrote:
>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
>>> 
>>> Hi; at the moment the ASF customisation to the tool is tracked in my github 
>>> fork along with issues.  There's no specific place to discuss it other than 
>>> secur...@apache.org.  That's all just because there's only me having worked 
>>> on it.
>>> 
>>> There are going to be some big changes needed to the tool and running 
>>> instance in the coming months to support the new CVE Project v5.0 JSON 
>>> schema, as that is required for more of the future CVE project automation 
>>> (such as live submission to their database), so that will likely take up 
>>> all the time I can personally spend updating the tool in the near future.
>> 
>> For the sake of discussion/argument: Do we want/need to reproduce this
>> information on the website or is linking to the changelog sufficient?
>> We lose our pseudo-scoring and the range of affected versions.  We
>> could bake them into our changelog-entry authoring/review.
> 
> I like to keep our current vulnerabilities page. On the contrary. I would 
> like to see it extended with the revision numbers that
> fixed the actual issue.

+1. makes sense to me.

> I like the vulnerabilities page we and Tomcat has very much as it eases the 
> search and doesn't force me to got through changelogs
> or other information not that quickly available.

Given the answer by Mark on extensibility of the cveprocess site, we should 
make a solution based on our own pmc repository.

What makes most sense to me is to copy the CVE-JSON to the pmc repro, when a 
CVE is "ready" (from our side) for a release. Let readiness.sh check on that 
and also verify that all fields we need are in there.

Since we no longer need to have unreleased version numbers, we can make a 
directory like "2.4.50" and add them there. The release scripts can then pick 
them up, put the info in the CHANGES and add them to the site. With an added 
"timeline" entry for date and release number.

The only manual thing is then to copy the JSON from the website once into a 
local file and the rest is automated. We can skip on creating a CHANGES per CVE 
and create that from the JSON. The CVEPROCESS file is then also obsolete. Just 
the existence of the JSON file in a version directory is enough.

- Stefan

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

[Ruediger Pluem]

On 9/16/21 10:12 PM, ste...@eissing.org wrote:
> 
> 
>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :
>>
>>
>>
>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:

 Hi; at the moment the ASF customisation to the tool is tracked in my 
 github fork along with issues.  There's no specific place to discuss it 
 other than secur...@apache.org.  That's all just because there's only me 
 having worked on it.

 There are going to be some big changes needed to the tool and running 
 instance in the coming months to support the new CVE Project v5.0 JSON 
 schema, as that is required for more of the future CVE project automation 
 (such as live submission to their database), so that will likely take up 
 all the time I can personally spend updating the tool in the near future.
>>>
>>> For the sake of discussion/argument: Do we want/need to reproduce this
>>> information on the website or is linking to the changelog sufficient?
>>> We lose our pseudo-scoring and the range of affected versions.  We
>>> could bake them into our changelog-entry authoring/review.
>>
>> I like to keep our current vulnerabilities page. On the contrary. I would 
>> like to see it extended with the revision numbers that
>> fixed the actual issue.
> 
> +1. makes sense to me.
> 
>> I like the vulnerabilities page we and Tomcat has very much as it eases the 
>> search and doesn't force me to got through changelogs
>> or other information not that quickly available.
> 
> Given the answer by Mark on extensibility of the cveprocess site, we should 
> make a solution based on our own pmc repository.
> 
> What makes most sense to me is to copy the CVE-JSON to the pmc repro, when a 
> CVE is "ready" (from our side) for a release. Let readiness.sh check on that 
> and also verify that all fields we need are in there.
> 
> Since we no longer need to have unreleased version numbers, we can make a 
> directory like "2.4.50" and add them there. The release scripts can then pick 
> them up, put the info in the CHANGES and add them to the site. With an added 
> "timeline" entry for date and release number.

I understand that there is no need to burn version numbers any longer with the 
new release scripts, but why would a failed release
matter to this process?

> 
> The only manual thing is then to copy the JSON from the website once into a 
> local file and the rest is automated. We can skip on creating a CHANGES per 
> CVE and create that from the JSON. The CVEPROCESS file is then also obsolete. 
> Just the existence of the JSON file in a version directory is enough.

Although I hate having a manual step in it, it sounds good. But I guess at 
least short to mid term the manual step cannot be
avoided. So lets go with it and make the best from the current. But if we no 
longer create a CHANGES per CVE we need to fill out
what should get into CHANGES somewhere in the CVE editor in an agreed field and 
an agreed way (e.g. indenting). Furthermore the
question is what happens to changes that become CVE's later and hence the 
changes entry was already committed with the fix.

Regards

Rüdiger