>
>
>
> I am aware of how to use Docker in our build jobs...  I am talking about
> Docker based GitHub Actions.  They can have published docker
> images that they used so they do not get rebuilt all of the time.  I called
> out SuperLinter as just an example.
>

Same thing. You can build and push Docker Image under your control and then
specify the action from there. This should be rather simple.

>
> Your workflow is not our workflow...  We have 4 different repos that have
> very similar sections to the yaml that currently we have to keep in sync
> including branches. GitHub knows this is a pain and is going to be
> supporting
> shared workflows to help support this, we should not be working against
> this.
>

Yeah. But is totally orthogonal to the issue we have now.


>
> > >
> > > Also as for banning the git credentials bit in checkout please make
> sure
> > > you keep in mind the different workflows that people have.  Are we not
> > > going to be able to auto push our website?
> > >
> >
> > Absolutely not. This is precisely where we use the action (of my friend
> > BTW)  https://github.com/ad-m/github-push-action
> >
> > It requires GITHUB_TOKEN to be passed and once you add it via submodule
> > you can review it and use it to push your changes to your or another
> > repo.
> >
> >
> Creating custom actions for each time I need to use the token...
>

This is how Github actually SHOULD work according to the
documentation:

https://docs.github.com/en/free-pro-team@latest/actions/reference/authentication-in-a-workflow#about-the-github_token-secret

The fact that you can bypass it is a security issue. I just got a message
today that they are looking into both issues I raised so I sincerely hope
they will close any other possibility but explicitly using the token in your
workflow when you need it,


>
>
> I am sorry but I hope this does not become policy I don't see how any of
> this really helps beyond what we get from pinning to SHAs or approved
> actions.  Anything else is creating developer friction for minor gains
> which just makes for complicated less secure systems.
>

I think there is very little complication involved, but security is much
higher.
Not for me to judge, but I really hope people like us are also security
aware
and understand that security is super-important. And sometimes it might
mean a little more friction.

You might not realise it but when it hits you, it hits you hard. For years
I've
been using hardware security tokens (Yubikey) for both authentication
and signing and it indeed comes with friction. But when I got involved in
fighting for privacy in Polish government-backed COVID application
when the pandemic started (https://github.com/ProteGO-Safe/specs/issues
- in Polish unfortunately)  I thanked for that because immediately
some hackers (likely some government controlled) tried to take-over my
GitHub account with a targeted phishing attack and only my hardware key
prevented me from losing access to my GitHub account.

Several years of friction traded for losing your account and wreaking havoc
in all the repositories you have access to.

I think I choose the former.



>
> --Brennan
>


-- 
+48 660 796 129

Reply via email to