There's a segment of the community that looks at their desktop computer and assumes that anything that they don't personally use is dead.
In fact, Linux and Java are the most used software in the world. Linux runs nearly everything that isn't your desktop computer, and a fairly substantial number of the applications you interact with over networks are Java.
Just because it isn't executing on your terminal doesn't mean you aren't using it.
I downloaded several packages at random and extracted them with "ar". There was no "_gpgorigin" file in any of them, indicating (as far as I can tell) that the *packages* aren't signed.
The package metadata is signed, but in that case the Release file contains an md5sum for the Packages file, which contains several checksums for the packages. That chain is only as secure as its weakest link. If you create a Packages file with modified hashes for your malicious package, then you appear to only need to find an MD5 hash collision to create a chain of Release -> Packages -> package file that will appear to be valid.
That's less secure than signing packages individually.
> That's basic package management security
Yes, I agree, which is what concerns me about Debian packages.
> whenever you add a PPA in Ubuntu, you have to explicitly trust the signing keys for it
The keys will be used to check the signature of the Release file, and packages if they're signed. Generally, however, they don't appear to be. The ones I sampled weren't, and I've read several times that they aren't. And, most importantly, the vulnerability described in this post wouldn't be possible if the pacakges were signed.
> though in practice you won't use dpkg directly just like using rpm directly is unusual.
That's true, but I'm not sure what point you're making. yum (or its replacement dpkg) validates the packages it downloads using a cryptographic signature, which makes it a more secure system than apt.
I'm not comparing rpm with apt or dpkg. I'm comparing yum with other package management systems.
> Yes rpm direct can verify signatures and dpkg direct cannot, but apt can verify signature of the file that has all the cryptographic checksums.
As far as I know, dpkg can verify signatures. The problem is that Debian and Ubuntu don't bother to sign their packages.
Checksums aren't secure. All an attacker has to accomplish is to generate a file with some garbage data in order to match the checksum. In other words, they only need to find a hash collision.
> This vulnerability is a way to trick apt into operating on a payload as a deb that shouldn't have been a deb.
No, it was a way to provide a package that didn't match the checksum, with the addition of a header that said that it did.
> so too would https as a default pretty much made this not exploitable
https would prevent against a man-in-the-middle, but it's still vulnerable to an attacker who gains control of the mirror you're using. A malicious mirror could have used this vulnerability or a hash-collision to push malicious packages.
> If you do not add foreign repositories, then there is no malware issue
I don't see anything in the research that indicates that this only affected "foreign" repositories. This appears to affect all repositories, because debian packages aren't signed, directly. They're checksummed, and the checksum list is signed. All well and good, but when the redirect was able to inject a header indicating a checksum of the attacker's choosing, that measure was defeated.
> Note that apt for both debian and ubuntu are all signed packages by default as well.
If you have a reference for that, I'd be really interested. Most of what I've read indicates that Debian and Ubuntu packages themselves are not signed, only checksummed (which is why this vulnerability exists to begin with). Only the package metadata is signed.
> Do Debian APT and PHP Pear Patches Highlight Vulnerability In Package Management Infrastructure?
Yes.
The security of the software delivery pipeline is something that Red Hat stresses, and is one of my top reasons for using their platforms. Universally signed packages is a significant security improvement over other systems.
You should definitely be concerned about the security of unsigned code, regardless of whether you get it through docker, pip, pear, gem, or other means where signatures are not present and verified by default.
I've seen numerous sites "debunk" the idea that your phone listens to your conversations and sends data to advertisers. The problem with every one of them is that they were analyzing the behavior of specific applications, typically the Facebook app. Because Facebook gets data from other application vendors, none of those tests were meaningful.
Does your phone listen to your conversations? Probably. Could be your laptop/desktop computer, too.
Sure, but there's no indication that will change. Red Hat will no longer ship KDE in RHEL at some point in the future, but Red Hat doesn't ship a *lot* of packages that are in Fedora with RHEL. That's what EPEL is for.
I don't see any reason to think that Fedora won't have great KDE packages in the future, or that KDE won't be available in EPEL.
Why should I have to care how many indents there are?... For example, I like 2 spaces for tabs for tighter indentation
Nowhere a hint of irony. *sigh*
You shouldn't have to care about indentation. And when there's a standard, you don't have to.
Complaints about whitespace are literally the most superficial complaint about a language possible. And honestly, when people start in with complaints about whitespace, I know immediately that they aren't going to have anything of value to contribute.
Arguing about how much your code should be indented is nothing more than bike-shedding. People express opinions about the things they understand. Arguing about indentation tends to illustrate the extent of your understanding.
Spot-checked a CentOS 6 system, and here's what I found:
No services appear to log stdout and stderr to logger. Anything output is printed on the console. If you're not physically at the console, that output is lost.
The "daemon" function does call cgexec if it is installed, but cgexec is not installed by default.
Numerous services don't use the "daemon" function, including mysqld, postfix, and sshd.
So, as I said: systemd does things *by default* that the older init system didn't. Not couldn't. It's possible to do some of those things, but making a large collection of shell scripts consistent is hard, and keeping them consistent over time is harder.
Well, one of the problems with init scripts is that they weren't consistent, so while it's possible to capture all output to the logs using "2>&1 | logger", I never actually saw an init script do that.
So, a) common init scripts didn't do what you're saying they "could", and b) even if some of them did, it wasn't something you could rely on as a standard. Logging output is standard under systemd.
The same applies to process groups. Under bash, you could probably "(set -m; exec $daemon) & echo $! >/var/run/pids/$service" or something, but have you ever seen that? Not to mention that you still wouldn't make use of cgroups, and your login processes wouldn't be grouping user sessions.
One legit bug, and one bug in a related project that isn't used by any distros (AFAIK). Neither of which support the wild assertions in the comment I replied to.
like when you're database is turned off by a failed webserver
I'm not talking about dependencies, I'm talking about process groups. Your database is almost certainly not started by your web server, or by the web server service. It's not part of the same process group.
I'm starting to get the impression that you don't understand how these things work.
systemd doesn't interact with sudo authentication *at all*. I don't know what you're on about.
Distros that adopted systemd updated their init scripts to unit files because they *could*, and because there were advantages to doing so. It wasn't because they *had to*. Not every init script in Fedora has been updated. The old "network" service still has a standard SysV-type init script, and that service still works, for example.
systemd keeps services (including user login sessions, which it treats the same way) as a group of processes, which the previous systems did not. When I stopped a service under SysV init, it would terminate the "main" process, but if that process had started children, they might not receive that signal. Thus, SysV init might leave some resources used, and attempting to start the service later might fail. systemd can reliably terminate a service and all its descendant processes.
Furthermore, systemd can report the status of all of those processes in its "status" command, which SysV did not.
systemctl can capture all of the output to stdout and stderr and collect those in logs that can be associated specifically with the service they came from, which SysV did not do. Troubleshooting services in SysV was sometimes more difficult because errors *were* printed by the service, but they were lost.
systemd has so many advantages that when I try to describe one advantage, I describe three.
The previous standard interactions with init, including the use of shell scripts in/etc/init.d, and the chkconfig and service commands still work. You don't actually need to learn anything new unless you want to take advantage of the new features that systemd offers.
So you might be able to see why your argument rings hollow.
Why would GNU be special enough to be named in one breath with Linux, but not those other authors
Because GNU/Linux is a mostly-compliant implementation of the POSIX spec. The other software that you mention isn't covered by the specification.
The name Linux covers a variety of largely dissimilar operating systems, including Android and embedded systems. The term GNU/Linux lets us discuss one of those, specifically.
Slashdot Mirror
There's a segment of the community that looks at their desktop computer and assumes that anything that they don't personally use is dead.
In fact, Linux and Java are the most used software in the world. Linux runs nearly everything that isn't your desktop computer, and a fairly substantial number of the applications you interact with over networks are Java.
Just because it isn't executing on your terminal doesn't mean you aren't using it.
> Of course Debian and Ubuntu sign their packages
https://blog.packagecloud.io/e...
I downloaded several packages at random and extracted them with "ar". There was no "_gpgorigin" file in any of them, indicating (as far as I can tell) that the *packages* aren't signed.
The package metadata is signed, but in that case the Release file contains an md5sum for the Packages file, which contains several checksums for the packages. That chain is only as secure as its weakest link. If you create a Packages file with modified hashes for your malicious package, then you appear to only need to find an MD5 hash collision to create a chain of Release -> Packages -> package file that will appear to be valid.
That's less secure than signing packages individually.
> That's basic package management security
Yes, I agree, which is what concerns me about Debian packages.
> whenever you add a PPA in Ubuntu, you have to explicitly trust the signing keys for it
The keys will be used to check the signature of the Release file, and packages if they're signed. Generally, however, they don't appear to be. The ones I sampled weren't, and I've read several times that they aren't. And, most importantly, the vulnerability described in this post wouldn't be possible if the pacakges were signed.
> though in practice you won't use dpkg directly just like using rpm directly is unusual.
That's true, but I'm not sure what point you're making. yum (or its replacement dpkg) validates the packages it downloads using a cryptographic signature, which makes it a more secure system than apt.
I'm not comparing rpm with apt or dpkg. I'm comparing yum with other package management systems.
> Yes rpm direct can verify signatures and dpkg direct cannot, but apt can verify signature of the file that has all the cryptographic checksums.
As far as I know, dpkg can verify signatures. The problem is that Debian and Ubuntu don't bother to sign their packages.
Checksums aren't secure. All an attacker has to accomplish is to generate a file with some garbage data in order to match the checksum. In other words, they only need to find a hash collision.
> This vulnerability is a way to trick apt into operating on a payload as a deb that shouldn't have been a deb.
No, it was a way to provide a package that didn't match the checksum, with the addition of a header that said that it did.
> so too would https as a default pretty much made this not exploitable
https would prevent against a man-in-the-middle, but it's still vulnerable to an attacker who gains control of the mirror you're using. A malicious mirror could have used this vulnerability or a hash-collision to push malicious packages.
yum is secure against those attacks.
> If you do not add foreign repositories, then there is no malware issue
I don't see anything in the research that indicates that this only affected "foreign" repositories. This appears to affect all repositories, because debian packages aren't signed, directly. They're checksummed, and the checksum list is signed. All well and good, but when the redirect was able to inject a header indicating a checksum of the attacker's choosing, that measure was defeated.
> Note that apt for both debian and ubuntu are all signed packages by default as well.
If you have a reference for that, I'd be really interested. Most of what I've read indicates that Debian and Ubuntu packages themselves are not signed, only checksummed (which is why this vulnerability exists to begin with). Only the package metadata is signed.
https://wiki.debian.org/Secure...
> Do Debian APT and PHP Pear Patches Highlight Vulnerability In Package Management Infrastructure?
Yes.
The security of the software delivery pipeline is something that Red Hat stresses, and is one of my top reasons for using their platforms. Universally signed packages is a significant security improvement over other systems.
You should definitely be concerned about the security of unsigned code, regardless of whether you get it through docker, pip, pear, gem, or other means where signatures are not present and verified by default.
I've seen numerous sites "debunk" the idea that your phone listens to your conversations and sends data to advertisers. The problem with every one of them is that they were analyzing the behavior of specific applications, typically the Facebook app. Because Facebook gets data from other application vendors, none of those tests were meaningful.
Does your phone listen to your conversations? Probably. Could be your laptop/desktop computer, too.
By removing the headphone jack on their lower-end models, they may intend to make the iPhone look cheap.
Sure, but there's no indication that will change. Red Hat will no longer ship KDE in RHEL at some point in the future, but Red Hat doesn't ship a *lot* of packages that are in Fedora with RHEL. That's what EPEL is for.
I don't see any reason to think that Fedora won't have great KDE packages in the future, or that KDE won't be available in EPEL.
Don't astronomers usually refer to them as satellites? I always though "moon" was the name of the Earth's satellite, specifically.
Why should I have to care how many indents there are? ... For example, I like 2 spaces for tabs for tighter indentation
Nowhere a hint of irony. *sigh*
You shouldn't have to care about indentation. And when there's a standard, you don't have to.
Complaints about whitespace are literally the most superficial complaint about a language possible. And honestly, when people start in with complaints about whitespace, I know immediately that they aren't going to have anything of value to contribute.
Arguing about how much your code should be indented is nothing more than bike-shedding. People express opinions about the things they understand. Arguing about indentation tends to illustrate the extent of your understanding.
Spot-checked a CentOS 6 system, and here's what I found:
No services appear to log stdout and stderr to logger. Anything output is printed on the console. If you're not physically at the console, that output is lost.
The "daemon" function does call cgexec if it is installed, but cgexec is not installed by default.
Numerous services don't use the "daemon" function, including mysqld, postfix, and sshd.
So, as I said: systemd does things *by default* that the older init system didn't. Not couldn't. It's possible to do some of those things, but making a large collection of shell scripts consistent is hard, and keeping them consistent over time is harder.
Well, one of the problems with init scripts is that they weren't consistent, so while it's possible to capture all output to the logs using "2>&1 | logger", I never actually saw an init script do that.
So, a) common init scripts didn't do what you're saying they "could", and b) even if some of them did, it wasn't something you could rely on as a standard. Logging output is standard under systemd.
The same applies to process groups. Under bash, you could probably "(set -m; exec $daemon) & echo $! > /var/run/pids/$service" or something, but have you ever seen that? Not to mention that you still wouldn't make use of cgroups, and your login processes wouldn't be grouping user sessions.
I also run hundreds of servers, running a *wide* variety of services. systemd isn't one of the applications I've found to be problematic.
One of us is confused. systemd logs stdout and stderr by default. Older init systems did not.
One legit bug, and one bug in a related project that isn't used by any distros (AFAIK). Neither of which support the wild assertions in the comment I replied to.
like when you're database is turned off by a failed webserver
I'm not talking about dependencies, I'm talking about process groups. Your database is almost certainly not started by your web server, or by the web server service. It's not part of the same process group.
I'm starting to get the impression that you don't understand how these things work.
systemd doesn't interact with sudo authentication *at all*. I don't know what you're on about.
Distros that adopted systemd updated their init scripts to unit files because they *could*, and because there were advantages to doing so. It wasn't because they *had to*. Not every init script in Fedora has been updated. The old "network" service still has a standard SysV-type init script, and that service still works, for example.
Can you provide any examples?
More ad hominem attacks on developers. I don't think you're going to sway any opinions today.
One example:
systemd keeps services (including user login sessions, which it treats the same way) as a group of processes, which the previous systems did not. When I stopped a service under SysV init, it would terminate the "main" process, but if that process had started children, they might not receive that signal. Thus, SysV init might leave some resources used, and attempting to start the service later might fail. systemd can reliably terminate a service and all its descendant processes.
Furthermore, systemd can report the status of all of those processes in its "status" command, which SysV did not.
systemctl can capture all of the output to stdout and stderr and collect those in logs that can be associated specifically with the service they came from, which SysV did not do. Troubleshooting services in SysV was sometimes more difficult because errors *were* printed by the service, but they were lost.
systemd has so many advantages that when I try to describe one advantage, I describe three.
I hear a lot of ad hominem attacks, and characterizations. I don't see a single example of a "bad" change.
I usually recognize scientists and engineers by their use of evidence.
The previous standard interactions with init, including the use of shell scripts in /etc/init.d, and the chkconfig and service commands still work. You don't actually need to learn anything new unless you want to take advantage of the new features that systemd offers.
So you might be able to see why your argument rings hollow.
That's a weird way to say "There aren't really that many developers or other technically skilled users who don't want systemd."
There's really very little "Linux" there.
None, as far as I can tell. When you run a GNU system using WSL, it's basically GNU/Windows.
Why would GNU be special enough to be named in one breath with Linux, but not those other authors
Because GNU/Linux is a mostly-compliant implementation of the POSIX spec. The other software that you mention isn't covered by the specification.
The name Linux covers a variety of largely dissimilar operating systems, including Android and embedded systems. The term GNU/Linux lets us discuss one of those, specifically.