It's a great read. One of the most critical determinations by the interdisciplinary team was that the most detailed information wasn't necessarily the most important or useful. You need multiple layers of messaging, when trying to convey something to people 10000 years from now who probably don't speak the same language. The most basic being: "There is a message here"
As if something like that can't also be reproduced. A built-in vulnerability is still a vulnerability. Also, letting the government (or corporations) have access to whatever they want, whenever they want. No thanks. Either strong encryption or NO encryption, not some half-assed broken thing.
How are you going to "reproduce" physical access to a device, and destruction of the chip, to apply that to more than one device?
> Breaking *anything* is a matter of cost and willingness.
AES-256? Serpent 256? Twofish 256?
The goal of crypto is to make something unbreakable. It seems it has generally succeeded, as best we know, as it appears impossible to do it. Brute forcing a 256 bit key is not a matter of cost. Getting into some hardware probably is, coercing software (if the ability to push the install remotely exists) absolutely is.
You're thinking only of encryption technologies, not physical access. Using only encryption technologies, if you break one you immediately break all that are using the same key. If to break a given device you need to disassemble it, rip apart the chip, and physically burn a hole through two layers at position 3254234138 x 4535332 and then attempt to scan for the nano-etching on the wafer that had part of the key inscribed, then having a remote key doesn't give you any access at all.
You can't have 'backdoors' in encryption without rendering the encryption worthless! Any method of enabling an end-run around the encryption itself is like having the best lock in the world on your front door then leaving a window wide open. At the point where government requires such things you may as well just ban ALL encryption outright and force everyone to have Red Data. Then at least you'll know who the criminals and terrorists are, because they will be using encryption.
Not if there's a physical lockout. If getting access to the key to decrypt requires physical access to (and destruction of, like in the case of a real, physical safe) the device, expert care to prevent damage to the contents, and about $200K of physical gear to get to, that's a bit different than a back door password or single key discoverable and exploitable by Romanian script kiddies.
If you go through the legal process and get a court order that is the system working as intended.
No, you're missing the point. Apple is not on trial here. Apple is not part of the investigation or under investigation. Apple made a phone, and now the government wants to FORCE Apple to help them access the information on it. Because apparently the FBI is incompetent and the NSA apparently won't help them. You know, two agencies with massive operational budgets who exist specifically to be experts at this kind of shit.
You seem to fail to understand that that's perfectly allowed by both case law, and common law tradition. In some counties in some states, it's a crime to fail to assist a Sheriff in the making of an arrest, so long as the instruction is reasonable.
The problem as I see it. Apple made their products so they cannot hack into their own devices. Making a back door, even for the government, means there is a spot for the non-government and other government which can get in.
When I do my job right, the products I make is made so without access I cannot get in unless I am setup as a user.
There should always be a manual override. The question is how difficult that manual override is to access.
In the case of a high-value safe, a couple of hours with trained experts and some precision blow torches can usually accomplish the job. You might need a contractor to help with repairing the room the safe is in though.
Cooperating fully would mean implementing a backdoor, not patching one that already exists. Kind of kills your line of reasoning.
The maker of a physical safe can implement a physical backdoor with a couple of hours, some high-precision blow torches, and a very large mess.
The problem with all-electronic/virtual back doors is that they can be easily hacked remotely, en masse, and surreptitiously. If a physical back door exists that requires a team of specialists, a couple hours with a scanning electron microscope, and a couple of hundred thousand dollars to disassemble a chip, followed by a court order to get the maker to release the combination key on top of it, I'm perfectly fine with that. That's, indeed, showing that the system can work.
Actually, in many countries, the pager infrastructure has been shut down. Where I live, the pager infrastructure was turned off around ten years ago. Nobody cared.
Are you sure you're not confusing that with analog cell service? That has indeed been shut down in most places, with very, very few exceptions globally (mostly in extremely rural areas where people haven't wanted to go to satellite service). Pager frequencies in a lot of places is still going very strong, for precisely the reasons indicated in the discussion.
That's even moreso the case depending on government needs in your jurisdiction. If there are Important Civilian Responsibilities, then the pager network likely still works, since they're probably not using milcom but may need to function when the cell towers are out.
You can have a single contact phone number that forwards to the persons on call cell phone based on the time of day, day of the week, or whenever you switch shifts.
And that's why you don't work in emergency services. Reliability Engineering is a thing, and every additional link in the chain adds additional failure points.
I like Google Voice, and Skype forwarding, and VOIP conference switches, and all that too... But a physical hand-off is much more reliable.
Way back in the primordial ooze of the early-mid 2000's, MySpace actually gained initial notoriety as a place for musicians and bands to congregate. That was one (small) reason why it always had good media functionality (for the time)... Auto-play MP3's, highly visual backgrounds, CSS, etc. (The other 85% of the reason was so that people could post sparkly glitter GIFs...)
When it got re-purchased after Facebook took over both the upper and "lower" classes of the internet social media space, MySpace decided to try to get back to its roots somewhat as a band-catering destination.
Who knows if it'll ever succeed (again) at that, but the battle for general social media presence is long-since over, so they had to do something with it.
Actually, for the US, you don't even have to hit anything.
A single nuclear explosion on the ground that hits an area of moderate importance would have tremendous geopolitical implications (to say the least), combined with probably a trillion dollar shock to the economy.
Three nuclear explosions somewhere 100 mi above the central US and West and East coasts would cause an EMP-triggered cascading failure of most consumer electrical devices for good, and most parts of the power infrastructure for months... if not years, considering the backlog of repair that would have to be coordinated and attempted without the use of power itself. In the meantime, countries not affected will use the effective absence of American involvement to promote their own agendas.
"Vaguely close, or in the right direction" is perfectly fine for nuclear effects.
Seriously... I can't think of any way shape or form that the "AI" behind a "self-driving car" is anywhere near ready for full legal responsibility for this.
Google (and/or other tech companies trying to get this to happen) must have placed tremendous pressure on them to make this happen.
SourceForge has a long way to go to regain mind share, but this is a good start. I think the type of folks that are posting to Slashdot are the type of folks who might be willing to help support it again. Let's see what comes next.
Perhaps this was written by someone too young to remember 3G video services.
Strangely enough, Verizon also doesn't charge me for receiving texts from their own customer support center, or "Fortune of the Day" service, or those chintzy CNNgo mobile.3gpp clips back in 2006, or NFL video, or any of the other benefits of cobranded services that carriers have offered. I fail to see how this is any different.
In fact, this is argueably LESS of an issue than T-Mobile's deal with the video services, simple as a result of it not being co-branded. If "Netflix by T-Mobile" was an actual thing, there'd be absolutely no room to complain at all.
In other words, it's a systemd problem because it doesn't hide the self-destruct switch enough?
Yes. There's a reason Big Red Buttons in datacenters usually have a protective cover on them.
And that the fact that the motherboard comes with a convenient software self-destruct switch isn't really a problem? Is it a problem with the vendor for not selling these mobos only to supervillains?
I've absolutely never said that the motherboard issue isn't a problem. In fact, I'm not sure I've seen *anyone* say that *anywhere* online in this entire debate... What IS a problem is that a random github project has control over the types of things that used to be decided at a much more distributed level. Complaints to distros are now sent upstream, where the self-described cabal decides what does and doesn't fit into their agenda for the Linux userspace.
This got closed as WONTFIX upstream no need to carry on with this here...
Fedora's policy of trying to stay close to upstream is about 15% to blame, and the rest is simply what distros will end up doing: taking the easy path. This is why centralization is a bad thing... It's going from the Bazaar back to the Cathedral in terms of lack of meaningful ability to influence. The "systemd cabal" is exactly that.
It's a systemd problem because of the defaults that it sets, not because of the buggy implementation.
Y'all are missing the point. There's no good reason for the init system to try to rewrite EFI variables, hence no reason for the init system to force mount efivarsfs into r/w mode. It's an unsafe default and there's absolutely NO reason for an init system to have a care (or a say) about the local policy one might adopt or prefer in dealing with that issue.
The systemd developers have decided to adopt the kitchen sink approach and consume other utilities and processes within the boot system. With the default action here present at https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L110 systemd is now involved in complaints about exposing an unsafe mount point by default, and flippantly closing it WONTFIX.
Or that, given the desire to boot into EFI firmware setup, a tool other than init wouldn't have the same problem that systemd does and wouldn't require the same writable filesystem to complete its task? Is your argument that such tools shouldn't exist? Because you didn't make any claims about how this is a problem because the two tools you would have need with sysvinit are now a single tool.
No, of course a tool like that would have a reason to exist, just like there are OS tools *now* that can flash firmware, reset BIOS variables, or whatnot. (Whether it's secure to have host-OS level access to those types of features is a different, albeit related question, of course...)
The problem is in what you've posted:
a tool other than init
/sbin/init doesn't need to do anything with BIOS or EFI variables;/sbin/init just needs to init. We've already booted.
If there are OS tools (like update_firmware from Dell's OMSA toolkit) requiring more access, then let them handle whatever they need to handle. And if they break, or do something stupid like leave something in read/write mode on the filesystem that can cause you to accidentally accidentally brick your server, then we get to blame them.
We don't want or need systemd to be involved in this, and we really don't want or need the systemd developers involved in this. No one died and made them benevolent dictators over the Linux userspace.
Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?
It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even/etc/fstab is considered more like a guideline than a rule for systemd to interpret.
If the authors of systemd didn't want to have to be smack in the [middle] of issues caused by disk mounts, perhaps they shouldn't have assumed disk mounting duties from other projects... nor advocated the removal of the easily adjustable init script which controlled them.
Just a thought.
And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:
We actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.
Thanks, systemd. This is now the time to point out that/sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.
While that's true, computer science is a good way to teach problem solving skills that are going to be useful no matter what you do.
I don't think they need to go too in depth. Just give the kids some guidance and turn them loose with Scratch or something similar where they can be creative. You're not going to turn everyone into a programmer, but you might get a few more kids interested who might otherwise not be.
Well, it's a good way to each *about* problem solving skills, but you don't need a computer to learn logic and reasoning any more than you need a calculator to learn math. It's fun, and good experience, even if they never take a CS class again, but it's not going to suddenly crank out more CS majors. Furthermore, in this day and age of budget constraints, it should seriously be considered whether class time should be taken up with something that could probably be easily done online from the comfort of home for those interested. (That's for CS, not for problem solving. Problem solving and reasoning still need class time.)
Slashdot Mirror
There's a lot of discussion about some of these problems in the various agencies tasked with documenting nuclear waste sites. Perhaps most famously, the WIPP:
Expert Judgment on Markers to Deter Inadvertent Human Intrusion into the Waste Isolation Pilot Plant (Excerpts here)
It's a great read. One of the most critical determinations by the interdisciplinary team was that the most detailed information wasn't necessarily the most important or useful. You need multiple layers of messaging, when trying to convey something to people 10000 years from now who probably don't speak the same language. The most basic being: "There is a message here"
Lawful Evil much?
Blame the English: https://en.wikipedia.org/wiki/Hue_and_cry
As if something like that can't also be reproduced. A built-in vulnerability is still a vulnerability. Also, letting the government (or corporations) have access to whatever they want, whenever they want. No thanks. Either strong encryption or NO encryption, not some half-assed broken thing.
How are you going to "reproduce" physical access to a device, and destruction of the chip, to apply that to more than one device?
> Breaking *anything* is a matter of cost and willingness.
AES-256? Serpent 256? Twofish 256?
The goal of crypto is to make something unbreakable. It seems it has generally succeeded, as best we know, as it appears impossible to do it. Brute forcing a 256 bit key is not a matter of cost. Getting into some hardware probably is, coercing software (if the ability to push the install remotely exists) absolutely is.
You're thinking only of encryption technologies, not physical access. Using only encryption technologies, if you break one you immediately break all that are using the same key. If to break a given device you need to disassemble it, rip apart the chip, and physically burn a hole through two layers at position 3254234138 x 4535332 and then attempt to scan for the nano-etching on the wafer that had part of the key inscribed, then having a remote key doesn't give you any access at all.
You can't have 'backdoors' in encryption without rendering the encryption worthless! Any method of enabling an end-run around the encryption itself is like having the best lock in the world on your front door then leaving a window wide open. At the point where government requires such things you may as well just ban ALL encryption outright and force everyone to have Red Data. Then at least you'll know who the criminals and terrorists are, because they will be using encryption.
Not if there's a physical lockout. If getting access to the key to decrypt requires physical access to (and destruction of, like in the case of a real, physical safe) the device, expert care to prevent damage to the contents, and about $200K of physical gear to get to, that's a bit different than a back door password or single key discoverable and exploitable by Romanian script kiddies.
If you go through the legal process and get a court order that is the system working as intended.
No, you're missing the point.
Apple is not on trial here. Apple is not part of the investigation or under investigation. Apple made a phone, and now the government wants to FORCE Apple to help them access the information on it. Because apparently the FBI is incompetent and the NSA apparently won't help them. You know, two agencies with massive operational budgets who exist specifically to be experts at this kind of shit.
You seem to fail to understand that that's perfectly allowed by both case law, and common law tradition. In some counties in some states, it's a crime to fail to assist a Sheriff in the making of an arrest, so long as the instruction is reasonable.
The problem as I see it. Apple made their products so they cannot hack into their own devices. Making a back door, even for the government, means there is a spot for the non-government and other government which can get in.
When I do my job right, the products I make is made so without access I cannot get in unless I am setup as a user.
There should always be a manual override. The question is how difficult that manual override is to access.
In the case of a high-value safe, a couple of hours with trained experts and some precision blow torches can usually accomplish the job. You might need a contractor to help with repairing the room the safe is in though.
Cooperating fully would mean implementing a backdoor, not patching one that already exists. Kind of kills your line of reasoning.
The maker of a physical safe can implement a physical backdoor with a couple of hours, some high-precision blow torches, and a very large mess.
The problem with all-electronic/virtual back doors is that they can be easily hacked remotely, en masse, and surreptitiously. If a physical back door exists that requires a team of specialists, a couple hours with a scanning electron microscope, and a couple of hundred thousand dollars to disassemble a chip, followed by a court order to get the maker to release the combination key on top of it, I'm perfectly fine with that. That's, indeed, showing that the system can work.
If you are statically linked AND you do something that results in DNS resolution (like resolving a hostname to IP), then yea, you'd need a recompile.
And this is why static linking and non-use-of-system-libraries is bad, unless done for very specific reasons and with a very specific update policy.
Actually, in many countries, the pager infrastructure has been shut down. Where I live, the pager infrastructure was turned off around ten years ago. Nobody cared.
Are you sure you're not confusing that with analog cell service? That has indeed been shut down in most places, with very, very few exceptions globally (mostly in extremely rural areas where people haven't wanted to go to satellite service). Pager frequencies in a lot of places is still going very strong, for precisely the reasons indicated in the discussion.
That's even moreso the case depending on government needs in your jurisdiction. If there are Important Civilian Responsibilities, then the pager network likely still works, since they're probably not using milcom but may need to function when the cell towers are out.
You can have a single contact phone number that forwards to the persons on call cell phone based on the time of day, day of the week, or whenever you switch shifts.
And that's why you don't work in emergency services. Reliability Engineering is a thing, and every additional link in the chain adds additional failure points.
I like Google Voice, and Skype forwarding, and VOIP conference switches, and all that too... But a physical hand-off is much more reliable.
https://xkcd.com/376/
Way back in the primordial ooze of the early-mid 2000's, MySpace actually gained initial notoriety as a place for musicians and bands to congregate. That was one (small) reason why it always had good media functionality (for the time)... Auto-play MP3's, highly visual backgrounds, CSS, etc. (The other 85% of the reason was so that people could post sparkly glitter GIFs...)
When it got re-purchased after Facebook took over both the upper and "lower" classes of the internet social media space, MySpace decided to try to get back to its roots somewhat as a band-catering destination.
Who knows if it'll ever succeed (again) at that, but the battle for general social media presence is long-since over, so they had to do something with it.
Actually, for the US, you don't even have to hit anything.
A single nuclear explosion on the ground that hits an area of moderate importance would have tremendous geopolitical implications (to say the least), combined with probably a trillion dollar shock to the economy.
Three nuclear explosions somewhere 100 mi above the central US and West and East coasts would cause an EMP-triggered cascading failure of most consumer electrical devices for good, and most parts of the power infrastructure for months... if not years, considering the backlog of repair that would have to be coordinated and attempted without the use of power itself. In the meantime, countries not affected will use the effective absence of American involvement to promote their own agendas.
"Vaguely close, or in the right direction" is perfectly fine for nuclear effects.
Seriously... I can't think of any way shape or form that the "AI" behind a "self-driving car" is anywhere near ready for full legal responsibility for this.
Google (and/or other tech companies trying to get this to happen) must have placed tremendous pressure on them to make this happen.
SourceForge has a long way to go to regain mind share, but this is a good start. I think the type of folks that are posting to Slashdot are the type of folks who might be willing to help support it again. Let's see what comes next.
In regard to social issues, I do like that Slashdot is getting back to its roots at least! :)
Perhaps this was written by someone too young to remember 3G video services.
Strangely enough, Verizon also doesn't charge me for receiving texts from their own customer support center, or "Fortune of the Day" service, or those chintzy CNNgo mobile .3gpp clips back in 2006, or NFL video, or any of the other benefits of cobranded services that carriers have offered. I fail to see how this is any different.
In fact, this is argueably LESS of an issue than T-Mobile's deal with the video services, simple as a result of it not being co-branded. If "Netflix by T-Mobile" was an actual thing, there'd be absolutely no room to complain at all.
In other words, it's a systemd problem because it doesn't hide the self-destruct switch enough?
Yes. There's a reason Big Red Buttons in datacenters usually have a protective cover on them.
And that the fact that the motherboard comes with a convenient software self-destruct switch isn't really a problem? Is it a problem with the vendor for not selling these mobos only to supervillains?
I've absolutely never said that the motherboard issue isn't a problem. In fact, I'm not sure I've seen *anyone* say that *anywhere* online in this entire debate... What IS a problem is that a random github project has control over the types of things that used to be decided at a much more distributed level. Complaints to distros are now sent upstream, where the self-described cabal decides what does and doesn't fit into their agenda for the Linux userspace.
No one asked for this.
A 7 digit UID is now a loyal old fart? This site has changed. (Do we still do my UID is lower than your's any more?)
You betcha we still do. Mind you I'm scared of waking up the really low UIDs
We lurk... waiting for the moment to strike.
You're honestly trying to tell me that RedHat can't change the systemd configuration (or code) to match their desires?
Won't, sadly, and for the record... https://bugzilla.redhat.com/show_bug.cgi?id=1304078:
Fedora's policy of trying to stay close to upstream is about 15% to blame, and the rest is simply what distros will end up doing: taking the easy path. This is why centralization is a bad thing... It's going from the Bazaar back to the Cathedral in terms of lack of meaningful ability to influence. The "systemd cabal" is exactly that.
It's a systemd problem because of the defaults that it sets, not because of the buggy implementation.
Y'all are missing the point. There's no good reason for the init system to try to rewrite EFI variables, hence no reason for the init system to force mount efivarsfs into r/w mode. It's an unsafe default and there's absolutely NO reason for an init system to have a care (or a say) about the local policy one might adopt or prefer in dealing with that issue.
The systemd developers have decided to adopt the kitchen sink approach and consume other utilities and processes within the boot system. With the default action here present at https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L110 systemd is now involved in complaints about exposing an unsafe mount point by default, and flippantly closing it WONTFIX.
Or that, given the desire to boot into EFI firmware setup, a tool other than init wouldn't have the same problem that systemd does and wouldn't require the same writable filesystem to complete its task? Is your argument that such tools shouldn't exist? Because you didn't make any claims about how this is a problem because the two tools you would have need with sysvinit are now a single tool.
No, of course a tool like that would have a reason to exist, just like there are OS tools *now* that can flash firmware, reset BIOS variables, or whatnot. (Whether it's secure to have host-OS level access to those types of features is a different, albeit related question, of course...)
The problem is in what you've posted:
a tool other than init
If there are OS tools (like update_firmware from Dell's OMSA toolkit) requiring more access, then let them handle whatever they need to handle. And if they break, or do something stupid like leave something in read/write mode on the filesystem that can cause you to accidentally accidentally brick your server, then we get to blame them.
We don't want or need systemd to be involved in this, and we really don't want or need the systemd developers involved in this. No one died and made them benevolent dictators over the Linux userspace.
Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?
It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even /etc/fstab is considered more like a guideline than a rule for systemd to interpret.
As I wrote in a post on that Github bug report that the Great And Powerful Lennart saw fit to remove:
And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:
Thanks, systemd. This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.
While that's true, computer science is a good way to teach problem solving skills that are going to be useful no matter what you do.
I don't think they need to go too in depth. Just give the kids some guidance and turn them loose with Scratch or something similar where they can be creative. You're not going to turn everyone into a programmer, but you might get a few more kids interested who might otherwise not be.
Well, it's a good way to each *about* problem solving skills, but you don't need a computer to learn logic and reasoning any more than you need a calculator to learn math. It's fun, and good experience, even if they never take a CS class again, but it's not going to suddenly crank out more CS majors. Furthermore, in this day and age of budget constraints, it should seriously be considered whether class time should be taken up with something that could probably be easily done online from the comfort of home for those interested. (That's for CS, not for problem solving. Problem solving and reasoning still need class time.)