Thread: Re: New process of getting changes into the commitfest app

Re: New process of getting changes into the commitfest app

From
Yura Sokolov
Date:
23.01.2025 15:57, Jelte Fennema-Nio пишет:
> (Resent because sending to both -hackers and -www gets emails put in
> the moderation queue, and I don't want to introduce that delay to all
> replies. If you received the previous version because you're in the CC
> please only reply to this one)
> 
> # Background
> 
> As some of you might have noticed I've been trying to breathe some
> more life into development on the commitfest app[1], both by
> contributing myself but also by encouraging contributions of others.
> Basically I'd like to become one of the maintainers of the commitfest
> app project. The process to get there has been much more of a struggle
> than I'd hoped...
 >
 > ...
 >
 > I requested Magnus to give me commit access to the pgcommitfest repo
 > so that I could deploy improvements without having to wait for his
 > reviews.

Given history of libxz backdoor, I'd fear to give "commit access" for
anything critical to rather fresh member of community.

I'm not in core-team though.



Re: New process of getting changes into the commitfest app

From
Umar Hayat
Date:
On Mon, 27 Jan 2025 at 03:09, Yura Sokolov <y.sokolov@postgrespro.ru> wrote:
>
> 23.01.2025 15:57, Jelte Fennema-Nio пишет:
> > (Resent because sending to both -hackers and -www gets emails put in
> > the moderation queue, and I don't want to introduce that delay to all
> > replies. If you received the previous version because you're in the CC
> > please only reply to this one)
> >
> > # Background
> >
> > As some of you might have noticed I've been trying to breathe some
> > more life into development on the commitfest app[1], both by
> > contributing myself but also by encouraging contributions of others.
> > Basically I'd like to become one of the maintainers of the commitfest
> > app project. The process to get there has been much more of a struggle
> > than I'd hoped...
>  >
>  > ...
>  >
>  > I requested Magnus to give me commit access to the pgcommitfest repo
>  > so that I could deploy improvements without having to wait for his
>  > reviews.
>
> Given history of libxz backdoor, I'd fear to give "commit access" for
> anything critical to rather fresh member of community.
+1 in github you can enforce a minimum number of reviewers. IMO there
should be a minimum of two reviewers and one of the reviewers should
be from the security group/role. Though primary risk would be
introducing new vulnerable dependency but there is no bound to other
kinds of exploitation. Also github vulnerability scan should be
enabled by default.

>
> I'm not in core-team though.
>
>


--
Umar Hayat
Bitnine (https://bitnine.net/)



Re: New process of getting changes into the commitfest app

From
Jelte Fennema-Nio
Date:
On Sun, 26 Jan 2025 at 19:09, Yura Sokolov <y.sokolov@postgrespro.ru> wrote:
> Given history of libxz backdoor, I'd fear to give "commit access" for
> anything critical to rather fresh member of community.

That's definitely a valid concern in the general case, but I wouldn't
call myself a fresh member of the community. I've been the primary
maintainer of the PgBouncer repo for ~2 years now and I also have
commit access to the cfbot repo. So *if* I wanted to add backdoor in
some critical infrastructure I wouldn't need access to the commitfest
app repo to do that. I also rank relatively high on Robbert's yearly
stats list[1].

[1]: http://rhaas.blogspot.com/2025/01/who-contributed-to-postgresql.html



Re: New process of getting changes into the commitfest app

From
Jelte Fennema-Nio
Date:
On Mon, 27 Jan 2025 at 05:38, Umar Hayat <postgresql.wizard@gmail.com> wrote:
> +1 in github you can enforce a minimum number of reviewers. IMO there
> should be a minimum of two reviewers and one of the reviewers should
> be from the security group/role.

In a perfect world I'd agree, but I don't think there are currently
enough people involved in the project to make two reviewers a
realistic option.

> Though primary risk would be
> introducing new vulnerable dependency but there is no bound to other
> kinds of exploitation. Also github vulnerability scan should be
> enabled by default.

Enabled that now on my Github mirror. I don't think it'll actually do
anything though. We don't pin exact python dependency versions,
because on prod we only use Python dependencies available in Debian
(which should resolve security issues).