Publishing releases to PGXN from a shared github repository

5 views
Skip to first unread message

Tomáš Vondra

unread,
Dec 22, 2024, 12:26:40 PM12/22/24
to PGXN Users
Hi,

I'm working on automating publishing releases for a couple extensions  hosted on github, but some of the repositories have multiple contributors and I'm wondering what's the best way to deal with that.

One way would be to use my personal credentials as secrets, but that seems wrong. So is there a concept of "shared" PGXN account, or something like that?

If I create a new account for this purpose, I assume I won't be able to publish releases for repositories owned by my current account. Is there a process to transfer ownership to the new account?

thanks
Tomas

Daniele Varrazzo

unread,
Dec 22, 2024, 2:14:12 PM12/22/24
to pgxn-...@googlegroups.com
Same concern of mine. pg_repack has gained a few maintainers, but I am
the only person who is able to upload on PGXN.

A shared account seems the wrong thing to do (there would be the need
to share credentials and no traceability in case they are
compromised).

Is the relation between users and projects strictly 1-M?

Cheers

-- Daniele

Tomáš Vondra

unread,
Dec 22, 2024, 4:33:33 PM12/22/24
to PGXN Users
I don't think PGXN necessarily has 1-M relationship between users and projects (or "distributins"). The dist names are unique, while e.g. on github the it's always (user + repo) that's unique. So I guess it would be possible to have multiple users with privilege to do releases.

Not sure it'd help the automated releases from a github workflow, though. AFAIK the secrets (used to store this kind of info) are per-repository or per-org, so it's shared by all users anyway. So even with multiple users being able to do a release on PGXN, the workflow would still use a single account. (There seems to be a way to do account-specific secrets in codespaces, but I've never used that and not sure if that helps.)

FWIW I'm not too worried about traceability - we have traceability for committed code, and I think that matters more than releases. Who ultimately created the tag to trigger a release is not that critical IMO. And you still know who created the tag, ofc. But if the people are trusted to commit stuff into the main branch, I think that should be enough for triggering a release. If not, it's probably better to not automate releases like this, or restrict who can create tags.

The thing that bothers me about the shared account is that if it's my private user/password, it's possible to exfiltrate the user/password and it'll work for all other distributions on PGXN. I'd like a solution that (even if you exfiltrate the info) does not provide access to any other distributions. For example, if I could create per-distribution "tokens" that allow me to publish releases for that one distribution, and nothing more, that would be enough. Yes, someone could still exfiltrate that, but it doesn't give them rights to do anything they couldn't do in the workflow.

regards

David E. Wheeler

unread,
Dec 23, 2024, 1:32:57 PM12/23/24
to pgxn-...@googlegroups.com
Hi Tomáš & Daniele,

On Dec 22, 2024, at 16:33, Tomáš Vondra <tv.f...@gmail.com> wrote:

> The thing that bothers me about the shared account is that if it's my private user/password, it's possible to exfiltrate the user/password and it'll work for all other distributions on PGXN. I'd like a solution that (even if you exfiltrate the info) does not provide access to any other distributions.

There are two types of relationships between users and distributions: owners and co-owners. Owners can grant co-ownership to any other PGXN user, and that user will be able to make releases using their credentials. Well, to be more precise, I’ve yet to implement the feature to allow owners to make such grants, but I can execute the appropriate SQL function. So if you want to make someone else a co-owner, just tell me their username.

One can also transfer ownership to another user. After the transfer, the old owner will not have the ability to publish new releases unless the new owner grants (er, asks me to execute the SQL to grant) the previous owner co-ownership.

For your purposes, you could create a new PGXN account, say for the “org” name for your project, and then I can grant co-ownership or transfer ownership to it. Then you can use its credentials to publish the extension instead of yours.

> For example, if I could create per-distribution "tokens" that allow me to publish releases for that one distribution, and nothing more, that would be enough. Yes, someone could still exfiltrate that, but it doesn't give them rights to do anything they couldn't do in the workflow.


I have all sorts of plans/ideas for how to improve this sort of stuff in the future, including something like JWT tokens. Not sure when I’ll get to it, but in the meantime, to protect your personal credentials, you can create other accounts just for each extension if you like. Note that then the extensions will be published by and associated with those accounts on the web site instead of yours.

Anyway, let me know if either of you would like to fiddle with the ownership of your distributions.

Best,

David

Tomas Vondra

unread,
Dec 23, 2024, 8:45:10 PM12/23/24
to pgxn-...@googlegroups.com, David E. Wheeler


On 12/23/24 19:32, David E. Wheeler wrote:
> Hi Tomáš & Daniele,
>
> On Dec 22, 2024, at 16:33, Tomáš Vondra <tv.f...@gmail.com> wrote:
>
>> The thing that bothers me about the shared account is that if it's
>> my private user/password, it's possible to exfiltrate the user/
>> password and it'll work for all other distributions on PGXN. I'd
>> like a solution that (even if you exfiltrate the info) does not
>> provide access to any other distributions.
>
> There are two types of relationships between users and
> distributions: owners and co-owners. Owners can grant co-ownership
> to any other PGXN user, and that user will be able to make releases
> using their credentials. Well, to be more precise, I’ve yet to
> implement the feature to allow owners to make such grants, but I can
> execute the appropriate SQL function. So if you want to make someone
> else a co-owner, just tell me their username.
>
> One can also transfer ownership to another user. After the transfer,
> the old owner will not have the ability to publish new releases
> unless the new owner grants (er, asks me to execute the SQL to
> grant) the previous owner co-ownership.
>
> For your purposes, you could create a new PGXN account, say for the
> “org” name for your project, and then I can grant co-ownership or
> transfer ownership to it. Then you can use its credentials to
> publish the extension instead of yours.
>

Makes sense, thanks for the explanation. I'll consider these two
approaches. Luckily I only have one or two extensions where this would
matter, so the separate "org" accounts would not be too much burden.

>> For example, if I could create per-distribution "tokens" that
>> allow me to publish releases for that one distribution, and
>> nothing more, that would be enough. Yes, someone could still
>> exfiltrate that, but it doesn't give them rights to do anything
>> they couldn't do in the workflow.
>
>
> I have all sorts of plans/ideas for how to improve this sort of
> stuff in the future, including something like JWT tokens. Not sure
> when I’ll get to it, but in the meantime, to protect your personal
> credentials, you can create other accounts just for each extension
> if you like. Note that then the extensions will be published by and
> associated with those accounts on the web site instead of yours.
>

Interesting. I imagined something much simpler, but JWT tokens with
embedded information might be useful.

> Anyway, let me know if either of you would like to fiddle with the
> ownership of your distributions.
>

Thanks.

Tomas
Reply all
Reply to author
Forward
0 new messages