HN user
From my perspective zig doesn't have "big cleanup" upfront. It's removing older features as it goes.
stdlib changes as it wants from version to version. So do language features. Since zig is pre-1.0, zig foundation isn't scared of breaking changes.
Instead of debating for years (like other languages), zig just tries things out. Worst case you can always rollback changes.
IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings.
This makes zig unique. It's fun to use and it stays fresh.
You can always just stay on older version of zig. But if you choose to update to newer version, you get new tools to make your code tidier/faster.
Except that many component manufacturers release their efi capsules signed with Microsoft PKI. So no, you can't fully remove them if you want to verify updates.
If you're interested in the topic there's great YouTube channel that demonstrates such attacks IRL together with full tutorials. Below are 2 satellite related videos:
Not the best name for the article. My first guess was version changes, or software being added/removed from repo. Turns out this is about source code modification.
A problem I encountered while writing custom stdlib, is that certain language features expect stdlib to be there.
For example, <=> operator assumes, that std::partial_ordering exists. Kinda lame. In the newer C++ standards, more and more features are unusable without stdlib (or at least std namespace).
Both AMD and Google note, that Zen[1-4] are affected, but what changed about Zen5? According to the timeline, it released before Google notified AMD [1].
Is it using different keys, but same scheme (and could possibly be broken via side-channels as noted in the article)? Or perhaps AMD notices something and changed up the microcode? Some clarification on that part would be nice.
[1] https://github.com/google/security-research/security/advisor...
Honestly I don't get why people are hating this response so much.
Life is complex and vulnerabilities happen. They quickly contacted the reporter (instead of sending email to spam) and deployed a fix.
we've fundamentally restructured our security practices to ensure this scenario can't recur
People in this thread seem furious about this one and I don't really know why. Other than needing to unpack some "enterprise" language, I view this as "we fixed some shit and got tests to notify us if it happens again".
To everyone saying "how can you be sure that it will NEVER happen", maybe because they removed all full-privileged admin tokens and are only using scoped tokens? This is a small misdirection, they aren't saying "vulnerabilities won't happen", but "exactly this one" won't.
So Dave, good job to your team for handling the issue decently. Quick patches and public disclosure are also more than welcome. One tip I'd learn from this is to use less "enterprise" language in security topics (or people will eat you in the comments).
Seems like you assumed none of your tools got backdoored. I'd start bootstrapping from busybox.
Linux Local Privilege Escalation, but the attacker has to be in sudo group in the first place.
Great read, but this feels like academic research. Technically correct, but impractical at best.
If you want to manage VMs, then you're probably using terraform + provider. However, SDN (Software Defined Networking) is not yet supported [1], which makes any kind of deployment with network separation not feasible (using IAC only).
[1] https://github.com/bpg/terraform-provider-proxmox/issues/817
Proxmox uses ZFS making snapshotting quick
Proxmox only supports linear snapshots using ZFS (so no tree-like snapshots). This might be a deal-breaker for some usages.
GitHub is slowly rolling out feature over moe than a year [1], which will have positive impact on overall IT security.
Spending 1 minute setting up 2FA is really not a big deal.
[1] https://github.blog/news-insights/product-news/raising-the-b...
Depends how much patience you have.
Firejail if you want ease of use (there are a lot of ready profiles to be used).
Bubblewrap if you want more security, at the cost of having to do more manual work.
TL;DR Firejail is a blacklist of things, while bubblewrap is an whitelist, so bwrap policies tend to be tighter.
I'm not a rust expert by any means, but I believe there's a problem with lifetimes. There are many ways to implement double-linked lists (think C++ smart pointers), but when you try to squeeze performance and use references, then it's a fight against borrow checker, which ends with the need to use unsafe rust.
smarter sources: https://rust-unofficial.github.io/too-many-lists/ https://softsilverwind.github.io/rust/2019/01/11/Rust-Linked...
Sounds like amazing material for a CCC talk.
While authelia is quite cool "infra-as-code" tool, since you have your entire configuration in yaml form, for those not willing to spend a few evenings configuring SSO, there is authentik [1] which features management UI.
Offers similar feature set, also self-hostable, but most importantly - simple to set-up. I've spent 8h on authelia deployment, where 30 minutes in authentik would be sufficient. But both are good options, pick what you prefer.
When performing forensic analysis, metrics don't usually help that much. I'd rather sift 2PB of logs, knowing that information I'm looking for is in there, than sit at the usual "2 weeks of nginx access logs which roll over".
Obviously running everything with debug logging just burns through money, but having decent logs can help a lot other teams, not just the ones working on the project (developers, sysadmins, etc.)
From my experience, you either go full reproducible builds with nix, or none at all.
Sitting in the middle results with additional downsides from modifying pipeline without core upsides of reproducible builds.
What's the point of having your 2FA codes synchronized across all your devices?
Isn't it in the name "TWO FACTOR"? It's supposed to be a separate device and ability to "across devices" comes as an anti-feature for me.
1) If you're not using password manager, then you're probably using same password everywhere, including your 2FA app.
2) If you're storing your 2FA codes in your password manager, then it's not really a 2nd factor. It helps against password leaks from services, not from a password manager leak.
Ability to synchronize encrypted backup is a different story.
Just last week google CTF featured a reverse engineering challenge of a neo geo game!
https://capturetheflag.withgoogle.com/challenges/rev-arcade
Also, the neo geo development wiki is an absolute goldmine of technical information about the console.
SSH certificates are fail-secure
Yeah... no. I think my private key stored on yubikey is harder to steal than session to your OIDC.
The gotcha is that "global" args don't propagate automatically to all stages (thin includes 1 stage builds).
I want this one arg in multiple stages, so I'll declare it above everything is the chain of thought.
Note, that paper provides environment for AWS FPGAs, which you can rent on per-hour basis.
As for cheaper FPGAs, the paper notes that the bottleneck is the size of on-chip memory. So I doubt it will be easy to find cheaper model to reduce costs.
Another hidden fee would be Vivado and Vitis (tooling) licenses, which you need for most upper-end FPGAs.
From developers perspective, it never did. From security perspective, it still does.
For me it means:
1) don't expose it to public internet
2) don't give it untrusted input
Which highly reduces the usability factor for me.