[Top][All Lists]
[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
- Re: [Sks-devel] Reverse Proxy, (continued)
Re: [Sks-devel] New Server, Jeffrey Johnson, 2012/04/28
[Sks-devel] RFE for sks-keyservers.net (was Re: New Server), Jeffrey Johnson, 2012/04/28