[erlang-questions] Coon - new tool for building Erlang packages, dependency management and deploying Erlang services

[Krzysztof Jurewicz]

Nowadays a typical specification of an external dependency (if we don’t want to rely on an external package index) looks like this:

dep_bar = git https://github.com/foo/bar.git v1.2.3

The problem with this solution is that it is completely mutable:

⒈ GitHub can decide to replace this repository with a malicious version (unlikely, but what if it was not GitHub, but a smaller, less trusted repository hosting?).
⒉ GitHub can be cracked.
⒊ Package mantainer can replace the repository with a malicious version.
⒋ Package maintainer’s account can be cracked.

To deal with it, one can use checksums instead of tag names (this is what lock files may do). However what if we want to update package bar from v1.2.3 to, let’s say, v1.3.0, and that we don’t want to check by hand that the checksum currently pointed by v1.3.0 is ok, but instead decide to trust package mantainers?

We can check that the Git tag is signed by a maintainer that we trust. This may work in many cases, but there are issues:

ⓐ If we want to upgrade to an old tag for which the signing key has already expired, then how do we know that the signature has not been generated after the expiration? We would need to associate trustable timestamps with PGP signatures to know that this has not occured. For example, a SHA-256 of a signature could be put in a Merkle tree for which the root hash has been put into Bitcoin blockchain. Git doesn’t support this out of the box, but it seems that an external implementation has already been started: https://github.com/opentimestamps/opentimestamps-client/blob/892e8378c4604a367654e49cac1220822d169e86/doc/git-integration.md [1].
ⓑ If we don’t want every trusted maintainer to be a single point of failure, then we may want to say that a new tag for package bar may be trusted if it is signed by at least m of n maintainers. But Git doesn’t seem to allow multiple signatures of one commit/tag.
ⓒ What if we don’t trust package maintainer at all, but we do trust some external reviewer that has checked that Git commit 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33 is safe/valid? He may sign the commit, but without putting the signature in the main repository. Therefore maybe commit/tag/any file signatures should be (optionally) decoupled from repositories?

To summarize:

Ⅰ To secure particular versions, we need checksums.
Ⅱ To secure package version naming, we need digital signatures with timestamping.

While package managers support Ⅰ, they seem to lack support for Ⅱ.

Not verifying downloaded code seems to be generally common in installation instructions on the Internet, but to stay within the area of Erlang package managers:

Though Loic does sign his commits, the recommended installation method for erlang.mk doesn’t seem to involve any GPG checking (the same applies to updates). There is even a relevant issue: https://github.com/ninenines/erlang.mk/issues/614

The recommended installation method for Rebar is downloading some binary from Amazon AWS without any verification. Tags are signed though.

The recommended installation method for the incriminately-named package manager is either using PyPi (don’t know whether packages are signed since it looks like it has been deleted from PyPi) or running make install (which involves sudo) after cloning the — unsigned — master branch.

Krzysiek

[1] See also the paper about Keyless Signatues’ Infrastructure for a description of a similar service, but not involving neither Git nor Bitcoin: https://eprint.iacr.org/2013/834.pdf