Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

F-Droid releases #37

Open
smarek opened this issue Dec 23, 2014 · 27 comments
Open

F-Droid releases #37

smarek opened this issue Dec 23, 2014 · 27 comments
Assignees

Comments

@smarek
Copy link

smarek commented Dec 23, 2014

Hello developers,

is there anything currently blocking the f-droid release channel?
Such as code licenses, your personal/project stance against f-droid, pre-compiled binaries being used without optional 3rd party verification, or so?

Since dSploit is taken down from all distribution channels and is currently replaced with binary only release of Zanti2 (whatever it is), I'd really like to help you and push the foss approach.

Thanks

@tux-mind
Copy link
Member

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
Copy link
Author

smarek commented Jan 12, 2015

@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
Copy link

mvdan commented Jan 12, 2015

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
Copy link
Member

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
Copy link
Author

smarek commented Jan 12, 2015

@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
Copy link
Member

OK, will do this.

but now i have to fix tens of bugs 😁

@tux-mind tux-mind self-assigned this Jan 12, 2015
@smarek
Copy link
Author

smarek commented Mar 16, 2015

@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
Copy link

mvdan commented Mar 16, 2015

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

@smarek
Copy link
Author

smarek commented Mar 16, 2015

@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
Copy link

mvdan commented Mar 16, 2015

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
Copy link
Author

smarek commented Apr 2, 2015

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

@smarek smarek closed this as completed Apr 2, 2015
@tux-mind
Copy link
Member

@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.

@tux-mind tux-mind reopened this Sep 24, 2015
@ghost
Copy link

ghost commented Sep 24, 2015

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
Copy link
Member

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
Copy link
Author

smarek commented Sep 25, 2015

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
Copy link

mvdan commented Sep 25, 2015

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

@smarek
Copy link
Author

smarek commented Sep 25, 2015

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

@mvdan
Copy link

mvdan commented Sep 25, 2015

Yep, LGTM. Will look at adding it now.

@mvdan
Copy link

mvdan commented Sep 25, 2015

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
Copy link

mvdan commented Sep 25, 2015

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
Copy link
Member

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
Copy link
Member

@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
Copy link

mvdan commented Sep 25, 2015

@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
Copy link
Member

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
Copy link

mvdan commented Nov 14, 2015

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
Copy link
Member

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

@IzzySoft
Copy link

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants