A new client configuration parameter, "trustedCerts" (list of strings)
is introduced. A certificate fingerprint is defined as the 10 digits
prefix of the sha1 of the whole certificate (in ASN1. DER form).
trustedCerts should contain the list of fingerprints of the
certificates we trust. If not empty, the server's certificate
is checked against that list, instead of using the full x509 validation
on it.
-added a dial function and tls configuration, which check if we're using
SSL, and if we're in "trustedCerts" mode.
pkg/client/client.go
pkg/client/config.go
-moved android specific hacks from camput to the client layer, so that
the dial and tls config could reuse/access them. Also allows future
reuse for other commands, such as camget.
pkg/client/android.go
-adapted camput to the above changes:
cmd/camput/android.go
cmd/camput/camput.go
cmd/camput/files.go
-server prints a hint when it generates the self-signed:
pkg/misc/misc.go
server/camlistored/camlistored.go
-camliactivity:
clients/android/res/xml/preferences.xml
clients/android/src/org/camlistore/Preferences.java
clients/android/src/org/camlistore/SettingsActivity.java
clients/android/src/org/camlistore/UploadService.java
clients/android/src/org/camlistore/UploadThread.java
http://camlistore.org/issue/131
Change-Id: I6be20161549a69aafc8eb7b9e96e9351dc1c5b09
works, but UI is terrible and unreliable. but it uploaded and vivified a photo shared from the gallery.
Change-Id: I63199a4d25597739920b276ac240efa27c07926c
For now it just smartly copies it from the APK zip to the filesystem and chmods it.
For testing:
(in an adb shell)
CAMLI_AUTH=userpass:USER:PASS /data/data/org.camlistore/files/camput.bin --server=https://server.example.com file -vivify /sdcard/DCIM/Camera/IMG_20130126_143719.jpg
... which now works, as of commit 51e88c7434 (camput: run in an Android linux non-cgo environment)
Change-Id: I32a7e1e28fdf781bec5156271a4b33f5bd3b8b83
This should fix
http://code.google.com/p/camlistore/issues/detail?id=3,
"Android client permits mutating the immutable cache".
I'm also removing the call to
URLConnection.guessContentTypeFromStream() in favor of
just using URLConnection.guessContentTypeFromName().
I don't think that the former was ever successful, and it
was hitting the disk from the UI thread.
when the Content-Length header is supplied, this makes us
check that we received the expected number of bytes. tested
by ctrl-c-ing the blobserver midway through a download.
- don't write search results to disk
- download into memory before writing to disk when
we have listeners asking for byte arrays
- don't read files while holding the lock
mpl