HHad3
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.
> 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...
You of course need people to maintain it -- the $300k turnkey solution might be the better option depending on current staff.
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.
This still effectively prevents Apple from adding backdoor to be installed on phones the user can no longer access.
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.
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?)
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.
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...
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!
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.
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.
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...
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...
(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.)
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.
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.
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.
> 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.
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.
Only Apple can provide the described security for their messenger, but other messengers which face similar challenges (rendering untrusted content) cannot protect themselves.
[1] https://www.phoronix.com/scan.php?page=news_item&px=Extendin...