Re: Permission to allow testing harness to send error reports for pgweb directly to mailing list.

> Security teams and security processes generally operate behind closed
doors, to avoid leaking vulnerabilities before they can be patched, and
then publish their work and findings once there is a remedy.

Ok! So we can then proceed with a private repository maybe? We can fork the
CI setup from the current testing harness and just add the respective
security tests. The generated report can then be accessed by the security
team/any concerned individuals in the deployment team. I'd be happy to host
this repo if needed for now.

> Thanks, that was a bit hidden

Yup this is one of my main concerns with only relying on github actions
also there are multiple runs for the monitoring cron job as well so these
test runs usually get lost in the list. As a temporary solution I had added
the github action run url in the email being sent and the reports attached
with that email.

I have started working on the website to view these reports, will be
sharing the development prototype url shortly.

Regards,
Akshat Jaimini

On Mon, Oct 9, 2023 at 6:12 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > On 6 Oct 2023, at 19:12, Akshat Jaimini <destrex271(at)gmail(dot)com> wrote:
>
> >
> > You can find the reports here:
> https://github.com/destrex271/pgweb-testing-harness/actions/runs/6189299124
> <
> https://github.com/destrex271/pgweb-testing-harness/actions/runs/6189299124>
> . You can check the 'report', 'test-log' and 'failure_logs' artifacts, the
> other ones are experimental for now.
>
> Thanks, that was a bit hidden (which is a Github UI issue and not something
> against this work).
>
> > I'll try to find more approaches to this because the private repository
> does not seem to go with the idea of open source. I might be wrong about
> this, so please let me know if I am wrong.
>
> Just because a project is open source doesn't mean that everything about it
> needs to be done in public. Security teams and security processes
> generally
> operate behind closed doors, to avoid leaking vulnerabilities before they
> can
> be patched, and then publish their work and findings once there is a remedy
> (either as an advisory with a CVE or some other form).
>
> --
> Daniel Gustafsson
>
>