1 |
Mark Knecht posted on Wed, 06 Aug 2014 14:33:28 -0700 as excerpted: |
2 |
|
3 |
> OK, I've modified make.conf as such: |
4 |
> |
5 |
> FEATURES="buildpkg strict webrsync-gpg" |
6 |
> PORTAGE_GPG_DIR="/etc/portage/gpg" |
7 |
> |
8 |
> and created /etc/portage/gpg: |
9 |
|
10 |
> drwxr-xr-x 2 root root 4096 Jul 6 09:42 |
11 |
|
12 |
> eix-sync seems to be working but it may (or may not) be caught in some |
13 |
> loop where it just keeps looking for older data. I let it go until it |
14 |
> got back into July and then did a Ctrl-C: |
15 |
> |
16 |
> c2RAID6 portage # eix-sync -wa |
17 |
> * Running emerge-webrsync |
18 |
> Fetching most recent snapshot ... |
19 |
> Trying to retrieve 20140805 snapshot from http://gentoo.osuosl.org ... |
20 |
> Fetching file portage-20140805.tar.xz.md5sum ... |
21 |
> Fetching file portage-20140805.tar.xz.gpgsig ... |
22 |
> Fetching file portage-20140805.tar.xz ... |
23 |
> Checking digest ... |
24 |
> Checking signature ... |
25 |
> gpg: Signature made Tue Aug 5 17:55:23 2014 PDT using RSA key ID |
26 |
> C9189250 |
27 |
> gpg: Can't check signature: No public key |
28 |
> Fetching file [repeat in a loop with older dates] |
29 |
|
30 |
> QUESTIONS: |
31 |
> |
32 |
> 1) Is the 'No public key' message talking about me, or something at the |
33 |
> source? I haven't got any keys so maybe i need to generate one? |
34 |
|
35 |
It's saying you need to (separately) download the *GENTOO* key using some |
36 |
other method, and put it in the appropriate place so it can verify the |
37 |
signatures its finding. |
38 |
|
39 |
Note that while I've not used webrsync, for some years (until I switched |
40 |
from signed kernel tarball to git-cloned kernel) I ran a script that I |
41 |
wrote up myself, that downloaded the kernel tarball as well as its gpg- |
42 |
signatures, and gpg-verified the signature on the tarball before |
43 |
unpacking it and going ahead with reconfiguration and build. |
44 |
|
45 |
So I have a reasonable grasp of the general concepts -- good enough I |
46 |
could script it -- but I don't know the webrsync specifics. |
47 |
|
48 |
But that's definitely a missing separately downloaded public key, so it |
49 |
can't verify the signatures on the tarballs it's downloading, and is thus |
50 |
rejecting them. |
51 |
|
52 |
Of course in this case such a rejection is a good thing, since if it was |
53 |
acting as if nothing was wrong and simply trusting the tarball even when |
54 |
it couldn't verify the signature, it would be broken in security terms |
55 |
anyway! =:^) |
56 |
|
57 |
So that's what you'll need to do, presumably based on instructions you |
58 |
find for getting that key and putting it in the right spot so webrsync |
59 |
can access it. But unfortunately since I've not used it myself, I can't |
60 |
supply you those instructions. |
61 |
|
62 |
Or wait! Actually I can, as google says that's actually part of the |
63 |
gentoo handbook! =:^) (Watch the link-wrap and reassemble as necessary, |
64 |
I'm lazy today. The arch doesn't matter for this bit so x86/amd64, it's |
65 |
all the same.) |
66 |
|
67 |
https://www.gentoo.org/doc/en/handbook/handbook-x86.xml? |
68 |
part=2&chap=3#webrsync-gpg |
69 |
|
70 |
Based on the above, it seems you've created the gpg directory and set |
71 |
appropriate permissions, but either you haven't downloaded the keys as |
72 |
described in the link above, or perhaps you're missing the PORTAGE_GPG_DIR |
73 |
setting. |
74 |
|
75 |
> 2) Once I do get this working correctly it would make sense to me that I |
76 |
> need to delete all existing distfiles to ensure that anything on my |
77 |
> system actually came from this tarball. Is that correct? |
78 |
|
79 |
Not unless you're extremely paranoid, tho it wouldn't hurt anything, just |
80 |
mean you blew away your cache and have more downloading to do until you |
81 |
have it again. |
82 |
|
83 |
Once you're verifying the tarball, part of the tarball's signed and |
84 |
verified contents is going to be the distfile digests. Once they're |
85 |
coming from the tarball, you have a reasonable confidence that they |
86 |
haven't been tampered with, and given the multi-algorithm hashing, even |
87 |
if one algorithm was hacked and the file could be faked based on only it, |
88 |
the other hashes should catch the problem. |
89 |
|
90 |
Of course, once you're doing this, it's even MORE important not to simply |
91 |
redigest the occasional source or ebuild that comes up with an error due |
92 |
to a bad digest. For people not verifying things to do that is one |
93 |
thing, but once you're verifying, simply doing a redigest yourself on |
94 |
anything that comes up bad directly bypasses all that extra safety you're |
95 |
trying to give yourself. So if a distfile tarball comes up bad, go ahead |
96 |
and delete it and try again, but if it comes up bad repeatedly, don't |
97 |
just redigest it, either check for a bad-digest bug on that package and |
98 |
file one if necessary, or simply wait a day or two and try again, as the |
99 |
problem is generally caught and fixed by then. |
100 |
|
101 |
(I've seen rumors of people on the forums, etc, suggesting a redigest at |
102 |
any failure, and it always scares me. Those digests are there for a |
103 |
reason, and if they're failing, you better make **** sure you know it's a |
104 |
legitimate bug (say kde making a last minute change to the tarballs after |
105 |
release to the distros for testing, but before public release, as they do |
106 |
occasionally) before redigesting. And even then, if you can just wait a |
107 |
couple days it should normally work itself out, without you having to |
108 |
worry about it or take that additional risk.) |
109 |
|
110 |
-- |
111 |
Duncan - List replies preferred. No HTML msgs. |
112 |
"Every nonfree program has a lord, a master -- |
113 |
and if you use the program, he is your master." Richard Stallman |