adamckay
Joined 5 years ago
Joined 5 years ago
 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.
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.
Thanks for letting me know (embarrassingly I did load up the PEP page to make sure I remembered the right number but I didn't check its status).
Was hoping that it would make things simpler for smaller projects and newbie developers but the rejection reason is solid.
I was asking if they are also suggesting that this second-degree insider trading be stopped somehow?
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...
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.
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.
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.