That’s not how legal jurisdiction works in the EU. Member states are still sovereign; if you’re liable for something in France and you get off a plane in Germany then France still needs to ask Germany nicely, and sans an extraditable conviction nothing is likely to come of it.
He’s not smart enough. More like the Grand Negus.
So you’re a practiced expert and cannot understand how those who are not practiced experts can have trouble?
Minimise your windows one at a time and check that the gnome keyring hasn’t popped up a dialog box sonewhere behind everything else that’s asking you if it’s okay to proceed.
It’s the gnome key ring ssh agent.
It’s possible that this has popped up a window asking gor permission / a passphrase / something and you’re not seeing that.
That’s only part of the handshake. It’d require agent input around that point.
Is this problem a recurring one after a reboot?
If it is it warrants more effort.
If not and you’re happy with rhe lack of closure, you can potentially fix this: kill the old agent (watch out to see if it respawns; if it does and that works, fine). If it doesn’t, you can (a) remove the socket file (b) launch ssh-agent with the righr flag (-a $SSH_AGENT_SOCK iirc) to listen at the same place, then future terminal sessions that inherit the env var will still look in the right place. Unsatisfactory but it’ll get you going again.
Okay, that agent process is running but it looks wedged: multiple connections to the socket seem to be opened, probably your other attempts to use ssh.
The ssh-add output looks like it’s responding a bit, however.
I’d use your package manager to work out what owns it and go looking for open bugs in the tool.
(Getting a trace of that process itself would be handy, while you’re trying again. There may be a clue in its behaviour.)
The server reaponse seems like the handshake process is close to completing. It’s not immediately clear what’s up there I’m afraid.
Please don’t ignore the advice about SSH_AGENT_SOCK. It’ll tell yoy what’s going on (but not why).
Without the ssh-agent invocation:
ssh-add -L show?lsof)This kind of stuff often happens because there’s a ton of terrible advice online about managing ssh-agent - make sure there’s none if that baked into your shellrc.
Have you seen pictures of the sub? What makes you think the wiring was all hidden?
You joke, but watch this:
https://archive.org/details/take-me-to-titanic
from 29 minutes in. A last-minute adjustment before launch plugged in a thruster backwards; no protocol to check the behaviour prelaunch. They doscovered it when they got to the bottom.
Figure eight on a bight.
[[[ …specifically garbage collection (GC) is really really fast compared to some other languages (I’m looking at you Java) ]]]
… Really? This is quite a claim - does anyone have references to the details behind this?
…unless it’s running software that uses signed 32-bit timestamps, or stores data using that format.
The point about the “millennium bug” was that it was a category of problems that required (hundreds of) thousands of fixes. It didn’t matter if your OS was immune, because the OS isn’t where the value is.
Dare I ask what the adjective “hella” means in this context?
The test case purported to be bad data, which you presumably want to test the correct behaviour of your dearchiver against.
Nothing this did looks to involve memory safety. It uses features like ifunc to hook behaviour.
The notion of reproducible CI is interesting, but there’s nothing preventing this setup from repeatedly producing the same output in (say) a debian package build environment.
There are many signatures here that look “obvious” with hindsight, but ultimately this comes down to establishing trust. Technical sophistication aside, this was a very successful attack against that teust foundation.
It’s definitely the case that the stack of C tooling for builds (CMakeLists.txt, autotools) makes obfuscating content easier. You might point at modern build tooling like cargo as an alternative - however, build.rs and proc macros are not typically sandboxed at present. I think it’d be possible to replicate the effects of this attack using that tooling.
Netware was rock solid.