Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

first attempt at explaining binary policies #36

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions binary_policies.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
title: Policies for Binary Packages
layout: single
author_profile: false
---

Spack has the ability to create, download, install, and bootstrap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does bootstrap mean here? I think we should leave that word out until it's defined in paragraph 2

dependencies from binary packages. Spack signs binary packages with
gpg, and the ``spack gpg trust`` or ``spack buildcache keys -it``
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GPG should be all caps and defined on first use on the page, e.g. "GNU Privacy Guard (GPG)"

commands tell Spack explicitly which gpg keys to trust.

When bootstrapping the lowest-level Spack dependencies from binaries,
binary verification is more complicated. Spack will bootstrap
``clingo`` and ``gpg`` without access to its normal gpg-based
verification capabilities. In those cases, Spack will bootstrap from a
very limited selection of binaries with sha256 checksums associated in
Spack. These bootstrapping binaries will also be associated with a
binary installation policy.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"binary installation policy" isn't defined yet -- we should probably lead with some motivation and that definition. Why is trusting binaries special (vs sources), what are Spack's policies -- basically the idea that a signature or a set of binaries are created using some process, and we want users to understand the process and trust it (or not)


Spack is configured by default with unkown trust levels configured for
its builtin binary bootstrapping capabilities. When Spack needs to
bootstrap, it will prompt the user any unknown trust decisions. Users
may also use the ``spack trust`` command with appropriate options to
ensure Spack will not prompt in automated workflows.

Trusting binaries is not something to be done lightly. Different trust
policies effect the security of your account, and ultimately of your
computer or center. To enable users to make the best possible
decisions, here we describe each of the policies available in Spack
and what it means.

## Binary Trust Policies
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

top level is #, then ##, then ###, etc.


Binaries distributed under each of the following policies are guaranteed, but gpg signing and by sha256 verification, to come from the worfklow outline for that policy

# llnl-spack-team

Binaries are built on LLNL hardware through CI on a gitlab instance on
the Livermore Computing (LC-CZ) network at LLNL. The CI jobs run on
ManyLinux containers downloaded once from the registry, and thereafter
stored on an LLNL machine so they are not a long-term target for
security threats. Binaries are checksummed as part of the CI workflow
on the same LLNL hardware, and are signed with a private gpg key owned
by one of the Spack maintainers employed at LLNL. All jobs in the CI
process are run as one of the Spack maintainers' user accounts.

# cloud-ci

Binaries are built by a github actions workflow
[in a public repo](https://github.com/alalazo/spack-bootstrap-mirrors)
owned by a Spack maintainer. Binaries are signed by a private gpg key
available to the CI process, and checksummed through the same workflow
that creates the binaries.