##Bringing this to development mailing list
>> ----- Original Message -----
>> From: d3fault <d3faultdot...@gmail.com>
>> To: bog_dan...@yahoo.com
>> Cc:
>> Sent: Wednesday, January 16, 2013 7:53 AM
>> Subject: Full Ministro in Ministro-Redirection stub
>>
>> Hi, sorry to bother you as I'm sure you're busy working on Android Qt,
>> but I'm wondering if maybe you didn't see my post here:
>> http://lists.qt-project.org/pipermail/development/2013-January/009249.html
>> on the topic of "[Development] Android port - Why do we need
>> Ministro?". I understand the technical problem of "no common shared
>> folder" that Ministro solves and I'm wondering if there's a problem
>> with the design in my link (solves the same problem) that I'm just
>> failing to see? I like what Ministro does but I think making the
>> experience as seamless as possible (aka, they don't ever see or
>> explicitly install Ministro) would be the best solution for the end
>> users.
>>
>> Also be sure to click to the next email in the thread for the "DUH"
>> solution to the bandwidth problem.
>>
>> I am aware of the 2 new cons introduced by my design: each/every Qt
>> Android application now requires access to the SD-Card and the Network
>> (security risks), but I think they're worth it in the end because
>> Android is not a secure OS to begin with, as it includes proprietary
>> and closed source binaries (I'm willing to bet our views on security
>> differ).
>>
>>
>> Thank you for all of your contributions to Necessitas/Ministro/Qt,
>> d3fault
>>
>
>On Wed, Jan 16, 2013 at 10:52 AM, BogDan <bog_dan...@yahoo.com> wrote:
> Hi,
>
> Your solution sound similar with this
> https://groups.google.com/group/android-qt/browse_thread/thread/708d0be52dd4af92
> one.
>
> Please check that thread for my answer.
>
> Cheers,
> BogDan.
>
Hmm, you're right, the design is flawed.
I've been letting the problem soak in my subconscious for the past
week or so and came up with a solution that I'm not sure you'll like.
Basically it's a compromise between:
a) Not trusting other applications to supply and/or not change the
libraries (because as you pointed out, md5 summing for integrity and
loading of libraries is not an atomic process)
b) Not caring about security because Android is already insecure
(proprietary binaries): as long as it is *FUNCTIONAL*, security can be
assumed to already be compromised so who really cares as long as it
works
Here's a solution that implements the compromise:
tl;dr: 2 Activities in the manifest. One for
'idgaf'/insecure/FUNCTIONAL usage, and one for
forced-loading-of-local/verified-and-non-outside-writeable-libraries/safer
usage
In Launcher:
1-ActivityRegular: Checks local dir for libs, broadcasts for libs
path (uses them if found), downloads libs if necessary, caches them on
SD card, md5sums local copy that is actually loaded
2-ActivityForcedSafer: Checks local dir for libs, DOES NOT BROADCAST
FOR LIBS PATH, downloads libs if necessary (or pulls from SD card
cache), caches them on SD card if relevant, md5sums local copy that is
actually loaded
Pros: Completely transparent/seamless to end users (the biggest pro of
them all), still provides 'moderate' security for those who actually
trust proprietary binaries (ROFLMFAO)
Cons: A pretty hefty amount of wasted disk space for every app that is
run even once in 'safer' mode (it would be possible/easy to run out of
space by running them all in Safer mode), cluttering of Launcher menu
(two entries for every one activity), all Qt-Android apps would need
Internet and SD Card Permissions
Even though the first con is a pretty big one, I think it's worth it
in order to provide a seamless Qt-Android user experience. I myself
will launch every app in 1-ActivityRegular mode, so the first con will
be invisible to me. I think most users will too because Android is not
a secure OS to begin with. Be that as it may, we should still provide
an "as secure as Ministro [currently]" mode of operation for those who
want it.
Additionally, knowledge of the underlying system/design allows you to
choose which Qt-Android application will be the one in charge
('trusted', just as Ministro needs to be trusted) of supplying the
libs: whichever one you install first.
d3fault
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
