There should be no risk to storing all your public keys in e.g. 1password. When signing up for e.g. facebook.com, you should be able to hit a button and have all your keys registered at the same time. You can send $site all your public keys, and sign auth reqs as you log in. Of course, the UX would be handled by webauthn, so you'd really just be tapping your yubikey or scanning your fingerprint on login.
Ideally, password managers would offer key servers that websites could hit in real-time to pull your public keys. That's probably a stretch - maybe websites could sync your 2fa pub keys in the background.
With such a model:
1. Having multiple yubikeys
2. Having multiple team members with access (same as 1, effectively)
3. Revocation of individual 2fa devices
4. Adding 2fa devices after account creation
Would be pretty trivial.
I assume there's something basic in the webauthn protocol that I'm overlooking that prevents such a model. What is it, and why can't we have these properties?
I for one don't want all my accounts to hinge on access to a single physical device, and I certainly don't want to register 10 yubikeys with every service (some I may not even have physical access to on a day-by-day basis).
GCP supports remotely loading public ssh keys onto a box. They do this using the metadata endpoint - this is (in theory) a trusted API endpoint available to instances @ 169.254.169.254. IAM actually uses this - when you call other services, client libs reach out to the metadata endpoint and get IAM creds to send with each request.
Anyway, they have a local process that polls the metadata endpoint and adds authorized keys on the host. So you can e.g. upload your public key in the web UI, their metadata endpoint will serve it up on your instance, the guest agent will poll the metadata endpoint and add your key to the authorized_keys file.
These folks spoofed a response from the metadata endpoint. They used https://github.com/kpcyrd/rshijack to inject their own hand-crafted public key, which the guest agent happily added to authorized_keys (and created the wouter user).
My main FUD with alpaca.markets is the ability to transfer assets in/out. It doesn't look like they offer ACATS transfers (although there's not much info on this!).
Using them for anything beyond entertainment budget is very scary - you may incur substantial tax liability if e.g. they ever go out of business or you choose to use a different brokerage.
Any insight here? Am I missing something? Is there any way to transfer holdings out without incurring the cap gains?
I built this because I had 10+ bank accounts, and they were annoying to monitor. I'd log in every month and have to chase down why they didn't look as I expected them too.
I've set up Lambda functions to e.g. post bills to Splitwise, email me when my balances go above/below thresholds, and pipe all transactions into Google sheets. I've been running my own personal finances off it for a while and it's greatly improved my quality of banking life.
It uses plaid under the hood, so I get read-only access to bank data. You can validate by inspecting network reqs - it just grabs a public token from plaid and sends it to my backend - I never see the bank creds. Whether you trust plaid is up to you.
The premise is simple - define arbitrary conditions on transactions or balances, and get webhooks or emails when those conditions fire on any of your bank accounts.
I have >10 bank accounts and was having trouble monitoring them. I use this to alert me of any activity, on any of my accounts, that is unexpected. I no longer need to log into banks. I also use it to alert me if my balance gets too low or too high in any account.
I've also deployed Lambda functions to e.g. post my utilities bill to Splitwise to automatically split with my roommates, or pipe all transactions into a Google sheet so I can analyze my spending over time.
It started out as a simple hobby project but has grown into an immensely useful tool in my day-to-day life.
Mount the docker socket. There's some quirks with storage volume paths. Also, security implications. Was not super hard to get working though.
I'd love to go straight to containerd or even basic linux containers but I'm not willing to run kubernetes on my personal machine and haven't found any ergonomic enough ways to run containers.
This is the exact class of problem that docker itself attempts to avoid. This is why I run docker-compose inside a docker container, so I can control exactly what it has access to and isolate it. There's a guide to do so here[1]. It has the added benefit of not making users install docker-compose itself - the only project requirement remains docker.
We've actually been working on something similar. Our goal is to make it as dead simple to send a letter as possible in USA. We'd love any feedback people have!
The webauthn spec has public/private keys incorporated: https://www.w3.org/TR/webauthn-2/#sctn-sample-registration
There should be no risk to storing all your public keys in e.g. 1password. When signing up for e.g. facebook.com, you should be able to hit a button and have all your keys registered at the same time. You can send $site all your public keys, and sign auth reqs as you log in. Of course, the UX would be handled by webauthn, so you'd really just be tapping your yubikey or scanning your fingerprint on login.
Ideally, password managers would offer key servers that websites could hit in real-time to pull your public keys. That's probably a stretch - maybe websites could sync your 2fa pub keys in the background.
With such a model:
1. Having multiple yubikeys
2. Having multiple team members with access (same as 1, effectively)
3. Revocation of individual 2fa devices
4. Adding 2fa devices after account creation
Would be pretty trivial.
I assume there's something basic in the webauthn protocol that I'm overlooking that prevents such a model. What is it, and why can't we have these properties?
I for one don't want all my accounts to hinge on access to a single physical device, and I certainly don't want to register 10 yubikeys with every service (some I may not even have physical access to on a day-by-day basis).