LonamiWebs/Stringlate

Authorisation at Github fails

Olf0 opened this issue · 15 comments

Olf0 commented

Steps to reproduce

  1. Start Stringlate.
  2. Tap on the settings button (gear icon) in the upper right corner.
  3. Tap on "Login to GitHub".
  4. Pick a web browser from the intent dialogue.
  5. When returning from the web browser, Android displays "Completing authorization...", immediately followed by Stringlate 0.14 displaying "GitHub Authorization failure":
    screenshot_20180421_004
  6. Strangely, the chosen browser is opened once more, sometimes.

Expected behaviour

Authorisation at Gitbub succeeds.

Notes

I successfully authenticated myself at Github with Stringlate 0.11 and / or 0.12 (I don't remember which one or both).

General information

Tested with Stringlate 0.14 from F-Droid under AOSP 4.1.2 (API level 16).

Log

Main log, filtered for lonamiwebs.

At this point, I feel like there is something wrong with your device. Perhaps some connectivity problem. Network issue maybe? I can't reproduce any of the issues you're posting! And I'm not sure if you're the only one having them. Maybe everyone else uses a version above 4.1.2? This one for instance points to:

NetworkUtils.performCall(GITHUB_COMPLETE_AUTH_URL, NetworkUtils.POST, map)

That's a network call. The previous issue you created links to:

Another network call! There's definitely something wrong with network calls alltogether.

I don't have any physical device running such an old version of Android and I have spent a considerable amount of time trying to setup an emulator for Android 4.1.2 (Android Virtual Device), with little success. I can't even connect to any site using https that's not Google. I feel like these issues affect only your Android version, otherwise I would hope more people could report and/or support them.

Could you provide the log unfiltered? I feel like filtering leaves out the surrounding lines and while these are short and nice to find where the bug probably is it doesn't tell me why.

I think I found why not a single calls works for your, and all our test in any emulator fail too: https://developer.github.com/changes/2018-02-01-weak-crypto-removal-notice/

As far as I know there was some more SSL stuff added at 4.2, which is missing in previous versions. GitHub dissallows connecting with such outdated and insecure params/versions and forces some minimum security level, and your device is not compliant. Nothing we can do about that, since we can't update SSL on that device and even if, neither Android API.

Thanks for the insight.

@Olf0 The only thing that seems not to be affected, seems to be git repos. You can sync/clone repos right?

More: https://githubengineering.com/crypto-removal-notice/

Olf0 commented

At this point, I feel like there is something wrong with your device.

I am usually testing on two Jolla 1 phones (both with the current SailfishOS release, but the testing phone has more software installed), but missed the check this specific issue on my "production" phone yesterday.
Will restest on both phones tonight or tomorrow, plus on a device with BlackBerryOS 10.3 (AOSP 4.3 based Android runtime environment (API 18)), but I cannot record logs on the BlackBerry device.

Perhaps some connectivity problem. Network issue maybe?

Definitely not: Testing occurs in my own WLAN at home. I was surfing the web and updating / installing software (native RPMs and Android APKs) immediately before and after testing.
Network setup is basic (WLAN router behind cable modem) and usual, assuming others are using /etc/hosts based ad-blocking (specifically Steven Black's "Unified hosts" list), too.

I can't reproduce any of the issues you're posting! And I'm not sure if you're the only one having them. Maybe everyone else uses a version above 4.1.2?

Sorry, I am aware that I am testing a niche use case. I will spend more time to ensure that they are not dependent on a specific configuration or device. But as my perspective for 2018 is to continue using these Android runtime environments at API levels 16 and 18 (plus 19, after having my Xperia X flashed with SailfishOS), I am still affected. And yes, IMHO it is likely that nobody else of the some 10.000 SailfishOS users and the some 100.000 remaining bbOS 10.3 users tried Stringlate yet, but OTOH the ones who maybe did might have given up, as a couple of functions are not working.
But OTOH, I have more than 150 APKs installed, using 10 to 15 often and many others occasionally, and none of them has exposed so many issues, hence I am also a bit puzzled.

Could you provide the log unfiltered? I feel like filtering leaves out the surrounding lines and while these are short and nice to find where the bug probably is it doesn't tell me why.

Will do.
And will check, if the device is trying to use outdated cryptography algorithms for SSL / TLS (Jolla 1 phones under SailfishOS 2.1.4 are using Linux 3.4.108 and OpenSSL 1.0.1m). @gsantner, your suggestion is to try a git clone command of a repository at Github at the command line, right?

@Lonami and @gsantner, thanks again for your support.

Olf0 commented
  1. A git clone done at the SailfishOS shell works nicely:
    $ git clone http://github.com/JusticeRage/ApkTrack
    Cloning into 'ApkTrack'...
    remote: Counting objects: 2595, done.
    remote: Total 2595 (delta 0), reused 0 (delta 0), pack-reused 2595
    Receiving objects: 100% (2595/2595), 1.97 MiB | 791.00 KiB/s, done.
    Resolving deltas: 100% (1262/1262), done.
    Checking connectivity... done.
    After that the repository is downloaded locally.

  2. But on an Android shell (using ConnectBot), the same command fails (apparently after downloading?!?):
    $ git clone http://github.com/JusticeRage/ApkTrack
    Cloning into 'ApkTrack'...
    remote: Counting objects: 2595, done.
    remote: Total 2595 (delta 0), reused 0 (delta 0), pack-reused 2595
    Receiving objects: 100% (2595/2595), 1.97 MiB | 625.00 KiB/s, done.
    Resolving deltas: 100% (1262/1262), done.
    Checking connectivity... done.
    fatal: unable to look up current user in the passwd file: no such user
    Unexpected end of command stream
    But for just reading IMO no authentication should be required!?!
    What does git want to obtain the username for, in contrast to executing the same command using the same git binary (2.0.0-minimal) on the same kernel (and the same device) outside the Android runtime environment?

Puzzled.

Side note: Did both git clone experiments in /tmp and checked each time that files and directories can be created (per touch foo and mkdir bar) there.

Olf0 commented

Observations in an Android shell:
$ whoami
whoami: cannot find name for user ID 10107
$ cat /etc/passwd | grep 10107
$
Or is this irrelevant WRT this issue?

P.S.: Note that my know-how of git usage at the command line and command line usage under Android is quite limited, currently.

I don't think you can compare both, as jGit doesn't use any system binaries

Olf0 commented

I don't think you can compare both, [...]

?
This is the same binary, as in a native shell and a Android shell (ConnectBot, local) both yield:
$ which git
/usr/bin/git
$ git --version
git version 2.0.0
$

[...], as jGit doesn't use any system binaries

Well, you suggested testing git clone, which is what I did.
If I should test jGit (supposedly because Stringlate uses it), if have no idea how, as it seems to be solely a Java library (or I missed something when glancing over its documentation). Any suggestion how to test with jGit?

I meant cloning using stringlate, yes. That works? Or not?

Olf0 commented

If "git clone" rsp. "cloning using stringlate" is supposed to mean "hitting + Add project, inserting a valid repository URL, followed by hitting ▶ START TRANSLATING", the description of issue #200 (which you closed, referencing to this issue, as they seem to be related) already answers that:
"Yes, is working" for repositories hosted at Gitlab and "No, fails" for those at Github.

I originally thought you suggested testing a "git clone" with a different tool, in the same environment (device etc.), hence the git command appeared to be the easiest way.
But what does testing that Stringlate is not working for me with repositories at Github reveal besides that Stringlate is not working for me with repositories at Github (which I filed issue #200 for)?

I will try to record more comprehensive logs, next.

Noting: https://developer.android.com/reference/javax/net/ssl/SSLSocket.html

not knowing about other required (or disallowed) stuff at github, but 16+ is req for tls1.2

Olf0 commented

Thank you @gsantner for all your support.

Technically TLS 1.2 is not the issue (I wonder, why so many people primarily suspect TLS), but SHA1:

Well, an understandable move by Github and I can still use Stringlate with a few projects at Gitlab.

I wonder what happens if you tried to git clone http://github.com/LonamiWebs/Stringlate.git on your Android device (note it's not https). On my desktop it redirects to the https version but perhaps it can't do that on Android and just works? You guys have more idea on this, I'm just brainstorming :)

Olf0 commented

@Lonami, thanks for your suggestion. Sorry, meanwhile I put this issue aside and somehow missed the notification email.

I revisited this issue the last couple of days, as it became apparent by the SailfishOS 3.0.0 announcements, that the situation (Android runtime environment stuck at API level 19 rsp. 16) will change late 2019 earliest.
For BlackBerryOS 10.3's Android runtime environment (at API level 18), there is no hope of ever receiving a substantial update anymore (it is still supported, but EOLed, hence in "minimal maintenance": A single, final update of BlackBerryOS 10.3 is still announced).

[...] git clone http://github.com/LonamiWebs/Stringlate.git on your Android device

... the test itself does not work as intended, as I have no "Android device":

  • Under SailfishOS, command line tools (/bin, /usr/bin etc.) are bind-mounted into the Android "container" (i.e. the usual chroot plus configuring cgroups, "lightweight virtualisation"). Consequently I am testing those, when using a "local shell" in an Android terminal app.
    Hence the git clone command works fine, with or without https.
    How did you check, if the git command is redirected from http to https by Github?
  • BlackBerryOS is tightly closed:
    I was not able to gain interactive shell access from within the Android runtime environment.

I also enhanced a little shell script ("test_ciphers.sh", original source link inside; it is ugly, with its unnecessary bash'isms, but works fine, now also optionally with e.g. -starttls {imap|smtp|xmpp|...}) to test a server's supported ciphers.
But ultimately, for this issue, only tests using the Android APIs would really provide results of significance. Unfortunately writing a program testing this way is beyond my capabilities.

Lastly, IMO a single enhancement suggestion can be extracted from this, which might be of common interest:
Enable Stringlate to access local repositories (i.e. on file-system), e.g. by allowing to enter file://<path-to-git-repo> as repository address.