Copy Current GPG Installation to Another Server

Doug Barton dougb at
Wed Mar 18 02:12:35 CET 2015

On 3/17/15 4:34 PM, Kristian Fiskerstrand wrote:
> On 03/17/2015 10:04 PM, Doug Barton wrote:
>> On 3/17/15 1:54 PM, Peter Lebbing wrote:
>>>>> -----Original Message-----
>> Assuming you get the package, the signature, and the fingerprint
>> from the same * resources, what does that buy you?
> Strictly speaking there could be multiple servers hosting the various
> resources and only one of which is compromised.

I conceded from the start that there are scenarios where Peter's threat 
model is valid. However they are overwhelmingly unlikely.

You also seem to be ignoring the bootstrapping problem of educating the 
new users on doing proper validity checking for fingerprints, keys, etc.

> It is also quite
> common to download the source from mirror rather than * directly

Yes, and mirrors, by definition, are copies of the original. So either 
they are all compromised (because the master is), or the subset of 
systems that get compromised will auto-correct at whatever interval they 
are set up to mirror the master.

So the scenario where "download the package and signature from one site 
and verify the fingerprint from another site provided by the same 
operator" is useful still falls into the "incredibly unlikely" category.

>> More extensive checking would be great, but would require a lot of
>> documentation to teach the users how to do it ... are you
>> volunteering to write it? :)
> Its included in every announcement[0]. Just a verification by
> cross-checking this information in various archives [1] mirroring the
> announcement reduce the likelihood of an active compromise, and is a
> far better to try to bootstrap a key validity in the absence of a
> direct key path.
> References:
> [0]
> [1]

The announcements are of no use to the user going to the FTP site to 
download a new package unless they happen to be on the mailing list. And 
in any case, the archives and mirror fall into the "same 
operator" trap described above.

The thing I'm trying to avoid here is adding complexity that does 
nothing but satisfy the OCD of experienced users who know the 
good/right/best way of doing things and add no real value to new users 
who are just trying to get started with the software.

If there were a comprehensive new-user guide that could explain all of 
this stuff that would be a valuable addition. But there isn't, and I'm 
not going to write one. So personally I'll settle for offering practical 
advice to folks at the level I think they're ready to deal with it. If 
you want to do more, then $DEITY bless you, I look forward to seeing 
your efforts.


More information about the Gnupg-users mailing list