sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] New Server


From: Jeffrey Johnson
Subject: Re: [Sks-devel] New Server
Date: Sat, 28 Apr 2012 11:41:14 -0400

On Apr 28, 2012, at 10:55 AM, Kristian Fiskerstrand wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 28.04.2012 16:45, Jeffrey Johnson wrote:
>> 
>> On Apr 28, 2012, at 10:16 AM, Kristian Fiskerstrand wrote:
>> 
>>>> 
>>>> Your remarks resemble my key servers. Can't be helped, sorry.
>>>> 
>>> 
>>> Aliases isn't necessarily a problem, at least, after the switch
>>> to using the reported Hostname of the SKS server. If there is
>>> enough need, I might consider creating a proper alias table, but
>>> I'd prefer not to have to :)
>>> 
>> 
>> Perfect: from this (and other remarks) and other comments your
>> definition of "proper FQDN" policy can be inferred (afaict):
>> 
>> The hostname reported in sksconf needs to be a "proper FQDN".
>> 
>> What hasn't been clear to me is that has an implicit restriction on
>> how membership files SHOULD be written using only hostnames that
>> match some other sksconf. That is the root of my confusion while
>> doing "unauthorized" log scraping and reconstruction.
> 
> I should probably be clearer on this, indeed - I'm referring purely to
> the Hostname: that is specified in sksconf and shows up in the status
> page.
> 

There's also someinconsitency with "proper FQDN"  in sks-keyservers.net.

Let me provide you with details in the current status display.

I have 2 "public" SKS servers in the sense these were the names sent
to other SKS operators for inclusion in the membership file:
        keys.rpm5.org
        keys.n3npq.net
Over time (and due to sloppy ad hoc sysadmin) the two active (i.e.
running and up-to-date and active here) other DNS entries
in your status pages are
        keys.rpm5.org -> keys.jbj.org
        keys.n3npq.net -> mashpee.jbj.org

You are also carrying an entry for an older VM instance of
        keys.n3npq.net -> keys.pmman.com
I have no idea (nor interest) where that DNS record points currently.

You are occasionally (not recently) picking up other *.jbj.org servers in the 
pool.
That's perfectly okay with me, but perhaps not what you/others want.

Note that the fault is mine, not yours, doing sloppy sysadmin without
understanding the implications imposed on membership entries used
in the pool. These days I tend to use IP addresses rather than DNS
names because of the chores of maintaining 3 DNS views accurately.

I also don't care about information "leakage" nor *.jbj.org pool inclusion per 
se,
though other SKS operators might. *shrug*

My servers are available, are maintained "best effort", and can be freely
used for whatever reasonable purpose as intended. YMMV depending
on other pool "quality" and "policy" metrics.

BTW: I've just added this configuration to @rpm5.org code headed for a MANDATORY
signature verification for all *.rpm packages over the summer:
        %_hkp_keyserver         hkp://pool.sks-keyservers.net

Translation:
        RPM will be retrieving needed pubkeys from the pool going "forward".
        
73 de Jeff



reply via email to

[Prev in Thread] Current Thread [Next in Thread]