I’m indeed talking about spinning up full vps. with untrusted workloads I’d rather have the best isolation reasonably possible. effectively, this is similar to how Github hosted runners work. my gitlab is currently primarily working by spinning up Hetzner cloud vps on demand, but I’ve also used this with proxmox before.

if I have very sensitive secrets accessible to my ci pipeline I want to minimize the risk of leakage through compromise of CI environments to a minimum.

I’ve been considering moving away from gitlab for a long time, but so far, as far as I know, it’s still the only service that supports ephemeral self hosted runners. with gitlab it can utilize docker-machine to spin up vps on demand and ensure only a single job runs on each vps before it gets destroyed again.

that’s odd, my (indirect, reported by others) experience with GlobalProtect on Linux was mostly fine, although when using SAML it only really works with the GUI version and not the CLI version

it doesn’t seem to be server specific because once prompted there is no way to use the account again, even if you decided to just not use a server that may have these settings set.

no, you’re also effectively locked out of any participation unless you provide an email address and phone number, which they won’t even tell you about in advance but use dark patterns and gaslighting that they noticed “suspicious activity” to step by step first ask you for an email and then once that is validated they prompt you for a phone number. the only thing they don’t do yet is ask for ID.

if you’re not community banned you might still be instance banned on the community instance, which wouldn’t show up in your local instances modlog if the ban happened on a <0.19.4 instance. if the methods pointed out by other comments here fail I suggest you visit the instance of the community and check the site modlog there, searching for your user.

i suspect you’re referring to your post to a lemmy.ml community and you have indeed been instance banned there for a limited amount of time.

I can sell you a copy of lemmys source code, are you interested?

🥇

The 90 days disclosure you’re referencing, which I believe is primarily popularized by Google’s Project Zero process, is the time from when someone discovers and reports a vulnerability to the time it will be published by the reporter if there is no disclosure by the vendor by then.

The disclosure by the vendor to their users (people running Lemmy instances in this case) is a completely separate topic, and, depending on the context, tends to happen quite differently from vendor to vendor.

As an example, GitLab publishes security advisories the day the fixed version is released, e.g. https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/.
Some vendors will choose to release a new version, wait a few weeks or so, then publish a security advisory about issues addressed in the previous release. One company I’ve frequently seen this with is Atlassian. This is also what happened with Lemmy in this case.

As Lemmy is an open source project, anyone could go and review all commits for potential security impact and to determine whether something may be exploitable. This would similarly apply to any other open source project, regardless of whether the commit is pushed some time between releases or just before a release. If someone is determined enough and spends time on this they’ll be able to find vulnerabilities in various projects before an advisory is published.

The “responsible” alternative for this would have been to publish an advisory at the time it was previously privately disclosed to admins of larger instances, which was right around the christmas holidays, when many people would already be preoccupied with other things in their life.

nearly all talks are either in English or have English translations. not sure if they’re available on YouTube but you should be able to find everything on https://media.ccc.de