Hacker Newsnew | past | comments | ask | show | jobs | submit | emptybottle's commentslogin

I wish we could simply return cardboard boxes to e.g. amazon (who drives every neighborhood daily)

and check a box “I prefer recycled boxes” to signal that you don’t mind using a second hand box for your delivery.


You may be receiving second hand boxes already. When I ship products out, it's generally in a clean Amazon box. No one has complained yet.


For the same reasons why Boeings max8 was unsafe after decades of know-how — Shareholder value.


Totally. There is a stigma against Wordpress for $reasons but compared to all the other platforms listed in this article WP is one of the most aligned with the open web.


I’d even suggest shedding the thought that things can be “wrong”

“Wrong” is a subjective outlook and usually is not a helpful conclusion. Especially if the system is already active.

Better to discuss in detail the benefits of an alternative.


It would change the dynamics of the comment section a lot.

Instead of varied thoughts from many people in replies you’d be much more likely to have the one person arguing their point against replies which is terrible every time I see ot.


Dear Google: please leave well enough alone


What is the benefit over ssh-agent?


Where is the ssh-agent reading your private key from? If from ~/.ssh/, you're just one "npm install" away from the key being exfiltrated by a compromised package. If the private key is on your Yubikey, you're already good. The 1password agent will provide a good hardwareless method of keeping your private keys off the local filesystem, and it'll sync between your devices too.


> you're just one "npm install" away from the key being exfiltrated

It's not as easy as that if your private key is protected with a passphrase, which IMO ought to be the default option.

I am amused by the rationalization going on here, though... taking extra steps to secure your SSH private key because you might "npm install" something bad. There's nothing wrong with enhancing the security of your private keys through dongles or TPM chips but it's a lot better to attack the root of the problem: just don't run "npm install" (or similar untrusted code) in an environment that you don't want to get pwned.

My day job has me working with javascript packages but I don't have npm installed on my system, and never will. All of my work with npm happens inside docker containers. This offers many workflow advantages besides a layer of security.


> just don't run "npm install" (or similar untrusted code) in an environment that you don't want to get pwned.

So it is unreasonable to want to develop a JS app on the same machine I use for SSH?

Docker works I guess, but adds a lot of mental (and in the case of Docker for Mac, performance) overhead.


Just because I happened to be dealing with this today (on Windows with WSL2 but same rules apply) I'll make a comment.

The issue I ran into was due to Docker for Desktop binding the local filesystem into the devcontainer running in a WSL2 VM.

The solution to this is to instead use a named volume in your docker-compose.yml and in your Dockerfile copy the files from your working directory into your devcontainer.

This provided an incredible improvement in the performance of using devcontainers in vscode. The one big drawback to this approach that I've run into is needing to make sure I commit and push my code to a git repo when I'm done working as there's not a copy stored on my local machine.


Even better is defense-in-depth. Do development in VMs AND don’t store your private SSH in plain text on your laptop.


Your ~/.ssh/ private key is not readable by normal users since it's encrypted, so that isn't going to work.

The main security benefit is here:

> 1Password will ask for your consent before an SSH client can use your SSH key. Because of this, there's no concept of adding or removing keys like with the OpenSSH agent.

This prevents SSH agent hijacking, requiring either a social engineering attack to bypass or a privesc.


> If the private key is on your Yubikey, you're already good.

This is the way.


Why can the compromised package not also access wherever 1p is storing the keys or access the part of memory they're loaded into?


Because the keys never exist "on disk"? Why isn't every password manager pwned on every persons machine is what you're asking it seems.


No but what you seem to be saying is .ssh is pwned on every machine that doesn’t use a password manager.


A process can not dump the memory of another process if those processes are executing under different users, or the process performing the dump is root.

On many OS's there are even more strict restrictions, where within a user a process can only dump the memory of processes that are its direct descendants.


1p runs as the logged in user so does a hypothetical malicious npm package.


they would have access to the socket not the key, sure a very elaborated attack can probably figure out how to exfiltrate a lot of things (since they have already compromised the host) but for most, if they don't see things in ~/.ssh they would just go away and figure out another host to exfiltrate keys


Other commenters have mentioned sync, which is absolutely nice, but one other advantage is shared keys.

Obviously it's not ideal to share SSH keys, but lots of teams will share the default EC2 keypair for example. This makes it much easier to pop that key into 1Pass, share it with the team, and easily get everyone into the box.

And, frankly, 1Password gui is much more user-friendly than other SSH agents. Personally, I'll stick with the tried and true OpenSSH agent, but I know many will be attracted by this feature.


Point of order: afaict currently keys can be put in a shared vault but only keys in a private vault can be accessed by the agent. So the workflow would be everyone copies the shared keys into their private vault.


> Other commenters have mentioned sync

Isn't this an anti-feature? The ability to revoke an SSH key specific to a stolen laptop from a server or your Github account seems like a benefit. Using the same SSH key on every machine is a downgrade.

On the other hand, the ability to manage access to shared keys is really nice.


I guess rotating one key is easier though. Just update in 1psw and done.


But why are you "rotating" keys? Most of the reasons people give involve unnecessary exposure of the private key material, which is exactly what you're encouraging by having 1password keep these keys instead of them living on individual hardware.


Well keeps are also shared via chat or emails and people exit the company. Sure taking out one key is more precise but rotating all is probably easier


You may notice they aren't called "Fun size sharing keys" or "Family pack keys" but instead "Private keys" because of that word "Private".

You don't need to wait for people to "exit the company". Sharing private keys was wrong, invalidate those keys. If somebody else knows your private key it isn't private any more. Get this stuff right and rotating keys is unecessary, get it wrong and rotating keys can't help you.


Presumably if the laptop is stolen, the key isn’t exposed because it’s in 1Password, and the attacker doesn’t have your master password?


Has anyone compared the new 1password GUI for ssh keys to the Userify one, esp for a team? The userify one is only for SSH keys, but it seems great for safely managing public keys and leaving the private keys safe on our dev laptops (you can put in more than one key so a user can just disable one key at a time, and then it also has a great feature of actually killing all remote sessions when you remove the user account across all the servers -- haven't seen anything else that can do that.) The UI is perhaps a bit simplistic but it seems to do the job.


The cloud syncing, I suppose. If you migrate devices frequently and have more than a single ssh key, it might make sense to log into 1Password instead of trying to securely copy your private key from one device to another.

It does seem like a weirdly specific use-case. I wonder if they're trying to instead target people who need to use ssh keys but aren't comfortable generating or managing them on the command line. With Github requiring SSH keys for command-line pushes, this is probably a growing demographic.


But don't you restore a backup from iCloud whenever you get a new laptop anyway? And by device I don't think you mean an iPhone.


access to your ssh keys on any machine


> The difference is really the OS

It’s a huge difference!

I’ve enjoyed seamless upgrades since the iPhone 1 and maintained essentially the same user experience (with minor changes) throughout.

For me stability is the major feature. I want a high quality phone that just works and for my data to carry across devices seamlessly.


Discord channel sprawl is a strange phenomenon. It happens to each server I’ve joined, just gets worse over time.

I think park of the issue is that you cant /part a channel in discord. Every channel you have access is automatically joined, you can’t leave and you have to adjust notifications for each to avoid an overwhelming number of messages.

That and the communities are usually small-ish so you have the same people in most of the channels.


The solution I use to combat this is right click > mute server for every server I join, and also check the box under notifications > suppress @everyone and @here notifications. Then if I want notifications (either just the visual dot indicator or an actual ping for messages) I can do that on a per channel basis.

The only notifications I get are when I'm explicitly tagged or if a role I've opted in to is tagged. This cleans up the notification spam almost entirely, I only wish there was a way to set that as the default for any new server I join.


Even small communities can have painfully unaware, "organization" obsessed OCD people in it. They are generally the ones that keep insisting some particular thread of discussion really belongs in #xyz.


bigger communities work around this with roles to gate access, where the role is granted with bot interaction.

we could argue over what the application defaults should be, but its not unexpected the authors and users trend toward engagement being the default.


Every server eventually adds channels for memes, general off-topic, and pets.


Not sure why this is downvoted. I think one of the (many) reasons to lock the doors is absolutely to keep unauthorized persons out of the room.


Press ideates as "mask the truth" where unauthorised covers all contingencies including nutcase pizzagate conspiracy hunters, Walter Mitty types and "cleaner unplugged the data rack power" fuckups.

It isn't driven to keep the press out. If any benefit its a side benefit and I observe a metric French tonne of press is locked inside the room(s) at that point.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: