This has been superseded by adding a builder-keys/ directory in guix.sigs, where the presence of keys, and validity of signatures is checked. Preventing issues like missing keys or invalid signatures.
New (or exisiting) Guix builders can add their key in the next PR they open adding attestations.
Related to issues like #26566, #26563.
Also follows up with the comment here: #26565 (comment).
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | hebasto |
| Ignored review | MarcoFalke |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
54 133EAC179436F14A5CF1B794860FEB804E669320 Pieter Wuille (sipa)
55+2F78ACF677029767C8736F13747A7AE2FB0FD25B satsie (satsie)
56 6A8F9C266528E25AEB1D7731C2371D91CB716EA7 Sebastian Falbesoner (theStack)
57-A8FC55F3B04BA3146F3492E79303B33A305224CB Sebastian Kung (TheCharlatan)
58 ED9BDF7AD6A55E232E84524257FF9BDBCC301009 Sjors Provoost (sjors)
59+4DAF18FE948E7A965B30F9457E296D555E7F63A7 Sjors Provoost (sjors)
48-C57E4B42223FDE851D4F69DD28DF2724F241D8EE midnightmagic (midnightmagic)
49+2CBBF208E594BF439B5F276C7465CFFF6793242E Niklas Gögge (dergoegge)
50 F4FC70F07310028424EFC20A8E4256593F177720 Oliver Gugger (guggero, Oliver Gugger)
51-D62A803E27E7F43486035ADBBCD04D8E9CCCAC2A Paul Rabahy (prab)
52-37EC7D7B0A217CDB4B4E007E7FAB114267E4FA04 Peter Todd (petertodd)
53 D762373D24904A3E42F33B08B9A408E71DAAC974 Pieter Wuille [Location: Leuven, Belgium] (sipa)
According to the readme:
Add your key to the list if you provided Guix attestations for two major or minor releases of Bitcoin Core.
So I am wondering if we should add keys for one-off signatures here?
So I am wondering if we should add keys for one-off signatures here?
I’m not sure. If we don’t have the keys, people will just complain they are missing. Historically, people don’t seem to be good at adding their own keys here either. We also don’t want to be running a faux keyserver.
So I am wondering if we should add keys for one-off signatures here?
I would keep them if they’re already here. If we want to lower the threshold for adding them (or even add them “non interactively”), that seems like a separate issue.
I’m not sure. If we don’t have the keys, people will just complain they are missing. Historically, people don’t seem to be good at adding their own keys here either. We also don’t want to be running a faux keyserver.
Well, if you think it is important to always list all keys, then your are running a keyserver (sort of). It will never be possible to have all keys at all times be listed, non-revoked and non-expired. So attempting that shouldn’t be a goal.
However, I wonder if this whole file can be removed and be replaced by having the full keys in the attestations repo, see also https://github.com/bitcoin-core/guix.sigs/issues/133 .
There’s (probably) not as much scrutiny on the guix.sigs repo as on this one, so at minimum we should keep (some) key ids here. For someone who has no developers inside their web of trust, the list here is a nice place to start.
If someone downloads the binary along with source code (e.g. via the Torrent), then they’ll have this file, but not the guix.sigs repo. (that said, verify-binaries currently isn’t designed to check files you already downloaded, but it could…)
There’s (probably) not as much scrutiny on the guix.sigs repo as on this one
This pull request is adding key fingerprints because they happened to be used once to sign and also happened to be on the internet somewhere. I don’t think this is any different from just doing https://github.com/bitcoin-core/guix.sigs/issues/133
vertiond. Could you adjust my name in parentheses to vertion (vertiond)?
Could you adjust my name in parentheses to vertion (vertiond)?
Thanks. Have updated. Will close 26634 now as well.
Seems like we should ping … to see if any of them have interest in doing Guix builds.
Yes, I’ll contribute some.
Hi! Thanks for the reminder. Been meaning to get that going. I’ll do it sometime this week.
Ditto.
I’m interested in doing Guix builds. I’ll setup my env during holiday.
On Mon, Dec 5, 2022, 11:05 Luke Dashjr @.***> wrote:
Seems like we should ping @schildbach https://github.com/schildbach @btcdrak https://github.com/btcdrak @theuni https://github.com/theuni @droark https://github.com/droark @cisba https://github.com/cisba @fivepiece https://github.com/fivepiece @Fuzzbawls https://github.com/Fuzzbawls @jhfrontz https://github.com/jhfrontz @jl2012 https://github.com/jl2012 @jtimon https://github.com/jtimon @kallewoof https://github.com/kallewoof @kristapsk https://github.com/kristapsk @niftynei https://github.com/niftynei @MarcoFalke https://github.com/MarcoFalke @TheBlueMatt https://github.com/TheBlueMatt @meshcollider https://github.com/meshcollider @miketwenty1 https://github.com/miketwenty1 @Michagogo https://github.com/Michagogo @midnightmagic https://github.com/midnightmagic @petertodd https://github.com/petertodd @TheCharlatan https://github.com/TheCharlatan @wtogami https://github.com/wtogami @willyko https://github.com/willyko to see if any of them have interest in doing Guix builds.
— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/26598#issuecomment-1337066475, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASHMNZJOAAG5C73Q46YBXLWLW5ADANCNFSM6AAAAAASONIKL4 . You are receiving this because you were mentioned.Message ID: @.***>
This has been superseded by adding a builder-keys/ directory in
guix.sigs, where the presence of keys, and validity of signatures
is checked. Preventing issues like missing keys or invalid signatures.
New (or exisiting) Guix builders can add their key in the next PR
they open adding attestations.
🐙 This pull request conflicts with the target branch and needs rebase.