My name, and the very fact that I exist are vectors for identity theft. But that doesn't mean I should keep those facts secret either, or that simply attempting to keep them secret will have any effect whatsoever.
They're offering to subsidize the cost that the individual would normally pay for COBRA coverage. They're only required to offer the coverage, but not to pay for it.
However, I don't think this is that unusual in SV layoff packages.
If so, that's really generous, given the cost of having to pay for COBRA.
Either way, I'd still be shitting my pants. 16 weeks is not a lot of time to find another job in today's environment. I know devs who have been out of work for years and had to resort to stocking shelves at Home Depot to tread water.
Everyone should do their damndest to get 6 months worth of bills into savings. This should be easy for well-paid tech workers.
I've been making tech money ($200-250K) for about 5 years now, and my savings is enough that I could ride out a job loss for at least a full year with no change in lifestyle. With some minor belt tightening (I eat out WAYYYY too much), I could go 2 years before I had to start worrying.
The point I'm trying to make is that even if you have savings and are eating into them, you should still be shitting your pants and acting as though those pants are on fire, because you're handling an emergency. That's why you call it your emergency fund.
If we are not employed, then we have N months until we are broke. This is true for what, 99.9% of us? Whether that N is a high or low number, the slope of the line is still downward and that makes it an emergency. Unless you are retired, and are hoping for N to be greater than your life expectancy.
It would be a reasonable, even logical expectation, but everybody does sometimes less-than-logical things, takes some risks etc. Most of the time it works out somehow, sometimes it doesn't.
I've done my share - after buying one smaller apartment some 12 years ago, paying all legal fees, taxes and full reconstruction I was, overall, -1500 euro worth and now with 2 parallel mortgages on my shoulders. Had to take short term employer's loan to get back into positive numbers (that loan, if fired/let go, would be conveniently ignored so that has been be my main motivation for taking it otherwise its a dumb move on its own).
Getting fired during that period and maybe next 6-12 months afterwards would be still devastating for me, I don't have rich parent/family to fall back on, smart moral hard working folks didn't get paid well during socialism/communism. This is where rich kids have massive non-obvious advantage - like ie Gates, they can go and take big risks that are not that big for them, and come crying to rich daddy if they screw up, or be a hero if lucky. Folks like me, they have to risk everything to even get the chance to play the game (which has its own risks which luckily didn't materialize).
I see it even now with my colleagues - nobody would take any big risk, all very risk-averse because they can. My risks though took me further than they managed to get with a massively better starting position. Sometimes, austerity is a great motivator.
But it was a temporary dip, and I had a bit of luck through it. To be in software engineering and having long term no savings, thats... bad life strategy in most cases.
Financial literacy isn't taught as much as it should, and I know devs who grew up in generational poverty who tragically mismanaged their paychecks. Nobody pointed them in the right direction before it was too late. The younger they are, the more I feel they have reasonable excuse.
You said it better than I could! As someone who does software for a living, do I want to come home and maintain a homelab that hosts photos, email, decentralized social, etc? Hell no!
Even if it's fun as a hobby, I don't want to be on call for my own basic online services.
This is what stops me from doing it. I used to host all my own stuff, with custom setups etc etc. But you end up having no free time, or reduces it at best, and it'll break down at the least convenient time.
The last part about it breaking can of course be true, although knock on wood has not happened to me in quite some time. But I don't find myself spending all that much time on my selfhosting setup day to day. Once a week I do a backup to external storage and upgrade software and that's it most of the time. Once everything's set up it is mostly quite hands off.
That said, I also don't think selfhosting is a realistic solution for most people.
Every time I hear about commit messages on HN, this is my first thought. I can't imagine not working in a squash workflow. No matter how good your commit messages are, I do not want to read all of them. The squashed commit will direct me to the original PR in case I need more detail.
It strikes me as odd that boxes are placed precisely using pixels, but the size of text is not specified, as far as I can tell. So you use real pixels to specify boxes, but still can't render a canvas exactly/consistently?
from my perspective--I have to use React, Lit, and all kinds of other creative solutions at my day job--I'm going to immediately devalue someone's argument if it starts with "I hate React".
React is not popular simply because engineers hate themselves or enjoy pain. There are problems it solves, and problems it creates. Explain what problems your solution solves, and feel free to dunk on React while you're at it, but write a tagline like this and I'm not gonna take you seriously.
"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action"
Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.
> Why doesn't GitHub just enforce immutable versioning for actions?
I always wish these arguments came with a requirement to include a response to "well, what about the other side of the coin?", otherwise, you've now forced me to ask: well?
The two sides of the coin: Security wants pinned versions, like you have, so that compromises aren't pulled in. Security does not want¹ pinned versions, so that security updates are pulled in.
The trick, of course, is some solution that allows the latter without the former, that doesn't just destroy dev productivity. And remember, …there is no evil bit.
(… I need to name this Law. "The Paradox of Pinning"?)
(¹it might not be so explicitly state, but a desire to have constant updated-ness w/ security patches amounts to an argument against pinning.)
> it might not be so explicitly state, but a desire to have constant updated-ness w/ security patches amounts to an argument against pinning
When you want to update, you update the hashes too. This isn’t an issue in any other packaging ecosystem, where locking (including hashing) is a baseline expectation. The main issue is developer ergonomics, which comes back to GitHub Actions providing very poor package management primitives out of the box.
(This is the key distinction between updating and passively being updated because you have mutable pointers to package state. The latter gets confused for the former, but you almost always want the former.)
This isn't a bad distinction that you've made, I just think even lockfiles (what you're suggesting, essentially) still fall prey to the same paradox I'm suggesting.
Yes, lockfiles prevent "inadvertent" upgrades, in the sense that you get the "pinned" version in the lockfile. So if we go with the lockfile, we're now on the "pinned" side of the paradoxical coin. Yes, we no longer get auto-pwned by supply chain, but security's problem is "why are we not keeping up to date with patches?" now, since the lockfile effectively prevents them.
And then you see tooling get developed, like what Github has in the form of Dependabot, which will automatically update that lockfile. Now we're just back to the other side of the paradoxical coin, just with more steps.
(This isn't to say we shouldn't do lockfiles. Lockfiles bring a lot of other benefits, and I am generally in favor of them. But I don't think they solve this problem.)
I don’t think this is a paradox, it’s just a process. You use lockfiles to establish consistent resolutions, and then you use dependency management tooling to update those lockfiles according to various constraints/policies like compatibility, release age, known vulnerabilities, etc.
(Another framing is that you might want floating constraints for compatibility reasons, but when actually running software you basically never want dependencies changing implicitly beneath you, even if they fix things. Fixes should always be legible, whether they’re security relevant or not.)
Their question isn't about pinned versions, it's about immutable versions. The question is why it is possible to change what commit "v5" refers to, not "why would you want to write v5".
You already don't get updates pulled in with the system unless they swap the version out from under you, which is not a normal way to deploy.
Version tags should obviously be immutable, and if you want to be automatically updated you can select 1.0.*, if you don't you just pick the version tag.
It amounts to an argument against pinning in a (IMO) weird world view where the package maintainer is responsible for the security of users' systems. That feels wrong. The user should be responsible for the security of their system, and for setting their own update policy. I don't want a volunteer making decisions about when I get updates on my machine, and I'm pretty security minded. Sure, make the update available, but I'll decide when to actually install it.
In a more broad sense I think computing needs to move away from these centralised models where 'random person in Nebraska'[0] is silently doing a bunch of work for everyone, even with good intentions. Decisions should be deferred to the user as much as possible.
Auto upgrade to version deemed OK by security team. Basically you need to get updates that patch exploits then wait and be more patient for feature upgrades.
So, in the context of me questioning "yes, but exactly how is this supposed to work", you're essentially punting the question into a black box that won't betray us.
In the real world, though, we don't have a magic little black box: we have to actually implement that.
The only answer I have seen from real world security teams is variations of "why wouldn't we be keeping up with updates?", and that's an unpinned dep.
> You can't. They can execute arbitrary code. They can download another bash file via Curl and execute that.
Presumably you'd check the code of the action before you include it (and then don't use an action with non-pinned versions). This way you know the action won't execute arbitrary code for this version and won't get any other code because of version pinning.
The docker action you linked is ironic in this regard since every other version in the code seems to be pinned except the one you linked to.
This recommendation is currently broken. Even when you pin the full commit SHA for an action, that action may still pull in transitive dependencies (other actions) that aren't pinned.
A better question perhaps is why we’ve allowed ourselves to be so vulnerable by a single provider (GitHub). Supply chain attacks would have a significantly smaller blast radius if people start using their own forges. GitHub as a social network is no longer a good idea
Even then, that's only immutable for the workflow config. Many workflows then go on to pull in mutable inputs downstream (eg: default to "latest" version).
I think that GitHub should set up Actions so that whenever you run a Github Actions step, it checks to see if either you have pinned it to a SHA or if the repository has immutable tags configured. If not, put a giant warning at the top of every pipeline run so that people are aware of the issue.
Because the true name of the feature is VisualSourceSafe actions. It's all over the code of the runner if you take a second to look, and the runner, like the rest of the feature, is of typical early 2000s Microsoft quality, which is to say, none at all.
I assume this is because it is modeled after git tags, and at this point it would be a major change to move away from this. But it should probably get started at some point.
reply