github.com/decred/dcrlnd@v0.7.6/docs/release.md (about)

     1  # `lnd`'s Reproducible Build System
     2  
     3  This package contains the build script that the `lnd` project uses in order to
     4  build binaries for each new release. As of `go1.13`, with some new build flags,
     5  binaries are now reproducible, allowing developers to build the binary on
     6  distinct machines, and end up with a byte-for-byte identical binary. However,
     7  this wasn't _fully_ solved in `go1.13`, as the build system still includes the
     8  directory the binary is built into the binary itself. As a result, our scripts
     9  utilize a work around needed until `go1.13.2`.  
    10  
    11  ## Building a New Release
    12  
    13  ### macOS/Linux/Windows (WSL)
    14  
    15  No prior set up is needed on Linux or macOS is required in order to build the
    16  release binaries. However, on Windows, the only way to build the release
    17  binaries at the moment is by using the Windows Subsystem Linux. One can build
    18  the release binaries following these steps:
    19  
    20  1. `git clone https://github.com/lightningnetwork/lnd.git`
    21  2. `cd lnd`
    22  3. `make release tag=<TAG> # <TAG> is the name of the next release/tag`
    23  
    24  This will then create a directory of the form `lnd-<TAG>` containing archives
    25  of the release binaries for each supported operating system and architecture,
    26  and a manifest file containing the hash of each archive.
    27  
    28  ## Verifying a Release
    29  
    30  With `go1.13`, it's now possible for third parties to verify release binaries.
    31  Before this version of `go`, one had to trust the release manager(s) to build the
    32  proper binary. With this new system, third parties can now _independently_ run
    33  the release process, and verify that all the hashes of the release binaries
    34  match exactly that of the release binaries produced by said third parties.
    35  
    36  To verify a release, one must obtain the following tools (many of these come
    37  installed by default in most Unix systems): `gpg`/`gpg2`, `shashum`, and
    38  `tar`/`unzip`.
    39  
    40  Once done, verifiers can proceed with the following steps:
    41  
    42  1. Acquire the archive containing the release binaries for one's specific
    43     operating system and architecture, and the manifest file along with its
    44     signature.
    45  2. Verify the signature of the manifest file with `gpg --verify
    46     manifest-<TAG>.txt.sig`. This will require obtaining the PGP keys which
    47     signed the manifest file, which are included in the release notes.
    48  3. Recompute the `SHA256` hash of the archive with `shasum -a 256 <filename>`,
    49     locate the corresponding one in the manifest file, and ensure they match
    50     __exactly__.
    51  
    52  At this point, verifiers can use the release binaries acquired if they trust
    53  the integrity of the release manager(s). Otherwise, one can proceed with the
    54  guide to verify the release binaries were built properly by obtaining `shasum`
    55  and `go` (matching the same version used in the release):
    56  
    57  4. Extract the release binaries contained within the archive, compute their
    58     hashes as done above, and note them down.
    59  5. Ensure `go` is installed, matching the same version as noted in the release
    60     notes. 
    61  6. Obtain a copy of `lnd`'s source code with `git clone
    62     https://github.com/lightningnetwork/lnd` and checkout the source code of the
    63     release with `git checkout <TAG>`.
    64  7. Proceed to verify the tag with `git verify-tag <TAG>` and compile the
    65     binaries from source for the intended operating system and architecture with
    66     `make release sys=OS-ARCH tag=<TAG>`.
    67  8. Extract the archive found in the `lnd-<TAG>` directory created by the
    68     release script and recompute the `SHA256` hash of the release binaries (lnd
    69     and lncli) with `shasum -a 256 <filename>`. These should match __exactly__
    70     as the ones noted above.