>>This [...] vuln is not a breach or compromise of MongoDB
>IANAL, but this seems like a pretty strong stance to take? Who exactly are you blaming here?
You elide the context that explains it. It's a vulnerability in their MongoDB Server product, not a result of MongoDB the company/services being compromised and secrets leaked.
Worktrees are useful particularly because they look like entirely separate projects to your IDEs or other project tooling. They are more useful on larger projects with lots of daily commits. If you just use branches then whenever you switch, in the worst case, your IDE has to blow away caches and reconstruct the project layout or build the project fresh. On large projects this takes significant time. But switching your IDE to a different project, there are now two project and build caches to switch between.
There are OS-level settings for date and unit formats but not all software obeys that, instead falling back to using the default date/unit formats for the selected locale.
Render to pdf or ebook to read from an ereader, at least that's what I prefer. I use Instapaper to quickly snag articles while browsing then later use my kobo to sit and read through them.
The article presumes the reader is familiar with "malicious inbox rules" and doesn't elaborate or link to further info on it. From what I can find online it seems to be a scenario where an email account has already been compromised somehow and the malicious actor sets up inbox rules to e.g. auto-forward emails to another attacker-controlled email. I assume the intent is to effectively gain access to emails like 2FA and password recovery in the event the target changes their email account password.
Rust caught the lock being held across an await boundary, but without further context I'd hedge there's still a concurrency issue there if the solution was to release the lock before the await.
Presumably the lock is intended to be used for blocking until the commit is created, which would only be guaranteed after the await. Releasing the lock after submitting the transaction to the database but before getting confirmation that it completed successfully would probably result in further edge cases. I'm unfamiliar with rust's async, but is there a join/select that should be used to block, after which the lock should be unlocked?
Same would be true for any resource that needs cleaned up, right? Referring to stop-polling-future as canceling is probably not good nomenclature. Typically canceling some work requires cleanup, if only to be graceful let alone properly releasing resources.
They first disabled rubocop to prevent further exploit, then rotated keys. If they awaited deploying the fix that would mean letting compromised keys remain valid for 9 more hours. According to their response all other tools were already sandboxed.
However their response doesn't remediate putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for me.
If your only professional experience is OCaml and you want to look elsewhere for work then your opportunities shrink noticeably. Especially if you're looking for a position that requires experience. It's much more digestible for a company to hire someone out of college and invest in training on tooling. But many companies won't get past the resume if a senior developer has to take more time to on-board.
I don’t even prefer it for indicating that something can return null. In most cases the Option API is more tedious and awkward than a null check and there are existing annotations that can be used to flag nullable return types, for documentation. The only places I’ve found Option to be helpful are where it helps with method composability, or in some hashmaps as a simple way to distinguish between “lookup not previously tried” vs “lookup resulted in no value” vs “lookup resulted in value” - it’s a hack and looked down upon because the Option value itself is null, but I view it the same as “Boolean” being nullable. As long as the details are encapsulated it’s not too problematic.
> The technique was called product-line engineering.
Thank you for adding this bit of info! We’ve been using this model for a while but I hadn’t come across a label for it. Now knowing this, I’m coming across a ton of great info about managing/sustaining these product families.
Great write up. I read through maybe half of the points and skipped to the end, bookmarked to come back and finish later.
I’d like if the author could elaborate a bit about the types of projects that influenced these guidelines. Roughly what constitutes a “large” project, were the projects open source, private/commercial, or a mix of both, does web/service platform vs. desktop/local platform have an impact on these, etc.