F-Droid releases about android

[tux-mind]

Hi @smarek .

I will really appreciate to see cSploit on F-droid , but it download some compiled stuff like ruby as optional plugin. also cSploit perform an internal check for updates, which is against F-droid rules.

the compiled Ruby is generated by cSploit sources on github and user confirmation is required.
also we can disable the internal update stuff is F-droid will do it for us.

maybe you are better informed about F-droid then me, what changes are required to do ?

we will evaluate the cost of the changes to the benefit to be on an alternative market ( no fake APK )

[smarek]

@tux-mind Hi, thanks for follow up.

Basically there are few rules to pass the community validation rules:

1. Use as little permissions as possible
2. Don't use external tracking services, or allow to disable them on buildscript level
3. Don't use pre-compiled binaries, if it's not possible to verify them (eg. without published sources)

So if you could simply add the buildscript configuration, to disable the self-update function, and provide a way to compile/verify the pre-compiled ruby, it's possible that team would want to compile it themselves, to be sure.

Can you attend the discussion please? @CiaranG @mvdan

[mvdan]

A few things to note:

• We have ruby installed on the buildserver, which is a debian testing virtual machine
• libs/*.jar also count as pre-compiled binaries
• We don't forbid self-updating apps, but in many ways that feature should be avoided because it's redundant and most of the time it won't work with F-Droid because of signature mismatches.

Rest looks fine to me.

[tux-mind]

thanks for the info guys !

cSploit use a lot of permissions.
a network map or a MITM attack use a lot of privileged parts of the OS.
but this respect the "as little as possible" XD

actually no tracking service are used. BTW i wish to use a crash handler in future.

all binaries sources are public.

@mvdan using maven instead of libs/*.jar is acceptable ?

can you explain what do you mean with signature mismatch ? the apk on F-droid isn't signed with my developer key ?

thanks again for your patience 😊

[smarek]

@tux-mind yes, release on F-Droid is signed by FDroid keys, so it would mismatch signature on your releases (ad auto-update function)

And yes, Maven is acceptable over libs/*.jar dependencies

Crash handler is OK, as long as it does not act without user consent (eg. it's optional in settings, or will pop out dialog to user before sending anything)

[tux-mind]

OK, will do this.

but now i have to fix tens of bugs 😁

[smarek]

@tux-mind i've just got back to test csploit again, and i'm sorry, but downloading some ZIP or XZ files from amazon aws (and similar) is strange behavior to me, having it compiled in and not-overriding the update process user wants (updating parts/modules without much info) would be probably the way to run it with f-droid
what do you think @mvdan ?

[mvdan]

What zip/xz files? I didn't understand the compiling and self-updating stuff.

[smarek]

@mvdan to clear up, building ruby/metasploit-framework/... was removed from build process and now the small application after it's installation downloads ZIP/XZ files with pre-compiled binaries and stuff.
But on the other hand, the same does OSMAnd~ (open street maps android) with map resources.

Would you consider this behavior as suitable for f-droid distribution or not?

[mvdan]

Well, what the app does once installed is its own business in that regard. Of course if it downloads sensitive data over http it may gain a disclaimer, but I'm hoping that's not the case.

We are strict as far as the building process goes, but we don't get into the security of running the app itself.

[smarek]

Well I'm closing this issue, because the build process now complies with f-droid concerns, @tux-mind I leave the decision about releasing through f-droid up to you. Thanks for your cooperation @mvdan

[tux-mind]

@smarek can you explain what part of our build system we should change ?
I want to give a try to botbrew.com , i think to use it to build the assets packages that cSploit downlaod.

Wouldn't the downloading of ruby and MSF, and core break:
the software should not download additional executable binary files (e.g. non-free addons, auto-updates, etc) ?

[tux-mind]

as you can see from above we just need to integrate ruby and MSF into a CI server.
once this is done our downloaded stuff can be verified and checked 👍

[smarek]

Well, it will be marked up that you're downloading pre-compiled binaries after application will install, so the only concern is for F-Droid team, to be able to reproduce compilation of anything, that should be signed by them.
So keep it simple, stupid, don't use any statically provided JAR libraries/dependencies and I've checked again, it seems like simply running ./gradlew assembleRelease will provide installable APK, so that's fine to me.

Regarding other data, it's more like my opinion, than something that concerns f-droid team.
I'm against downloading pre-compiled binaries and for me it would be great to have one installable package, which would contain everything (also it would be far more stable testing, knowing, there is no other apk version vs. binaries version than what's provided)
And if you do download binary packages, i'd like to be able to verify them ie. using GPG --verify (so providing official signature of the cSploit team), and don't download them through HTTP (no-SSL)

Also, @tux-mind i've closed this issue with status, that you're good to go for f-droid team from my point of view, so it's only question, if @mvdan will confirm this
And yes, having full build+verify process scripted so that CI system can run and verify it, would be really great !

Thank you for heads up

[mvdan]

I've been out of the loop on all of this for a while - exactly what are you asking of me to confirm?

[smarek]

@mvdan if cSploit is currently good to go for f-droid or not 👍

[mvdan]

Yep, LGTM. Will look at adding it now.

[mvdan]

I just noticed that you guys have been bumping the version name, but not the version code. This will need to change in future releases.

[mvdan]

Fails to build with the latest NDK:

jni/openssl/Crypto.mk:85: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/openssl/Apps.mk:33: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/sqlite/dist/Android.mk:138: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/libxml2/Android.mk:90: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/libxslt/Android.mk:53: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
Making include directory...not needed
jni/openssl/Crypto.mk:85: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/openssl/Apps.mk:33: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/sqlite/dist/Android.mk:138: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/libxml2/Android.mk:90: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/libxslt/Android.mk:53: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
Making include directory...not needed

 % la /opt/android-ndk/build/core/build*
3672555 -rw-r--r-- 1 root root 5.2K Oct 13  2013 /opt/android-ndk/build/core/build-all.mk
3672554 -rw-r--r-- 1 root root  26K Mar  2  2015 /opt/android-ndk/build/core/build-binary.mk
3672553 -rw-r--r-- 1 root root 1.1K May  5  2012 /opt/android-ndk/build/core/build-executable.mk
3672552 -rw-r--r-- 1 root root 7.9K Apr  7 02:09 /opt/android-ndk/build/core/build-local.mk
3672551 -rw-r--r-- 1 root root 1.3K May  5  2012 /opt/android-ndk/build/core/build-module.mk
3672550 -rw-r--r-- 1 root root 1.2K Feb  5  2013 /opt/android-ndk/build/core/build-shared-library.mk
3672549 -rw-r--r-- 1 root root 1.1K Feb  5  2013 /opt/android-ndk/build/core/build-static-library.mk

[ETeissonniere]

Hey @tux_mind,
I am taking a look at botbrew
Le 25 sept. 2015 02:30, "Daniel Martí" [email protected] a écrit :

Fails to build with the latest NDK:

jni/openssl/Crypto.mk:85: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/openssl/Apps.mk:33: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/sqlite/dist/Android.mk:138: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/libxml2/Android.mk:90: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/libxslt/Android.mk:53: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
Making include directory...not needed
jni/openssl/Crypto.mk:85: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/openssl/Apps.mk:33: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/sqlite/dist/Android.mk:138: /opt/android-ndk/build/core/build-host-executable.mk: No such file or directory
jni/libxml2/Android.mk:90: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
jni/libxslt/Android.mk:53: /opt/android-ndk/build/core/build-host-static-library.mk: No such file or directory
Making include directory...not needed

% la /opt/android-ndk/build/core/build*
3672555 -rw-r--r-- 1 root root 5.2K Oct 13 2013 /opt/android-ndk/build/core/build-all.mk
3672554 -rw-r--r-- 1 root root 26K Mar 2 2015 /opt/android-ndk/build/core/build-binary.mk
3672553 -rw-r--r-- 1 root root 1.1K May 5 2012 /opt/android-ndk/build/core/build-executable.mk
3672552 -rw-r--r-- 1 root root 7.9K Apr 7 02:09 /opt/android-ndk/build/core/build-local.mk
3672551 -rw-r--r-- 1 root root 1.3K May 5 2012 /opt/android-ndk/build/core/build-module.mk
3672550 -rw-r--r-- 1 root root 1.2K Feb 5 2013 /opt/android-ndk/build/core/build-shared-library.mk
3672549 -rw-r--r-- 1 root root 1.1K Feb 5 2013 /opt/android-ndk/build/core/build-static-library.mk

—
Reply to this email directly or view it on GitHub
#37 (comment).

[tux-mind]

@mvdan use the build.sh script.
it will make those missing scripts for you ( it just touch $path ).

@DeveloppSoft thanks, I think that it would be great, move botbrew conversation on #220

[mvdan]

@tux-mind that makes no sense. My user doesn't have write access to my NDK, and that is on purpose - why would you modify the NDK?

[tux-mind]

I prefer to use libraries from google, like sqlite, lib, liiconv etc...
those libraries make use of some extra scripts that the standard NDK does not have for some advanced build targets.
after all cSploit will not use those scripts, because they are used in targets not needed by the normal build process, but they must exists in order to proceed with the build.

this is why the script just touch $scriptname.

anyway @DeveloppSoft are testing botbrew and I will play with it when I get back home in a few days.
using botbrew will almost wipe the cSploit jni directory 😊

[mvdan]

I've "fixed" and enabled the build by first making a full copy of the NDK into the clone directory. This is a terrible fix because it means copying 3G at each build. But it works, so it's good enough for now.

[IwraStudios]

@mvdan will there be an new version of Csploit on F-Droid soon? 1.6.5 is a little outdated

[IzzySoft]

@tux-mind @fat-tire: Just to bring this issue at F-Droid to your attention. We've looked at many places, but found no answer to the question: what is it that the app wants to download and run? From a security standpoint, it looks a bit – suspicious? strange? – that F-Droid offers an app after checking its code, and then the app downloads "other code" and runs that.

So in short: Could you please clarify:

• what is "csploit core"?
• why does the app download that (instead of the app being updated via the regular channels – here, via F-Droid)?

The tendency currently is to remove the app as we cannot explain it. An explanation (ideally also added to your FAQ) would help coming to the right conclusion on whether to keep it. Thanks!