I think a listing is sufficient. I just need to know which keys might be
used.
Btw, here's my use case:
ENV GPG_KEYS \
# 4096R/345AD05D 2015-01-20 Hans Wennborg <hans at chromium.org>
B6C8F98282B944E3B0D5C2530FC3042E345AD05D \
# 2048R/02119294 2014-05-06 Tom Stellard <tstellar at redhat.com>
11E521D646982372EB577A1F8F0871F202119294 \
# 2048R/BB5A0569 2013-12-24 Bill Wendling <void at llvm.org>
54E3BDE33185D9F69664D22455F5CD70BB5A0569 \
# 4096R/7BFB4EDA 2014-06-16 Brad King <brad.king at kitware.com>
CBA23971357C2E6590D9EFD3EC8FEF3A7BFB4EDA
RUN set -ex; \
for key in $GPG_KEYS; do \
gpg --keyserver pgp.key-server.io --recv-keys "$key"; \
done
RUN set -ex; \
curl -fSL https://cmake.org/files/v3.7/cmake-3.7.2-SHA-256.txt -o
cmake-3.7.2-SHA-256.txt; \
curl -fSL https://cmake.org/files/v3.7/cmake-3.7.2-SHA-256.txt.asc -o
cmake-3.7.2-SHA-256.txt.asc; \
curl -fSL https://cmake.org/files/v3.7/cmake-3.7.2-Linux-x86_64.tar.gz -o
cmake-3.7.2-Linux-x86_64.tar.gz; \
gpg --verify cmake-3.7.2-SHA-256.txt.asc; \
grep cmake-3.7.2-Linux-x86_64.tar.gz cmake-3.7.2-SHA-256.txt | sha256sum
--check; \
tar -xf cmake-3.7.2-Linux-x86_64.tar.gz -C /usr/local
--strip-components=1; \
rm cmake-3.7.2-Linux-x86_64.tar.gz
RUN set -ex; \
curl -fSL https://releases.llvm.org/4.0.1/llvm-4.0.1.src.tar.xz -o
llvm.src.tar.xz; \
curl -fSL https://releases.llvm.org/4.0.1/llvm-4.0.1.src.tar.xz.sig -o
llvm.src.tar.xz.sig; \
gpg --batch --verify llvm.src.tar.xz.sig llvm.src.tar.xz; \
...
On Thu, Aug 10, 2017 at 2:22 PM, Hans Wennborg <hans at chromium.org>
wrote:
> I suppose we could do this.
>
> Which do you think would be better, having a link together with each
> release (which we have for some), or just listing the most frequently
> used keys near the top?
>
> On Wed, Aug 9, 2017 at 8:57 PM, don hinton via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I see that some, but not all, releases provide a local link to the key
> used
> > to generate the signature files, which makes it difficult for a script
to
> > use them to verify the signatures.
> >
> > Gcc solves this problem by including the following on their mirrors
page
> > (https://gcc.gnu.org/mirrors.html):
> >
> > The archives there will be signed by one of the following GnuPG keys:
> >
> > 1024D/745C015A 1999-11-09 Gerald Pfeifer <gerald at pfeifer.com>
> > Key fingerprint = B215 C163 3BCA 0477 615F 1B35 A5B3 A004 745C 015A
> > 1024D/B75C61B8 2003-04-10 Mark Mitchell <mark at
codesourcery.com>
> > Key fingerprint = B3C4 2148 A44E 6983 B3E4 CC07 93FA 9B1A B75C 61B8
> > 1024D/902C9419 2004-12-06 Gabriel Dos Reis <gdr at acm.org>
> > Key fingerprint = 90AA 4704 69D3 965A 87A5 DCB4 94D0 3953 902C 9419
> > 1024D/F71EDF1C 2000-02-13 Joseph Samuel Myers <jsm at
polyomino.org.uk>
> > Key fingerprint = 80F9 8B2E 0DAB 6C82 81BD F541 A7C8 C3B2 F71E DF1C
> > 2048R/FC26A641 2005-09-13 Richard Guenther <richard.guenther at
gmail.com>
> > Key fingerprint = 7F74 F97C 1034 68EE 5D75 0B58 3AB0 0996 FC26 A641
> > 1024D/C3C45C06 2004-04-21 Jakub Jelinek <jakub at redhat.com>
> > Key fingerprint = 33C2 35A3 4C46 AA3F FB29 3709 A328 C3A2 C3C4 5C06
> >
> > Would it make sense to add something similar to our download page?
> >
> > thanks...
> > don
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170810/21f1de2e/attachment.html>