2

I am maintaining and Android app that now suffers from an unsafe X509 TrustManager implementation. Since the app doesn't make any HTTPS calls except through dependencies, one of the dependencies is causing the issue.

The problem is that I don't know what any of these dependencies are for (there are ~20) except for one, which is a simple "social (Facebook, Twitter) button" library. I looked through the source code of that one, because it was small enough, and it's not the issue.

Some of the dependencies are packaged through Maven so I can't browse their source, and some of them are no longer on Github (the library was OS, but eventually scrapped).

Many of the dependencies make HTTP(S) requests, which is causing the X509TrustManager error. How can I figure out which one is causing the error without having the source?

Improve this question
4
  • The old standby of "delete the dependency and check the compilation/unit test errors" is insufficient? Commented Jul 23, 2016 at 15:37
  • @Telastyn I tried that, but a lot of the dependencies make network requests using what I presume to be HTTPS, which is why there is an X509TrustManager error; how do I know which one actually has the error without being able to view the source? I guess I should have been more descriptive about that in my question, so I apologize. The only solution I have right now is to strip out the dependencies one by one, fix compilation errors, then upload the APK to Google Play so their server checks for that specific security error. But that takes about 6 hours for each dependency... Commented Jul 23, 2016 at 15:47
  • I can't imagine a good reason deleting a dependency would take 6 hours. Commented Jul 23, 2016 at 18:52
  • @CandiedOrange It takes about 1.5 hours for me to get rid of a dependency and everything it's tied to so I can actually compile. The other 4.5 hours is what it takes for Google Play to tell me if the X509 error still exists (meaning that dependency I just removed wasn't causing the problem). This code base is really old, and really complex. Removing stuff takes some time, but waiting for Google Play is what takes so long. Commented Jul 23, 2016 at 19:16

2 Answers 2

Reset to default
1

If you really have no better clues than delete and test I suggest a binary search. Spend 1.5 * 10 hours getting rid of half of the dependencies. Then test and see if it's in that half. Lather rinse, repeat until you're down to one suspect dependency.

Save it in the different states so you can go back without it being a pain. Document it well. Sucks to go down this rabbit hole for hours and then get lost.

Should take no more than

1.5 * 10 + 4.5 +
1.5 * 5 + 4.5 +
1.5 * 3 + 4.5 +
1.5 * 2 + 4.5 +
1.5 * 1 + 4.5 = 54 hours.

Better than 120 I guess.

Sure there are no better clues?

Improve this answer
1
  • 1
    This was the approach that I used, and it worked well. I solved it in about 12 hours, much faster than I was expecting! Commented Aug 3, 2016 at 16:37
0

Even without the source, you should be able to search the libraries for references to the classes in question. You can find what they are by looking at the pom and then the poms of the dependences in your pom (rinse and repeat.) That might take a while because Maven encourages people to not know what they are creating dependencies on so there are likely many unused dependencies in your project.

I would start by searching through the local maven repo where you are doing your builds. javap is a useful tool for viewing bytecode but if you install eclipse, you can use that to search the libs brought in by maven via your pom.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.