Oh I think I've met you! You must be my coworker!
Just joking of course, looking fun of a privacy focused person while making a point my coworkers also don't read. I'm glad you didn't delete the post though, I enjoyed the journey. You did read, you're better than my coworkers.
Or maybe they're trying to keep their system minimised from yet to be found security issues in the hundreds of packages pre installed that they don't ever use or need, and act as nothing other than additional threat surface.
Yep though I'm a sysadmin and can feel for that, these consolidated platforms are being used as a straight "you trust this, when I infect you, I'll use payloads I'll temporarily host in github because you adjust already block overseas by default expect a bunch of whitelist trusted domains.".
It's technically easy to allow a subdomain, but it's really hard to unblock just a path.
So yeah, what generally happens is the SOC team complains that the new threat is here, and either vendors (had this with fortinet) move the risk rating of github from a 3.5 to a 6 out of 10, I had put the threshold at a default 5, and now it's being blocked. I wonder why it wasn't blocked before, well it wasn't as risky last week as it is now.
Anyway just thought I'd share the IT sysadmin POV.
More to point, using security as an example, we use SentinelOne and azure sentinel. I've had a 'I want to compare crowdstrike and huntress labs' because I've seen really good things with those xdr seim tools. But I got shot down. Why? We can't deviate our standards. Well, how will we know if the competition is better? Is our choice good? Who knows.
I still don't know. I sleep easy knowing it's not my burden though. It's their fault if they get compromised on an attack that the other vendor would stop.
Penny drop moment of "oh right we have to look at the competing engines to see our own weakness"? Frankly it should be obvious.
"If you know the enemy and know yourself, you need not fear the result of a hundred battles."
For me it raises really a odd question about their culture too, since only after inshin's remaster did they add a policy to review developer tools and technology, in a development company.
I'm trying to not read into it any more than that but I can't help but imagine there were board meetings beforehand going 'guys our team want to try using unreal' and some exec going 'no it's banned we only use our own propriety code or else we'll lose our brand and be washed out! All other engines are banned!'.
I agree I need someone who could tell me what a state nation could do with sequenced Ebola from a risk point of view.
I both think it would be a requirement to cure, and a requirement to modify to weaponise.
I think when the scientists lied when interviewed though they would only do that if they knew the trouble was grave.
The messaging around this so far doesn't lead me to want to follow the fork on production. As a sysadmin I'm not rushing out to swap my reverse proxy.
The problem is I'm speculating but it seems like the developer was only continuing to develop under condition that they continued control over the nginx decision making.
So currently it looks like from a user of nginx, the cve registration is protecting me with open communication. From a security aspect, a security researcher probably needs that cve to count as a bug bounty.
From the developers perspective, f5 broke the pact of decision control being with the developer. But for me, I would rather it be registered and I'm informed even if I know my configuration doesn't use it.
Again, assuming a lot here. But I agree with f5. That feature even beta could be in a dev or test environment. That's enough reason to know.
Edit:Long term, I don't know where I'll land. Personally I'd rather be with the developer, except I need to trust that the solution is open not in source, but in communication. It's a weird situation.
Although that might be true, the moment the 'friend' gave away his account recovery answers to the phisher I think he would have been compromised either way. It was likely that the phisher was in real time actioning a account recovery, and using the friend as the proxy to give answers to the prompts. Plus since it's already second hand info we can't tell, but if the phisher simply asked 'can you read me the code on your authenticator' or 'press approve and you'll complete the recovery process' and would have been successful.
In investigating account breaches I've found most people shamefully don't retell the whole story they're embarrassed and upset and fearing loss of employment. They kind of shut down. In this case, social status or opinion could bet harmed so it would be hard to trust the story is complete. Generally my logs come from entra ID and you can see the authentication came from the mobile device even though it was a prompt generated by the phisher.
Anyway I'm a big advocate for layers of security and you're completely right in your stance. Technology is fragile to exactly what you said. We live in a world of incomplete information using trust and judgement under time pressure and poor sleep. Phishing attacks are ruthlessly designed to target that weakness in people. I'm empathetic when it is successful.
On many systems, the weakest link is that it needs to accommodate a 'lost my x' eg mfa, password etc.
Systems often have a way to get in by resetting them by validating through more factors but often weaker ones, "not phishing resistant" factors like security questions. That way the account can get it removed or a new one put on.
Mfa isn't a silver bullet, it is another layer of Swiss cheese, most people will think twice about giving it away on a chat app. But there's a reason IT departments sign you up for those phishing simulation and training videos.
But you could still be right in this case, I just wanted to note broadly speaking you can't assume prefect security is achieved with mfa. You still need to be constantly vigilant.
Digging tunnels.
IP and Routing is layer 3, broadcast is layer 2 with Mac addresses being shared within a broadcast domain (often a vlan/lan) and the only requirement for layer 2 is a switch you don't need routers. Devices on a lan talk only via switches which switch based on Mac address tables. You don't learn Mac addresses of devices past your broadcast domain, that's what a router handles.
So in network practice (nothing Linux related) if you are on a broadcast network that's a /24 subnet, what should happen is all devices within that subnet talk to each other without using a router, instead they learn a mac address and the associated ip from a broadcast from the device which owns it.
If you tell your device that it's only on a /32 then it should discard every arp it hears as invalid. Which means it won't learn any neighbouring lan devices.
While your network on your single device with the /32 probably works ok to get to other networks (routed networks like internet or other vlans), because other networks ask the router, and the router probably learned your mac and ip on whatever vlan/interface your device is connected via.
But unless you're trying to do something unconventional, devices on a lan should match the routers expected subnet. This way devices can trust their assumption that within their subnet they communicate to other local devices by learning other network devices network address via arp, and communicate directly in unicast via learned ips from that arp. If it's outside the subnet they then look to the gateway. They trust the gateway. The gateway should route to the right interface or next hop.
If you really wanted to make this work though, usually routers can proxy arp. So in this case, you tell the router to 'oroxy' and broadcast your arp to other devices. Those devices on your lan looking for your ip will find the routers Mac address, then using destination network address translation you can redirect the incoming connection from a lan device to your device via your router. Then your /32 ip can probably work. Usually this is done when someone has put a static ip on a device with a wrong subnet ip on a vlan with another subnet. So the device which arps is ignored by the router and the other network devices. If you use the router to proxy arp you can basically give the local lan devices an ip to hit that they expect, which then you can translate to the misconfigured device. This generally is considered a bandaid solution temporary until a vendor or technician can fix their misconfiguration. I do not recommend.
I mean, the rdp is from Linux to Windows for desktop application access, so it's the right tool for that job.
Reasonably sure they mean telegram. Only secret chats are encrypted. Telegrams chat otherwise is basically transport layer encryption.
https://www.wired.com/story/telegram-encryption-end-to-end-features/