I agree with you that far too little effort has been extended in pushing systemd concepts as standards outside Linux, and the scope has been distressingly ambitious.
Still, systemd is a great improvement over the respawn behavior of inittab, allowing me to drop root privilege, set environment variables, chroot(), all combined with restart supervision. Yes, there are likely many other programs that do this, but respawn is SysV's job, and it should be more flexible. As it stands, when I have to do this, I write a bunch of shims either with shell scripts or custom C, and I've had do it on a wide variety of legacy operating systems.
The inetd.conf also benefits from most of these new features, although I uncovered a bug with socket activation and chroot() that I was able to work around that has since been fixed.
Improvements to respawn and inetd are the killer features for me, and give me things that simply cannot be done with standard tools on other POSIX-focused operating systems.
SysV init should be extended to cover these uses, and I would feel more nostalgic for it were new versions to emerge.
Browser fingerprinting is big business. Tor Browser constantly throws warning dialogs for sites using the canvas element in attempts to uniquely identify your machine.
Tor Browser also warns you not to maximize it, as your monitor size is also useful tracking information.
Tor Browser conspicuously features duckduckgo.com as the preferred search engine.
Microsoft provides search services for Duck Duck Go, so much that Bing's results are commonly identical. Firefox can and should promote Bing in all of it's guises.
The startpage.com search engine appears to be based in Europe, and seems to continue to outsource to Google although this branding was recently removed from the home page.
It is Firefox that should demote Google to a second-class citizen, immediately opening an incognito window on startpage.com for Google searches and potentially launching a Tor process for it (which they are in discussions to bundle). Firefox should loudly begin work to sandbox gmail, maps, drive, and all other Google properties.
A few press releases of this, without even beginning work, would likely get Mozilla everything it wants.
I seriously doubt that access to the entire set of hidden bridge nodes has been blocked. These nodes are not advertised, and I am assuming that they do not appear in the public consensus documents.
The distribution points of the bridge node IP addresses were likely blocked. If and when Tor users find new bridge nodes by some means or other, they will be able to access the network again.
I also understand that WPA3 will get forward secrecy, and sessions will negotiate a temporary ("ephemeral") key for symmetric cryptography (assuming AES).
Should the traffic be recorded, it cannot be decrypted later if the password is broken.
The other benefit comes in the event that your password gets compromised nonetheless. With this new handshake, WPA3 supports forward secrecy, meaning that any traffic that came across your transom before an outsider gained access will remain encrypted. With WPA2, they can decrypt old traffic as well.
I do agree that it's not quite comparable, but I don't know any minimal Linux distribution that implements the equivalent of the OpenBSD base.
Perhaps to be fair, it appears that Oracle's RHCK has been reissued 7 times since April 15th, which is not quite as bad.
I have had several rounds of users who want one of the Red Hat clones for some app, then realize after deployment that avalanches of patches are required for these platforms and balked - easily thousands over a six-month period for a typical system. That is aggravating.
It would be nice if the browser could signal the scheduler that it launched a new tab as an untrusted process, causing the kernel to sanitize caches before and after its future time slices (in addition to any sandboxing the browser parent process and the OS were already doing).
It might also make sense if only processes with the same UID could run on different SMT threads on the same core, rather than just turning them off completely.
The current release of OpenBSD, version 6.3, has issued a total of 10 patches against base since release on April 15th. Four of these are security-related, and six are reliability bug fixes.
Oracle / Red Hat Linux in that time has issued 50 security-related patches, and hundreds more that are classed as bug fixes or enhancements.
Linux is strong because it scales up and down very well, it exploits CPU features for speed to make applications run very fast, it is friendly to new features, and it has the most market share in the POSIX realm. Linux is weak because it has sacrificed security for speed in many cases, and we have Dirty Cow, Towelroot, and many similar problems in userspace - this makes Linux a bad choice for systems that will not receive patches (i.e. phones, IoT devices, embedded systems, etc.).
OpenBSD prioritizes security over speed and flexibility. It does not implement fine-grained SMP due to security concerns, and has a "big kernel lock" that Linux left behind in 2.2. It ignores many well-known standards (i.e. NFSv4). There are many things that you cannot do on OpenBSD, but what you can do is magnitudes safer than Linux.
Android politely stole OpenBSD's entire libc implementation (and then ignored it for several years), and IIRC the OpenBSD code is the largest contribution outside of the kernel itself.
OpenBSD is also the home of OpenSSH, which itself is quite secure.
I trust the opinions of the OpenBSD kernel architects, and I will look forward to their patch.
Fukushima has shown us that a loss of power for 36 hours at any of these facilities will cause them to boil off all their coolant, melt their containment vessels, and poison the surrounding environment for thousands of years. This includes both the reactor vessels and the waste/spent fuel rods in the local storage ponds.
The exact same GE model that failed in Fukushima runs 30 miles upstream from me on the Mississippi. Should it lose power as Fukushima did, the Mississippi river will be lost to our country. This reactor was scheduled for closure and was saved by my state legislature, and it should not be running.
The iFont app in Google Play offers a font named "Armani."
I was able to use iFont to create an APK file of this font, which I pulled onto a Red Hat desktop. After running unzip on the APK, I found an "Armani.ttf" True Type font file.
The font viewer reports this to be Bauhaus ITC regular.
This is my favorite font, and I copied it over the Android default/system/fonts/Roboto-Regular.ttf.
Supposedly, this typeface was obtained legally. I have had trouble with iFont in the past, so I don't install it anymore, but I have kept the exported typeface.
I am able to load Cygwin on my Windows 10 system at home in the/cygwin64 directory, bring it to work on a flash drive, unzip it on my work desktop, and I suddenly have X-Windows, an ssh suite, and a compiler.
It is unlikely that I will be getting WSL on my work machine without lots of approval gymnastics, so I will pass on it for now.
I am very pleased that major U.S. carriers were pressured to dump you. The unlockable bootloaders were likely a ploy anyway. ZTE has given us reason to spurn these products.
For those times that I want or need to use Microsoft mail services, I prefer to use Tor Browser to connect to http://outlook.com/
Be aware that Microsoft will prompt for extra security info when they detect your session originates at a Tor exit node. I wish they would refrain.
$ rpm -qi microcode_ctl | tail -3
The microcode update is volatile and needs to be uploaded on each system
boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts
back to the old microcode.
Do you think that ARM will be replacing all the Cortex A75s that are vulnerable to the full range of Meltdown and Spectre vulnerabilities? Are we sure that Apple's ARM implementations will have superior security architecture?
AMD isn't pushing a Spectre fix for older CPUs. Nor is Qualcomm for Snapdragon. Nor is Samsung for Exynos. We could go on for quite a long time with such a list.
If you need the fix for your i7 which Intel has abandoned (just like all the vendors above), run a modern Linux kernel where you see the file/sys/devices/system/cpu/vulnerabilities/spectre_v2. If this file contains the word "Full" then your kernel is protected, and you don't need microcode.
The microcode is only required on Skylake and newer for full remediation.
As long as "Full generic retpoline" is reported in the/sys/devices/system/cpu/vulnerabilities/spectre_v2 file, Spectre (and likely Meltdown) are not a concern.
The best was to accomplish that for Red Hat environments is to install Oracle's kernel RPM for the "Unbreakable Enterprise Kernel" (UEK).
I do not want a Platform Security Processor, Management Engine, or any other hardware on my CPU that I cannot control.
These products serve absolutely no purpose for the general consumer - they are only useful in enterprise (corporate) environments for centralized control.
I would like the option to destroy the PSP on any CPU that I own.
If you refuse to manufacture CPUs lacking this component, then give customers the ability to request an unlock code that forever physically disables a component that is both dangerous and (to them) irrelevant. The request could work similarly to cell phone programs that unlock bootloaders.
AMD, make no mistake - home users emphatically do not want the PSP.
Google ought to pour a LOT of love into a SPARC port. The best-situated would be OpenBSD.
Why, you ask? For the same reason that Microsoft's original target for the NT kernel was MIPS, and x86 was specifically secondary - oddball architectures will force you to clean up your code.
OpenBSD is also vicious in showing you your use-after-free mistakes since malloc() uses mmap() instead of sbrk() on their platform.
Amazon Kindle alone has enough inertia to fork AOSP. Since Google fled, many Chinese OEMs build Android devices that never had Play and never will.
Google knows very well of the large Android market segment that is beyond their control. Any attempt to kill the platform will see it immediately forked and forever wrested from their control.
That would not be such a bad thing, but I don't think Google is foolish enough to try it.
Slashdot Mirror
I agree with you that far too little effort has been extended in pushing systemd concepts as standards outside Linux, and the scope has been distressingly ambitious.
Still, systemd is a great improvement over the respawn behavior of inittab, allowing me to drop root privilege, set environment variables, chroot(), all combined with restart supervision. Yes, there are likely many other programs that do this, but respawn is SysV's job, and it should be more flexible. As it stands, when I have to do this, I write a bunch of shims either with shell scripts or custom C, and I've had do it on a wide variety of legacy operating systems.
The inetd.conf also benefits from most of these new features, although I uncovered a bug with socket activation and chroot() that I was able to work around that has since been fixed.
Improvements to respawn and inetd are the killer features for me, and give me things that simply cannot be done with standard tools on other POSIX-focused operating systems.
SysV init should be extended to cover these uses, and I would feel more nostalgic for it were new versions to emerge.
Browser fingerprinting is big business. Tor Browser constantly throws warning dialogs for sites using the canvas element in attempts to uniquely identify your machine.
Tor Browser also warns you not to maximize it, as your monitor size is also useful tracking information.
F-Droid has a browser implemented with the system Webview that disables Javascript by default, and gives you a one-button enable.
Privacy Browser does not offer extensions, but it does have a few more useful features, including blocklists and Tor integration.
I hope that you find it useful.
Tor Browser conspicuously features duckduckgo.com as the preferred search engine.
Microsoft provides search services for Duck Duck Go, so much that Bing's results are commonly identical. Firefox can and should promote Bing in all of it's guises.
The startpage.com search engine appears to be based in Europe, and seems to continue to outsource to Google although this branding was recently removed from the home page.
It is Firefox that should demote Google to a second-class citizen, immediately opening an incognito window on startpage.com for Google searches and potentially launching a Tor process for it (which they are in discussions to bundle). Firefox should loudly begin work to sandbox gmail, maps, drive, and all other Google properties.
A few press releases of this, without even beginning work, would likely get Mozilla everything it wants.
Give it a try.
I seriously doubt that access to the entire set of hidden bridge nodes has been blocked. These nodes are not advertised, and I am assuming that they do not appear in the public consensus documents.
The distribution points of the bridge node IP addresses were likely blocked. If and when Tor users find new bridge nodes by some means or other, they will be able to access the network again.
I also understand that WPA3 will get forward secrecy, and sessions will negotiate a temporary ("ephemeral") key for symmetric cryptography (assuming AES).
Should the traffic be recorded, it cannot be decrypted later if the password is broken.
I do agree that it's not quite comparable, but I don't know any minimal Linux distribution that implements the equivalent of the OpenBSD base.
Perhaps to be fair, it appears that Oracle's RHCK has been reissued 7 times since April 15th, which is not quite as bad.
I have had several rounds of users who want one of the Red Hat clones for some app, then realize after deployment that avalanches of patches are required for these platforms and balked - easily thousands over a six-month period for a typical system. That is aggravating.
It would be nice if the browser could signal the scheduler that it launched a new tab as an untrusted process, causing the kernel to sanitize caches before and after its future time slices (in addition to any sandboxing the browser parent process and the OS were already doing).
It might also make sense if only processes with the same UID could run on different SMT threads on the same core, rather than just turning them off completely.
The current release of OpenBSD, version 6.3, has issued a total of 10 patches against base since release on April 15th. Four of these are security-related, and six are reliability bug fixes.
Oracle / Red Hat Linux in that time has issued 50 security-related patches, and hundreds more that are classed as bug fixes or enhancements.
Linux is strong because it scales up and down very well, it exploits CPU features for speed to make applications run very fast, it is friendly to new features, and it has the most market share in the POSIX realm. Linux is weak because it has sacrificed security for speed in many cases, and we have Dirty Cow, Towelroot, and many similar problems in userspace - this makes Linux a bad choice for systems that will not receive patches (i.e. phones, IoT devices, embedded systems, etc.).
OpenBSD prioritizes security over speed and flexibility. It does not implement fine-grained SMP due to security concerns, and has a "big kernel lock" that Linux left behind in 2.2. It ignores many well-known standards (i.e. NFSv4). There are many things that you cannot do on OpenBSD, but what you can do is magnitudes safer than Linux.
Android politely stole OpenBSD's entire libc implementation (and then ignored it for several years), and IIRC the OpenBSD code is the largest contribution outside of the kernel itself.
OpenBSD is also the home of OpenSSH, which itself is quite secure.
I trust the opinions of the OpenBSD kernel architects, and I will look forward to their patch.
Fukushima has shown us that a loss of power for 36 hours at any of these facilities will cause them to boil off all their coolant, melt their containment vessels, and poison the surrounding environment for thousands of years. This includes both the reactor vessels and the waste/spent fuel rods in the local storage ponds.
The exact same GE model that failed in Fukushima runs 30 miles upstream from me on the Mississippi. Should it lose power as Fukushima did, the Mississippi river will be lost to our country. This reactor was scheduled for closure and was saved by my state legislature, and it should not be running.
The iFont app in Google Play offers a font named "Armani."
I was able to use iFont to create an APK file of this font, which I pulled onto a Red Hat desktop. After running unzip on the APK, I found an "Armani.ttf" True Type font file.
The font viewer reports this to be Bauhaus ITC regular.
This is my favorite font, and I copied it over the Android default /system/fonts/Roboto-Regular.ttf.
Supposedly, this typeface was obtained legally. I have had trouble with iFont in the past, so I don't install it anymore, but I have kept the exported typeface.
I am able to load Cygwin on my Windows 10 system at home in the /cygwin64 directory, bring it to work on a flash drive, unzip it on my work desktop, and I suddenly have X-Windows, an ssh suite, and a compiler.
It is unlikely that I will be getting WSL on my work machine without lots of approval gymnastics, so I will pass on it for now.
I am very pleased that major U.S. carriers were pressured to dump you. The unlockable bootloaders were likely a ploy anyway. ZTE has given us reason to spurn these products.
Seriously, if Apple can't manage to design PCs, give it to an organization that can.
The current Oracle UEKr4 is a v4.1.12 kernel, and can be loaded in a supported configuration with Ksplice on a Red Hat system.
The preview of the UEKr5 is a 4.14.26 kernel (the Long Term Support release). That is in beta.
You can find installation instructions here for both versions.
For those times that I want or need to use Microsoft mail services, I prefer to use Tor Browser to connect to http://outlook.com/ Be aware that Microsoft will prompt for extra security info when they detect your session originates at a Tor exit node. I wish they would refrain.
As I understand it, only Skylake and later CPUs are not completely addressed by retpolines.
Ubuntu released a kernel that reported this around 2/15.
Red Hat released one with partial support that seemed to require microcode around 3/8.
Oracle implemented the Full generic support starting 3/14.
OpenBSD just got this capability also.
$ rpm -qi microcode_ctl | tail -3
The microcode update is volatile and needs to be uploaded on each system boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts back to the old microcode.
Do you think that ARM will be replacing all the Cortex A75s that are vulnerable to the full range of Meltdown and Spectre vulnerabilities? Are we sure that Apple's ARM implementations will have superior security architecture?
AMD isn't pushing a Spectre fix for older CPUs. Nor is Qualcomm for Snapdragon. Nor is Samsung for Exynos. We could go on for quite a long time with such a list.
If you need the fix for your i7 which Intel has abandoned (just like all the vendors above), run a modern Linux kernel where you see the file /sys/devices/system/cpu/vulnerabilities/spectre_v2. If this file contains the word "Full" then your kernel is protected, and you don't need microcode.
The microcode is only required on Skylake and newer for full remediation.
As long as "Full generic retpoline" is reported in the /sys/devices/system/cpu/vulnerabilities/spectre_v2 file, Spectre (and likely Meltdown) are not a concern.
The best was to accomplish that for Red Hat environments is to install Oracle's kernel RPM for the "Unbreakable Enterprise Kernel" (UEK).
I do not want a Platform Security Processor, Management Engine, or any other hardware on my CPU that I cannot control.
These products serve absolutely no purpose for the general consumer - they are only useful in enterprise (corporate) environments for centralized control.
I would like the option to destroy the PSP on any CPU that I own.
If you refuse to manufacture CPUs lacking this component, then give customers the ability to request an unlock code that forever physically disables a component that is both dangerous and (to them) irrelevant. The request could work similarly to cell phone programs that unlock bootloaders.
AMD, make no mistake - home users emphatically do not want the PSP.
Google ought to pour a LOT of love into a SPARC port. The best-situated would be OpenBSD.
Why, you ask? For the same reason that Microsoft's original target for the NT kernel was MIPS, and x86 was specifically secondary - oddball architectures will force you to clean up your code.
OpenBSD is also vicious in showing you your use-after-free mistakes since malloc() uses mmap() instead of sbrk() on their platform.
Amazon Kindle alone has enough inertia to fork AOSP. Since Google fled, many Chinese OEMs build Android devices that never had Play and never will.
Google knows very well of the large Android market segment that is beyond their control. Any attempt to kill the platform will see it immediately forked and forever wrested from their control.
That would not be such a bad thing, but I don't think Google is foolish enough to try it.