Use GitHub actions at your own risk

3

timvisee 2 months ago | link

I think GitLab uses a better approach. Secret environment variables (holding keys/passwords) in CI are only accessible from protected contexts. You can configure who is allowed to create or update such protected tag or branch.

4

borntyping 2 months ago | link

Something else GitLab does is provide a ephemeral API token to CI jobs. It’s only valid until the job ends, so it can’t be extracted and used elsewhere later on. It’s limited in scope (and obviously isn’t useful when your CI job has to interact with external services) but the approach is very useful when working with Docker images written by someone else.

1

A-Za-z0-9 2 months ago | link

I remarked on this a while back, but good to see confirmation (and the commit hash work-around; I didn’t realize that was possible.)

I have doubts with respect to the trust model and third-party actions. I’m happy to trust the Github provided actions with my secrets, and I’m happy to trust e.g. peaceiris/actions-gh-pages@v2.5.0 with my deploy key after reviewing it. But I don’t see any guarantees that it won’t be replaced by a malicious version.

1

lattera 2 months ago | link

An interesting observation regarding using commit hash as version, as demonstrated in the command-line:

hbsd-dev-laptop[shawn]:/home/shawn/tmp $ git init test.git
Initialized empty Git repository in /usr/home/shawn/tmp/test.git/.git/
hbsd-dev-laptop[shawn]:/home/shawn/tmp $ cd test.git
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ touch file1
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git add file1
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git commit -m "initial commit"
[master (root-commit) ff1c2c6] initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file1
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git log|cat
commit ff1c2c64ed5aacf91c94c86ac058167d3729ddbd
Author: Shawn Webb <shawn.webb@hardenedbsd.org>
Date:   Sat Dec 21 01:58:33 2019 -0500

    initial commit
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git tag -a ff1c2c64ed5aacf91c94c86ac058167d3729ddbd -m "ff1c2c64ed5aacf91c94c86ac058167d3729ddbd"
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git describe
ff1c2c64ed5aacf91c94c86ac058167d3729ddbd
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git tag
ff1c2c64ed5aacf91c94c86ac058167d3729ddbd
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ touch file2
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git add file2
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git commit -m "blargh"
[master f568378] blargh
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file2
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git describe
ff1c2c64ed5aacf91c94c86ac058167d3729ddbd-1-gf568378
hbsd-dev-laptop[shawn]:/home/shawn/tmp/test.git $ git show ff1c2c64ed5aacf91c94c86ac058167d3729ddbd
warning: refname 'ff1c2c64ed5aacf91c94c86ac058167d3729ddbd' is ambiguous.
Git normally never creates a ref that ends with 40 hex characters
because it will be ignored when you just specify 40-hex. These refs
may be created by mistake. For example,

  git switch -c $br $(git rev-parse ...)

where "$br" is somehow empty and a 40-hex ref is created. Please
examine these refs and maybe delete them. Turn this message off by
running "git config advice.objectNameWarning false"
commit ff1c2c64ed5aacf91c94c86ac058167d3729ddbd (tag: ff1c2c64ed5aacf91c94c86ac058167d3729ddbd)
Author: Shawn Webb <shawn.webb@hardenedbsd.org>
Date:   Sat Dec 21 01:58:33 2019 -0500

    initial commit

diff --git a/file1 b/file1
new file mode 100644
index 0000000..e69de29