HHad3

Unfortunately, with secrets in the OS env, you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident.

The env and more importantly what populates it should be secure, but security works best in layers. Sanitizing the env after loading it is a nicer middleground, k8s-style secrets materialized to files work best and are conceptually close enough to the OS env.

This article is probably not correct. The actual behavior is documented [1]:

> BitLocker hashes the user-specified personal identification number (PIN) by using SHA-256, and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key.

So what's actually happening is that the PIN is used to derive an authValue passed to the TPM, which compares it to the expected value, and can trigger lockout on too many mismatches.

I can't find specifics to how Windows configures the TPM wrt. lockout, but the mechanism described in the article appeared fishy to me, and contradicts official docs. It also would not make sense that TPM+PIN was known to be safe against bus sniffing attacks if it would still reveal all data required to brute-force the PIN.

[1] https://learn.microsoft.com/en-us/windows/security/operating...

That is complete nonsense and not how switched networks work.

Is this LLM slop? One cannot truncate RSA signatures and still check them. The sample hook code is nonsense, it lacks an address to hook (and would break Enigma‘s self-checks). The sentence structure and all lower-case looks like a bad prompt attempt to hide LLM usage.

That's including the enterprise premium for software, hardware support, and licenses. Building this in-house using open source software (e.g. Ceph) on OEM hardware will be cheaper by an order of magnitude.

You of course need people to maintain it -- the $300k turnkey solution might be the better option depending on current staff.

I would welcome if this global legislative push would end up in a more open app ecosystem for iOS overall.

BrowserEngineKit is a thin wrapper over XPC and iOS' extension system. The system would be so much better to develop for if XPC was an open API, and JIT for isolated sub-processes was permitted without Apple's blessing.

* Messengers could have separate sub-processes for preprocessing untrusted inputs -- iMessage already does this, third-party messengers are single-process and cannot.

* Applications could isolate unstable components for better user experience and crash recovery.

* Emulators, e.g. for retro systems, would benefit from speedy emulation.

* WASM would become useful in iOS.

* Browser could use XPC without special-purpose API wrappers such as BrowserEngineKit.

But alas, all of this would make it easier to load code that runs at native speed into an iOS app after a store review happened, and as we all know that'll be the end of the world.

You can update SEP firmware, but only by providing your PIN. This is why iOS prompts for you PIN again before updating.

This still effectively prevents Apple from adding backdoor to be installed on phones the user can no longer access.

They might just as well send any other .reg file that runs a program (e.g. by creating an autoboot entry, COM server, service, ...) that bricks devices.

Apple unfortunately declared XPC to be a private API on iOS, whereas on macOS it is the foundation for sandboxing custom services.

I found no way to sandbox things beyond the sandboxes provided by iOS extension points (which are mostly XPC under the hood, but with no control options for the app).

Apple makes heavy use of XPC to sandbox iMessage services, but on iOS that remains an Apple-only feature.

Not storing raw HTML might be a last resort to avoid these kinds of bugs in other software, but a good amount of things need to go wrong for them to happen in the first place. The issue is that your data is rendered outside of your software and known-good environment, so all bets are off.

You could as well have triggered a bug in some LaTeX engine that happened to be configured to allow arbitrary shell command execution.

Another strategy to defend against these issue you describe would be to not let developers access raw production data in the first place, but always anonymize it first, or remove internet access from machines accessing production data. (How sensitive is the data in your users table? Could a developer's test script accidentally send emails to your live users?)

SysCfg with serial number etc has been on a separate NOR chip for quite some time [1]. I wouldn't be surprised if Apple allowed DFU restore to initialize a blank flash as mere optimization in the production process.

[1] https://www.theiphonewiki.com/wiki/NOR

Sure, there are solutions presented in the installation guide [1]. It usually involves using the cloud or virtualization platform's out of band channel, which Talos all supports, to securely provision a config on first boot.

You can also generate a custom installation medium or cloud image that pulls config from your trusted machines if you cannot use out-of-band provisioning.

You can also securely use the insecure maintenance mode when there is a firewall in front of the machine, which prevents access by non-administrator clients to the API ports on IP level.

I'm not a fan of Talos booting into insecure maintenance mode without config w/o prompting for at least a PIN displayed on-screen, but the problem you're describing in no way prevents production use.

[1] https://www.talos.dev/v1.6/talos-guides/install/

The linked msdos source code on GitHub has since been rewritten by Apple /again/ [1], so the article is a bit out of date. This happened 3 months ago, and it now plugs into a private framework named FSKit.

I did not immediately see any private entitlements that restrict access to this API, nor is msdos.fs signed with special entitlements on my machine. Chances are this API works for any filesystem by dropping an appex into /Library/Filesystems. Looking forward to this being documented and made public eventually.

[1] https://github.com/apple-oss-distributions/msdosfs/blob/423d...

I was about to send a rational response to explain how furries are just a bunch of LGBTQ folks (though maybe we met different ones), but then I briefly looked at your HN comments history and decided not to. I hope that not too much of the younger generation has to deal with your bigotry, so I also wish you good luck with them.

Hi Gigachad!

Is there a policy on using portrait photos of oneself at your company? Then the profile photos should indeed be changed, because they're not photos of oneself, but drawings of cartoonish animals.

Otherwise there is no issue here but your understanding of subcultures and these three members of your team. I invite you to talk to them directly, mention the sex thing, and watch hilarity ensue.

> I've tried to bring this up with management but have been told they don't see any issues and I should drop it.

They probably value their contribution to the company over potential misunderstandings should these developers come into contact with customers via Teams. Management might not know what furries are. They might have googled it and found it to be benign. They also might have reacted that way due to the way you presented the issue, or interact with management or your team in general. It's impossible to tell from your post alone.

> Am I overreacting here?

Yes, but that is understandable if you believe that it's a sex thing.

> Is this normal in a corporate environment? I get that with remote work, things have become more casual, but not too sure if this is too far.

Depends on the company. Some may have policies on profile pictures, none of those will explicitly ban furry avatar pictures.

Good luck with the younger generation, Gigachad!

This is unfortunate. The writing was on the wall already with vSphere+, but I can't really commit to a subscription for VM infrastructure. Broadcom would be able to hold the whole company hostage with price increases.

I’m not sure yet where we'll end up, but the small cluster of 8 machines of ours will not run vSphere in 2025.

We've moved to plain markdown in Git(Lab) as Confluence replacement. A CI pipeline compiles it to HTML and hosts it on the web via Material for MkDocs.

It lacks most collaboration options for non-developer users, but we found that they are rarely, if at all, used anyway. Non-developer users can still use an edit button that points to GitLab's web editor and update the docs that way.

I can't suggest a replacement for Jira at this point. I don't think there is one tool to recommend that fits every company's workflow. The other comments seem to have some nice tools to try.

Using Atlassian cloud products is a business risk. They previously let customers sit for weeks without access to their data [1]. Cloud-hosted products do get early patches for unsecured /setup routes though [2], so there's that.

At this point the decision has been made in our org to firewall their products off the internet and internal networks, and migrate to something else by 2024.

[1] https://hn.algolia.com/?q=atlassian

[2] https://confluence.atlassian.com/security/cve-2023-22515-pri...

The PostgresBuild 2021 slides of OrioleDB [1] (also linked in the GitHub project's readme) mention that there is a 1K LoC patch that adds features to the extension interface. I guess the patch is larger by now in 2023.

Slide 45 specifically lists:

* Extended table AM

* Custom toast handlers

* Custom row identifiers

* Custom error cleanup

* Recovery & checkpointer hooks

* Snapshot hooks

[1] https://www.slideshare.net/AlexanderKorotkov/solving-postgre...

Author of parent comment here: Interesting insight! I love (and somewhat miss) this industry because the game of cat and mice is never over.

Oldest trick in the book, good luck faking the PE signature to match the vendor's certificate ;-)

(Jokes aside, the kernel does not provide any information about which application reads a canary page. It's best to just use this as necessary condition and take it with a good pinch of salt.)

Previous discussion: https://news.ycombinator.com/item?id=34909218

(Wrote anti-cheat software in the past.)

There are multiple ways to detect this. Hardware breakpoints were already mentioned, but they only work per thread, so if one is sniffing on your memory from another process or the kernel then these won't help.

The most stealthy and evil way I found was to allocate a page but never actually use it.

Windows lazily allocates physical memory for fresh memory pages when they are first used.

The detection is to periodically poll the page map from your process and check your canary pages via NtQueryVirtualMemory. If your unused page suddenly is backed by some physical memory then something happened to read from it! Bonus-points for putting such canary pages into places previously used for real game data.

This method is not foolproof: Anti-virus programs can read memory of all programs (but don't, Overwatch e.g. does not like this and crashes randomly due to this exact protection method). A bug in the program could also read from the page accidentally (e.g. out-of-bounds array read). But it's a /very/ good indicator that something is wrong when other cheat detection mechanisms also trigger.

Once you know how this works it's pretty easy to defeat unfortunately: Read the page map first, then avoid reading pages that have no backing physical memory, because those contain no useful data at best and are canary pages at worst.

Just, uh... don't have a custom cross-platform scrollarea? This is a feature the browser provides already.

Your page is perfectly usable by just removing `overflow: hidden scroll;` of div.data-radix-scroll-area-viewport`, and `overflow: hidden;` from .s24.

So you'll probably achieve intended behavior of having a scroll area that works on all browsers by just not using any custom scroll area plugin, but a plain <div> instead.

This is great! I hope that this project enables those many FUSE-related applications to return to Homebrew since an open-source FUSE provider is now available again.

I am curious though why a NFSv4 server was chosen over wrapping Apple's File Provider API [1], which seems to be the native method for providing virtual file systems from user space on macOS since macOS 11.5. After glancing over the API I guess it's because FPEs are too high-level to implement FUSE properly, but I'd be glad if you can share any details to satisfy my curiosity.

[1] https://developer.apple.com/documentation/fileprovider

EDIT: Errata, I assumed it was open-source, but it is not. Too bad :( -- but at least this will eventually provide a more stable FUSE experience on macOS.

tl;dr this adds a clause to forbid reserve engineering and bypassing "technical limitations"

> You agree that you will not work around any technical limitations in the software provided to you as part of the Services, or reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits.

What threat model does AMD attempt to address by burning vendor keys into the CPU itself? It can't be physical attacks, because a physical attacker could just replace the CPU by one w/o PSB fuses blown and then go on his merry way to patch the board's firmware.

If physical attacks are not an issue, then why is there no separate ROM on the board that provides vendor PSB configuration instead of burning this info into the CPU? Remote attestation as described by the author of this article would continue to work nicely and securely with an out-of-CPU ROM.

A separate ROM seems to be the obvious solution to me, so either I am missing something, or the second-hand CPU market was (deliberately?) ignored to save the cost of a separate ROM chip.

And its last byte is a NOP, quite a flex :-).

Open source aside, it would be great if any developer could do this on iOS. Unfortunately -- in contrast to macOS -- Apple keeps the XPC API on iOS private, so that it is impossible for "normal" app developers to properly sandbox the more critical and exposed parts of their application.

Only Apple can provide the described security for their messenger, but other messengers which face similar challenges (rendering untrusted content) cannot protect themselves.

Details are missing in the linked techradar article, but covered in its source [1]. To summarize, futex2 (for faster Windows-style locking) and syscall user redirection (for supporting odd DRM constructs) may land in Linux 5.11.

[1] https://www.phoronix.com/scan.php?page=news_item&px=Extendin...