yeah! you beat me to it 👍
guess this instance is lost, lets restart the matrix!
yeah! you beat me to it 👍
guess this instance is lost, lets restart the matrix!
with a microscope
if it was at least a scanning tunneling one, then yes, good job 👍 🤪
well there is plenty of what is possible to try. but unless one had looked at the real cause i’ld suspect one of apples hardware backdoors to cause the crashes like if the backdoor doesn’t work, crash the kernel, so we never loose control over the sheeapple thing. or more realistic if you want:
First maybe just crappy hardware:
There is a reason why i suspect apple’s hardware, cause my shitty macbook at work should(!) go to something like hibernate, sleep, or its spyveillance-only mode when closing the lid, and it should also lock the screen when doing so, the actual results seem pure randomly choosen, sometimes the sleep mode survives the weekend with lots of accu left, sometimes its completely depleted and i even have to charge it for a while before it has enough power to show the charging logo. for security reasons i have to manually lock my screen, verify it and then close the lid, which is pure annoy. this could just be buggy hardware, a sensor so broken that reading its inputs directly could crash any OS that assumes i.e. no division by zero, pointers to nonexisting ram or whatever, and maybe apple just knows what faulty measurements mean what (but cannot make that stable too, only no crash occurs)
secondly with a hardware backdoor:
“The discovered vulnerability is a hardware feature, possibly based on the principle of “security through obscurity,” and may have been intended for testing or debugging. Following the initial 0-click iMessage attack and subsequent privilege escalation, the attackers leveraged this hardware feature to bypass hardware-based security protections and manipulate the contents of protected memory regions.”
which is that (some/all?) iphones have at least one memory page where one only has to accidently or intentionally write something into it, that could trigger the backdoor feature to let you choose which memory address to overwrite with what bytes, bypassing every(!) security mechanism in hardware AND of course those made of software too. that is how i understood documentation and presentations about it. now apple said they “fixed” it in software, from what i remember that fix was just a “os preventing apps from writing to that memory backdoor page” thus not a fix but only a mitigation, while “fix” is more a lie than only misleading words to just pretend it wasn’t permanent and unfixable. let us assume that linux does not include hardware backdoor mitigations for apple devices AND that apple placed the very same backdoor memory page into macbooks as well but maybe at (an)other physical address(es). now the code that runs on closing the lid “might” just reside at or write to the very same memory page on every boot for a given exact same kernel, which might be a memory page that acts the same or similar like that iphone hardware backdoor, overwriting some other memory page depending on what is actually written to the backdoor page which immediately crashes the kernel. if that’s whats happening there, t2linux is not broken, but macbooks are just insecure costly (loss of money, time, security, trust, work performance, patents, stability, a.s.o. …) waste.
how to find out? (maybe)
changin the kernel a lot by removing everything(!) not needed should in theory/hopefully also change the pages that would be affected when closing the lid. same effect: likely no backdoor. no effect: maybe something you deactivated, maybe yet another backdoor discovery.
it might also be solveable by sth like acpi settings or such, probably switchable from kernel boot cmdline , maybe change settings for hibernate / suspend to ram (does apple hardware even support such? i mean without the buggy behaviour i experience?)l
but you did notice that compilers can be manipulated to include backdoors into resulting binaries AND put the same manipulation into newly compiled compilers as well, right? then where did you get that compiler from? did you have a look at the binary output? then if so, did you look at it using the hexeditor of that same compiler? 😎 plz have a look … 💥 bzzzt … really you are lucky to be alive after a blast like that, especially you, have yourself checked out with ems before you leave!
you should definitely know what type of authentication you use (my opinion) !! the agent can hold the key forever, so if you are just not asked again when connecting once more, thats what the agent is for. however its only in ram, so stopping the process or rebooting ends that of course. if you didn’t reboot meanwhile maybe try unload all keys from it (ssh-add -D, ssh-add -L) and see what the next login is like.
btw: i use ControlMaster /ControlPath (with timeouts) to even reduce the number of passwordless logins and speed things up when running scripts or things like ansible, monitoring via ssh etc. then everything goes through the already open channel and no authentication is needed for the second thing any more, it gets really fast then.
you already have an internet connected back door in your CPU.
unless you’re running your own gsm station and let your cpu’s safely connect to it, and use that connection for additional snmp monitoring data?
i would not trust hardware from a vendor that puts hardwired backdoors into physical memory… you’ld undermine any security the OS could give you.
The whole point of ssh-agent is to remember your passphrase.
replace passphrase with private key and you’re very correct.
passphrases used to login to servers using PasswordAuthentication are not stored in the agent. i might be wrong with technical details on how the private key is actually stored in RAM by the agent, but in the context of ssh passphrases that could be directly used for login to servers, saying the agent stores passphrases is at least a bit misleading.
what you want is:
also an idea:
all depends on the level of security you want to achieve. additional TOTP could improve security too (but beware that some authenticator providers might have “sharing” features which could compromise the TOTP token even before its first use.
My theory is that you already have something providing ssh agent service
in the past some xserver environments started an ssh-agent for you just in case of, and for some reason i don’t remember that was annoying and i disabled it to start my agent in my shell environment as i wanted it.
also a possibility is tharlt there are other agents like the gpg-agent that afaik also handles ssh keys.
but i would also look into $HOME/.ssh/config if there was something configured that matches the hostname, ip, or with wildcards* parts of it, that could interfere with key selection as the .ssh/id_rsa key should IMHO always be tried if key auth is possible and no (matching) key is known to the ssh process, that is unless there already is something configured…
not sure if a system-wide /etc/ssh/ssh_config would interfere there too, maybe have a look there too. as this behaviour seems a bit unexpected if not configured specially to do so.
i experimented with this some time ago, see my post here: https://lemmy.ml/post/18706002/12772832
i had experimented with kexec and takeover.sh to install a distro that was not available by my provider.
it resulted in some scripts i now (triggered by this thread) have published (in a nonready state):
http://github.com/tobinq/goaround
the scripts may be in bad shape but i successfully changed one preinstalled ubuntu to a devuan with what is in these scripts. however i didn’t work on them for month now and am not sure about that last state… so its experimental only.
What are you using to actually get the detail?
i am using the F-Droid “app” (currently 1.20.0), not a browser now. But i asumed css or such could be a cause as sometimes nonvisible content is behind some bad (ad?) layer. i thought i had seen such infos also on their website, but that is then too long ago and i might just be wrong with that.
maybe you can only get that info from the app which would feel a bit like an anti feature *haha
yes it protected - by accident - the servers from booting into malware 😁
well maybe letting them pay compensation to all(!) victims (not just their customers) for all losses including lost time already would solve that problem.
that would leave the decades-long unsolved problem of microsoft not beeing held liable for their buggy products (which is the reason for all security-products-as-a-workaround-to-compensate-that-crappy-os companies existance) open.
why not in general hold companies liable for the damage they cause so they CAN develop beeing more cautious with what they do? i mean not ONLY cs should be sued to hell, but ALL of them should be sued until they are reasonable cautious with all possible damages they can cause (and already did in the past)
so i misunderstood. sry then.
and yes, every company running an alltime-ever-in-news-due-to-critical-exploitable-bugs-in-the-mailclient already IS in freefall after that said jump.
i somehow feel this might be sort of a vim-vim situation 😁
maybe the browser version isn’t fully complete, or there might be a thing with css, bad browser specialities, just a bug in the webpage (did you check if it does show up in page source plaintext maybe?)
i would see the warning "bound to a specific non-changeable service as a good thing, as it would promote completely-free apps like (i think) fluffy chat, which does neither depend on a specific matrix service nor on a specific push service (i.e. it uses ntfy for push when installed, and if i choosed to use my own instance it would - i think - use that instead of the default ntfy.sh) in theory everyone could run something like osm and in practice this could come in very handy in the future one day, but currently IMHO only one osm exists, so maybe its not that bad for an app to be bound to it, but its always good to know if an app is bound or free to choice, same i would like to know if its maybe multi-account (which fluffy-chat is), but single-account-apps are so very common and thus this is not seen as an anti-feature which is completely ok for me.
but also in this case here the app is not only bound to osm, but to two other non-changeable services too, thus the warning is due even if label-app-bound-to-label-service would NOT be considered an anti-feature.
most Linux “Users” would’nt be that stupid. it nearly always takes a noob in a CEO position (okay, just saying CEO is sufficient here) to blindly trust malware distributers and their ads.
maybe there was a mixup of individual datapoints and individual persons.
lets see if that could fit.
as far as i read things in this thread, the whole security is based on exactly these datapoints: Full Name, Date of Birth and SSN (three datapoints) plus username and password for 3 sites (six datapoints) makes 3+6= 9 datapoints per person.
2.9 billion (us) should be 2.900.000.000 (correct me if i’m wrong, but where i live one “billion” is actually “1.000.000.000.000” thus a “bit” more)
divided by 9 those 2.9billion would be ~ 320 million.
on wikipedia they say the us had 331 million people in 2020…
that would fit like an ass on a bucket! lol just to mention that.
have a nice day!