u/esiy0676

I put this under "password managers" because it will likely turn out to be the next great breach. Termius is probably known to many as their cross-platform SSH client.

I gave up some time ago when it started pushing sharing my private keys through their infra. I also went asking where this company is based, what they do, but it miraculously gets removed (do your own homework, I guess).

Now, I am still getting promo for: https://sshid.io

To each their own, they say, but I'd like to believe I am not the only one who can see where this will be another "injection" vector of another great (or silent) breach somewhere. Intentional or not, the design is utterly stupid.

That's all - just my opinion and maybe gives you a reason to take a second thought.

> The future of Open Source Software (OSS) as a global public good is at risk. The need for a resilient, community-owned alternative has never been more urgent: OSS may have "taken over the world", but... did someone take control of OSS itself in the process, locking it into a proprietary platform, controlled by a single vendor? Is this still a sustainable path today, in the time of trade wars, volatile tariffs, GenAI mandates and countries fighting for data sovereignty?

> This talk will introduce you to Radicle, a new, decentralized code forge that's built on a peer-to-peer architecture. We'll explore how Radicle works and how it extends Git to create a secure and resilient network for code collaboration. We'll cover its peer-to-peer replication protocol, its decentralized identity system, and its novel approach to code discovery.

> This talk is for developers of all levels interested in the future of Open Source. You'll leave with a better understanding of the challenges involved in designing and running distributed, peer-to-peer systems. You'll also learn how you can start mirroring / migrating your code to the Radicle network, so you can #FreeYourCode !

Looking at it backwards - where is this heading? The official toolkit is falling behind, the action repos READMEs all state:

> We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time.

But then back in 2022, it was the toolkit that was primary, CLI not being worth to keep in sync (linked issue).

So: What other areas?

Is this a subliminal message to let co-pilot put something together without worrying much about any of the architecture? From the design standpoint, GHA looks like on life support, but that's nowhere it should be from the product lifecycle aspect of things.

---

My OP on r/github:

---

TL;DR I suppose some of the below might (if you will) be assigned to a "learning curve issue", but all in all and given Microsoft's budget: Are GHA basically a "launch and forget" product? Is the official toolkit supposed to become "outsourced" to the Marketplace?

Is this meant to be production quality tooling? Because it feels a bit like an experiment that got abandoned.

---

I went to build a relatively simple pipeline with a couple of reusable workflows, bunch of composite actions and make use of GHCR where the images that are used to run the jobs reside - they are built from workflows too. There's been quite a few gotchas to me so far.

Workflows and composite actions discrepancies

• workflows can define top-level env, actions cannot
• workflows can (in fact, must) pass in secrets
• actions do not support secrets (and one better remembers to ::addmask:: on anything passed in)
• workflows must define types on inputs strictly (and it ends up being string all of the time)
• workflows must not define types on secrets
• actions must not define types on inputs

Reusable workflows do not get anything checked out with them, not even if called from separate repo, but composite actions do get everything checked out alongside in that case - in fact all the other actions from their repo get checked out.

There's no reasonable way to share inputs between workflow_call: and repository_dispatch:, i.e. one needs to make extra job to reconcile inputs in these two cases even it could be all structured the same in client_payload.

Composite actions have not been designed to be nested when sharing the same repo, i.e. calling one from within another requires one to fully specify the user/repo/action@ref even if it is meant to use the very same one, thus making it necessary to keep updating @ref for every push - or avoid using the construct altogether and resort to e.g. shared scripts.

---

Aside: Debugging

Talking of scripts, one cannot see outputs unless tee -a $GITHUB_OUTPUT >&2, which makes one want to use multi-line HEREDOC - not exactly robust approach. And that only works for steps, obviously.

Then having shell run by default with set -e with no indication on which line it exited is a bit of a nightmare. Either good for running single-liners, always setting own trap <echo> ERR or resorting to copious error output that kills readability of CI scripting, always.

I suppose the single-liners were expected because every Run folds into its first line which is best to be some # summary comment since description is not supported on steps. Alas, calling actions has to be with no comments.

The initial temptation to have anything multi-line inside scripts that are then single-liners however results in the realisation that - see above - workflows do not get them checked out.

---

About jobs

It is impossible to share matrix between jobs, as if the env is evaluated in the same pass - it cannot be used as a constant, so the workaround is to set repository variable and then strategy: matrix: field: ${{ fromJson(vars.CONST) }} in each job - or keep doing copy/paste.

Running jobs in containers does not allow for the very basics to be specified to be meaningful, i.o.w. one cannot really - within the YAML syntax - run the equivalent of e.g. podman run --rm --network=none <...> and select mounts only. In fact, one gets extra stuff (node et al) always mounted. Goodbye hermetic-anything.

Official Actions falling behind

Even though GHCR is a GH product, the accompanying GH actions are rusting, e.g. the actions/delete-package-versions has not been updated since January 2024 and is thus throwing EOL Node warnings.

Even the daily driver actions are somewhat falling behind, e.g. actions/download-artifact keeps throwing: [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. and it seems to be recurrent issue over a long period. I understand deprecation is not a failure, but - this used to be sign of unmaintained software.

And then others where the need naturally come from GHA runs, e.g. creating releases got completely abandoned and one has to resort to the Marketplace or run their own gh CLI.

CLI that is "too much work to keep parity"

At the same time, actions/upload-artifact do not even have a CLI equivalent because "it would be too much work replicating".