Intel's Crosswalk open source dev library has serious SSL bug Developers using Intel's Crosswalk SSL library: it's time to patch and push out an upgrade. Crosswalk is a cross-platform library that supports deployment to Android, iOS and Windows Phone, but the bug is Android-specific. The library has a bug in how it handles SSL errors, and as a result, end users on Android could be …
Could there be an easier way to make sure all applications using it were upgraded? Perhaps we could have a directory containing libraries to be shared by different applications. I think we'd call them "shared libraries".
This way, we'd only have to update a single place instead of all the different applications. A revolutionary idea? Perhaps a bit too revolutionary for a system like Android?
Pros and cons.
Pro - your single update theory.
Cons: Wikipedial 'DLL hell'
1) Difficult to test your software since you'd need to test against every version of every library that exists, with potential interactions between all of them, since a client machine could have anything installed.
2) if your code has workarounds for buggy implementations they may fail when the bug in the upstream implementation is fixed. Or an incompatible upgrade where going from 'v1' to 'v2' removed some API or added something that you didn't implement because it wasn't needed in 'v1'?
3) Who is responsible for doing the updating? Your app? Every app? Relying on the OS vendor to own and update? If not the OS vendor, then what stops some naughty app adding a bad version that then affects all other users of that particular set of libraries?
4) What happens when an update breaks apps? How is it reverted? An update to 'Pokeman' breaks your banking app. Who's at responsible?
The term "shared library" doesn't mean "system library". It means that it can be dynamically linked at runtime thus shared between binaries that link against it.. it doesn't have to be visible system-wide to be shared.
Android has shared system libraries and most apps will be using them. There are very good reasons applications can't go messing with system libraries. Take a few moments and think about it...
Now a thought experiment; What do you do if you want to provide some functionality that isn't available in the system libraries? Do you allow random applications to fight over which version of the library gets installed system-wide or do you just sandbox the application and let it provide whatever libraries it wants for it's own use without interfering with the OS and other applications?
"Where the DLL resides doesn't change the problem."
It does. If a .so is packaged with an Android application other applications shouldn't be able to load it (Each application is sandboxed in it's own user on Android) so if there is a problem with that .so it's limited to that application.
"Either the OS upgrades a library, with all the potential compatibility problems, or the app does it,"
We're not talking about anything special here because it's a library. As far as the OS is concerned is just a file owned by the application. There's no way to track every single piece of code that is shipped with third party applications and have the OS go around fixing it. The only realistic option is to contain the damage by sandboxing the applications as much as possible.
Google has options via the Play Store to press the eject button on apps that are really serious problems and they apparently do scan code (compiled from Java) for common defects (recently they have been sending e-mails out for issues that will stop apps working with N) but if you think that they can build something into the OS that can work out where each binary in an application comes from, work out what it was really built from (app specific patches etc) and supply automatic replacement binaries without breaking applications then I want some of what you're smoking.
"in which case you're waiting on the developers."
You're waiting on developers either way. If the fix for this is trivial to implement (updating the SDK and rebuilding the APK) updates will be hitting the Play store in no time.
I haven't a clue what you're arguing.
The original point was that, rather having components built into apps, we should have shared libraries so they could be updated without having to wait for the app vendor. DLL hell was raised as an objection to this. You then suggested sandboxes as a fix but, as you admit, that puts us back in the situation we were in initially: waiting on devs. It's an implementation detail whether a library is statically linked or a DLL (sandboxed or local -- Windows has linked against DLLs in the app's directory for decades).
@Brewster's Angle Grinder
Android apps use "shared libraries".. mainly because if you want to add native code to an app deployed in Java the native code is loaded in via a shared library.
So long story short: Android has shared libraries, system wide ones and APK wide ones.
Apps shouldn't be allowed to mess with the system wide ones as that would be a disaster and the OS has no hope in hell of patching random .so files shipped with apps. You seem to think some code being in another file == totally easy to do security updates for with no knowledge of what the .so actually is.
Obviously, Android already has a SSL library, serviced and updated by the Play Services, so is always upto date, on an device 2.3 (Gingerbread) onwards. This only applies if you had an idiot developer that decided to use a standalone, manually updated SSL library.
https://developer.android.com/training/articles/security-gms-provider.html
That will only work for apps developed in Java as that isn't replacing the system TLS library but replacing the security provider used by the "Java" runtime to create instances of SSLSocket etc.
It doesn't actually update the system wide library that is in the read only system partition...
And this doesn't work for the SDK in question because it's a platform for writing cross platform apps so it's unlikely to be able to call into Java code to setup TLS sockets.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
