I proposed to the lsl project (used for neuroscience research) that they encrypt and authenticate their biosignal streams.  I wasn't sure what system to suggest and suggested hypercore because it offers some small proof of creation after the fact  They were expecting TLS of course, which I worry around because it doesn't say anything about archival integrity after decryption.  Hypercore wasn't really a good suggestion because it is written in nodejs and lsl is in c++ :-/
...
Rust stores its cargo.io package index in a single git repository with history.  Each package's source bundle is hashed with sha256, although it does not look like the format provides for easily upgrading that algorithm.
...

The mitm-commit-tip of https://github.com/google/trillian-examples for me is 267fb50f0b5571b879ac75fd52a113af1b31c6a0 .  In the sumdbaudit/ folder is software in go for producing, auditing, and running a go sumdb mirror.

Athens is a tool that will run a local copy of a go development ecosystem including the sumdb.  https://docs.gomods.io/

Even though sumdb is heavyweight, golang projects do store their dependency checksums by default, like rust binary projects, which is more than can be said for most C/C++ projects unless they use subtree, submodules, distribution libraries, cmake externalproject hashes, or some other external dependency system.  Nodejs projects support hashing in the package.lock file, but it has sometime become a norm to not include this file in shared code.

There's a lot of discussion around signing cargo packages for rust at https://github.com/rust-lang/crates.io/issues/75 .  The conversations there also include some existing in-use systems, but the issue is open.  The devs didn't want to rely on git's sha-1, refrained from signing the repo, and then many releases happened while there was no velocity on an alternative implementation.

I tried cloning the rust index in termux on my phone:

$ git clone --mirror https://github.com/rust-lang/crates.io-index
Cloning into bare repository 'crates.io-index.git'...
remote: Enumerating objects: 2048515, done.
remote: Counting objects: 100% (3869/3869), done.
remote: Compressing objects: 100% (1596/1596), done.
Receiving objects: 100% (2048515/2048515), 565.69 MiB | 4.85 MiB/s, done.
remote: Total 2048515 (delta 2642), reused 3437 (delta 2212), pack-reused 2044646
Resolving deltas: 100% (1414312/1414312), done.
Checking objects: 100% (4194304/4194304), done.

It's half a gigabyte ;p. I don't see evidence of signatures but don't really remember how to check.

It looks like the latest tool mentioned at the bottom of that thread is https://github.com/crev-dev/crev :


# Crev - Code REView system that we desperately need

## Implementations

* [cargo-crev: Crev for Rust/cargo](https://github.com/crev-dev/cargo-crev) - ready and working
* [npm-crev: Crev for Node/NPM](https://www.npmjs.com/package/crev) - baby steps
* [pip-crev: Crev for Python/PIP](https://github.com/crev-dev/pip-crev) - still early
* Crev for Julia/Pkg - in plans; ask around on [Crev Matrix channel](https://matrix.to/#/#crev:matrix.org)
* other languages/ecosystems - join [Crev Matrix channel](https://matrix.to/#/#crev:matrix.org), tell us about your interest and find help

## Introduction

You're ultimately responsible for vetting your dependencies.

But in a world of NPM/PIP/Cargo/RubyGems - how do you do that? Can you keep up with ever-changing ecosystem?

Crev is an actual *code review* system as opposed to typically practiced *code-change review* system.

Crev is scalable, distributed, and social. Users publish and circulate results of their reviews: potentially warning about problems, malicious code, or just encouraging high quality by peer review.

Crev allows building a personal web of trust in other people and the code they use and review.

Crev [is a][f] [tool][e] [we][d] [desperately][c] [need][b] [yesterday][a]. It protects against compromised dev accounts, intentional malicious code, typosquatting, compromised package registries, or just plain poor quality.

[a]: https://www.csoonline.com/article/3214624/security/malicious-code-in-the-node-js-npm-registry-shakes-open-source-trust-model.html

[b]: https://thenewstack.io/npm-attackers-sneak-a-backdoor-into-node-js-deployments-through-dependencies/

[c]: https://news.ycombinator.com/item?id=17513709

[c]: https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_stealer/

[d]: https://www.zdnet.com/article/twelve-malicious-python-libraries-found-and-removed-from-pypi/

[e]: https://www.itnews.com.au/news/rubygems-in-recovery-mode-after-site-hack-330819

[f]: https://users.rust-lang.org/t/security-advisory-for-crates-io-2017-09-19/12960

## Vision

We would like Crev to become a general, language, and ecosystem agnostic
system for establishing trust in Open Source code. We would like to have
frontends integrated with all the major Open Source package managers and ecosystems,
and many independent and interoperable tools building on top of it.

## Overview

At it's core Crev defines a simple, human-readable data format to communicate
trust in code (results of code review) and people (reputation).

Using tools implementing Crev, you can generate cryptographically signed artifacts (*Proofs*).

Here is an example of a *Package Review Proof* that describes results of reviewing a whole package (library, crate, etc.):

```
-----BEGIN CREV PACKAGE REVIEW-----
version: -1
date: "2018-12-16T00:09:27.905713993-08:00"
from:
  id-type: crev
  id: 8iUv_SPgsAQ4paabLfs1D9tIptMnuSRZ344_M-6m9RE
  url: "https://github.com/dpc/crev-proofs"
package:
  source: "https://crates.io"
  name: default
  version: 0.1.2
  digest: RtL75KvBdj_Zk42wp2vzNChkT1RDUdLxbWovRvEm1yA
review:
  thoroughness: high
  understanding: high
  rating: positive
comment: "I'm the author, and this crate is trivial"
-----BEGIN CREV PACKAGE REVIEW SIGNATURE-----
QpigffpvOnK7KNdDzQSNRt8bkOFYP_LOLE-vOZ2lu6Je5jvF3t4VZddZDDnPhxaY9zEQurozqTiYAHX8nXz5CQ
-----END CREV PACKAGE REVIEW-----
```

*Proofs* are published and exchanged in a similar way that Open Source code is, for other people to benefit from.

## Fundamental beliefs of Crev design:

* Trust is about people and community, not automatic scans,
  arbitrary metrics, process, or bureaucracy. You can't replace a human judgment
  with an algorithm. Tools can only help make such a judgment.
* Code quality, risk management, and trust requirements are subjective, contextual, and personal.
  Islands of Trust must grow organically.
* Not many people can review all their dependencies, but if every user
  at least skimmed through a couple of them, and shared that information with
  others, we would be in a much better situation.
* Trust should be spread redundantly between many people, so one compromised or malicious
  actor can't abuse the system.
* Crev does not have to be perfect. Instead it should be robust, simple and flexible, so
  it can evolve to be good enough.

## Further reading

For more concrete information, see [cargo-crev - first and currently most advanced implementation of Crev](https://github.com/crev-dev/cargo-crev).