| Age | Commit message (Collapse) | Author |
|---|
|
Riseup's EE certificate expired (EE = End-Entity, the commercial
certificate signed by the issuer), and we weren't able to fetch
provider.json because the pin wasn't valid.
This problem needs to be avoided in the future, using
HKPK (https://tools.ietf.org/html/rfc7469), which Micah's implementing
on Riseup.
Switching from build types from flavors enables us to run tests against
production apk, not just debug. I didn't detect this pinning problem
because tests were run only against the debug apk, which trusted
preseeded providers by default (thus bypassing pinning issue).
|
|
Next step: beautify.
|
|
|
|
I've separated the user session management to it, and encapsulated
ProviderAPICommand into its own class.
Putting the fragment statically in dashboard.xml isn't working, Android
complains about it being duplicated, so I'm going to add it dynamically.
|
|
|
|
A provider can be asked if it's configured or not, so that we don't find
more provider = null issues.
I've created a DefaultedURL which links to https://example.net, so that
we can initialize an URL. I use composition instead of inheritance,
since URL class is final.
|
|
Using AndroidPinning library from Moxie, I make sure the provider.json
file Bitmask downloads is fetched from a pinned https connection, so
that the api certificate fingerprint is the good one.
|
|
String locale = Locale.getDefault().getLanguage() + Locale.getDefault().getCountry();
|
|
|
|
|
|
In the near future, I should implement an error feedback
mechanism (ideally using ics-openvpn's log view), and avoid the
e.printStackTrace() and Log.d("","") without losing information.
|
|
|
|
|
|
I haven't still decided how to show that warning, I'm talking to gus
about it. This is just the first idea, but the core mechanism is
implemented at least.
|
|
|
|
Switching orientation doesn't hide that information, now we have two
places to avoid it.
|
|
|
|
It was giving problems when trying to change the arguments.
|
|
This makes sure that if a a certificate is not valid, a new one is
downloaded. Unit tests don't apply to this, I've already added one to
the certificate validator, whose result will determine if a new
certificate will be downloaded.
|
|
Last refactor, introducing ButterKnife and all those things, I forgot to
update this layouts.
|
|
|
|
|
|
|
|
|
|
According to https://github.com/JakeWharton/butterknife/issues/167:
"The view isn't set until onPostCreate. You need to either trigger layout creation by setting the adapter before calling ButterKnife or by moving the call to inject to onPostCreate."
|
|
|
|
Beware! https://code.google.com/p/android/issues/detail?id=80074: Wrong VpnService.prepare() behavior after re-installation of the VPN app on Android 5.0
"The following steps will cause incorrect behavior of the VpnService.prepare():
1. Establish VPN connection using any VPN app. VpnService.prepare() will return an intent for the "Connection request" system activity. Once user accepts it, VPN connection can be established successfully.
2. Uninstall VPN app.
3. Re-install the same VPN app.
4. Now VpnService.prepare() returns null, as if the VPN service has been already prepared.
5. Now VpnService.protect() returns false and VPN connection fails.
Device reboot is needed in order to be able to establish VPN connection again."
|
|
Refactored the new provider dialog too.
|
|
Removed the sign up dialog, log in one is enough with the third button I
added some time ago to sign up.
Removed classes we don't need due to the libraries I have recently
introduced.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update gradle to 2.2.1.
|
|
One more onReceiveResult for Dashboard, that method needs a rethink: a
statemachine class, and a simple "next()" method? The reality is that
the onReceiveResult specifies a linked process, and that should have a
better model than a series of if/else cases with strings comparisons hehehe
|
|
|
|
|
|
|
|
Reproduced the refactoring done in debug.
|
|
Reuse EipServiceFragment's stopEip and startEipFromScratch in Dashboard.
|
|
Fix a typo in the debug source of ProviderAPI.
|
|
|
|
Always. Previously we didn't do so if EIP hadn't been started before.
Fix a small bug introduced during latest refactoring, authentication did
not work because the final result variable wasn't assigned.
|
|
Authenticate and Register methods are now renamed and split. It's much
more readable, the new emacs-default indentation helps to that too.
|
|
|
|
|
|
|
