Wire up the "Setup Repo" button on the Local Repo view to generate an
FDroid repo on the device that is hosted with the local webserver. This
also generates an index.html for when people navigate to the local repo via
a browser. This index.html will allow them to both download FDroid and to
setup the repo on the device running the webserver on the local FDroid.
refs #3204https://dev.guardianproject.info/issues/3204
refs #2668https://dev.guardianproject.info/issues/2668
This is a skeleton for the upcoming local repo (aka swap aka Kerplapp).
Right now, it just provides an Activity for controlling a Service which
manages a local webserver (nanohttpd). Next, it will be wired up to the
local repo created via a dedicated Activity for managing the list of apps
included in the local repo.
refs #3204https://dev.guardianproject.info/issues/3204
The local repo will need to both have current wifi settings in order to
send the correct IP address, SSID, etc. Also, this could be used to handle
interrupted downloads and updates, but that is not included in this commit.
refs #3204https://dev.guardianproject.info/issues/3204
This webserver is the core of the kerplapp swap local repo when used over
IP connections (WiFi). It is the smallest Java webserver we could find. It
is included as a git submodule, but then only the actual source files that
are needed are included. They are symlinked in src/.
The git repo used is the one that we submitted upstream as a pull request.
The pull request contains changes required to support https://. It has not
yet been accepted, so we cannot yet use the official repo. Once the pull
request is included, this should be switched to the latest release in the
official git repo.
https://github.com/eighthave/nanohttpdhttps://github.com/NanoHttpd/nanohttpd/pull/107
refs #3204https://dev.guardianproject.info/issues/3204
This app needs to be able to generate QR Codes regardless of what other
app might be installed, so zxing's core.jar needs to be embedded in this
app.
This also includes two classes which are modified versions of ZXing classes
that allow the generation of QR Codes without the Barcode Scanner app being
installed:
https://stackoverflow.com/questions/4782543/integration-zxing-library-directly-into-my-android-application
The classes are src/com/google/zxing/encode/Contents.java which is a copy
of zxing/android/src/com/google/zxing/client/android/Contents.java; and
src/com/google/zxing/encode/QRCodeEncoder.java which is a heavily stripped
and modified version of
zxing/android/src/com/google/zxing/client/android/encode/QRCodeEncoder.java
refs #3204https://dev.guardianproject.info/issues/3204
refs #2470https://dev.guardianproject.info/issues/2470
The receiver of this can at least make some sense of it, versus null or a
blank string. This prevents crashes where FDroid.repo.address is not yet
set since the wifi was never enabled or it does not have an IP address yet.
For some reason, on some emulators, it is failing to find a place to write
the test index files. But on most setups, it works fine. So instead try
writing the files to the cacheDir of FDroid itself rather than the test app
It seems that sometimes checking dialog.isShowing() is not enough. I got a
crash on dialog.dismiss(). But since the dialog is already gone in that
case, just catch the Exception and move on. Here's the stacktrace:
31760 FDroid D Update took 45 seconds.
31760 FDroid D Invalidating preference 'lastUpdateCheck'.
31760 AndroidRuntime D Shutting down VM
31760 AndroidRuntime E FATAL EXCEPTION: main
31760 AndroidRuntime E java.lang.IllegalArgumentException: View not attached to window manager
31760 AndroidRuntime E at android.view.WindowManagerImpl.findViewLocked(WindowManagerImpl.java:378)
31760 AndroidRuntime E at android.view.WindowManagerImpl.removeView(WindowManagerImpl.java:223)
31760 AndroidRuntime E at android.view.Window$LocalWindowManager.removeView(Window.java:432)
31760 AndroidRuntime E at android.app.Dialog.dismissDialog(Dialog.java:278)
31760 AndroidRuntime E at android.app.Dialog.access$000(Dialog.java:71)
31760 AndroidRuntime E at android.app.Dialog$1.run(Dialog.java:111)
31760 AndroidRuntime E at android.app.Dialog.dismiss(Dialog.java:268)
31760 AndroidRuntime E at org.fdroid.fdroid.UpdateService$UpdateReceiver.onReceiveResult(UpdateService.java:124)
31760 AndroidRuntime E at android.os.ResultReceiver$MyRunnable.run(ResultReceiver.java:43)
31760 AndroidRuntime E at android.os.Handler.handleCallback(Handler.java:587)
31760 AndroidRuntime E at android.os.Handler.dispatchMessage(Handler.java:92)
31760 AndroidRuntime E at android.os.Looper.loop(Looper.java:130)
31760 AndroidRuntime E at android.app.ActivityThread.main(ActivityThread.java:3687)
31760 AndroidRuntime E at java.lang.reflect.Method.invokeNative(Native Method)
31760 AndroidRuntime E at java.lang.reflect.Method.invoke(Method.java:507)
31760 AndroidRuntime E at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:842)
31760 AndroidRuntime E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:600)
31760 AndroidRuntime E at dalvik.system.NativeStart.main(Native Method)
119 E Dumpstate > /data/log/dumpstate_app_error
119 ActivityManager W Force finishing activity org.fdroid.fdroid/.views.RepoDetailsActivity
more info:
https://stackoverflow.com/questions/19538282/view-not-attached-to-window-manager-dialog-dismiss
This helps with dealing with listFragment being null after a rotation. That
was happening when an Intent was coming in from a QR Code scanner, and
the screen was rotated during the process. This snippet was taken from
SearchResults.java
This is Peter Serwylo's idea, I just typed it up and tested it :)
Fix/update notification
In addition to making update notifications work again (fixing issue #20) I also removed an unused class, and made the update count easily accessible from the AppProvider.Helper class.
security updates for added repos
These commits fix a couple of security issues with adding repos, they should be included in the 0.65 release. Here is the bug report from Adam Pritchard, these issues should be fixed:
2.
But wait, you say? Where's the "EF" at the start? F-Droid actually shows
(and takes) a version of the fingerprint with the first byte (first two
hex) dropped. Bwah?
You can see this with Guardian's fingerprint here:
https://guardianproject.info/2012/03/15/our-new-f-droid-app-repository/
len('050C8155DCA377F23D5A15B77D3713400CDBD8B42FBFBE0E3F38096E68CECE') / 2 *
8 == 248
...But it should be 256.
On purpose?
3.
And it seems like there's a bug in F-Droid. If you enter the fingerprint
when adding the repo, the repo gets flagged with "Unsigned", but if you add
the repo without entering the fingerprint it doesn't.
Reproduction:
- Add https://guardianproject.info/repo/ and enter
050C8155DCA377F23D5A15B77D3713400CDBD8B42FBFBE0E3F38096E68CECE
- Refresh
- It's say "Unsigned" in red text under the repo name
- Delete the repo
- Add it again, but without the fingerprint
- It won't have any red text
This is surely unintended?
If a repo was configured with a fingerprint, but it has not yet updated and
gotten the pubkey from the index.jar, then it will be in an "unverified"
state, i.e. the signing key fingerprint is stored, but it has not yet been
used to check against the pubkey in the index.jar
The logic here is crufty, so I slapped a flag in there to make sure that
the pubkey gets stored when someone configures a repo and includes the
fingerprint. When the fingerprint is set, it will first download the
index.jar and verify it against that fingerprint. The logic for storing
the pubkey permanently happens later in the XML parsing, so there needs to
be a flag to signal to store the pubkey in this case.
Before the flow was always index.xml -> get pubkey -> index.jar. Really,
there should no longer be support for unsigned repos, then all of this
stuff can be dramatically simplified.
fixes#2924https://dev.guardianproject.info/issues/2924
refs #2960https://dev.guardianproject.info/issues/2960
This was causing the first byte of the signature to be chopped off, so
therefore it would not validate since the fingerprint of the cert from
the net connection had the right fingerprint, but it was compared to the
stored, truncated version.
This also means that the database version needs to be bumped to trigger an
upgrade so that the bad 62 char fingerprints are removed from the database.
Since before, incoming repo Intents where handled in the Fragment's
onCreate(), an Intent that was received while the Fragment was visible was
just ignored. Activities have onNewIntent() for that, but Fragments don't
so the repo Intent handling had to be moved to the ManageRepo Activity.
That makes for a more direct relationship anyway, since ManageRepo is what
is configured as receiving all those Intents in AndroidManifest.xml.
