Maintain a forked plugins/git

[UnlimitedCookies]

Ref: https://hub.docker.com/r/plugins/git
Ref: https://github.com/drone-plugins/drone-git
The docker hub image has been updated 2 years ago.

It is being used in the clone step and the recommended way to clone according to the docs.

clone:
  git:
    image: plugins/git:next

We should maintain our own version of plugins/git.

Distilling the knowledge from https://discourse.drone.io/t/planned-change-to-git-clone-logic/1165

And checking drone v1's clone logic

Maybe there needs to be a fork. 🍴

[UnlimitedCookies]

(Also: The docs might need the mention of available options or a link to docs of the clone image used, where all available flags are listed)
https://woodpecker-ci.github.io/docs/usage/pipeline-syntax#clone only shows the depth flag.

[anbraten]

similar to #78

[UnlimitedCookies]

Oh yeah, that issue is ancient.

I especially would like to point out that the next image ships with Alpine Linux v3.6.
Alpine v3.6 is unsupported since 2019-05-01, so this is definitely a security problem.

The latest build seems to ship with a binary built with Golang 1.11 and Alpine v3.9 which is EOL since 2020-11-01.

This is especially important because known vulnerabilities can be exploited through a malicious pull request. So I would suggest raising the priority of this issue.

[UnlimitedCookies]

I am very curious: How does the current drone handle the clone step, since they archived this clone docker image?

[mscherer]

So besides vulnerabilities (which matter, but really, there is easier way to get a RCE with a CI), there is the lets encrypt root certificate expiration:

Initialized empty Git repository in /drone/src/git.example.org/misc/blog/.git/
+ git fetch origin +refs/heads/main:
fatal: unable to access 'https://git.example.org/misc/blog.git/': SSL certificate problem: certificate has expired

Since the base image is not up to date, it fail with my self hosted gitea (using letsencrypt). See https://scotthelme.co.uk/lets-encrypt-old-root-expiration/ for details.

Switching to a supported base image is usually enough (I had to fix already 2 CI problem related to that, non up to date docker image/venv/etc).

[6543]

haha ☝️ thanks for the hint!

I already forked it - we just need to build it (https://github.com/woodpecker-ci/plugin-git)
this should be done asap ...!

[UnlimitedCookies]

Why didn't we fork https://github.com/drone/drone-git ? It seems that this repo is also Apache-licensed.

[6543]

well did not have an overview of all plugins and there repos jet
@mscherer I did place a hotfix for you: woodpecker-ci/plugin-git@8b5d2ca (docker.io/a6543/test_git_plugin:latest) for amd64-linux

[mscherer]

So I can confirm this work around the problem, thanks (still have to fix the other problems with my code unfortunately).

Now, another problem is to get the word out to people, and the fact that "image: plugins/git:next" was a elegant naming that can't be easily reproduced because this use a docker org named "plugins". It took me a while to understand that, so maybe no longer using this trick would be for the best.

[anbraten]

Now, another problem is to get the word out to people, and the fact that "image: plugins/git:next" was a elegant naming that can't be easily reproduced because this use a docker org named "plugins". It took me a while to understand that, so maybe no longer using this trick would be for the best.

plugins being an org totally confused me as well. At the beginning I search the whole code before I figured out it's just the org name of a normal docker image 🤦🏾

If the "new" woodpecker-ci/plugin-git can be treated as stable we should make it the default clone plugin.

[6543]

Yey just have to setup the CI to let things build & publish automaticaly and multiarch ...

[mscherer]

Speaking of changing the plugin, is there plans to self host the registry, or have a vhost and/or a redirection ?

On the benefit side, it would ease a migration in case DockerHub go down/bad (as they changed their ToS not so long ago, and I got another email recently for another change). It would also help to get some numbers regarding usage (which may or may not matter, and may or may not cause controversies). A smaller benefit is that it would work around a issue with podman and moby-client.

A vhost would also permit to have mirror of the main repo, and redirect the load among them.

On the downside side, self hosting the registry for plugins might add a undue burden on the project. Getting a vhost that serve as a redirection would be easier, but a outage there would break CI for others people, which may not be desirable given the project ressources.

[6543]

we do for sure ;)

-> v1.1.0 got released

[6543]

https://hub.docker.com/r/woodpeckerci/plugin-git/tags