Perkeep status update (2018-03)

[Brad Fitzpatrick]

Keepers,

This is your somewhat-regular status update on what's new in Perkeep.

* the mailing list has been moved from camli...@googlegroups.com to
per...@googlegroups.com. We're cross-posting this status update, but
be sure to move to https://groups.google.com/group/perkeep if you
haven't already. (We've been trying to migrate people slowly, within
the allowed rate limits)

* the "camtool" command has been renamed to "pk". The "pk" command
will be the main entrypoint to all CLI usage of Perkeep in the future.
Renaming & merging of other tools is still underway.

* The migration away from sha1 should now be complete. A few remaining
pieces in the index & search systems have been fixed to be
hash-agnostic.

* The Perkeep schema now supports very large static directories that
previously could not be presented within the default maximum blob size
(16MB). Static directories previously had to have their entries
represented in a single blob, but now they can form a tree of blobs,
so it's possible to store, for instance, directories with over 20,000
children.

* The Android app is being resurrected & fixed up.

* The vendor directory continues to be cleaned up, and we're now
auto-pruning the dependencies (using dep 0.4).

* The "blobpacked" storage target now does a quick integrity check on
start-up, to tell you if your indexes are corrupt or missing. This
isn't quite done. Some final bugs are being fixed up in
https://github.com/perkeep/perkeep/issues/1068

* The web UI's "Download" action no longer zips the files if only file
was selected.

* A new storage target named "overlay" presents a read/write set of
blobs that out of a base layer and a delta layer, similar to the Linux
kernel's overlayfs. See https://perkeep.org/pkg/blobserver/overlay for
more.

* some web UI navigation bugs were fixed when editing permanodes

* a new "-1" (dash one) option to "pk search" permits listing just the
matching blobrefs, one per line, instead of JSON, suitable to passing
to xargs.

* Due to LetsEncrypt shutting down the TLS-SNI challenge type we
depended on previously, we've now enabled http-01 challenges (and thus
listening on port 80) when using LetsEncrypt for TLS certificates.

We're still working towards a release.

The main blockers until the next release are finishing up the
blobpacked validation on startup, and adding some configuration
options for permitted digest algorithms for new & existing blobs.