Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
On 9/17/21 11:29 AM, [email protected] wrote: > > >> Am 17.09.2021 um 11:20 schrieb [email protected]: >> >> >> >>> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem : >>> >>> >>> >>> On 9/17/21 9:36 AM, [email protected] wrote: > Am 17.09.2021 um 08:54 schrieb Ruediger Pluem : > > > > On 9/16/21 10:12 PM, [email protected] 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 [email protected]. 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? One thing that was nagging me in the release scripts: the steps run over some time (up to a week possibly), and assume that nothing changes in the pmc repository during this time. So the scripts might pick up a "ready" CVE that is not part of the tarballs. I was thinking of create a version directory to fix that, but that seems overkill on reconsidering it. I am not thinking that the release >>> >>> I am a little bit confused with this and the following sentence. >>> Do you want to say I am *not* thinking or I am thinking? >> >> Sorry, not enough coffee. "I am *now* thinking..." > > To spell it out more clearly: > > - when a CVE is considered "ready" by us, but not set > to READY in the cveprocess (it is not released yet), > we manually copy the CVE-JSON from the site into > "pmc/SECURITY/ - tools/readiness.sh checks that file for completeness > - dev-tools/release/r0-make-candidate.sh copies those > files into "pmc/SECURITY/release-" dir. > - cancelling a candidate would remove that dir again > - dev-tools/r4-stage-release.sh takes the CVEs from that > dir and adds content to CHANGES, copies to site etc. > > This means that when CVEs become ready after a candidate is > built, it won't slip accidentally into the announcements > or CHANGES. > > There is the one manual step of copying, but the rest is > handled by scripts. Thanks for the clarification. +1 to the steps above. Regards Rüdiger
Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
> Am 17.09.2021 um 11:20 schrieb [email protected]: > > > >> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem : >> >> >> >> On 9/17/21 9:36 AM, [email protected] wrote: >>> >>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem : On 9/16/21 10:12 PM, [email protected] 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 [email protected]. 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? >>> >>> >>> One thing that was nagging me in the release scripts: the steps run over >>> some time (up to a week possibly), and assume that nothing changes in the >>> pmc repository during this time. So the scripts might pick up a "ready" CVE >>> that is not part of the tarballs. >>> >>> I was thinking of create a version directory to fix that, but that seems >>> overkill on reconsidering it. I am not thinking that the release >> >> I am a little bit confused with this and the following sentence. >> Do you want to say I am *not* thinking or I am thinking? > > Sorry, not enough coffee. "I am *now* thinking..." To spell it out more clearly: - when a CVE is considered "ready" by us, but not set to READY in the cveprocess (it is not released yet), we manually copy the CVE-JSON from the site into "pmc/SECURITY/" dir. - cancelling a candidate would remove that dir again - dev-tools/r4-stage-release.sh takes the CVEs from that dir and adds content to CHANGES, copies to site etc. This means that when CVEs become ready after a candidate is built, it won't slip accidentally into the announcements or CHANGES. There is the one manual step of copying, but the rest is handled by scripts. - Stefan
Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem : > > > > On 9/17/21 9:36 AM, [email protected] wrote: >> >> >>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem : >>> >>> >>> >>> On 9/16/21 10:12 PM, [email protected] 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 [email protected]. 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? >> >> >> One thing that was nagging me in the release scripts: the steps run over >> some time (up to a week possibly), and assume that nothing changes in the >> pmc repository during this time. So the scripts might pick up a "ready" CVE >> that is not part of the tarballs. >> >> I was thinking of create a version directory to fix that, but that seems >> overkill on reconsidering it. I am not thinking that the release > > I am a little bit confused with this and the following sentence. > Do you want to say I am *not* thinking or I am thinking? Sorry, not enough coffee. "I am *now* thinking..." > >> scripts should, when creating the candidate, create a pmc/SECURITY/version >> directory and move all ready CVEs there. Later stages of release scripts >> would them only consider those. >> > > Regards > > Rüdiger
Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
On 9/17/21 9:36 AM, [email protected] wrote: > > >> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem : >> >> >> >> On 9/16/21 10:12 PM, [email protected] 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 [email protected]. 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? > > > One thing that was nagging me in the release scripts: the steps run over some > time (up to a week possibly), and assume that nothing changes in the pmc > repository during this time. So the scripts might pick up a "ready" CVE that > is not part of the tarballs. > > I was thinking of create a version directory to fix that, but that seems > overkill on reconsidering it. I am not thinking that the release I am a little bit confused with this and the following sentence. Do you want to say I am *not* thinking or I am thinking? > scripts should, when creating the candidate, create a pmc/SECURITY/version > directory and move all ready CVEs there. Later stages of release scripts > would them only consider those. > Regards Rüdiger
Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem : > > > > On 9/16/21 10:12 PM, [email protected] 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 [email protected]. 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? One thing that was nagging me in the release scripts: the steps run over some time (up to a week possibly), and assume that nothing changes in the pmc repository during this time. So the scripts might pick up a "ready" CVE that is not part of the tarballs. I was thinking of create a version directory to fix that, but that seems overkill on reconsidering it. I am not thinking that the release scripts should, when creating the candidate, create a pmc/SECURITY/version directory and move all ready CVEs there. Later stages of release scripts would them only consider those. > >> >> 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. Hating manual too, but seems we cannot avoid that for some time. We could also keep CHANGES, but I think we could also format the CVE-JSON in a much better way for the changelog entries, basically in a format similar to our vulnerabilities pages (which do take all data from CVE-JSON already). Cheers, Stefan > > Regards > > Rüdiger
Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
On 9/16/21 10:12 PM, [email protected] 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 [email protected]. 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
Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
> 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 >>> [email protected]. 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
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 >> [email protected]. 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
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 > [email protected]. 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
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 [email protected]. 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 [email protected] > wrote: > >> > >> > >> > >>> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem : > >>> > >>> > >>> > >>> On 9/16/21 2:59 PM, [email protected] 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
On 9/16/21 3:16 PM, Eric Covener wrote: > On Thu, Sep 16, 2021 at 9:07 AM [email protected] wrote: >> >> >> >>> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem : >>> >>> >>> >>> On 9/16/21 2:59 PM, [email protected] 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
On Thu, Sep 16, 2021 at 9:07 AM [email protected] wrote: > > > > > Am 16.09.2021 um 15:01 schrieb Ruediger Pluem : > > > > > > > > On 9/16/21 2:59 PM, [email protected] 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
> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem : > > > > On 9/16/21 2:59 PM, [email protected] 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
On 9/16/21 2:59 PM, [email protected] 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
And thanks, Rüdiger, for noticing and the quick fixes.\o/ > Am 16.09.2021 um 14:53 schrieb [email protected]: > > 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, [email protected] 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
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, [email protected] 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
On 9/16/21 2:25 PM, [email protected] 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
On 9/16/21 2:14 PM, [email protected] wrote: > >> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem : >> >> >> >> On 9/16/21 12:33 PM, [email protected] 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
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 [email protected]: > > > >> Am 16.09.2021 um 14:14 schrieb [email protected]: >> >>> >>> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem : >>> >>> >>> >>> On 9/16/21 12:33 PM, [email protected] 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
> Am 16.09.2021 um 14:14 schrieb [email protected]: > >> >> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem : >> >> >> >> On 9/16/21 12:33 PM, [email protected] 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
> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem : > > > > On 9/16/21 12:33 PM, [email protected] 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: [httpd-site] branch main updated: publishing release httpd-2.4.49
On 9/16/21 12:33 PM, [email protected] 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
