21–30 of 65 posts
This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…
Sorry, that whole github actions concept gives me the screaming heeby-jeebies. We're really not even pulling the dependency locally, we're just going to run someone else's code from their repo, on github's server, with our data and secrets? What could possibly go wrong with that? /s
This isn't much different than other CI/CD pipelines. Docker images come to mind.
Earlier quoted context omitted.
This isn't much different than other CI/CD pipelines. Docker images come to mind.
This isn't much different than other SaaS CI/CD pipelines.
This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…
Do you fork your own programming languages too?
This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…
Many automated vendor/package management tools will not automate pulling newer changes from upstream. If this was instead a simple a read-only version/tag, it is easy for those tools to provide upgrade/update path.
This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…
Do you fork your own programming languages too?
Earlier quoted context omitted.
That's definitely true, but given the sensitivity of having access to private source and secrets I think its fair to call out a warning.
couldn't a malicious docker image also be tooled to dump all of that stuff to an external destination?
This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…
While I understand the "fork everything you use" policy, github should make this process easier. Even though it is "free", it pollutes one's account/profile with hundreds of packages that are not really 'forks' with independent or alternate functionality. Many automated vendor/package management tools will not automate pulling newer changes from upstream. If this was instead a simple a read-only version/tag, it is ea…
I mean, there is an action in the marketplace that runs git-crypt to decrypt your files. With this issue, no user should ever be using this action without forking it to their repo first.