548 karma · joined December 28, 2010
www.dwightgunning.com
Based on the track, it appears the ship changed course slightly and slowed as it approached the bridge [2].
[1] https://www.marinetraffic.com/en/ais/details/ships/shipid:28...
[2] https://www.marinetraffic.com/en/ais/home/shipid:2810451/zoo...
The attack works when the user doesn’t realize they’re sending their SHH private key through the password form of malicious-site.com.
Something like accidentally putting your Google password into the Dropbox login form. Dropbox have now seen your Google password.
With the recent LastPass exposure, the supply-chain attack on PyTorch, needing to be vigilent and avoid granting apps access to my cloud drive, I've actually just been reviewing my setup and workflow.
Here's what I'm planning to change...
Phone: Switching from MiniKeePass to KeePassium. I've found it's not too difficult to build KeePassium from source and install without needing an Apple Developer subscription. This means I can properly audit the code and control/verify all updates.
Laptops: Start building KeePassXC from source. In the short term, I'll be more diligent in obtaining updated versions from trusted sources and using PGP to verify the package.
File sync: Start storing the password file on a self-hosted file server. Having recently setup Tailscale on all my devices, it's now convenient to manage Samba and remove cloud storage from the system. In case the SMB share is inaccessible, I'll fallback to the backups kept by KeePassium and use cron+rsync to maintain an secondary copy on my laptop.
Backups: I'm planning to periodically backup to a hardware keypad encrypted USB drive. In comparison to a regular USB / external drive, the hardware encryption makes it harder for somebody to quickly make a copy of the password file and take it away to be brute-forced.
Would welcome any pointers on things I may not be considering or suggestions for improvement!
I took a look and the vulnerability that was exploited is warned about and described in the documentation.
> Warning > Using this option to search for packages which are not in the main repository (such as private packages) is unsafe, per a security vulnerability called dependency confusion: an attacker can claim the package on the public repository in a way that will ensure it gets chosen over the private package.
Still good but hardly fresh for a specialty.
Anyway. There’s a 6x number in here that somebody (or somebodies) completely missed…
Seems like what they thought was a fair-to-good deal was actually a such a terrible deal that, given their incorrect definition of a unit, the numbers in their model lined up.
That might be something the consultant could have spotted, since they’d seen the numbers around previous deals. I’m not sure it’s their duty/obligation to.
So far I’ve not found any limitations or issues using Ubuntu runners on my OSX dev machine. A couple examples from my workflows: - building docker images - provisioning VMs with the Digital Ocean cli / http api - hardening VMs with ansible - creating/managing k3s clusters with k3sup - deploying apps with helm
I like your suggested approach of using tmate to access the worker mid-way through a run. This should make it faster to develop/debug the steps that make up the workflow. Though this doesn’t address the cycle time of push-to-GitHub/queue-workflow/watch-for-result.
I’m actually going to try combining the two techniques - use tmate to develop inside a local act runner.
But it’s just a data point… gotta do your research.
Hang on a minute... their partner manufactured hardware product is easier to setup than their own software?
How hard is it to install on the major OSes?
Seems like a strange angle.
It’ll be interesting to see if converting classics will become more common. Here’s hoping.
Github: https://github.com/dwightgunning
Résumé/CV: https://www.dwightgunning.com/static/downloads/Dwight_Gunnin....
Email: dwight@dwightgunning.com
Location: Amsterdam, The Netherlands (permanent residency; Australian citizen)
Remote: Yes
Willing to relocate: Yes (US, Australia)
Location: Amsterdam, The Netherlands (permanent residency; Australian citizen)
Remote: Yes
Willing to relocate: Yes (US, Australia)
Technologies: HTML, CSS, JavaScript (Angular|React), Python (Django|Django Rest Framework), APIs and integrations, Postgres, AWS (EC2|S3|Lambda|RDS|CloudFront|R53)
Résumé/CV: https://www.dwightgunning.com/static/downloads/Dwight_Gunnin....
Email: dwight@dwightgunning.com