It’s nice that this exists, but even for this I’d prefer to use an open source tool.
And it of course helps with migration only if the old HS is still online…
I think most practically this migration function would be built inside some Matrix client (one that would support more than one server to start with), but I suppose a standalone tool would be a decent solution as well.
Wish the homeserver portability would be worked on more. The ability to change homeserver would really allow people to more easily move on from matrix.org.
Myself included ;).
Optimally it would even allow the switch “after the fact”, so after your original homeserver is down, assuming your client has a local copy of the server-side secret storage. It would need to be based on some cryptographic identity then, I suppose.
Does he already not have the opportunity, robot or not?
I’m also in a one-party consent country, and I’ve found it sometimes useful to get back to some calls just to find out some details, such as agreed date/time or some detail of a discussion I had with my mother. I would enjoy an automatic text translation to be stored alongside them.
I miss the feature now that I have Pixel 8.
I used syncthing to sync them to PC. Size-wise I have so few phone calls (work meetings excluded, which they are as they are over Slack/Teams) that all of them will fit most any modern phone easily.
They presumably assume they’d be selling so little that it wouldn’t be worth the trouble.
They’ll probably wait out this situation for a while and see what the competition does…
If you just do it on your own computer, the packet will be already dropped by your own gateway. You can fake whichever address in your local subnet, but those are very likely remapped anyway in your gw to the one given by your ISP.
If you would have access to the switch port used by your ISP in the Internet exchange point (IX), you would have more liberties in choosing the IP.
That’s a bit surprising, given DDG uses Bing, Bing is Microsoft and Microsoft owns Github.
Did you try the same search with Bing, or have an example to share?
Did you give it to it?
It can be a pretty nice feature for using map-based apps in the browser.
I haven’t used such websites for a while and I don’t see Firefox in the recent users of the location API, even though I use Firefox Android all the time. (Info available in Android under Settings/Location.)
And did mentioning these things just make the message disappear on US-based lemmy-instances?
I don’t believe it did.
Perhaps many, but I have over 500 accounts in my password manager, yet none of have been leaked per the password exposure report (which I assume is based on the https://haveibeenpwned.com/ database).
So perhaps the problem is overblown in practice, assuming you don’t use the same password in many sites.
Realistically, how often does this happen?
Maybe find a solution when it happens.
In theory, yes. But if you follow the link and that leads to downloading the JS and running it, you’re already too late inspecting it.
And even if you review it once (and it wasn’t too large or obfuscated via minification), the next time you load a page, the JS can be different. I guess there could be a web browser extension for pinning the code?
The only practial alternative I know of is to have a local client you can review once (and after updates).
So the trick is to use the #fragment part of the URL, that is not sent to the server.
Of course the JS one downloads from the server could easily upload it to it, so you still need to trust the JS.
Maybe consider static ip assignment in your DHCP server (e.g. internet router) if at all possible… Then you can add a name to it to /etc/hosts.
Alternatively you could use Avahi to provide mdns names to your local network
Do you have that file? If not, then unset SSH_AUTH_SOCK will work just as well.
If it does exist, then I suppose it has good chances of working correctly :). ssh-add -l will try to use that socket and list your keys in the service (or list nothing if there are no keys, but it would still work without error).
At the end of the log you find:
822413 connect(4, {sa_family=AF_UNIX, sun_path="/run/user/1000/gcr/ssh"}, 110) = 0
...
822413 read(4,
meaning it’s trying to interact with the ssh-agent, but it (finally) doesn’t give a response.
Use the lsof command to figure out which program is providing the agent service and try to resolve issue that way. If it’s not the OpenSSH ssh-agent, then maybe you can disable its ssh-agent functionality and use real ssh-agent in its place…
My wild guess is that the program might be trying to interactively verify the use of the key from you, but it is not succeeding in doing that for some reason.
As mentioned, -v (or -vv) helps to analyze the situation.
My theory is that you already have something providing ssh agent service, but that process is somehow stuck, and when ssh tries to connect it, it doesn’t respond to the connect, or it accepts the connection but doesn’t actually interact with ssh. Quite possibly ssh doesn’t have a timeout for interacting with ssh-agent.
Using eval $(ssh-agent -s) starts a new ssh agent and replaces the environment variables in question with the new ones, therefore avoiding the use of the stuck process.
If this is the actual problem here, then before running the eval, echo $SSH_AUTH_SOCK would show the path of the existing ssh agent socket. If this is the case, then you can use lsof $SSH_AUTH_SOCK to see what that process is. Quite possibly it’s provided by gnome-keyring-daemon if you’re running Gnome. As to why that process would not be working I don’t have ideas.
Another way to analyze the problem is strace -o logfile -f ssh .. and then check out what is at the end of the logfile. If the theory applies, then it would likely be a connect call for the ssh-agent.
Well that’s exactly the worry. Why shouldn’t it be? It is their business and livehood.
As if taking down the systems is the biggest cybersecurity threat a company might have.
Well, if these devices required any sort of authentication (e.g. pairing) to free access to their ram and flash, we wouldn’t be having this particular story…