It's probably the right approach to onboard a few independent security companies and task them with reviewing multiple OSS projects than it is to onboard each project individually.
It takes decades to grow the trees that then absorb the CO2 that is emitted from the burning, and the biomass that Drax burns has been (and still is) imported from Canada from felling old-growth forests (some of which have been estimated to be over 250 years old), and this isn't even considering the emissions from transporting the pellets via ship, rail and road from western Canada to eastern England which is not tracked against Drax.
Your markdown file has an image that links to another server controlled by the attacker and the path/query parameters you're attempting to render contains sensitive data.
For context, Major Paeta Hess-von Kruedener emailed [1] days before saying that Hezbollah were using his positions and the IDF was being forced to fire on them out of "tactical necessity". This isn't as clear-cut as you're attempting to paint it.
I can imagine soon - within the next year or so - that business emails will simply be AI talking to AI. Especially with Microsoft pushing their copilot into Office and Outlook.
You'll need to email someone so you'll fire up Outlook with its new Clippy AI and tell it the recipient and write 2 or 3 bullet points of what you want it to include. Your AI will write the email, including the greeting and all the pleasantries ("hope this email finds you well", etc) with a wordy 3 or 4 paragraphs of text, including a healthy amount of business-speak.
Your recipient will then have an email land in their inbox and probably have their AI read the email and automatically summarise those 3 or 4 paragraphs of text into 3 or 4 bullet points that the recipient then sees in their inbox.
If you want to stick with using `pip` over any of the newer tools that build on top of it (Poetry - my favourite, pdm, pipenv, rye, ...) the simplest way I used in the past was to use a `requirements.human.txt` to set my dependencies, then install them in a venv and do `pip freeze > requirements.txt` to lock all of the transitive dependencies.
An Xbox was ordered that's classed as a "high value" item so requires a OTP being given to the driver to release the package.
The package was hand delivered to the customer when the customer provided the OTP, but it turns out the contents of the package were swapped out with junk.
I'm asking for clarification because whilst there's a strong argument that politicians are performing insider trading (which as you say is widely regarded as something that should be stopped), if an amateur can copy those trades and make a 20% profit on them, what's stopping hedge funds from doing the same and millions or billions from what is basically second-degree insider trading?
I was asking if they are also suggesting that this second-degree insider trading be stopped somehow?
Can you clarify what you mean by "this"? Being able to copy the trades of politicians or politicians making trades that are almost instantly profitable?
Poetry is an all-in-one tool that does dependency management using `pyproject.toml` files and its own `poetry.lock` files, as well as package building, virtualenv management, and also has hooks for entrypoints and scripts.
It's rather a useful tool and I'm personally using it for dependency management and packing for all my projects moving forwards, though for venvs I'm using `pyenv` and the `pyenv-virtualenv` plugin.
Once you figure out your workflow it can be quite nice, but it's figuring it out that's a huge mess in Python at the minute. Hopefully PEP 582 (Python local packages directory) solves it a bit...
> the attacker obtained a valid administrative session token from _after_ any MFA would've been completed
But you can lock session tokens to specific IPs or user agents. I've implemented similar in the past for a B2B admin-panel, and whilst there were the occasional false positive with browsers updating in the middle of a session (incrementing the user agents version number) and people's IP changing if they switched networks (or in one instance, a badly configured office network that randomly routed through 2 proxy servers with different outbound IP addresses) which then made it demand MFA again, it was fairly rare and didn't attract too many complaints.
> In 2018, Airbnb began its migration to a service-oriented architecture, as the Ruby on Rails “monorail” started becoming hard to maintain and was a single point of failure.
A monolithic codebase doesn't have to be deployed as a single artifact to be a single point of failure.
There's nothing stopping you from deploying a monolith application across a distributed number of machines in a highly available manner, including making machines favour some types of work (e.g. web workers and background job workers). Nor is there anything stopping you from performing blue-green deployments or A/B testing if you want to interpret single point of failure as a bug is deployed to all machines simultaneously and affects your entire application.
You would be correct if the ID were an integer being serially increased. I can sign up to your website today and get an ID X and then sign up again in a week and get ID Y, I can then calculate the number of new users you've had by performing Y-X.
If this ID is a timestamp then there's no such information I can get out of it from a small sample. I sign up today and get todays timestamp, then I sign up next week and get next weeks timestamp..?
> BUT my problem with this is "where do you draw the line?"
Wherever it makes sense for you and your organisation. There's not a list of approved "boring technology" and unapproved "exciting but scary technology". It's not about the age of the technology, but your level of experience with it. If you know it inside out, understand its failure modes and can easily find information when something goes wrong it's "boring".
If your team can configure AWS services in their sleep but have never touched a bare metal box then AWS is boring. On the flip side, if you're a bunch of Linux greybeards and wrote the book on iptables but can barely spell VPC then on-prem is boring.
This is also where the concept of "innovation tokens" comes in. C++ is well established and quite far from innovative on its own, but if you're building a web app and your team is full of new graduates and interns that have only ever touched Javascript and Python then using C++ would spend one of your "innovation tokens" as your team is busy learning it instead of learning the business domain.
But if you're using Postgres as your queuing system because you're already using it as your core database technology for your app, you've got the same issue. If your single Postgres instance is down then your app is, too, and won't be enqueuing more jobs.
And unless your jobs are trivial then it's highly likely that they interact with your app in some way so it doesn't really matter if your workers are distributed and up, they're not able to complete their work because your app is down because of a single-node Postgres.
No, I don't think you're missing anything, other than you'd only mount the directories you want the tool / development environment to have access to. Take for instance the `npm` command [1], it mounts `$PWD` so if you install a compromised package then it can go through the folder you're in, but it can't then go up directories and sniff around your home directory. It would also only have access to the environment variables that have been configured for the container, which in this case would also include AWS credentials.
> It's the environment and socialization factors that drive this.
Then why is it overwhelmingly this breed that attacking people?
We accept that certain breeds have innate instincts and traits - border collies herd, labradors retrieve, greyhounds run, pointers point, small terriers chase - but you argue that this breed of dog that was (when you trace its lineage [1]) originally bred to bring down bulls and be aggressive and fight can't possibly be aggressive because of its breed?
It's been recently reported that half of all of these XL Bully dogs in the UK are descended from a single dog called "Killer Kimbo" which itself was inbred [2] and its first and second generation offspring were responsible for killing a 4 year old child and a grown man respectively.
It's probably the right approach to onboard a few independent security companies and task them with reviewing multiple OSS projects than it is to onboard each project individually.