Add AIMSICD to the F-Droid Repository

[PowerPress]

Please add this project to https://f-droid.org/ repository.
Its a wonderful idea and should be spread to people who most likely will use it FOSS.

[SecUpwN]

Hey @PowerPress, thank you for your awesome suggestion and your warm words! You are right, adding it to the F-Droid store would be the best idea (I hate the PlayStore and its policies, to be honest). Furthermore, as soon as the first BETA will be out, we are aiming at (hopefully) being featured on the website of the 'Surveillance Self-Defense Project' (https://ssd.eff.org/) as well as on 'The Guardian Project' (https://guardianproject.info/). Be curious and follow my links. Have a smooth Monday! ;-)

@xLaMbChOpSx, shall I open up a new official repo there and publish WIP-releases?

[dalb8]

I doubt they'll accept it now that it has the framework jars. Google Maps is possible to get around but they can't build those jars from source. You can always serve APKs to the F-Droid client from your own repo, as the Guardian Project do.

[dalb8]

Since the framework and telephony jars are part of the system, it could be argued that the source code doesn't need to be provided, under the system library exception of the GPL. The same is true of Google APIs but in that case maps.jar is the same everywhere, since it is non free. However f-droid removed Google APIs from their setup for some reason, so the only way to publish it there is by replacing Google Maps with OSM, which is easy enough, but may not work too well. I plan to do this myself, so please add some kind of centre the map button as that will fix the usual problems that the MapsAPI replacement has.

[SecUpwN]

@dalb8, thanks for clarifying this. So let me summarize: F-Droid would not accept our app because it currently utilizes Google Maps, which would have to be replaced by OSM (or equivalent). Have you heard about the NOGAPPS Project yet? Those are also Open Source. Would be cool to have @mar-v-in in our team! 👍 What do you think @mar-v-in, - would you be able to replace all the proprietary stuff?

[mar-v-in]

@SecUpwN, I think @dalb8 is aware of my work :)
I think the Maps are a minor problem for the inclusion in f-droid. There are other apps that require maps api already on f-droid and with this it should be fairly easy to replace Google Maps with osmdroid.
A much bigger problem is the signature. As AIMSICD uses a shared system uid it must be signed with the same key as the Firmware. The f-droid build server uses it's own key for signing which is not the platform key. A F-Droid build will therefor not work, even if installed as system app (which F-Droid is not capable to do either).

[SecUpwN]

What if we changed the key to the one of the F-Droid build server, @mar-v-in? Please point me in the right direction if I didn't get the point yet. I'm just trying to find the best solution to the problem..

[mar-v-in]

It's not you who would have to change the key. Point is that the ROM and the AIMSICD app must be signed with the same key.

Many custom ROMs use the AOSP default/sample key (which is a security problem), I guess that's why you did so with the released APK. F-Droid does not (and should not) sign applications with this key or with any other publicly provided key for security reasons.

To be honest, I don't see any way to add AIMSICD to the official f-droid repository. One could create a custom f-droid repository, but that's another thing.

[dalb8]

It's possible to sign an APK with two keys, but I don't know if the share uid would still work.

[dalb8]

No, Android wont accept an upgrade with a double signature even if the first is recognized.

[dalb8]

It looks like PGP signatures will be offered on f-droid.org before too long and eventually should be supported by the client, https://f-droid.org/repository/issues/?do=view_issue&issue=284. They'd also get need to add the platform key to their key store, if it would be in their repo. In the mean time publishing gpg signatures would give some defended.

[SecUpwN]

@dalb8, I appreciate your effort to dive into this so deep! Question is: Shall we really add the AIMSICD to the F-Droid Store? What would be the advantages? Why not get it directly through the WIP-Releases? And then, _if_ we should add it to F-Droid, what would be the most convenient, hassle-free way of doing so? I'd like to avoid too much struggle for our developer. We currently only have one main developer (meaning the awesome @xLaMbChOpSx) - I DON'T want to lose him because of this.

[xLaMbChOpSx]

The only way around the platform key signing I think is to totally use reflection to access the methods hidden by the standard SDK, but I think the apk will still need to be a system application I could try this out but the main reason why I changed the manifest to share the phone process was the issues I was facing with reflection and creating the defaultphones() method which expects to be called from the main looper thread which is only accessible through a main system process like the phone process.

[dalb8]

If only the ROMs would do the build, you wouldn't need to avoid using the shared uid. Even if they felt that the app isn't ready to be included in the zip they could distribute it outside of it. There is a topic on jira.omnirom.org about including F-Droid, but it doesn't say whether they would include their own repo in it or just the f-droid.org one.

[E3V3A]

Sorry, but I don't think this is the way to go. I don't want AIMSICD to be dependent on anything. If ROM developers want to use it, fine, but I think that at this early stage of our development, we should not spend time on these kind of issues, and we (AIMSICD) should not have to maintain this.

At this point in time (and I'm open to change my mind) I would like AIMSICD to be a completely free-standing, directly downloadable/installable application for as many people as possible. Point your phone to a QR code and run!

[illarionov]

You can split the application into two pieces.
The first application is a system application that provides access to low-level hardware capabilities and internal/non-standart API, that is not available for standard applications (invokeOemRilRequestRaw, e t.c.).
The second application is the normal application that is used a standard SDK and services provided by the first one. If the first application is not installed, it will have limited functionality.

I have made a test application to show how it can be HERE

[SecUpwN]

@illarionov, interesting point. As much as I would like to add AIMSICD to the F-Droid store, I prefer to let it be a unified installation in one App. As for now, our primary focus is to create the features to protect and warn the user that an IMSI-Catcher attack is taking place. We'll re-evaluate F-Droid later,

BTW: Did you use RawPhone source code to create your app? You should give proper credit..

[illarionov]

No, RawPhone was not used. Some code was taken from (android_packages_apps_SamsungServiceMode)[https://github.com/CyanogenMod/android_packages_apps_SamsungServiceMode]. I'll add a license and credits for this application in future.
Usually I try not to use the code under a GPL license.

[SecUpwN]

Out of curiosity: Why don't you like code under a GPL license, @illarionov?

[illarionov]

I think GPL it's too restrictive. In general, I like it and I am an active user of GPL software. Just try to avoid it when choosing the license for the any new my program, preferring less restrictive licenses that are compatible with GPL.

[SecUpwN]

Do you think our license is too restrictive? Which license do you recommend, @illarionov?

[E3V3A]

Interesting topic. I'd like to know as well. For now I think the current licensing is good. We could consider relaxing the license, if necessary, once we have some generally working functionality.

[illarionov]

Sorry, but I can not give any recommendations here, there are many of them. Actually I'm not asking you to change the license.

[E3V3A]

@dalb8 , @mar-v-in and @xLaMbChOpSx :

"A much bigger problem is the signature. As AIMSICD uses a shared system uid it must be signed with the same key as the Firmware. "

I was browsing the Xposed Framework thread. (I think someone already suggested to use Xposed before, but now I can't find that post.)

Can we use that to circumvent this signing business?

Given the current difficulties we have, I think it would be just fine that our App would be dependent on a different "something" as long as it is possible to use on stock ROM. Else, we'll just rely on AOSP like the initial commits.

[SecUpwN]

@E3V3A, in fact, I was the one who suggested to use the Xposed Framework. But I deleted my suggestion from the README as it was too early to speak about it. Now it seems time has come. But please note that Xposed will ONLY work on ROOTED systems. I don't have a problem of AIMSICD being a Root-Only App, but didn't you say that it shall be "optional" to have ROOT when using our App? :)

[E3V3A]

@SecUpwN Aha, thanks for clarification. Let's see what happens with the new ideas (in other issue thread). And we can get back to this if we're not happy.

About having rooted phone, I think is the only way to go until Google decides to include more useful Radio stuff in their API or we can circumvent it or find another way.

[SecUpwN]

Why in the world are you closing all Issues, @E3V3A? I'm a little baffled..

[E3V3A]

@SecUpwN Because it's no longer an issue, if we still agree that we will not use F-droid as discussed above. So then I'm the one baffled, why not to close it?