Telegram-FOSS

Forums Submissions Complete Telegram-FOSS

This topic contains 14 replies, has 3 voices, and was last updated by  mvdan 3 years, 2 months ago.

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #10467

    slp
    Member

    Category: Phone & SMS
    License: GPLv2+
    Summary: Unofficial, FOSS friendly fork of the original Telegram client for Android.
    Description:
    An unofficial, FOSS friendly fork of the original Telegram client for Android. This is a list of changes between the official version and this one:
    – Remove binaries from repository.
    – Remove Google Play Services dependency, and associated services (Location and G2CM).
    – Remove HockeySDK dependency.
    – Remove SMS listener and associated permissions (you’ll need to enter the registration code manually).
    – Add tags for easily tracking releases.
    .

    Repo Type: git
    Repo: https://github.com/slp/Telegram-FOSS

    • This topic was modified 3 years, 2 months ago by  mvdan.
    #10468

    Foley
    Member

    IIRC, F-Droid has a policy to not allow insecure applications. I think an app was pulled because it had glaring security holes.

    Telegram seems to employ a flawed approach to cryptography, see the answers at
    https://security.stackexchange.com/questions/49782/is-telegram-secure

    and the mentioned blog posts
    http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/
    concerning the crypto and
    http://thoughtcrime.org/blog/telegram-crypto-challenge/
    about their flawed contest.

    I’d therefore recommend to not include Telegram or its forks into the F-Droid repo, there are better alternatives.

    #10470

    slp
    Member

    From reading your links (the first one just refers to the other two), you can say that “some people are not satisfied by Telegram’s cryptography” or “Telegram cryptography could be better”, but saying that “Telegram is insecure” only makes sense in a black or white perspective.

    Actually, Telegram is more secure than most XMPP/SSL clients, specially if you’re using point-to-point encryption (secret chats), and there are plenty of such clients on F-Droid already.

    #10471

    slp
    Member

    .

    #10474

    mvdan
    Moderator

    FWIW, I tried building it on my own and it builds fine, but doesn’t run. Here’s the logcat of the startup crash:

    E/AndroidRuntime(18242): java.lang.UnsatisfiedLinkError: Couldn't load tmessages from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.telegram.messenger-1.apk"],nativeLibraryDirectories=[/data/app-lib/org.telegram.messenger-1, /vendor/lib, /system/lib]]]: findLibrary returned null
    E/AndroidRuntime(18242): 	at java.lang.Runtime.loadLibrary(Runtime.java:358)
    E/AndroidRuntime(18242): 	at java.lang.System.loadLibrary(System.java:526)
    E/AndroidRuntime(18242): 	at org.telegram.messenger.Utilities.<clinit>(Utilities.java:136)
    E/AndroidRuntime(18242): 	at org.telegram.ui.ApplicationLoader.onCreate(ApplicationLoader.java:57)
    E/AndroidRuntime(18242): 	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1007)
    
    #10475

    mvdan
    Moderator

    Here’s what was done to build it, from a fresh clone:

    cd TMessagesProj
    gradle clean
    ndk-build -j4
    gradle assembleRelease
    
    #10476

    slp
    Member

    FWIW, I tried building it on my own and it builds fine, but doesn’t run. Here’s the logcat of the startup crash:

    That’s probably due to the lack of jni libraries in the apk. I had this problem when building the debug version, but never with a release.

    I’ve just tried again, doing a fresh clone and following the same steps as you, and after installing the apk on a clean Android device (never had Telegram installed before), it worked properly, so it must be something with the environment.

    Do you have a native-libs.jar in you build directory? Could you unzip the apk and check if the libtmessages.so libraries are actually there?

    #10477

    mvdan
    Moderator

    @slp: Yup, build/native-libs/native-libs.jar exists and is 1.3M. The contents are:

     % find .
    .
    ./native-libs.jar
    ./lib
    ./lib/x86
    ./lib/x86/libtmessages.so
    ./lib/armeabi-v7a
    ./lib/armeabi-v7a/libtmessages.so
    ./lib/armeabi
    ./lib/armeabi/libtmessages.so
    
    #10478

    slp
    Member

    Are those libraries inside the apk too?

    #10479

    mvdan
    Moderator

    Where would they be in the apk? I found no .so files, if that’s what you mean. What could have gone wrong?

    I’m using gradle 1.10, btw.

    #10480

    slp
    Member

    Okay, I’ve been able to reproduce it. The first time you run assembleRelease, gradle generates an apk without the libraries. Running it again, generates a new apk, this time the libraries:

    slopez@linux-web9:~/Fuentes/Telegram-FOSS/TMessagesProj/build/apk> unzip -l TMessagesProj-release.apk |grep tmessage
       557840  2014-02-21 20:38   lib/armeabi/libtmessages.so
      1004312  2014-02-21 20:38   lib/x86/libtmessages.so
       602984  2014-02-21 20:38   lib/armeabi-v7a/libtmessages.so
    

    Apparently, every time I’ve generated an apk, I needed to run assembleRelease twice (usually because I forgot to properly configure the keystore first), that’s the reason I didn’t noticed this. On the other hand, I don’t know the cause yet, but it happens with the code from the official repo too.

    #10481

    mvdan
    Moderator

    @slp: Thanks for figuring it out. Good to know I’m not retarded 🙂

    There is probably something wrong regarding the packaging of the native libraries. For example, I imagine that they are prepared *after* the assets are loaded, hence they are found on a second run but they are not yet there in the first run.

    This is kind of a problem. I guess there is some task we could run before the first and only assembleRelease to trigger the preparation of the native libs.

    #10483

    slp
    Member

    This is kind of a problem. I guess there is some task we could run before the first and only assembleRelease to trigger the preparation of the native libs.

    Doing a “nativeLibsToJar” before “assembleRelease” does the trick in a consistent way.

    I’m curious about the root cause for this, though. “build.gradle” looks good to me, I’d say is a bug in the android plugin for gradle, but that’s just the lazy answer. 😉

    #10491

    mvdan
    Moderator

    After @krt‘s work on gitorious, telegram (from your fork) should be available tomorrow morning.

    #10561

    mvdan
    Moderator

    Added.

Viewing 15 posts - 1 through 15 (of 15 total)

The forum ‘Submissions Complete’ is closed to new topics and replies.

Posted in