Hacker News new | past | comments | ask | show | jobs | submit | patrakov's comments login

Not only that. Having private IPv6 addresses in the LAN is the easiest way to work with two ISPs and have fail-over. The other way is RFC8475, but I don't know of any implementation except my custom script on OpenWrt: https://forum.openwrt.org/t/ipv6-wan-fail-over-without-ipv6-...

> Basically outside of the corners like Nix, Guix and maybe a few random people in discussions about issues of package managers, I have not met anyone knowing how to and caring about reproducibility.

And I did. He was a developer of a purported secure messaging app. The question that changed his mind was: "How are your users, who surely audited your sources and found no trojans hiding there, going to know that you are not distributing trojaned official binary builds?"


> OpenWRT is pretty great at offering features and security for consumer devices

That's a misconception. Nobody actually cares about security for packages that are not in the default install. For example, the initscript for sstp-client disables certificate validation unconditionally, see https://github.com/openwrt/packages/issues/25212


It at least offers more security than the usual alternative on a consumer router of the manufacturer's OS (i.e. something updated once a decade running linux 2.6 with GPL-violating unreleased patches so you can't update it yourself, all written in C by the contractor that bid the lowest).

If others think this is in jest, there are recent TP-Link routers with 2.6 kernel and Broadcom.

Good job on raising that issue. TIL SSTP.

> Nobody actually cares about security for packages that are not in the default install.

Probably an exaggeration, but it's clear there are some packages that are insecure out-the-box.


Worse; the crappy sensors will be only 8 megapixels or less, but the camera software will inflate that with AI to 200 megapixels.


This has been happening for ages in the trail camera market.


It's, possibly, not good enough. In case of a fire, if you left all your phones at home, you are screwed.

Exactly because of the fire risk, I set a policy for myself that all passwords should be somehow recoverable only from something that I know. However, I don't meet this policy at the moment.


It is not just a script running every 90 days. It's also monitoring that the script didn't break, cron didn't break (you know, cron sometimes breaks after the PAM package update), your account didn't get banned, and that your domain name is not affected by a mass revocation.


Are you... not monitoring those things otherwise?


It does not matter in the real world whether the vendor declares it secure.

Did it help anyone pass any kind of security audit? In other words, do auditors recognize it as a valid environment for working with potentially malicious documents, or only as a toy?


Three points:

(1) Qubes is open-source.

(2) Qubes is written and maintained by security professionals.

(3) Most (all?) security audits are worse than useless.


I think I know what has happened.

The PSU manufacturer has cheaped out on the capacitor in the input, in hope that the circuit which switches the primary coil would still be able to extract enough power even if the instantaneous mains voltage drops to something as low as 30V (which it does twice every period). So, on a pure sine wave input, they only need to cover this (relatively short, below 3%) below-30V gap twice every period.

But with the UPS feeding the circuit, the situation is different: most of the time, the rectified voltage is 340V, however, there is a significant period of exactly 0V that still needs to be covered by the capacitor.


Nodex is not only an internet provider, but also a hosting provider. For example, you could (before the attack) rent a VPS from them.


Pixel Experience was not based on LineageOS. And Pixel Experience is dead and unsupported now. While there is no official direct successor, EvolutionX offers a comparable feature set.


Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: