When working properly, as far as I understand it, the checksums of all the packages are signed in the repo. Correct that rpm can carry a signature directly, though in practice you won't use dpkg directly just like using rpm directly is unusual.
Yes rpm direct can verify signatures and dpkg direct cannot, but apt can verify signature of the file that has all the cryptographic checksums.
This vulnerability is a way to trick apt into operating on a payload as a deb that shouldn't have been a deb. Sure, if debs had signatures it would have been an additional layer of protection to require both apt and deb protections to break, so too would https as a default pretty much made this not exploitable, but at least when things work as designed, you do have key based validation of the package integrity so long as you don't manually download and dpkg things.
Note that if you download and manually install an rpm file without a signature, redhat (at least by default) lets you do that without warning or error, yum is the only method that will tend to be strict on the signatures, so when both are working as designed they have very similar behaviors.
Well, the animated gif (what a terrible way to provide concrete examples) suggest a far more simplistic helper than people are imagining.
Basically their example of it doing it's thing is just finding all instances where a method is called on something and prefacing that with 'if null, return immediately without data'.
Of course I've spent a non trivial time working in a language that pretty much lives that way: Perl. In perl if you go off the reservation, it just keeps on going... somewhere.
Funny thing happens, you don't get 'null pointer exception' behaviors, but you do end up with much harder to fix behaviors resulting from that undefined behavior propagating until it finally explodes in weird behavior for the user. Your application manages to avoid crashing, but the user would have probably been better off if the application crashed. At first I did think it was a blessing because it did save me a lot of tedium since *most* of the time something undef and false was what I'd want a screwup to look like, but now I appreciate a language that breaks immediately when there's any ambiguity possible.
I will say my one-line summary was incorrect, it's a bit trickier, but the end result is executing the normal install process of an untrusted, unsigned.deb file. The protections are there, but defeated by the mistake.
Scripting language package management is however accurate, not much in the way of signing and further not particularly reviewed packages.
Yes, but the mechanism was through getting apt to install a deb that bypassed all the signing. The package contained malicious scripting that was executed in the configuration phase of the install.
The vulnerability was basically sneak a deb into the 'don't care' portion of a gpg file, trick apt into treating that gpg file as a deb to install, which then discards the 'don't care' part that is the gpg signature and does a normal install of the file that should have not made it through the signature validation. Normally that portion of the install didn't expect to have to worry about signature verification (it was supposed to be handled before then), so arbitrary deb gets to be installed with malicious payload put to disk and/or configuration payload that executes at apt execution time.
After 'fixing' the PEAR problem to no longer have a vulnerability, PEAR's security becomes as strong as APT while afflicted by this cited vulnerability.
APT's vulnerability was to bypass the signature checking, while PEAR doesn't even have it in the first place.
Note that apt for both debian and ubuntu are all signed packages by default as well.
Here the vulnerability is that the HTTP reply can just claim a hash and cause apt to assume the given hash is correct without calculating it itself. A huge mistake that defeats the package signiing but a mistake that may be patched.
You are right with pip, pear, gem, npm, and cpan, most of the language specific repositories are security nightmares (not just general lack of signing, but the 'anyone can publish' model means that even if signed, you generally don't have much of a chance to manage your trust relationships anyway).
Basically the major linux distros take package signing seriously but the scripting languages don't and can not.
A lot of this is because in Windows, every vendor pretty much had to build-their-own auto-updater, if at all.
If a software installs an auto-update agent that runs as a matter of course, they are assholes because they are running when they shouldn't be and many auto-updaters add up.
If a software checks auto-update on startup, it's annoying and disruptive because you are trying to use this app, not get nagged about updating. Additionally this means software is neglected when not run and frequently an update is 'do it later' because you are trying to use the app and don't want to wait/risk.
It's a shame MS never delivered an extensible auto-update framework that applications could register their update sources. MS store is the closest thing, but a good facility would not require Microsoft servers to be involved.
Some have raised the valid point that software changes crap and has inflicted update fatigue on people and that is an issue, but I wager most of the time it's because the 'system update' doesn't have a path for applications to naturally get updated at the same time.
Basically, in the case of casettes it looks like it's (mostly) not about the music and more about the context making them collectible.
3 out of the top 4 are basically equivalent to having action figures or similar. Fun collectible that happens to function. Also they more than make up the entirety of the boost in sales, and the sales represent less than 0.1% of the market, so it's fun to report on and I'm sure fun for the people making and consuming the tapes, but not actually significant at all in the general market.
As a music format, it only had any value until CD-Rs became available to the common man (by which time CD players also had big enough buffers to overcome the skip problem that plagued early portable CD players).
Vinyl music comes in potentially awesome packaging and isn't prone to so many problems that tapes were. Tapes only existed because of the ability for common person to record and possibility of car stereo playback and walkman, and we are now a few generations past that.
At the time I started with them, they had crazy amounts of third party content and very cheap prices. I think largely because the content owners weren't taking streaming seriously.
Now as their third party catalog evaporates and their prices increase and their home-grown content is mostly not along the lines of what I'm looking for, it's rapidly losing it's appeal to me...
Having to keep track of several accounts being billed and having to think 'which provider has the series I want to watch again?' is annoying.
Funny thing is back in the day I think Netflix could have been *the* streaming provider. They stuck to their guns about a flat subscription and refused to negotiate an 'a la carte deal' for some content and that set precedent for many companies to decide to compete.
What, some background process that's responsible for somehow updating the batter meter, resulting in it not going down even though the battery is going down?
No, that's not the case? Then the battery life is not 'superficially' extended, it is either extended or it isn't. If they claim better battery life as a reason, but they don't actually get battery life, that is not superficially extended, that is flat out incorrect.
I don't think they are crippling the Ryzen for Intel, they do the same thing to Intel processors a lot: impose a lower TDP envelope than you'll see on the spec sheet to try to deliver 'good enough' in a slimmer-than-needed form factor.
As long as you are doing home assist or similar, consider using snips instead of google or alexa for voice support.
I like the idea of having the home automation on a closed loop for the most part, and keeping the microphones from sending to the internet is just one more nice move.
To the extent I have interest, it is to close gaps not conveniently with a button.
It's very frivilous, like dimming lights from couch, or my roku remote is approximately two buttons shy of doing what I want with my entertainment system, and voice commands might bebetter than juggling another remote for just two buttons.
Of course I'm more interested in Snips and keeping the voice control within the house. I do not want to be going along with the fallacy that I need hot mics into Amazon or google's datacenter to do this simple stuff.
In this instance, the factory stereo also has the air conditioning controls, so the kit had to include a replacement for the air conditioning controls, since cars are routing all sorts of crazy stuff through it.
For my car model, a double din headunit is possible, but the kit for allowing a custom stereo is $460, and also a huge PITA, having to unsolder knobs and such, and lots of car function is disabled despite that
The provided unit works fine, and I don't see why I'd want to spend well over $500 dollars to accommodate a device without a headphone jack rather than doing what I'm already doing.
It seems a strange response to someone stating disappointment in vendor choice to omit a feature to declare how much inconvenience and cost the user *should* go through to go along with it, rather than admitting the vendor has left that person out of their strategy. As someone who makes a living off product, I'd rather have people tell me what my work is lacking rather than just seeing people buy alternative products with no good way of knowing why.
Of the internet media (books, video, music), music is the only one where purchased tracks are generally *not* drmed, so I have no particular inclination to buy CDs and rip.
Video on the other hand, I buy and rip media rather than buying DRM encumbered video files that can go poof at the whim or misfortune of the vendor.
Ah yes, pay several hundred dollars to go along with the whim of Apple or other similar device makers to not have a headphone jack versus... staying with a phone that actually works with his existing setup for no cost or buying a different phone that has a headphone jack?
Also a very probable pain is that the stereo is no where near a standard DIN form factor and/or has essential car related functionality integrated. Not a trend I like, but it is a reality that fewer and fewer car models have realistically replaceable stereos.
I suppose the question is why he should have to pay *more* money to allow Apple to pursue their agenda, versus just buying products/sticking with products that are still designed in a way he prefers? Of course all that said he really should move to a credit card device that isn't magstripe based, due to liability issues, but not because he should pay more to have less function.
I would never dare say someone else's preference for having a port is any of my business.
Personally, I bought an android phone with only usb-c and dongles for headphones. When that phone messed up out of warranty, I was so glad to have a headphone jack again and not deal with the hassle of a dongle, and paid much less for the phone with *more* ports which is a very weird dynamic in the industry.
No idea, just a thought off the top of my head. I just disable upnp as any things I want exposed I know enough to do it myself and it's such a rare phenomenon that the relative tedium is acceptable. Such a feature would be of great use to those lacking that degree of experience or putting gobs of enabled services on a network, but I don't need it so I haven't looked into it.
1) I think Upnp could be useful, but it would only be useful for generating a selection of services to add on the router through some interface (it's web page or a phone app with notifications), rather than auto-granting. Having true peer to peer technologies without blessed cloud intermediaries would be nice.
2) It sounds like they don't request that port be forwarded, but malware running on the same network segment is sending upnp packets on behalf of detected chromecasts to make them internet accessible, which circles around to point 1.
3) While I do not particularly think PewDiePie is a particularly worthwhile source of content, odds are against him being in any way responsible for this campaign and instead someone else who finds it amusing to spam about PewDiePie for whatever reason.
Well, it's largely on Google, in an ideal world it would be 100%. A device's security strategy should never include 'dear god please don't let internet hosts connect to me'
However, UPnP is a problem in practice because we have *so many* devices that employ this strategy, and UPnP offers a trivial way for opening them up, as well as opening command and control ports open to a client device that should never be running a service, without even a way to request approval for a UPnP forwarding request from an authorized software.
Practically speaking, routers should probably pair with some sort of phone app and do notifications to ask for approval when a upnp request comes in and not grant forwarding until approved.
It is a shame that in practice internet capable devices have terrible security that keeps us from having nice things like internet services on devices.
Slashdot Mirror
When working properly, as far as I understand it, the checksums of all the packages are signed in the repo. Correct that rpm can carry a signature directly, though in practice you won't use dpkg directly just like using rpm directly is unusual.
Yes rpm direct can verify signatures and dpkg direct cannot, but apt can verify signature of the file that has all the cryptographic checksums.
This vulnerability is a way to trick apt into operating on a payload as a deb that shouldn't have been a deb. Sure, if debs had signatures it would have been an additional layer of protection to require both apt and deb protections to break, so too would https as a default pretty much made this not exploitable, but at least when things work as designed, you do have key based validation of the package integrity so long as you don't manually download and dpkg things.
Note that if you download and manually install an rpm file without a signature, redhat (at least by default) lets you do that without warning or error, yum is the only method that will tend to be strict on the signatures, so when both are working as designed they have very similar behaviors.
Well, the animated gif (what a terrible way to provide concrete examples) suggest a far more simplistic helper than people are imagining.
Basically their example of it doing it's thing is just finding all instances where a method is called on something and prefacing that with 'if null, return immediately without data'.
Of course I've spent a non trivial time working in a language that pretty much lives that way: Perl. In perl if you go off the reservation, it just keeps on going... somewhere.
Funny thing happens, you don't get 'null pointer exception' behaviors, but you do end up with much harder to fix behaviors resulting from that undefined behavior propagating until it finally explodes in weird behavior for the user. Your application manages to avoid crashing, but the user would have probably been better off if the application crashed. At first I did think it was a blessing because it did save me a lot of tedium since *most* of the time something undef and false was what I'd want a screwup to look like, but now I appreciate a language that breaks immediately when there's any ambiguity possible.
I will say my one-line summary was incorrect, it's a bit trickier, but the end result is executing the normal install process of an untrusted, unsigned .deb file. The protections are there, but defeated by the mistake.
Scripting language package management is however accurate, not much in the way of signing and further not particularly reviewed packages.
Yes, but the mechanism was through getting apt to install a deb that bypassed all the signing. The package contained malicious scripting that was executed in the configuration phase of the install.
The vulnerability was basically sneak a deb into the 'don't care' portion of a gpg file, trick apt into treating that gpg file as a deb to install, which then discards the 'don't care' part that is the gpg signature and does a normal install of the file that should have not made it through the signature validation. Normally that portion of the install didn't expect to have to worry about signature verification (it was supposed to be handled before then), so arbitrary deb gets to be installed with malicious payload put to disk and/or configuration payload that executes at apt execution time.
After 'fixing' the PEAR problem to no longer have a vulnerability, PEAR's security becomes as strong as APT while afflicted by this cited vulnerability.
APT's vulnerability was to bypass the signature checking, while PEAR doesn't even have it in the first place.
Note in the context of this particular thread, the question would be whether pypi is secure, and the answer is not really.
In fact, one could describe the apt vulnerability as degrading apt security to pypi/pear/gem/npm security on their *best* day.
Note that apt for both debian and ubuntu are all signed packages by default as well.
Here the vulnerability is that the HTTP reply can just claim a hash and cause apt to assume the given hash is correct without calculating it itself. A huge mistake that defeats the package signiing but a mistake that may be patched.
You are right with pip, pear, gem, npm, and cpan, most of the language specific repositories are security nightmares (not just general lack of signing, but the 'anyone can publish' model means that even if signed, you generally don't have much of a chance to manage your trust relationships anyway).
Basically the major linux distros take package signing seriously but the scripting languages don't and can not.
A lot of this is because in Windows, every vendor pretty much had to build-their-own auto-updater, if at all.
If a software installs an auto-update agent that runs as a matter of course, they are assholes because they are running when they shouldn't be and many auto-updaters add up.
If a software checks auto-update on startup, it's annoying and disruptive because you are trying to use this app, not get nagged about updating. Additionally this means software is neglected when not run and frequently an update is 'do it later' because you are trying to use the app and don't want to wait/risk.
It's a shame MS never delivered an extensible auto-update framework that applications could register their update sources. MS store is the closest thing, but a good facility would not require Microsoft servers to be involved.
Some have raised the valid point that software changes crap and has inflicted update fatigue on people and that is an issue, but I wager most of the time it's because the 'system update' doesn't have a path for applications to naturally get updated at the same time.
Basically, in the case of casettes it looks like it's (mostly) not about the music and more about the context making them collectible.
3 out of the top 4 are basically equivalent to having action figures or similar. Fun collectible that happens to function. Also they more than make up the entirety of the boost in sales, and the sales represent less than 0.1% of the market, so it's fun to report on and I'm sure fun for the people making and consuming the tapes, but not actually significant at all in the general market.
As a music format, it only had any value until CD-Rs became available to the common man (by which time CD players also had big enough buffers to overcome the skip problem that plagued early portable CD players).
Vinyl music comes in potentially awesome packaging and isn't prone to so many problems that tapes were. Tapes only existed because of the ability for common person to record and possibility of car stereo playback and walkman, and we are now a few generations past that.
Pretty quick...
At the time I started with them, they had crazy amounts of third party content and very cheap prices. I think largely because the content owners weren't taking streaming seriously.
Now as their third party catalog evaporates and their prices increase and their home-grown content is mostly not along the lines of what I'm looking for, it's rapidly losing it's appeal to me...
Having to keep track of several accounts being billed and having to think 'which provider has the series I want to watch again?' is annoying.
Funny thing is back in the day I think Netflix could have been *the* streaming provider. They stuck to their guns about a flat subscription and refused to negotiate an 'a la carte deal' for some content and that set precedent for many companies to decide to compete.
What, some background process that's responsible for somehow updating the batter meter, resulting in it not going down even though the battery is going down?
No, that's not the case? Then the battery life is not 'superficially' extended, it is either extended or it isn't. If they claim better battery life as a reason, but they don't actually get battery life, that is not superficially extended, that is flat out incorrect.
I don't think they are crippling the Ryzen for Intel, they do the same thing to Intel processors a lot: impose a lower TDP envelope than you'll see on the spec sheet to try to deliver 'good enough' in a slimmer-than-needed form factor.
Add to that that 'dead weight' is often used as buffer in the event of layoffs.
Big businesses are highly dysfunctional, lots of wasteful spending and hiring to counteract braindead executive behaviors.
As long as you are doing home assist or similar, consider using snips instead of google or alexa for voice support.
I like the idea of having the home automation on a closed loop for the most part, and keeping the microphones from sending to the internet is just one more nice move.
To the extent I have interest, it is to close gaps not conveniently with a button.
It's very frivilous, like dimming lights from couch, or my roku remote is approximately two buttons shy of doing what I want with my entertainment system, and voice commands might bebetter than juggling another remote for just two buttons.
Of course I'm more interested in Snips and keeping the voice control within the house. I do not want to be going along with the fallacy that I need hot mics into Amazon or google's datacenter to do this simple stuff.
In this instance, the factory stereo also has the air conditioning controls, so the kit had to include a replacement for the air conditioning controls, since cars are routing all sorts of crazy stuff through it.
For my car model, a double din headunit is possible, but the kit for allowing a custom stereo is $460, and also a huge PITA, having to unsolder knobs and such, and lots of car function is disabled despite that
The provided unit works fine, and I don't see why I'd want to spend well over $500 dollars to accommodate a device without a headphone jack rather than doing what I'm already doing.
It seems a strange response to someone stating disappointment in vendor choice to omit a feature to declare how much inconvenience and cost the user *should* go through to go along with it, rather than admitting the vendor has left that person out of their strategy. As someone who makes a living off product, I'd rather have people tell me what my work is lacking rather than just seeing people buy alternative products with no good way of knowing why.
Of the internet media (books, video, music), music is the only one where purchased tracks are generally *not* drmed, so I have no particular inclination to buy CDs and rip.
Video on the other hand, I buy and rip media rather than buying DRM encumbered video files that can go poof at the whim or misfortune of the vendor.
Ah yes, pay several hundred dollars to go along with the whim of Apple or other similar device makers to not have a headphone jack versus... staying with a phone that actually works with his existing setup for no cost or buying a different phone that has a headphone jack?
Also a very probable pain is that the stereo is no where near a standard DIN form factor and/or has essential car related functionality integrated. Not a trend I like, but it is a reality that fewer and fewer car models have realistically replaceable stereos.
I suppose the question is why he should have to pay *more* money to allow Apple to pursue their agenda, versus just buying products/sticking with products that are still designed in a way he prefers? Of course all that said he really should move to a credit card device that isn't magstripe based, due to liability issues, but not because he should pay more to have less function.
I would never dare say someone else's preference for having a port is any of my business.
Personally, I bought an android phone with only usb-c and dongles for headphones. When that phone messed up out of warranty, I was so glad to have a headphone jack again and not deal with the hassle of a dongle, and paid much less for the phone with *more* ports which is a very weird dynamic in the industry.
No idea, just a thought off the top of my head. I just disable upnp as any things I want exposed I know enough to do it myself and it's such a rare phenomenon that the relative tedium is acceptable. Such a feature would be of great use to those lacking that degree of experience or putting gobs of enabled services on a network, but I don't need it so I haven't looked into it.
1) I think Upnp could be useful, but it would only be useful for generating a selection of services to add on the router through some interface (it's web page or a phone app with notifications), rather than auto-granting. Having true peer to peer technologies without blessed cloud intermediaries would be nice.
2) It sounds like they don't request that port be forwarded, but malware running on the same network segment is sending upnp packets on behalf of detected chromecasts to make them internet accessible, which circles around to point 1.
3) While I do not particularly think PewDiePie is a particularly worthwhile source of content, odds are against him being in any way responsible for this campaign and instead someone else who finds it amusing to spam about PewDiePie for whatever reason.
Well, it's largely on Google, in an ideal world it would be 100%. A device's security strategy should never include 'dear god please don't let internet hosts connect to me'
However, UPnP is a problem in practice because we have *so many* devices that employ this strategy, and UPnP offers a trivial way for opening them up, as well as opening command and control ports open to a client device that should never be running a service, without even a way to request approval for a UPnP forwarding request from an authorized software.
Practically speaking, routers should probably pair with some sort of phone app and do notifications to ask for approval when a upnp request comes in and not grant forwarding until approved.
It is a shame that in practice internet capable devices have terrible security that keeps us from having nice things like internet services on devices.
On the other hand, they did pay $400,000 for... something...
If they can't do *anything* with that $400,000 purchase, it would seem that they were screwed too.