Please create an account to participate in the Slashdot moderation system
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I couldn't really understand why they wanted to do any change until I read through the actual proposal text..
A reason for defaulting to installing non-free firmware *by default* is accessibility. A blind user running the installer in text-to-speech mode may need audio firmware loaded to be able to drive the installer at all. It's going to be very difficult for them to change this. Other people should be able to drive the system (boot menus, etc.) to *not* install the non-free firmware packages if desired.
We will *only* include the non-free-firmware component on our media and on installed systems by default. As a general policy, we still do not want to see other non-free software in use. Users may still enable the existing non-free component if they need it.
We also need to do the work to make this happen:
* in d-i, live-boot and elsewhere to make information about firmware available.
* add support for the non-free-firmware section in more places: ftpsync, debian-cd and more.
and I plan to start on some of those soon.
How about because putting fanaticism over functionality is of no benefit to users? This has always been their problem, happy to submit patches to strip out firmware, rarely submitting patches that actually do any reverse engineering or clean-room reimplementation to provide a practical alternative, then pretending like they've somehow done something to address the problem. I remember when some of these clowns first started posting patches to the lkml, in which they also stripped out GPLed bytecode for thing
Indeed. The primary effect of not taking firmware updates is that you miss out on all the security fixes and your new devices stop working when faced with old firmware.
The reason a lot of firmware is locked down harder than Fort Knox is that it would be a massive security hole to open it up for any piece of passing malware to mess with. The kind of security hold that you would never know is there and would not be able to remove if you did.
I predict there will be people posting that closed source code is ins
The reason a lot of firmware is locked down harder than Fort Knox is that it would be a massive security hole to open it up for any piece of passing malware to mess with. The kind of security hold that you would never know is there and would not be able to remove if you did.
The reason a lot of firmware is locked down harder than Fort Knox is that it would be a massive security hole to open it up for any piece of passing malware to mess with. The kind of security hold that you would never know is there and would not be able to remove if you did.
The same can be said of any code run on a system, firmware or not. The difference between firmware and everything else however, is the security theater manufacturers put on for the crowds when what they really need it for is control. Most people out there believe in the performance. The reality is that any special code that has ridiculous privileges and no ability to be audited, let alone replaced by the device owner, is the Holy Grail for hackers. Specifically because the owner is powerless to do anything
You might not realize you are installing nonfree binaries, or (someone less intelligent than you) might not realize that nonfree binaries are a security risk.
Please explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk? (I accept that if they were open source drivers in linux / BSD then ensuring they don't break between kernel changes and getting better performance is easier)
You don't know what they might have inserted or modified, even with published source code. For closed source, you have _no_ idea what else they might have done without a great deal of resources and tools like a decompiler. One of the best examples of such abuse is when the company that owned Sourceforge repackaged the Windows version of GIMP with pernicious adware added. It wasn't in the GIMP source code, they didn't publish their changes as required by the GPL, and many people seeking a GPL, free software
the company that owned Sourceforge
the company that owned Sourceforge
I can't seem to compose a comment explaining the timeline of the DevShare saga without encountering a lameness filter. I'll leave it to Wikipedia's coverage [wikipedia.org].
In this specific scenario, they are talking about hotplug firmware, meaning code that is executed on the target device, rather than host CPU. The manufacturer can inject the same level of security problems in device-hosted firmware as they can hotplug. There may be some legitimate trust issues, but you would need to filter out all hardware that *comes* with closed firmware. If you are that diligent, you might as well also know what would be accompanied by closed hotplug firmware and avoid that.
Closed source drivers are still not on the table, so at least this specific measure doesn't change what may/may not be executed in OS context. There's plenty of room for shenanigans running on components of course, but they could just as soon do it using firmware that comes in the device's ROM, so non-free firmware doesn't afford protection.
You don't know what they might have inserted or modified, even with published source code. For closed source, you have _no_ idea what else they might have done.
You don't know what they might have inserted or modified, even with published source code. For closed source, you have _no_ idea what else they might have done.
But you have just installed their hardware inside your computer. You have _no_ idea what else that might be doing. This is why the security argument always fails for me.
For the most part, I would think this won't apply. Most firmware is being used on discrete parts which don't have any external connectivity of any sort. On your NIC or BMC, maybe that's a concern, but on other parts it's simply not going to do anything except its single job. It won't be wired up to anything but the parts it needs to control.
Some of these parts do have proper CPUs on them, for example my HBA has a PowerPC processor on it. These are, to all intents and purposes, completely independent com
If being able to freely view the source code was a guarantee of being secure
If being able to freely view the source code was a guarantee of being secure
That was never the claim , asshole.
If you open the hardware up for any old crusty to change the firmware, then your security problems are real and present, compared to the undintified security flaws of closed source firmware.
explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
Explain why you think they aren't, when they clearly are.
You can't blindly trust signing. There are stories here all the time of official keys being used to sign malware. And there are also ways to bypass signing requirements in some cases.
Non-free firmware that runs in an microcontroller on a graphics, audio, or networking coprocessor is a security risk. This is true whether the non-free firmware is in the coprocessor's flash memory or in the coprocessor's RAM. The only difference here is that Debian plans to offer a disk image containing non-free firmware sent to the coprocessor's RAM during the install-time boot process rather than requiring people who need to use non-free firmware during installation to discard their hardware and replace
You have already installed the manufacturers hardware in your computer. If you don't trust them then your security is compromised. There is nothing they can't do without a binary firmware blob that they can't do with the hardware __you__ installed for them. (note this is slightly different to having binary only drivers which would have access to parts of the system that the manufacturers hardware doesn't).
explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk? Explain why you think they aren't, when they clearly are.
explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
Explain why you think they aren't, when they clearly are.
Seeing as you didn't explain why they are, I'll explain why they aren't. You have already installed the manufacturers hardware in your computer. If you don't trust them then your security is compromised. There is nothing they can't do without a binary firmware blob that they can't do with the hardware __you__ installed for them. (note this is slightly different to having binary only drivers which would have access to parts of the system that the manufacturers hardware doesn't).
Seeing as you didn't explain why they are, I'll explain why they aren't. You have already installed the manufacturers hardware in your computer. If you don't trust them then your security is compromised.
Seeing as you didn't explain why they are, I'll explain why they aren't. You have already installed the manufacturers hardware in your computer. If you don't trust them then your security is compromised.
You: explain Me: you can't trust that the firmware comes from the manufacturer You: the firmware comes from the manufacturer Me: ...
But you trust the hardware from the same manufacturer? Better yet, if the firmware was put on a flash chip on the device, would you trust it then? Howe about the firmware in the BMC or the BIOS?
But you trust the hardware from the same manufacturer?
But you trust the hardware from the same manufacturer?
Wow. I mean, wow. Just, wow. Seriously, wow.
Go back and read the whole thread again, and if you still think this response makes sense, just don't. I mean, don't at all. Not at all.
I'm telling you, these apes can talk, they can type, but they're just mimicking. They're not thinking about any of this, and they're not actually reading what anybody writes. They're only scanning your words to see if you're on their team. If you're not on their team, the select a response from the buffet of responses they've seen given to other people who were on the Wrong Team.
He said HARDWARE you fuckwit.
If you don't trust the firmware, you can't trust the unknown silicon which can be designed to do anything, and you can't know exactly what without completely reverse engineering it under a microscope.
Explain why you think they aren't, when they clearly are.
Explain why you think they aren't, when they clearly are.
Explain why if open source code is a guarantee of security why so many exploits exist in FOSS, some of them including the very recent and very serious CVE-2021-4034 in Polkit which had been allowed to exist for 12 years?
Explain why if open source code is a guarantee of security
Explain why if open source code is a guarantee of security
Dum, de dum dum dumb!
Explain why you think that is the claim.
https://letmegooglethat.com/?q... [letmegooglethat.com]
of course *all* software can have vulnerabilities, but the more software you install and the less control you have over it, the higher the risk. debian, quite sensibly, will not endorse third party binary blobs they can't even review. of course they would never endorse proprietary closed code to begin with, but the added security considerations are obvious.
Top link was to a driver, not firmware.
As you pointed out - there are issues with both open and closed source software. The "open source security is good" has been disproved so many times (google openssl security if you like!)
failures don't make it worse than the alternative. there is no total security, it's a process and opensource and disclosure is clearly an improvement over obscurity for that process any day. this is software security 101 and amply proven, even if some heartbleed slipped. but even in the worst case, at the very least it will be always publicly traceable, you will know what happened and why, and who it affects. business' shiny dirty little secrets don't even qualify in that regard.
Top link was to a driver, not firmware.
Top link was to a driver, not firmware.
As a firmware engineer I have to say, this is one of the stupidest things said in the ocean of stupid that is this thread.
The year is 2022. You still haven't figured out how a WinModem differs from a regular modem? Egads!
that would be one of the many distributions that carried that package, yes. and?
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
If the only firmware that mitigates a security issue is in a non-free binary and you don't install it, you don't get the fix -- duh.
Which raises an important point. Much of this hardware is already running non-free firmware anyway. Even if it's just a bootloader to enable installation of a binary blob later.
If you leave the bootloader running and you don't load your own firmware, maybe malware can load it instead. Or maybe it can just exploit the bootloader itself.
Have you ever heard, for example, of Specter?
There are many bugs that require nonfree binaries for patching at hardware level so... be my guest if you want to keep your hardware opened to those attacks...
Have you ever heard, for example, of Specter?
Have you ever heard, for example, of Specter?
No, but I've heard of SPECTRE, for which there are mitigations in the Linux kernel. There's no good reason not to deliver new CPU firmware though, free or non-free. The firmware ought to be broken up by device class (if not by device family!) and not dumped in one big package.
Have you ever heard, for example, of Specter? No, but I've heard of SPECTRE...
Have you ever heard, for example, of Specter?
Have you ever heard, for example, of Specter?
No, but I've heard of SPECTRE...
I've heard if SPECTRE...I have watched all of the Sean Connery and Roger Moore James Bond movies. After those 2 major stars the franchise went off a cliff.
In the old days the firmware was burnt into EPROMs on whatever expansion card you had. In theory this could be updated but no-one ever did.
Then are stuff got more complex someone had the idea of having the firmware downloaded onto the card by the driver when the computer was booted. This made it nice and easy for updates etc to be applied (by updating the driver).
Then a bunch of open source fanatics decided they wanted to cut off their nose to spit their face and said "give us all your trade secrets and o
And the frequent manufacturer response if they do care about Linux is to shrug and just have their firmware in their device still and fall back on 'users must run update utilities to get updates'.
The hotplug firmware model (and some adapters even supported that as the *update* mechanism, which was nice and transparent) is fantastic, but things like this make hardware manufacturers steer away from it.
Then are stuff got more complex someone had the idea of having the firmware downloaded onto the card by the driver when the computer was booted. This made it nice and easy for updates etc to be applied (by updating the driver).
Then are stuff got more complex someone had the idea of having the firmware downloaded onto the card by the driver when the computer was booted. This made it nice and easy for updates etc to be applied (by updating the driver).
Nope. They do that to make the hardware cheaper, by not requiring enough flash to hold the firmware. Nice imagination, though.
Then a bunch of open source fanatics decided they wanted to cut off their nose to spit their face and said "give us all your trade secrets and open source your firmware otherwise we'll say you suck"
Then a bunch of open source fanatics decided they wanted to cut off their nose to spit their face and said "give us all your trade secrets and open source your firmware otherwise we'll say you suck"
And they do suck. Their business model is unsustainable and anti-consumer.
And they do suck. Their business model is unsustainable and anti-consumer.
And they do suck. Their business model is unsustainable and anti-consumer.
A business model where they care about 99.9% of their customers over the other 0.1% is unsustainable?
In the old days the firmware was burnt into EPROMs on whatever expansion card you had. In theory this could be updated but no-one ever did.
In the old days the firmware was burnt into EPROMs on whatever expansion card you had. In theory this could be updated but no-one ever did.
Once upon a time the local electronics parts store did brisk business in EPROM chips, driven mostly by their free service to burn alternate modem firmware onto them. You could upgrade a number of modems from 28.8 (or nearby) to 56.6 using this technique, for about $12.
If you wanted them to swap out the chip for you they charged an extra $20. Still, a lot of people paid this, because $32 was a lot cheaper than a new modem!
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
It's not if you live in an ideal world where you have a totally open hardware platform. However most of us have to deal with the reality that Intel may ship a binary microcode security fix. Even for a project with solid free software credentials like Debian, it doesn't make a lot of sense to make it hard to apply it.
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD. It's not if you live in an ideal world where you have a totally open hardware platform. .
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
It's not if you live in an ideal world where you have a totally open hardware platform. .
If open hardware and software was such a guarantee of security then why have so many seriously major exploits not been found for years in some packages that are parts of every major distro such as CVE-2021-4034 for Polkit that managed to survive 12 years before being found?
If open hardware and software was such a guarantee of security then why have so many seriously major exploits not been found for years in some packages that are parts of every major distro such as CVE-2021-4034 for Polkit that managed to survive 12 years before being found?
If open hardware and software was such a guarantee of security then why have so many seriously major exploits not been found for years in some packages that are parts of every major distro such as CVE-2021-4034 for Polkit that managed to survive 12 years before being found?
I just meant that in an ideal world, you would have the option of a fully open stack with no proprietary firmware. Sure it's not a panacea for all security vulnerabilities but we wouldn't have to deal with crap like Intel only shipping IME in a secure configuration to 'special' customers.
You don't know what's in them, you can't recompile them, and you don't know the environment they were built in. You lose "provenance", the ability to trace the source and contents of software. It's precisely what concerned Richard M. Stallman when he published the Gnu Manifesto and created the Free Software Foundation, which since than has hosted many of the most important components of a Linux operating system besides the kernel itself.
Do you need us to walk through more specific examples?
I think you misread his statement, he was saying the opposite of what you are saying, that "why should non-free *improve* security?" to which the answer is in the summary: Some devices ship with baked in, vulnerable firmware and hotplug firmware brings security fixes, so you get to choose between old vulnerable non-free and new non-free. In those situations free isn't even an option, so shunning non-free hotplug firmware still means you run non-free firmware, just older firmware.
If you have a choice between
I was answering an earlier question, which said:
> Please explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
I'm sorry that Slashdot threading can sometimes be confusing.
You don't know what's in them, you can't recompile them, and you don't know the environment they were built in. You lose "provenance", the ability to trace the source and contents of software.
You don't know what's in them, you can't recompile them, and you don't know the environment they were built in. You lose "provenance", the ability to trace the source and contents of software.
You did not have any of that when firmware came in an EEPROM chip in the device. If it was not a problem then, why is this a problem now?
Did I say it wasn't a problem then, either?
Is this a serious comment?
If the hardware just works, then suddenly there is no reason for the existence of Ubuntu.
If the hardware just works, then suddenly there is no reason for the existence of Ubuntu.
If the hardware just works, then suddenly there is no reason for the existence of Ubuntu.
Yep, because the *only* difference between Debian and Ubuntu is hardware support. The ONLY difference. /sarcasm.
I suspect you either have no idea what Debian is or what Ubuntu is. The two are like apples and oranges of the Linux world (or poo and chocolate depending on how extreme you are on some issues).
There's no other important difference, besides that Ubuntu typically is closer to being up to date on package revisions than Debian, and that you can remove systemd from Debian if you're not running GNOME (and why would you be?) Ubuntu's big difference from Debian is snap, which is crap, and is best handled by apt purging it with extreme prejudice.
On average, Ubuntu LTS is about as behind on library functionality as Debian stable. So perhaps one might phrase the difference as "Ubuntu also has a 6-month update track in addition to a Debian-style stable track."
There are others. Ubuntu has demonstrated hat they care far less about user privacy, by collating user data, and reselling it to Amazon. They've made it much less obvious, since people noticed and became _very_ upset, especially about the default enabled harvesting for all users. It's a problem for Ubuntu, but Ubuntu relies on the income from Amazon, so it's not likely to stop.
Yep, because the *only* difference between Debian and Ubuntu is hardware support. The ONLY difference.
Yep, because the *only* difference between Debian and Ubuntu is hardware support. The ONLY difference.
Of course it's not the only difference. For example, Ubuntu has Snap.
Hardware support is the only benefit Ubuntu provides over Debian.
I suspect you either have no idea what Debian is or what Ubuntu is. The two are like apples and oranges of the Linux world (or poo and chocolate depending on how extreme you are on some issues). The person who has no idea would seem to be you if you think comparing Debian to Ubuntu is like comparing an apple to an orange.
I suspect you either have no idea what Debian is or what Ubuntu is. The two are like apples and oranges of the Linux world (or poo and chocolate depending on how extreme you are on some issues).
I suspect you either have no idea what Debian is or what Ubuntu is. The two are like apples and oranges of the Linux world (or poo and chocolate depending on how extreme you are on some issues).
The person who has no idea would seem to be you if you think comparing Debian to Ubuntu is like comparing an apple to an orange.
There's no prize for "least useful not-a-summary ever", EditorDavid.
That's when I use my hootoo AP as an ethernet to wifi gateway. I have a "Driverless" USB2 to Eth100 adapter (I forget the driver, but it's one that's included with everything) which I can use to get there if there's no onboard baseTX eth, or no firmware for same.
Irritating, yes. But not a show stopper...
I also use an old USB-LAN device. They nearly all use the same chipset, which has long been stable in the Linux kernel. But frankly, it's been quite a long time since I had to do a hardware installation, it's almost all virtual machines these days. And that eliminates a lot of the driver difficulties at installation time. It does limit access to the underlying physical hardware for optimal performance, but I'm not running crypto-miners, more databases and monitoring systems.
Most users just want an OS that works. They don't care if the firmware is free or not. Just make it work
Most users just want an OS that works. They don't care if the firmware is free or not. Just make it work
Which is why Ubuntu is so successful.
Debian GNU/Linux cares about software freedom, fanatically so.
And yet here they are, being pragmatic about it, which seems decidedly un-fanatic.
Is it possible to be fanatically pragmatic?
And yet here they are, being pragmatic about it, which seems decidedly un-fanatic.
And yet here they are, being pragmatic about it, which seems decidedly un-fanatic.
No, not really. In this case they looking at an accessibility edge case and are still debating whether to force users who need non-free binaries to jump through hoops or get other distributions so as to not dirty their pure distro.
That is not pragmatic, that is still very much fanatical. A pragmatic approach would be to simply include non-free binaries in the installer to allow necessary accessibility and give the user the option to not install non-free software during the installation process.
It's fine as long as there are Debian based distros like Ubuntu which offer that easy experience. I don't think many people installing Debian are complete noobs.
Most users just want an OS that works. They don't care if the firmware is free or not. Just make it work
Most users just want an OS that works. They don't care if the firmware is free or not. Just make it work
Debian is not for most users. I love it, it's close to perfect for me, ymmv.
Take it up with Red Hat, systemd was the brainchild of Leonart Pottering over there. Oh, wait, he just left Red Hat and wound up over at Microsoft.
I do wish we had a transcript of that discussion with Red Hat. Modern departures of technical leaders rarely include public announcements of why they left, and this is one such case. I do wonder if Microsoft had already made him the offer when he left Red Hat.
Ridiculous amount. I'm going to add all GPUs, Realtek Network and Audio chips.
It's practically unavoidable to use non-free drivers. Adding "non-free" repositories to APT is one of the first things, if not the first, I change when installing fresh Debian. Otherwise, I love Debian distro. I've been through quite a few a decade ago and stayed with Debian since then because it's very reliable/stable when you use a stable release.
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
The Ashes of Four 'Star Trek' Actors Will Be Carried Into Deep Space
Neal Stephenson Thinks Rockets are an Overhyped Technology
Message from Our Sponsor on ttyTV at 13:58 ...