Codeberg/Community
54
325
Fork
You've already forked Community
12

actions/checkout only has github in ssh-known-hosts #1971

Open
opened 2025年06月01日 21:55:05 +02:00 by rimas · 5 comments

Comment

When using Codeberg Actions, the actions/checkout action allows cloning a different repository than the one that has triggered the workflow, however, if you want to push new commits to that different repository, you have to clone it over SSH, and currently, that requires to either set the ssh-strict parameter to false, or to be manually populate the ssh-known-hosts value with the result of ssh-keyscan codeberg.org. At the same time, per documentation, GitHub keys are already known by default.

I wonder if it's possible to add Codeberg keys in addition to GItHub ones to the default set.

I thought I'd report this issue to the actions/checkout repository, but apparently, it's just a mirror of the equivalent repo on GItHub, and I doubt GItHub would be interested in adding our SSH keys. But I think it should be controllable without modifying the actions/checkout source, since it only references GitHub keys in the docs, but doesn't seem to be doing anything special to default to them.

### Comment When using Codeberg Actions, the [`actions/checkout`](https://code.forgejo.org/actions/checkout) action allows cloning a different repository than the one that has triggered the workflow, however, if you want to push new commits to that different repository, you have to clone it over SSH, and currently, that requires to either set the `ssh-strict` parameter to `false`, or to be manually populate the `ssh-known-hosts` value with the result of `ssh-keyscan codeberg.org`. At the same time, per documentation, GitHub keys are already known by default. I wonder if it's possible to add Codeberg keys in addition to GItHub ones to the default set. I thought I'd report this issue to the [`actions/checkout`](https://code.forgejo.org/actions/checkout) repository, but apparently, it's just a mirror of the equivalent repo on GItHub, and I doubt GItHub would be interested in adding our SSH keys. But I think it should be controllable without modifying the `actions/checkout` source, since it only references GitHub keys in the docs, but doesn't seem to be doing anything special to default to them.

It is hardcoded in the action actions/checkout@09d2acae67/src/git-auth-helper.ts (L250). I don't think Codeberg can do much to change or inject our own SSH host key (and if it was possible, it would be a security concern if that was possible).

It is hardcoded in the action https://code.forgejo.org/actions/checkout/src/commit/09d2acae674a48949e3602304ab46fd20ae0c42f/src/git-auth-helper.ts#L250. I don't think Codeberg can do much to change or inject our own SSH host key (and if it was possible, it would be a security concern if that was possible).
Author
Copy link

Perhaps a solution would be maintain a synced fork of the action instead of just mirroring it?

Perhaps a solution would be maintain a synced fork of the action instead of just mirroring it?

We don't have the capacity to maintain such a fork, neither really want to. The actions on code.forgejo.org is served via different infrastructure maintained by the Forgejo team, it has better uptime and capacity to deal with serving actions at the moment.

We don't have the capacity to maintain such a fork, neither really want to. The actions on code.forgejo.org is served via different infrastructure maintained by the Forgejo team, it has better uptime and capacity to deal with serving actions at the moment.
Owner
Copy link

I'll try to keep this in mind, but it will definitely take a while. It might need changes to the Forgejo Actions ecosystem at a whole to allow this, e.g. by somehow obtaining the data from the server to ensure it always works with the server the runner is connected to.

I'll try to keep this in mind, but it will definitely take a while. It might need changes to the Forgejo Actions ecosystem at a whole to allow this, e.g. by somehow obtaining the data from the server to ensure it always works with the server the runner is connected to.
Author
Copy link

I initially though that maybe this could be preconfigurable via environment, but seeing that the keys are committed into the code, I think forking the repo and just adding Codeberg's keys might be the best option.

For one, it would ensure that the default known keys are actually known in advance and auditable, which is good for security.

And maintenance-wise, I don't think it would be too much to handle, especially now that the parent repo is effectively dormant (see its latest commit).

I initially though that maybe this could be preconfigurable via environment, but seeing that the keys are committed into the code, I think forking the repo and just adding Codeberg's keys might be the best option. For one, it would ensure that the default known keys are actually known in advance and auditable, which is good for security. And maintenance-wise, I don't think it would be too much to handle, especially now that the parent repo is effectively dormant (see [its latest commit](https://code.forgejo.org/actions/checkout/commit/09d2acae674a48949e3602304ab46fd20ae0c42f)).
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure

Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers

Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support

This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#1971
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?