lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

66
active users

#githubactions

0 posts0 participants0 posts today

Liebe Folglinge,

ich suche leider noch immer nach einem neuen Job als #iOS und/oder #macOS Entwickler. Ich spreche #ObjectiveC, #Swift (auch Server-Side) und #SwiftUI und nutze die ganzen Tools drumherum (#Xcode, #Git, #GitHub, #GitHubActions, #ShellScripting etc.). Ich bringe 30 Jahre Berufserfahrung als Software-Entwickler mit, davon knapp 20 im #Apple Ökosystem.

Am Idealsten waere eine #Festanstellung zu 100% remote. Sollte es im Raum #Bregenz oder #Dornbirn etwas geben, dann auch gerne vor Ort.

Ich danke euch fuers Teilen. 🙏🏻
:boost_ok:

LinkedIn: linkedin.com/in/phranck/
Xing: xing.com/profile/Frank_Gregor0

Hi!

I'm Adrian, a FullStack #Developer looking for a job either in #Québec (or from it if you allow for remote work), with a permanent and open visa

I have experience building and maintaining web apps and APIs, designing systems, doing #DevOps and a bit of #BigData, #MachineLearning and #IoT

I'm experienced using #Elixir, #Phoenix, #LiveView, #NodeJS, #TypeScript, #Fastify, #Express and #Python ; and on the DevOps side in CI/CD pipelines (either #GithubActions and Gitlab CI/CD), #Docker and a bit of #Kubernetes

I was tasked with a lot of the #innovation happening in my previous company, researching tools, librairies, patterns or general technologies either for our own #DeveloperExperience or for our products

I also wrote a lot of technical and non technical documentation and internal presentations, and even participated in a few meetups. You can read some of my writing on my blog: blog.adrianc.eu

You might also have seen me on a few Elixir-related Discord servers, or even Bluesky (@adrianc.eu) and Twitter ; either sharing tech news, helping people, reading in book clubs or just chatting

I’m open to full-time right now, contracting work can be discussed.

I'm looking for any developer position, not only #ElixirLang, even though it represents most of my experience. And if the technology you're using isn't on my resume, give me a chance! I'm a fast learner and I might anyway have studied it in class :P

DM me for more info, like github link, my resume or anything :)

Boosts, responses and DM welcome, of course!

AdrianCAdrianCCuriosity propelled
Continued thread

2/ I'm thinking here particularly of junior to mid-level #developers who may not have a lot of "work" they can show.

I'm also thinking particularly of #web development. In my mind they should probably be looking for a full-stack app that:

1. Uses popular tech like #docker, #git, #github, #githubactions, #eslint, #typescript, #sql, #react, #aws or the like.
2. Allows them to get involved in the full lifecycle - from setting up a local dev environment through CI/CD to production.

We want to have (potential) #user #feedback :)

If you use Github-/Gitea-/Forgejo- #actions , why have you not switched or what would make you potentialy do so?

If you are not in position to decide, just try to asume why :)

For "other" feedback, just comment "below" ;)

Notice of breaking changes for GitHub Actions, including:

Ubuntu-latest upcoming breaking changes: ubuntu-latest is migrating to ubuntu 24 between 5 Dec-17 Jan, and has has a different set of tools and packages than ubuntu 22, with cuts to save disk space.

Artifacts v3 brownouts: v3 is closing down by 5 Dec with brownouts this month.

Changes to workflow validation for pull requests originating from forked repositories

github.blog/changelog/2024-11-

The GitHub BlogNotice of breaking changes for GitHub Actions · GitHub ChangelogNotice of breaking changes for GitHub Actions

-10-
Grand Theft Actions: Abusing Self-Hosted GitHub Runners at Scale - Adnan Khan, John Stawinski

GitHub Actions is a CI/CD tool that lets you run code (workflows) in response to events. Being code and all—it needs something to run on.
The default option is GitHub runners - an ephemeral VM. Another option, more commonly used for large repos, is self-hosted runners— bringing your own machine to run workflows on.

Self-hosted runners are a security nightmare. Clearly shown throughout this talk, the main issue is that they’re persistent, so any vulnerability in self-hosted workflows is amplified.

Jumping ahead, the talk presents many attack techniques against self-hosted runners, nicely concluded by John in this diagram: github.com/jstawinski/Github-A

The research found vulnerabilities in dozens of high profile orgs, but the talk itself focuses on PyTorch. So what’s the recipe for hacking into self-hosted runners?

First: become a contributor. The default config only blocks first-time contributors from running workflows, so after the first approved PR— it's a free game.
Find a simple grammar mistake and fix it in a quickly accepted PR, becoming a contributor in the process. From then on, you can run workflows on the self-hosted runner using PRs from your fork.

Then, gain persistence: since the machine might be protected, the researchers take a safe approach and deploy another self-hosted runner agent that connects to a private repo. Neat!

Next, steal GITHUB_TOKEN— a secret allowing access to GitHub for the workflow. However, in fork PRs these have read only access. But, workflows share the self-hosted runner, so after gaining persistence access they simply stole a GITHUB_TOKEN from another workflow from the base repo.

With such a token, there are many options for supply chain attack, like changing release assets!

But it wasn’t enough for Adnan and John— they wanted to steal real secrets from workflows. These would most likely escalate their privilege into the PyTorch organization.

It only takes compromising one workflow using these secrets. But, the already-compromised workflow did not use them, and the stronger GITHUB_TOKEN cannot modify the workflows directory.

The solution is simple— they found a workflow depending on a Python code from outside the workflow directory. Now, all that's needed is use GITHUB_TOKEN to create a branch, add a payload to the Python code that dumps the secrets to logs, trigger the workflow with the, and retrieve the secrets from the logs.

The stolen secrets contained a GitHub personal access token with wide access to PyTorch’s private repos, as well as an AWS access key with highly privileged access to PyTorch’s AWS account.

And, just like that, becoming a contributor with a simple PR led to full compromise of PyTorch’s GitHub and AWS, which could have led to catastrophic consequences had it not been for this research. Amazing work!

youtube.com/watch?v=5P7KatZBr_

GitHubGitHub - jstawinski/GitHub-Actions-Attack-DiagramContribute to jstawinski/GitHub-Actions-Attack-Diagram development by creating an account on GitHub.