On Thu, Feb 25, 2016, at 08:01, Hans-Christoph Steiner wrote: > Any chance of viewing this in git?
Not until it gets released. At that point, it will be in my book's massive repo (https://github.com/commonsguy/cw-omnibus), along with the rest of my book samples. > I'll start digging into these. I looked at netcipher-hurl, that seems > to be a simplified duplication of what's already in the > NetCipher.getHttpURLConnection() methods, based on the > TlsOnlySocketFactory.java class. Was that deliberate? No. My biggest problem with all of this is that NetCipher is undocumented AFAICT. Hence, I worked off of the sample app to determine what is and is not your supported API. I didn't notice a getHttpURLConnection() method. I'll run a comparison and make changes if needed -- thanks! > > I do not believe that setPackage() is sufficient, for the Orbot status > > Intent, to get Orbot to run after a fresh installation, if the user has not > > run the Orbot activity. As of Android 3.1, apps are installed in a > > so-called “stopped state”, where manifest-registered receivers will not > > receive broadcasts of implict Intents. Using an explicit Intent, as I am, > > will help here. > > Ok, that's interesting. I couldn't find where you are making an > explicit Intent for this. That's inside validateBroadcastIntent(), over in my CWAC-Security library. For the purposes of my book, having it there is fine. For any long-term NetCipher reuse, we'd want to copy the logic from there or do something equivalent, so there's no dependency on something tiny like this: https://github.com/commonsguy/cwac-security/blob/master/security/src/main/java/com/commonsware/cwac/security/SignatureUtils.java#L70-L152 > It could easily take Orbot more than 30 seconds to complete the whole > Tor startup sequence. That's a key reason for the Intent broadcasts > with the OFF/STARTING/ON/STOPPING status. That let's the app then > respond accordingly, like holding network connections when in the > STARTING state. StatusCallback could be expanded for the other states. Again, it's not obvious what is and is not part of the supported API. Expanding StatusCallback is out of scope for the current book sample (like your sample, it doesn't really need it), but it's clearly something that could be added as part of any long-term NetCipher reuse. > I think we should skip that approach entirely, and leave only where it > was used for backwards compatibility. AndroidPinning provides a more > manageable approach to certificate pinning. If you are interested in > looking more into that, it could be a new chunk of work related to this. If you mean https://github.com/moxie0/AndroidPinning, that's GPLv3. Thanks! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
