Samsung To Push Monthly Over-the-Air Security Updates For Android 126
wiredmikey writes: Smartphone maker Samsung said on Wednesday that it soon will implement a new Android security update process that fast tracks mobile security patches over the air when security vulnerabilities are uncovered. The South Korea-based maker of popular Android smartphones said that it recently fast tracked security updates to its Galaxy devices in response to the recent Android "Stagefright" vulnerabilities uncovered late last month by security firm Zimperium. News of the initiative is great for Android users. For years, wireless carriers and phone manufacturers have been accused of putting profits over protection and dragging their feet on regular operating system updates, making Android users vulnerable to malware and other attacks. Nexus is also joining the monthly OTA update club.
I'll believe it when I get the notification. (Score:5, Insightful)
Promises, promises, promises...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
...better hope it demands to be on wifi before transferring, else a few folks are going to get a bit of sticker-shock on the next phone bill...
Re: (Score:2)
Re: (Score:2)
Promises, promises, promises...
Not even specific promises.
I would bet it is only for the first year after a model is released and even then, only if the carrier cooperates.
Re: (Score:3)
Basically, prove it!
Re: (Score:2)
Good point.
Because I mean, they said Galaxy line, which is a LOT of phones. In 2014 alone, Samsung released around 2-3 new phones a week. (They released about 1 new tablet a week, too - 54 different models!)
We're talking well over 100 new Android phones in 2014 alone. Granted, a lot are just variants for carriers, but that's still a LOT of phones and models and builds.
Yes, Samsung has a HUGE software development force - larger than Google, Apple and Microsoft combined (well over 100K software developers), b
Re:Mfgrs don't sell them for disposable prices (Score:2)
The US wireless carrier may be selling the phones for disposable prices, but they're paying the manufacturer the real price (with highly negotiated discount rates and volume plans, I'm sure, but the manufacturer isn't selling them below cost.)
I've got a Galaxy S4 Mini, because it was smaller than the newer phones they had on the market at the time, and I wanted a phone that would fit in my pocket. Probably should have gotten an Apple iPhone instead.
Re:I'll believe it when I get the notification. (Score:5, Funny)
Microsoft Windows 10 comes with spyware, ads and automatic updates built in, none of which can be disabled.
Which means the Year of the Linux Desktop is right around the corner!
But what about profits? (Score:4, Insightful)
Re:But what about profits? (Score:5, Informative)
I'm curious how they'll "encourage" users to upgrade to the latest shiny if the slightly tarnished shiny is still up-to-date...
Android's hardware requirements grow more than fast enough to encourage users to upgrade every couple of years.
Re: (Score:1)
I'm curious how they'll "encourage" users to upgrade to the latest shiny if the slightly tarnished shiny is still up-to-date...
Android's hardware requirements grow more than fast enough to encourage users to upgrade every couple of years.
Yep. My Galaxy 3 can't be upgraded to Samsung's release of Kit-Kat, because it "only" has 1GB of RAM. Apparently, for Kit-Kat and Lollipop, the Galaxy series needs 2GB. This illustrates the amount of bloat in the Samsung releases, as Kit-Kat officially needs only 512MB [wikipedia.org].
Re: (Score:2)
Yeah I was about to mention that. Kitkat lowered the hardware requirements back to what Gingerbread needed.
Honestly words can't express how much I hate Samsung's variant of Android. Every time I hear somebody say "android is slow and buggy compared to X" (be that ios/wp) the first thought that comes to my head is: "Oh, you're using a Samsung."
Re: (Score:2)
Kitkat lowered the hardware requirements back to what Gingerbread needed.
And Lollipop raised them again. "System" processes on my Nexus 7 (2012) are using more RAM under Lollipop than they were under KitKat.
Re: (Score:2)
And Lollipop raised them again.
Not by much.
Re: (Score:2)
Except that was during an era when most users only had 4MB of RAM, maybe 8MB if they were lucky. Oh, and RAM was actually expensive back then. Like more expensive than a whole smartphone is today.
Re: (Score:1)
They'll issue security updates to the current OS, not update Android as a whole. That way you never get anything new without paying but they won't be accused of not fixing security issues.
Re:But what about profits? (Score:4, Interesting)
Google's app upgrades are a minefield at best and a disaster at worst. Chrome seems to get slower every update (typing a website now hangs for a couple seconds after the first letter while it populates the history, and sometimes before you start typing at all, and loses letters typed during the pauses), plus the interface changes at random (pulling down at the top of a page reloads it now, which works great with websites that want you to swipe to control them). Chat->Hangouts drops a lot of information about contact status. Maps, similar issues to their web version.
Re: (Score:2)
Let me also mention Gmail: some half a year ago I upgraded Gmail on my Samsung Galaxy S3, and was so thoroughly disgusted by the bugs and the useless UI changes that I promptly proceeded to downgrade it. At least Android allows me to keep the version of the app I prefer.
Yes, I also use a relatively old version of Maps.
Re: (Score:2)
The good thing about Android is that you can replace most components. I've moved to Dolphin Browser, which works well, and has a good choice of extensions. Hangouts gets replaced by a secure SMS application. Even the launcher gets tossed and replaced by Nova Launcher.
The only real app that I cannot find a replacement for is the default mail one, as it works well with both Exchange (mail, calendaring, contacts, tasks), and IMAP.
Re: (Score:2)
That is a double edged sword. Security patches only is one thing. Security patches plus bloatware that can't be disabled... I'll pass.
Of course, the ideal would be if CM would get OTA updates, since it is is one of the best ROMs to be using on an Android device anyway.
Re:But what about profits? (Score:4, Insightful)
It is as simple as this: "We push security updates more often than our competitors" - it isn't just about retaining market share, it is about acquiring it from competitors. This is a highly requested feature from users that handset makers and carriers have been fucking up for years. So if a company delivers on this, it could very well easily be the tipping point between otherwise seemingly similar devices on the market - especially in the enterprise/government sector.
Re: (Score:2)
I'm concerned about this being a double edged sword. A "security update" can be something to get rid of root or harden the bootloader against the user just as much as something to block a remote attack. Heck, a "security update" could also bring along bloatware with it.
Re: (Score:1)
Re: (Score:2)
I'm curious how they'll "encourage" users to upgrade to the latest shiny if the slightly tarnished shiny is still up-to-date...
Same way Apple does. Add new features to the hardware and software which also results in higher requirements for the system. Your older systems are still up to date but they run slower and lack newer features but at least they don't have critical bugs.
Re: (Score:2)
They understand their market. Most people don't upgrade their phones whenever a new model comes out, they get them on contract and upgrade on a two year cycle when the contract ends. Consumers are looking at phones that they think will last them two years, or just buying whatever seems the most shiny at the time their contract happens to end.
Re: (Score:2)
A possible workaround ...
When I first saw this bug, I changed my Galaxy S3 [running 4.4.2] to disallow MMS from unknown senders. Start the [default] Messaging app, click the left soft key, select "Settings", scroll to bottom and click the check box for "Block unknown senders". I don't know if this actually will provide a true workaround, but it's the only thing I could find.
Reportedly, Google Hangouts has a similar option. In short, whatever app you're using for messaging might/should have this option.
Samsung needs to offer custom roms for there phone (Score:1)
Samsung needs to offer custom roms for there phones there don't void any warranty when installed over the carrier roms of there phones. As well the rooting tools if needed to install a custom rom.
Re: (Score:2)
Re: (Score:2)
Among the four major U.S. networks, are there still any that don't have a carrier that itemizes the price of the phone and service?
MVNOs have been itemizing hardware and service for a long time. Among non-virtual U.S. carriers, T-Mobile led the way with its "Even More Plus" plan that did not include a handset, which eventually evolved into its current "un-carrier" pricing structure. Ting, an MVNO, started on the Sprint network and has expanded to be a T-Mobile MVNO as well. But what MVNO is any good for "un
updates, updates, ... (Score:4, Interesting)
Does anyone remember the time when software just WORKED? When you didn't have an update of something every single day? What is it with phone users? I know everyone seems to want the latest and greatest. But DOZENS of app updates a week is just boring. And when the phone is updating you can barely use it.
I thought the future was going to be full of ads. It seems the future, actually, is just full of updates...
Re:updates, updates, ... (Score:4, Interesting)
If an app is built for just that phone then you have a point, but they aren't. They are built for many phones, different versions of Android and as such there is a constant update process to fix issues with the app working on one thing or the next. What phone are you using that makes it so you can barely use it when it is getting an update? Perhaps you have too many apps?
Undefined behavior (Score:2)
APIs are SUPPOSED to shield developers from constantly changing parent software, be it a browser or an OS.
Supposed to, yes, but a lot of app developers unwittingly end up depending on behaviors that the API specification called undefined, unspecified, or implementation-defined. Such dependency is a defect, but that doesn't stop applications from being published with hidden defects.
It is an insult to good developers who actually take more than 5 seconds to sit down and think, "HMMM, you know, changing this would break literally everything, better not do that!"
How about "the way we designed it it three years ago is vulnerable to a certain class of attacks that was discovered a couple months ago"? Windows Vista, for instance, had to break compatibility with interactive services because of th
Nexus 7 is unusable while installing updates (Score:2)
What phone are you using that makes it so you can barely use it when it is getting an update? Perhaps you have too many apps?
My Nexus 7 (2012) tablet running Lollipop is unusably slow while an app is being installed or updated.
Re:updates, updates, ... (Score:5, Interesting)
Has software ever "just worked"?
I can name bugs in 30+ year old software that made it into a production release and could never be patched because of the capabilities at the time.
And that was when the "app" was the only thing running on a single processor with complete "kernel" access to the entire machine, so not at all complicated by filesystems, process interactions, security mechanisms, etc. The days when software COULD take advantage of the timing of a particular processor, and even things like undocumented opcodes.
Software is an inherently "unfinishable" product. Just as everything works, something will break somewhere - you get your app going in DOS and then all your clients move to Windows, you get it working on Windows, and then all the Windows versions move to NT-based kernels and the like. It's a never-ending game.
And, with security particularly, there is no point at which you can call the software finished. There isn't a piece of software in existence that is "unbroken" on a general purpose modern machine - even those released dozens of years ago. Nobody was considering timing-based memory cache attacks back then.
Software that stays static is THE WORST culprit of exactly this kind of shit - unfixed bugs that propagate and hang around for years undiscovered until they become much more serious and affect devices that can no longer be commercially-viable to update.
Software is not static, and mainly because our expectations, operating systems and even hardware aren't static either.
You think Word 2.0 for DOS is somehow magically "secure" or better programmed than modern stuff made with optimising compilers that warn about everything and do proper memory separation?
Re:updates, updates, ... (Score:5, Insightful)
Has software ever "just worked"?
Somewhat. My Sun workstation ran for years with no software updates. It had bugs, but nothing that required a new operating system or application software.
The big difference was that it was behind a firewall and a 19.2k modem, so there wasn't much anyone could do to attack the--probably numerous--security holes.
Re:updates, updates, ... (Score:5, Insightful)
And I bet even that firewall and modem had bugs that exposed more of an attack surface than you ever wanted it to.
Systems don't "stop running" without updates. They stop being secure. And now that systems are all online, all the time, it's more important to be secure than almost anything else.
Re: (Score:1)
They stop being secure.
They were never secure, unless proven bug-free
Re:updates, updates, ... (Score:4, Interesting)
They stop being secure.
They were never secure
Is a system with no security defects known by anyone secure?
This might appear to be a philosophical maundering like "If a tree falls and no one is around to hear it, does it make a sound?", but it's not. It's a very serious question, with real implications... and the answer is yes.
Consider FakeID, a serious vulnerability in the Android app signing infrastructure that basically allowed any app to be claim to be from any provider -- including claiming to be signed by the OEM, to obtain system privileges. The bug was introduced in 2.2.1 in 2010 and existed in all versions of Android until 2014.
But no one knew.
Once the flaw was revealed Google was easily able to go back and examine the certificates of all apps uploaded to Google Play during the entire period of time between when the vulnerability was introduced and when it was fixed. Google also examine the contents of other app stores, and non-store app repositories. There wasn't a single instance of an app with a faked certificate chain, anywhere, until the public disclosure of the bug. Snowden's documents gave no hint that the NSA knew of it. Hacking team's archives had no hint of it. If anyone, anywhere, knew of the bug they were incredibly circumspect and careful with their usage. The more reasonable conclusion is that no one knew.
During those four years, all Android devices were vulnerable to this serious security hole, but none of them were exploited. So, the Android app signing architecture was effectively secure even while it was technically broken.
And as I said above, this is not just a semantic quibble. If your definition of "secure" (under some defined threat model) assumes that the system must have no security defects, then no system of any complexity ever has been or ever will be secure. Security is only meaningful within a defined context, and that context includes the knowledge of the adversaries. Of course, we can never know what the attackers do or do not know, but we can reasonably suppose that if they don't use a devastatingly effective attack it's because they don't know about it. This means that systems actually do get less secure over time, unless they're maintained.
(Note, BTW, that the mere existence of a known security defect also doesn't necessarily make the system insecure. That also depends on threat model and on whatever other mitigations may be in place. For example, take the libstagefright bug. 90% of Android devices in the world are running Ice Cream Sandwich or higher, and have ASLR enabled in their kernels which makes a bug like the one in libstagefright very hard to exploit.)
Re: (Score:2)
"But no one knew. "
That you know of.
Are you not making an assumption that an entity like the NSA, had they known, would have shared their findings with the vendor or make it public?
Re: (Score:2)
It was patched before exploit (Score:2)
Not unless you can guarantee that the defect will be found and patched before it's exploited.
The FakeID bug was patched before any exploit. Read again what swillden wrote: "Google also examine the contents of other app stores, and non-store app repositories. There wasn't a single instance of an app with a faked certificate chain, anywhere, until the public disclosure of the bug." Even when Google made like Flo from Progressive Insurance, scanning its own app store and those of its competitors, it still found no exploitation of this particular defect.
Re: (Score:2)
Re: (Score:2, Funny)
The big difference was that it was behind a firewall and a 19.2k modem
ping -c 3 -p "+++ATH0"
Many haynes clone command sets (and even a couple bugged haynes firmwares) did not require the 300ms pause between the +++ "I want to send a command" pattern, and the actual command to the modem. You just had to get the remote system to reply with that command pattern to disconnect.
The best was against email servers. Send an email you know will bounce with a +++ATH0H1DT1900xxxyyyy number under your control and the bounced emails will make the modem hang up and call your toll number o
Re: (Score:2)
Has software ever "just worked"?
Somewhat. My Sun workstation ran for years with no software updates. It had bugs, but nothing that required a new operating system or application software.
The big difference was that it was behind a firewall and a 19.2k modem, so there wasn't much anyone could do to attack the--probably numerous--security holes.
So, if we just disable all network interfaces and keep our phones physically secure behind locked doors, updates won't be needed.
Brilliant!
Re:updates, updates, ... (Score:4, Interesting)
Does anyone remember the time when software just WORKED?
I remember those days well. It was just like yesterday.
However, back in those days, our computers ran MS-DOS, and weren't connected to the internet. For the few people who did have internet access (mainly college students), they usually didn't have their own computer hooked up to the internet, they shared some VAX or Unix machine, and mainly used it just for email, USENET, and maybe exchanging files via FTP. Some people used Gopher, though I don't remember what for. Since so few people used networked computers, hacking wasn't much of a problem, and was mostly an activity done by bored college students to see if they could.
Also, I do remember some updates back then, mainly to DOS games. Even back then, the games were buggy, but not too much. I remember some of them using some kind of utility (was it called "Patch"?) to update their software, so the updates could be distributed on BBSs. This software actually worked quite well: it only contained the parts that had changed, and the utility would actually modify the binaries on-disk as necessary. I haven't seen anything like it since, which is a shame since we do so many updates these days. For some strange reason, all our updates now involve distributing a bundle that includes all the changed files (rather than just the changed part of a file), so the update bundle is much larger than it needs to be. If some pathetically slow circa-1992 DOS machine could handle modifying binaries on-disk, why can't modern machines? It would save a huge amoung of bandwidth.
Re: (Score:2)
For some strange reason, all our updates now involve distributing a bundle that includes all the changed files (rather than just the changed part of a file), so the update bundle is much larger than it needs to be.
This is a bad idea in case the target image doesn't match exactly what you expected it to be. For instance, the target file may be one of several previous versions... which version do you create a diff against? Or do you bundle ALL possible diffs? Oops, we just lost our advantage in size, and we made things a hell of a lot more complicated or ourselves and the user. Or what happens if the file has been somehow altered unexpectedly, via corruption or malware? No way to solve that little issue.
It's far s
Re: (Score:2)
The launchers/updaters for many MMOs also work the same way. I know Final Fantasy XIV and Lord of the Rings Online both distribute updates as deltas from known versions whenever possible.
The MSI installer framework that many Wi
Re:updates, updates, ... (Score:5, Informative)
No, nobody remembers that time. I remember when Windows couldn't run more than a few days without crashing. I remember when getting a program to work required arcane knowledge and steps bordering on voodoo. I remember when getting a wireless card working on Linux was the realm of super hackers. I remember Sasser.
Re: (Score:3)
No, nobody remembers that time. I remember when Windows couldn't run more than a few days without crashing.
That's what you get for buying cheap crap. In that same era, the first time I rebooted my Sun was for a CPU upgrade... but it cost at least 5x as much as a Windows PC.
Re: (Score:2)
That's what you get for buying cheap crap. In that same era, the first time I rebooted my Sun was for a CPU upgrade... but it cost at least 5x as much as a Windows PC.
No, that is what you get for running a crappy OS... :)
A modern $400 Dell machine will run 24/7 for almost ever now... rebooting only for Windows Updates...
That is a nice change... :)
Re: (Score:2)
I remember those days well. Fuck That Shit. I had an Amiga 500, I couldn't scratch my ass with out it falling over. I had to reformat the HD at least once very few months because the god damn file system was so fucking fragile.
Fuck that shit.
Re: (Score:1)
Yeah. Back in the 80s.
Had systems that were damn fucking rock solid. and would seemingly take a bullet and keep going. They had wonderful, solid monochrome green screen serial terminals and nothing changed. Ever.
Now these pesky users want color, graphics, local storage, sound, mice and other pointing devices, portable workstations, handheld computers, printers, and customizable everything. Worst of all they want to connect to this huge world-wide network called the internet! There's no way at all to control
Re: (Score:1)
Does anyone remember the time when software just WORKED?
Yeah, when it was printed on ROM. Writable memory will kill us all!
Yes, I remember when we didn't care about bugs. (Score:2)
You mean back before it was networked (or otherwise shared data with potentially-hostile parties) so that the bugs didn't matter? And before people really started looking very hard for the bugs?
Sure, I remember then. You had shitloads of bugs, but you didn't know about most of them, and when you did know about one ("if you type too long of an answer in this char[40] blank, it makes weird t
Re: (Score:2)
Re: (Score:2)
And when the phone is updating you can barely use it.
Have you considered upgrading your hardware? :-)
Re: (Score:2)
Just buy the unlocked international version of the phone you want.
device not eligible (Score:2)
Device released prior to not eligible for updates.
Re: (Score:3)
The devices I can see were launched within the past two years. Looking a few of them up, the oldest I see was launched November 2012 and discontinued November 2014. In my view these should all be getting standard support anyway. We're not talking about an announcement to patch phones from 2007 or 2010.
Supporting a two-year-old product SHOULD be non-news, the true problem (sadly) is that it has become such.
Hopefully, they'll be able to bypass the carriers (Score:5, Insightful)
Samsung can make all of the updates they want, but if Verizon and other companies just sit on them, it won't do us much good.
Re: (Score:3)
Came here to say this.
The problem has never really been Android's willingness to correct and publish security-related patches; the problem is that the carriers control OTA and therefore limit OTA update support for phones that are fairly new. According to the carrier, if you want a secure phone, you'll just have to buy a new one from them.
Re: (Score:2)
Hang on a second... I understand what you're saying, and I'll definitely believe it applies to phones originally bought from a carrier. However, if I were to buy a Samsung directly from the manufacturer and then use it with a carrier, I'm not beholden to the carrier for updates, right? Since it's not a carrier-branded phone, I can just get updates over any valid internet connection, right?
Or does what you're sa
Re: (Score:2)
However, if I were to buy a Samsung directly from the manufacturer and then use it with a carrier, I'm not beholden to the carrier for updates, right? Since it's not a carrier-branded phone, I can just get updates over any valid internet connection, right?
I did forget about the possibility of BYOD, but as far as I know the big carriers get really passive-aggressive about putting your device on their network. I guess if you contract with an MVNO, or sign up for their poorly-publicized BYOD programs, they m
Re: (Score:2)
Imagine that happening on a computer that didn't fit in your pocket. "I can't upgrade my desktop from 12.04 to 14.04 because Comcast won't let me." It would almost be enough to make you stop buying PCs from your ISP!
CDMA2000 carriers (Score:2)
How about "I can't connect this computer bought elsewhere to Comcast's network because Comcast won't let me"? Good luck getting anything other than a Verizon or Sprint phone working on Verizon, Sprint, or Sprint MVNOs, because these networks use CDMA2000 instead of the more widespread GSM/UMTS.
Not quite clear on this (Score:1)
So with my otherwise perfectly functional 2011 plain old Nexus that hasn't seen an upgrade since Jellybean I'm out of luck? Eh, life in the big city, I guess.
SwiftKey? (Score:5, Interesting)
What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.
When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.
Re: (Score:2)
What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.
Didn't they block it with a security policy update until the patch was available?
It's hard to tell, since there doesn't seem to be any way to figure out which changes are in which policy updates.
Re: (Score:2)
Phone defect tracking opportunity? (Score:2)
When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.
It would be very helpful if there were a website that tracked cellphone support information, such as outstanding defects, and average defect correction time. I don't know of any such existing site, but suspect it would be a splendid opportunity to attract a large number of clicks.
Re: (Score:2)
Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers.
And if it turns out that the only responsive maker is Apple, then what? If I'm developing apps for a device, I won't be able to verify my compiler toolchain using diverse double-compiling because only Xcode can sign apps for execution on an iOS device.
(Note to moderators: dwheeler popularized diverse double-compiling, a method of ensuring that a compiler is unlikely to contain self-propagating malware by bootstrapping it with other implementations of the same language.)
Re: (Score:2)
or just buy what you want and install CM.
Re: (Score:1)
And then wait for CM to stop issuing stable (or even "snapshot") builds for your model. I can do without the newest shiny features, but I want the security updates backported to the latest stable version. CM is beholden to no one.
Re: (Score:2)
When buying an Android phone: check if it is supported by different open custom rom projects. Who cares about those horrid default Android installs that come with the phone.
This is a new update mechanism (Score:3)
This is a new update mechanism for security updates [and bug fixes, hopefully] for the device firmware (e.g. kernel) that makes it less painful for phone vendors and carriers to implement.
A few things to note [most of this is conjecture on my part, as software engineer, until the details emerge]:
- Android source code (e.g. kernel, dalvik, etc.) is maintained via git (with a Google wrapper program called "repo"). I regularly update a source tree via this.
- git has extremely powerful branching and merging capabilities. Thus, it's very easy to create a fix in one version and get git to apply the resulting patch/delta to other branches of the tree. That is git's forte. For example, do the security fix in the latest under development branch and then propagate it to all older branches [can be automated easily].
- Because you're just changing a small portion [we hope that the bug fix is only a hundred lines of code or so], the patch can easily be applied.
- Because the change is relatively small (e.g. 4.4.2 to 4.4.2.1) vs. going from 4.4.x to 5.0.0, it's far less QA testing as the old rev has been extensively QA'ed as a whole.
- This will encourage vendors/carriers to adopt this, even for old phones, because it's just a bug fix and not feature creep that might require more powerful hardware.
- This mechanism won't cut into margins because it is [will be] an automated way to apply just security updates (e.g. [gasp] Windows update). This could still have been done in the past, but it wasn't as easy [as Google seems to want to make it].
- Vendors/carriers will still be able to "up sell" to the latest and greatest for new features. So, no conflict/disincentive.
- Vendors/carriers will be encouraged because it's now easy to do, everybody will be doing it, and [a serious] black eye for any vendor/carrier that doesn't [far more so than in the past].
- And the legal liability for Google, vendors, and carriers for the MMS vulnerability is so severe, that any company that does not implement this could be sued into oblivion. For example, in the PC world, would any motherboard vendor decide they would prohibit critical security bug fixes via Windows update?
Re: (Score:2)
- git has extremely powerful branching and merging capabilities. Thus, it's very easy to create a fix in one version and get git to apply the resulting patch/delta to other branches of the tree. That is git's forte. For example, do the security fix in the latest under development branch and then propagate it to all older branches [can be automated easily].
What kind of world do you live in where you think its safe and practical to automatically merge fixes into old versions of software automatically? Especially when it comes to kernel level bug fixes! Depending on the area affected by the change, an automatic merge may not even be possible, yet the bug may still exist. If it were just a simple matter of an automatic git merge then RHEL would not need any active developers. That's one of the silliest things I have read all day. Git is great at branching an
Re: (Score:2)
I've been a kernel developer for 40 years [and when you can top that, you can mouth off]. And, I have plenty of experience with diagnosis, bug fixes, patches, multiple supported revs in the field, and automated build and testing. And, have created tools to do all that.
When Linus gave his original talk on git, he said it was all about merging. git has powerful branching [everything is a branch], but what really sets it apart is its merging.
Recommended best practice is to enable automatic rebasing on a pul
Re: (Score:2)
Re: (Score:2)
From the first line of my post:
This is a new update mechanism for security updates [and bug fixes, hopefully]
Also, see http://arstechnica.com/securit... [arstechnica.com]
Google also announced changes to the way the company distributes Nexus security updates. Starting Wednesday, Nexus devices will receive regular monthly security updates.
There is already a mechanism to push full Android updates. That's been the problem. It's all or nothing [if the vendor doesn't want to re-QA the entire update] (e.g. going from 4.0.0 to 5.0.0).
It may involve sending a full load [if that makes sense]. But, with just the necessary patches. It will be done monthly and not just when a new version [with new features] is stable and available. Since Android already does a.b.c versionin
Re: (Score:2)
I thought this effort was in part to continue security updates on phones manufactured "some time ago", especially pre-Lollipop devices.
Can We Finally Get This for Laptops Too? (Score:2)
Great, awesome, now can we finally get updates for laptop video cards now too? You know, especially the ones marketed as "gaming laptops" that only ever get one driver release and are incompatible with the chipset manufacturer's source drivers?
Re: (Score:2)
Great, awesome, now can we finally get updates for laptop video cards now too? You know, especially the ones marketed as "gaming laptops" that only ever get one driver release and are incompatible with the chipset manufacturer's source drivers?
If you're running Windows and have an Nvidia card then you typically just need to modify an INI file that ships with the drivers from Nvidia. Their drivers are pretty universal and the drivers on their site do not include a hardware identifier that is specific to your laptop manufacturer. Of course, the last time I dealt with this was when Vista shipped with all laptops, so perhaps things have changed.
How about .. (Score:2)
Terrific (Score:2)