[ot][spam] Thank you for your post coderman

Thu Jul 1 02:34:02 PDT 2021

> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 13721 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20210701/58ec34a7/attachment.txt>