Re: number of keys reported by hockeypuck

[Gunnar Wolf]

Gunnar Wolf dijo [Tue, Sep 14, 2021 at 10:51:25AM -0500]:
> Umh... My reasons to believe this are:
> (...)

I reduced the verbosity level from INFO to WARNING, and got the
following in my log after a (I'd say, failed) recon attempt:

Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: panic: sync: WaitGroup 
is reused before previous Wait has returned
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: goroutine 12101 
[running]:
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: 
sync.(*WaitGroup).Wait(0xc000152398)
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: 
/usr/lib/go-1.15/src/sync/waitgroup.go:132 +0xae
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: 
gopkg.in/hockeypuck/conflux.v2/recon.(*Peer).mutate.func1(0x0, 0xc000275500)
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: 
/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/peer.go:216 +0x39
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: 
gopkg.in/tomb%2ev2.(*Tomb).run(0xc000152368, 0xc98050)
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: 
/home/gwolf/packaging/src/gopkg.in/tomb.v2/tomb.go:153 +0x38
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: created by 
gopkg.in/tomb%2ev2.(*Tomb).Go
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: 
/home/gwolf/packaging/src/gopkg.in/tomb.v2/tomb.go:149 +0xbc
Sep 14 16:07:03 hkp.openpgpkeys.net systemd[1]: hockeypuck.service: Main 
process exited, code=exited, status=2/INVALIDARGUMENT
Sep 14 16:07:03 hkp.openpgpkeys.net systemd[1]: hockeypuck.service: Failed with 
result 'exit-code'.
Sep 14 16:07:03 hkp.openpgpkeys.net systemd[1]: hockeypuck.service: Consumed 
50.181s CPU time.
Sep 14 16:07:03 hkp.openpgpkeys.net systemd[1]: hockeypuck.service: Scheduled 
restart job, restart counter is at 80.


signature.asc
Description: PGP signature

Re: number of keys reported by hockeypuck

[Gunnar Wolf]

Andrew Gallagher dijo [Sun, Sep 12, 2021 at 11:19:41PM +0100]:
> > But it does not seem to enter my database. Just 30 minutes after the
> > log entries I pasted, my server recovered successfully(?) 7766 items
> > from the same peer.
> > 
> > So, any pointers on how to get this to work?
> 
> I don't see any reason to believe it *isn't* working. I can see regular
> successful sync with your server in the pgpkeys.eu logs.

Umh... My reasons to believe this are:

1. My server shows 4425272 and 1562088 new keys for the first two days
   it (successfully?) gossipped, but *0* updated keys. Right, this
   might mean it's just getting to know the world and has got no
   updates WRT the DB dump I started from, but I think it's quite
   unlikely

2. Most telling is the fact that the new/updated key count seems to
   progress (i.e. right now I have 9 and 362 respectively), but
   disappears (drops down to 0?) after some time.

3. I see a big differentce with my peers. As an example, I'm peering
   with pgpkeys.eu, and it reports:

   DayNew   Updated
   2021-09-08   1   46248
   2021-09-09   2   40641
   2021-09-10   6   36949
   2021-09-11   6   26264
   2021-09-12   6   42388
   2021-09-13   37  41187
   2021-09-14   3   23073

   It seems I'm missing all those updates (tens of thousands daily).

> Transient sync errors are to be expected, particularly when reconciling
> against single-threaded SKS peers. Also remember that there are a
> significant (if small) number of abusive keys floating around the
> dataset that Hockeypuck will refuse to import.

OK, it's good to learn that Hockeypuck refuses to import those keys,
so as long as there are SKS servers between my peers, there will
always be some "noise". I will go and try to learn about the filters
Hockeypuck informs to have.

> The number of real new keys entering the synchronising network has
> reduced to one every few days now that the pool DNS entries no longer
> resolve. Some hockeypuck servers report a large number of updated keys
> every day, but this is almost exclusively churn - I suspect it is due to
> inconsistent ordering of packets between different keyservers.

Quite possible. But the difference is huge. And the odds of it
reaching _zero_ for a full week smells very fishy :-(


signature.asc
Description: PGP signature

Re: number of keys reported by hockeypuck

[Gunnar Wolf]

Hello Andrew, list,

I hope I am not abusing the list to ask for Hockeypuck-related support.

Andrew Gallagher dijo [Tue, Sep 07, 2021 at 08:10:06PM +0100]:
> > My new hockypuck instance reports 0 keys, but when I go to the database 
> > directly
> > and query the number of keys I see 6 million+ keys.  Can anybody suggest 
> > what is
> > wrong ?
> 
> Hi, Skip.
> 
> It sounds like your ptree database has not been populated. After you
> restore the postgres database, you need to run `hockeypuck-pbuild` to
> generate the ptrees. After that it should return the correct number of
> keys (and sync correctly!).

I had the same issue as Skip, but with Andrew's help, I managed to get
my server (hkp.openpgpkeys.net, aliased as pgp.gwolf.org, as I
operated that keyserver in the past and there are some servers still
trying to sync with it) to start syncing last week. However, my
happiness lasted only for two days, as can be seen in the server's
statistics:

https://hkp.openpgpkeys.net/pks/lookup?op=stats

I got 4425272 new keys on 2021.09.02, 1562088 on 2021.09.03, and
nothing afterwards. Every now and then, a third row appears with
today's date, showing a number of updated keys, but it ends up
rejecting them. I have the following in my logs:

First of all, I see many lines simliar to the following in the logs:

time="2021-09-10T17:39:57Z" level=error msg="recon with 194.95.66.28:11370 
failed" 
error="[{/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/gossip.go:115:
 } {/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/peer.go:427: 
} {/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/peer.go:373: 
} {/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/peer.go:359: 
} 
{/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/messages.go:144:
 } {read tcp 132.248.241.96:41648->194.95.66.28:11370: read: connection reset 
by peer}]" label="gossip :11370"

Sometimes, though, a reconciliation attempt does start to progress,
and I see lines increasing the size of the recover set, such as the
following:

time="2021-09-08T16:09:56Z" level=info msg= POST="/pks/hashquery" 
duration=1.566869497s from="31.220.44.249:42062"
time="2021-09-08T16:09:56Z" level=info msg="ReconRqstPoly: solved" 
label="gossip :11370" localSet={17513954546661128035079817349538381151, 
49879024575748961585423554984045044319} 
remoteSet={261125229682694284340418712624697891935}
time="2021-09-08T16:09:56Z" level=info msg="recover set now 1 elements" 
label="gossip :11370"
time="2021-09-08T16:09:56Z" level=info msg="ReconRqstPoly: low MBar" 
label="gossip :11370"
time="2021-09-08T16:09:56Z" level=info msg="ReconRqstPoly: sending 
SyncFail" 
error="[{/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/gossip.go:258:
 bs=010101 leaf=false size=6134} 
{/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/decode.go:289: } {low 
MBar}]" label="gossip :11370"
time="2021-09-08T16:09:56Z" level=info msg="recover set now 1 elements" 
label="gossip :11370"
time="2021-09-08T16:09:56Z" level=info msg="ReconRqstPoly: low MBar" 
label="gossip :11370"
time="2021-09-08T16:09:56Z" level=info msg="ReconRqstPoly: sending 
SyncFail" 
error="[{/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/recon/gossip.go:258:
 bs=010110 leaf=false size=5954} 
{/home/gwolf/packaging/src/gopkg.in/hockeypuck/conflux.v2/decode.go:289: } {low 
MBar}]" label="gossip :11370"
time="2021-09-08T16:09:56Z" level=info msg="recover set now 1 elements" 
label="gossip :11370"
time="2021-09-08T16:09:56Z" level=info msg="ReconRqstPoly: low MBar" 
label="gossip :11370"

after which, the recover increases until several thousand elements, and seems 
to be successful:

time="2021-09-08T16:10:39Z" level=info msg=ReconRqstFull label="gossip 
:11370" localNeeds=1 remoteNeeds=0
time="2021-09-08T16:10:39Z" level=info msg="recover set now 4403 elements" 
label="gossip :11370"
time="2021-09-08T16:10:39Z" level=info msg="recover set now 4403 elements" 
label="gossip :11370"
time="2021-09-08T16:10:39Z" level=info msg="reconcilation done" 
label="gossip :11370"
time="2021-09-08T16:10:39Z" level=info msg="recovered 4403 items" 
label="serve :11370"
time="2021-09-08T16:10:39Z" level=info msg="waiting 36s for next gossip 
attempt" label="gossip :11370"

But it does not seem to enter my database. Just 30 minutes after the
log entries I pasted, my server recovered successfully(?) 7766 items
from the same peer.

So, any pointers on how to get this to work?

Thanks!

Re: No DNS records anymore - alternative ?

[Gunnar Wolf]

Andrew Gallagher dijo [Wed, Jul 21, 2021 at 01:10:33PM +0100]:
> On 20/07/2021 21:49, Andreas Puls wrote:
> > Do we have any Pool alternative yet, or shall we just "quit" it ?
> 
> Whether you want to quit it depends on what you're doing "it" for. :-)
> 
> There is currently no pool, although there has been some discussion over on
> the gnupg-devel list about restarting one. I'm skeptical of the utility of
> such a thing (see my earlier posts for why, I don't want to be a bore). But
> I hope that a synchronising network of keyservers can survive, and grow to
> include keys.openpgp.org, keyserver.ubuntu.com etc. - so IMO having a
> healthy community of keyserver operators is still valuable.

I understand the issues of a single point of contact regarding GDPR,
but am anyways worried about how to better serve users of the WoT
network. At the very least, an easy-to-find listing of keyservers to
choose from. I guess that information derived/simplified from what can
be currently found at sks-status.gwolf.org could be useful for this,
but distributed among operators to reduce the single-point-of-failure
issue.



signature.asc
Description: PGP signature

Re: shutdown of pgpkeys.co.uk and pgpkeys.uk

[Gunnar Wolf]

Wiktor Kwapisiewicz dijo [Wed, Jun 23, 2021 at 08:29:04AM +0200]:
> > (For full disclosure: I recently joined a PhD program, and my study
> > subject is how to keep the decentralized properties of the WoT network
> > while at the same time being able to counter the attacks we have seen
> > on it).
> 
> You may be interested in this Merge Request:
> https://gitlab.com/hagrid-keyserver/hagrid/-/merge_requests/176

Thanks a lot Wiktor! Yes, this is certainly interesting to me -- I
fear it falls very (too?) close to the proposal I wanted to make, so
I'll have to go back to the thinking room, but after all I'm only at
the very early stages of my program ☺

> In short this is about adding Attested Certifications support to
> Hagrid. Attested Certifications are third-party signatures that are
> "approved" by the key owner. This makes it easy to distinguish real
> third-party signatures that the key owner cares for from flooded
> signatures.
> 
> Sadly they are not yet supported in GnuPG but adding them to Hagrid may
> be a good way to solve the "chicken and egg" problem with this feature.
> 
> For technical bits see rfc4880bis section 5.2.1: "0x16  Attested Key 
> Signature"
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.1

Thank you very much for the pointers.

Re: shutdown of pgpkeys.co.uk and pgpkeys.uk

[Gunnar Wolf]

Andrew Gallagher dijo [Wed, Jun 23, 2021 at 10:12:14AM +0100]:
> Making sks-keyservers.net point to somewhere that still works has merit. I
> would be cautious about taking it on though, as whoever owns it will inherit
> Kristian's GDPR problems. You would need to be prepared to respond to RTBF
> requests in a timely fashion - although this applies to all keyserver
> operators, the owner of sks-keyservers.net will naturally get the highest
> number of requests.
> 
> So please, if anyone is considering claiming it, don't run SKS on it or you
> will find yourself unable to comply with GDPR. And I would strongly advise
> against running a new pool - doing so effectively claims responsibility for
> other people's servers outside your control.

Well, for people who have been running SKS lately -- Is dealing with
GDPR requests something you have to deal with often on an ongoing
basis? I cannot answer, as I shut down my server about two years ago
(and neither my server nor myself are in Europe).

Personally, I am willing to put my resources into maintaining a
working decentralized keyserver network; of course, I am not
_currently_ running a keyserver (that will probably change within the
next week or two), and it won't do much if I'm the only one doing
so. But, in order to rebuild a network able to withstand the migration
to the 21st century... we must be willing not to kill the network to
begin with!

> That said, I think sks-status.gwolf.org is great, and deserves our support.
> I notice that it is currently failing, perhaps because the URL that you were
> using as your initial node is no longer available? Feel free to use
> pgpkeys.eu as the initial node instead.

Of course, thanks for reminding me about it! I am adopting pgpkeys.eu
as the starting point.

Small catch -- About a month ago, you answered my previous mail
pointing out my code didn't correctly parse Hockeypuck's status
(because, yes, it uses a different DOM). I had to take the opportunity
to update my scripts to be able to deal with this difference. So,
win-win :-D

I have not yet addressed all the points you pointed out in that mail,
but at least it's working again.


signature.asc
Description: PGP signature

Re: shutdown of pgpkeys.co.uk and pgpkeys.uk

[Gunnar Wolf]

Andreas Puls dijo [Tue, Jun 22, 2021 at 09:32:50PM +0200]:
> A new domain must be established into the "world". Maybe Kristian would
> transfer the domain / software to one of us. So we could run it on our own.

I agree, having a well established name behind helps. Furthermore,
sks-keyservers.net is part of countless configuration
files. Inheriting the name for a new pool/network would be great to
help users from hitting an unexpected breakage.

On the other hand, sks-keyservers.net denotes a specific
implementation -- One we are trying to migrate away from. So, in case
Kristian agrees to transfer the domain, my opinion is that it should
be used basically to point at a new name.

I suggest (and have just bought) «openpgpkeys.net». Of course, I am
putting it at the service of the current keyserver operators' and
users' community; I hope it can be of service.



signature.asc
Description: PGP signature

Re: shutdown of pgpkeys.co.uk and pgpkeys.uk

[Gunnar Wolf]

Andreas Puls dijo [Tue, Jun 22, 2021 at 09:32:50PM +0200]:
> Hey all,
> 
> as far as i know Hagrid doesn't support "peering" like SKS or
> Hockeypuck. Regarding the latter one I'm running 3 Keyserver with it.
> It's working very well and also support key blacklisting and ignores
> huge subkeys. A little downside is only the "heavy" read / write
> consumption compared to sks.
> 
> A new domain must be established into the "world". Maybe Kristian would
> transfer the domain / software to one of us. So we could run it on our own.

Hagrid is IMO a no-go: in order to solve the greatest shortcomings of
SKS, it drops one of OpenPGP's greatest features: the Web of
Trust. Yes, for many, the WoT is an anachronistic holdout... But many
among us still believe in it.

I have been pondering to set up a hockeypuck keyserver to get
acquinted with it, as I will be doing some work in the next couple of
years.

(For full disclosure: I recently joined a PhD program, and my study
subject is how to keep the decentralized properties of the WoT network
while at the same time being able to counter the attacks we have seen
on it).

Re: Livelihood statistics of the SKS keyserver network

[Gunnar Wolf]

Andrew Gallagher dijo [Thu, May 13, 2021 at 12:34:20PM +0100]:
> > The first thing to understand what I'm plotting are the many graphs
> > that are _not_ present in the summary page: Scroll down to the table
> > that has many dates. Clicking on any such date will show you a walk of
> > gossiping servers, starting from basically a random server in the
> > network (I pick up whatever answers to pool.sks-keyservers.net -
> > That's why you will see many entries with zero or very few nodes: it
> > means I was unlucky with the resolution for a given day). The (quite
> > ugly and ad-hoc) source for those graphs is at:
> > 
> >  http://sks-status.gwolf.org/walk_sks.rb
> 
> It might be worth exploring whether starting with more than one initial node
> would help your luck - usually ha.pool.sks-keyservers.net, na.pool, eu.pool
> resolve to different servers and at least one of those should be in good
> shape at any given time.

I guess it would! It is... an improvement I'll save for later,
though. I don't want to put too much (more) work into it, as I only
get bad connections' "noise" in about 1/10 of the tries. But yes, that
would surely help!

> > Do note that at the beginning I sampled the network much more often
> > (hourly). I decided this was too much, and since June 2019, am now
> > walking the network only every four hours. I do hope nobody sees this
> > as excessive!
> 
> Given that fastly and happy-eyeballs spider the network several times a
> minute, I can't imagine anyone would have a problem with your hourly
> extravagance. :-D

That's very good to know :-)

> > This shows the very large drop the SKS network had in mid-2019, as
> > well as its behavior since then. I am happy, even hopeful, to note
> > that it seems the network hit reliability minimums between October
> > 2020 and February 2021, but it seems there is a slight trend for
> > improvement, at least back to the late-2019 levels.
> 
> I think we can attribute some of that to Casey's work on Hockeypuck which
> has downgraded the poison key issue from a killer to an annoyance.

Great! Well, it's very good to have a data point for this.

> > Please do tell me if this data sounds interesting, and if you can
> > thing of anything to improve on what I'm doing. Of course, I cannot
> > apply any changes  to already-collected data, but there are surely
> > many other things that can be considered.
> 
> This is very interesting work, thank you. I find the connectivity graphs
> hard to make sense of though as the nodes tend to be drawn on top of each
> other. A quick google hasn't thrown up any answers but I'm sure there's a
> way to address this by imposing some minimum separation between nodes. The
> graph browser we include in our software in $WORK has the ability to do
> this, but I need to check the details before recommending it, as I'm not
> sure if it has a noninteractive mode.

Right. Well, I'm now also producing links to the source Graphviz
files, it might be easier for you to produce something easier to
view. 

> Some simple changes that I would otherwise suggest:
> 
> 1. produce a connectivity graph with only working nodes

Added, as "Success" graph.

> 2. ignore localhost and private IPs, they will never work :-)

Of course. But still, it documents a given server works in a clustered
way. Of course they will fail, but who cares? ;-

> 3. should it not default to port 11371 and fall back to 80?
> 4. don't plot *.pool.sks-keyservers.net in the graph

Right... I could add this bit later on, but then again, it does not
clutter the graph much. AFAICT, It is only a single, starting node,
and no nodes ever point back to it, right?

Erm, no, _not_ matching reality. There are several servers as a
destination...

> Some more complex issues:
> 
> It seems that your Hockeypuck status parsing is broken, as a significant
> number of Hockeypuck nodes are listed consistently as Nil. It's probably due
> to assumptions you're making about the DOM in Hpricot. Thankfully,
> Hockeypuck emits a JSON stats page at 'pks/lookup?op=stats&options=mr' . If
> you get Nil from Hpricot, maybe you could fall back to the JSON? Beware that
> if you request the JSON page from SKS it will give you an HTML stats page
> regardless.
>
> Also, the peers of some Hockeypuck nodes are throwing InvalidURIError - I
> suspect this is because of an inconsistency between SKS and Hockeypuck in
> how peers are reported - SKS says "host port", while Hockeypuck by default
> uses "host:port", but beware that many Hockeypuck operators have changed
> this back to SKS format so that the pool spider can parse the peer tree.
>
> Unfortunately, it's not as simple as splitting on /(\s+|:)/ as this will
> bork on ipv6 addresses. I'd suggest something like the following:
> 
>   host, port = server.split(/\s+/)
>   if port == ''
> host, port = host.split(/:/)
>   end

Ooo! Important and interesting. I have to look into how to deal
with it, specially if the number of Hockeypuck servers grows

Re: Livelihood statistics of the SKS keyserver network

[Gunnar Wolf]

Andrew Gallagher dijo [Thu, May 13, 2021 at 01:36:34PM +0100]:
> On 13/05/2021 12:34, Andrew Gallagher wrote:
> > Some simple changes that I would otherwise suggest:
> 
> Oh, one more thing
> 
> The yellow font in the Unreachable column is hard to read. :-)

At least that was easy to fix ;-)


signature.asc
Description: PGP signature

Re: Livelihood statistics of the SKS keyserver network

[Gunnar Wolf]

Hello Gabor,

Gabor Kiss dijo [Thu, May 13, 2021 at 06:38:49AM +0200]:
> > thing of anything to improve on what I'm doing. Of course, I cannot
> > apply any changes  to already-collected data, but there are surely
> > many other things that can be considered.
> 
> > Do note that at the beginning I sampled the network much more often
> > (hourly). I decided this was too much, and since June 2019, am now
> > walking the network only every four hours. I do hope nobody sees this
> > as excessive!
> 
> Okay, but it would be useful if you could standardize the graphs somehow.
> I.e. try to PLOT successful_connections per time_interval.

I don't know if I understood this correctly. As I said, I changed the
polling frequency after a couple of months; I am sure this would skew
the results.

My first plots had one column for each sample. What I'm doing now
-precisely, in order to normalize the plot- is to "lump together" all
of the plots for a given day into the same column. Thus, the generated
plot respects and properly represents time (skipping a day here or
there, as there might be some glitches in my data acquisition), but
mostly in an uniform way.

(...or... Did I completely fail to understand you?)

Livelihood statistics of the SKS keyserver network

[Gunnar Wolf]

Hi,

I have not been active for a long time in this list. I recently
got started on a project that will bring me back to the SKS sphere,
hopefully to help address the crisis in the keyserver network. But
it's too early to get into that.

What I wanted to bring to you all is a work I started doing over two
years ago, then completely forgot about it... And now, looks like an
interesting point from where to start understanding what the SKS
network looks like - Even, possibly, to help try to address its future.

If you are interested, please visit:

http://sks-status.gwolf.org/

The first thing to understand what I'm plotting are the many graphs
that are _not_ present in the summary page: Scroll down to the table
that has many dates. Clicking on any such date will show you a walk of
gossiping servers, starting from basically a random server in the
network (I pick up whatever answers to pool.sks-keyservers.net -
That's why you will see many entries with zero or very few nodes: it
means I was unlucky with the resolution for a given day). The (quite
ugly and ad-hoc) source for those graphs is at:

http://sks-status.gwolf.org/walk_sks.rb

Do note that at the beginning I sampled the network much more often
(hourly). I decided this was too much, and since June 2019, am now
walking the network only every four hours. I do hope nobody sees this
as excessive!

I am also plotting a single aggregate from all those data points: The
three graphs you will see at the top of the page, as well as the page
itself, are generated by:

http://sks-status.gwolf.org/mkindex.rb

This shows the very large drop the SKS network had in mid-2019, as
well as its behavior since then. I am happy, even hopeful, to note
that it seems the network hit reliability minimums between October
2020 and February 2021, but it seems there is a slight trend for
improvement, at least back to the late-2019 levels.

Please do tell me if this data sounds interesting, and if you can
thing of anything to improve on what I'm doing. Of course, I cannot
apply any changes  to already-collected data, but there are surely
many other things that can be considered.

Greetings,


signature.asc
Description: PGP signature

[Sks-devel] Shutting down pgp.gwolf.org

[Gunnar Wolf]

Hello,

I am shutting down my sks server. I have been part of this network for
a couple of years, and have grown used to SKS' oddities and
fragility. However, this year this is the third time the database gets
corrupted. Restoring from dumps repeatedly leads SKS to Segmentation
fault. And... Well, the reality stands - SKS as it is feels very much
like a relic from other times, unable to cope with an
ever-more-hostile network.

I will be explicitly reaching out to the peers I have on my membership
file.

Thanks for all the fish,

   - Gunnar Wolf


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Quick and dirty test

[Gunnar Wolf]

Todd Fleisher dijo [Mon, Feb 11, 2019 at 04:23:26PM -0800]:
> That one does load, but it’s really just a series of directories
> being cataloged. Once I stumbled across an SVG file, I find the way
> the data is visualized to be very difficult to digest
> (e.g. 
> http://sks-status.gwolf.org/20190123-182818/walk_sks_20190123-182818.dot.svg
> )

Right - as I said, I currently have only a preliminary stupid set of
dumps on my machine. I do intend to do something more from it... but
have not had time to do so :-(

> I haven’t run it in a while, but https://fleetstreetops.com/gossip/
>  might be of interest to
> you. It’s based off the code found @
> https://gist.github.com/diafygi/3f344c22f8a37a7b2151
> 

Very cool visualization, thanks!

It is quite similar to what I have, and no doubt, clearer to
understand and follow. I have some extra information which I want to
play with, which is including the unresponsive servers (plus, if I
could gather it, the reason why they are unresponsive). Also, given
I'm taking the snapshots basically as a time series, I will be able to
present some sort of evolution / trends.

But, right now, you are right: I only have a sh!tload of unusable data
presenting not-exactly-useless-but-far-from-good SVGs.


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Excessive use of /var/lib/sks/DB/log.*

[Gunnar Wolf]

Hey dkg!

> If you're using a debian system, please compare
> /usr/share/doc/sks/sampleConfig/DB_CONFIG with
> /var/lib/sks/DB/DB_CONFIG -- if your files differ, i'd be happy to help
> you figure out whether the problematic behavior you're seeing could be
> attributable to those differences.
> 
> If they don't differ (if you're seeing the problematic behavior using
> the sample DB_CONFIG, and *especially* if you fix your problem by
> deviating from the shipped sample), i'd like to know that too.

With hindsight, that was my mistake - When I rebuilt my server
about a month ago (after a DB corruption), I decided to keep my
installation and just delete /var/lib/sks/DB/*, rebuilding from
dumps. Of course, I blew the DB_CONFIG (which IMO has no business
there!)

In fact... I think that The Debian Way™ would be to have it in
/etc/sks, with a message on top clearly stating it should be linked
from /var/lib/sks/DB (as we Debian people are often too lazy to look
up configuration details in our software and expect everything to be
in /etc) 😉


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Quick and dirty test

[Gunnar Wolf]

Todd Fleisher dijo [Wed, Feb 06, 2019 at 08:24:38PM -0800]:
> FYI - that site generates an untrusted ssl certificate warning and
> after acknowledging that I get an error that the site couldn't be
> found on dreamboat.

You are right, I will now check with Dreamhost why this is
happening. Try the same URL, but without SSL:

http://sks-status.gwolf.org/

I will soon add some more explanation, the source to my program and
more.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Quick and dirty test

[Gunnar Wolf]

Kiss Gabor (Bitman) dijo [Tue, Jan 29, 2019 at 07:56:32PM +0100]:
> Hi folks,
> 
> It is funny but one of my peer partners did not notice that his server
> is dead since a few months. :-)
> 
> So I just show anyone who is interested in it how a simple but effective
> cron job warns me if my server is not OK:
> 
> 42 5-8,15-20 * * *   test "$(curl -s 
> https://sks-keyservers.net/status/ks-status-json.php?server=keys.niif.hu | jq 
> '[.IPv6, .Port80, .Last_status]' | tee /tmp/sksstatus | md5sum)" = 
> 'f2a95d496447b4bd81314f4a550a247c  -' || ( echo 'Something went 
> wrong:\\nhttps://sks-keyservers.net/status/' ; cat /tmp/sksstatus)
> 
> Of course hostname and actual MD5 sum value must be tailored
> according to checked fields of JSON output from curl.

FWIW, I have been playing with some data that might be connectable to
this. I did not *yet* intend to go public with this information, but
it might help use cases as yours:

https://sks-status.gwolf.org/

Give me a couple of days and I'll share more complete information. In
the mean time, you can see where your server is as part of the mesh :-]

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Excessive use of /var/lib/sks/DB/log.*

[Gunnar Wolf]

Hello,

Since a couple of days ago, I have noticed an incredible growth in
space usage (so much it has killed my server twice, hitting partition
limits). Since February 3rd, I have over 4000 files with binary-only
contents (could find no meaningful information in them) called
/var/lib/sks/DB/log. - I have just
checked, and it *seems* removing them causes no ill effects.

But... TTBOMK, I have not modified anything in my configuration. I
removed them knowing I might be doing something stupid, in the know
that BDB does not like external processes touching its turf, and was
happy not to lose my keyserver - but I was ready to rebuild it.

I haven't been monitoring this list as much as I should. Is there
anything I should be on the look for? I removed files dated ≤ Feb 3,
so there is still a lot of information if somebody wants to debug the
issue.

Should I just point a "logrotate" or such to the directory? What did I
do before that I'm not correctly doing now?

Thanks!



signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Very incomplete dumps in keyserver.mattrude.com

[Gunnar Wolf]

Hi,

While rebuilding my server, I downloaded the dumps available from the
first option listed¹. Not only is mattrude the first listed option,
but it seems to be the most up-to-date one.

¹ https://bitbucket.org/skskeyserver/sks-keyserver/wiki/KeydumpSources

Download bandwidth is terrible, but that would be OK (I just left the
server pulling overnight)... Were it not that it's serving a very
incomplete keyring (only a couple hundred megabytes).

So, please - either fix the dumps, or take them off, as they can be a
source of confusion (specially for new admins who don't yet know well
what to expect!)

Thanks,


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] pgp.gwolf.org back online soonish)

[Gunnar Wolf]

Gunnar Wolf dijo [Fri, Dec 14, 2018 at 02:58:59PM -0600]:
> Hi,
> 
> I am on vacation, and my SKS keyserver (pgp.gwolf.org) has stopped
> syncing since three days ago. When restarting sks-recon, my logs say:
> (...)

I have downloaded an up-to-date key dump (5400426 keys) and started my
system again; I kept my old membership file, so it will soon start
peering with the known peers.

Greetings, and happy new year!


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] pgp.gwolf.org temporarily not syncing (will rebuild soonish)

[Gunnar Wolf]

Hi,

I am on vacation, and my SKS keyserver (pgp.gwolf.org) has stopped
syncing since three days ago. When restarting sks-recon, my logs say:

Dec 14 14:50:11 pgp systemd[1]: sks-recon.service: Main process exited, 
code=exited, status=2/INVALIDARGUMENT
Dec 14 14:50:11 pgp systemd[1]: sks-recon.service: Unit entered failed state.
Dec 14 14:50:11 pgp systemd[1]: sks-recon.service: Failed with result 
'exit-code'.

I will download a new snapshot and get my system back online soonish,
but it will take me a couple of days to do so.


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] pgp.gwolf.org back online!

[Gunnar Wolf]

Gunnar Wolf dijo [Wed, Apr 25, 2018 at 10:18:36PM -0500]:
> Hi guys,
> 
> I am doing the migration of pgp.gwolf.org to a better machine which
> should give better stability and response times, but after moving my
> files, I got the dreaded exception:
> (...)
> So, my server will be down for some hours, some days tops.

So it was quicker than expected - I had a corrupted (truncated?) file
copied from the old to the new server. Did the copy again, and it is
now running smoothly again. Hopefully, better than before!

http://pgp.gwolf.org/pks/lookup?op=stats



signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] pgp.gwolf.org temporarily offline

[Gunnar Wolf]

Hi guys,

I am doing the migration of pgp.gwolf.org to a better machine which
should give better stability and response times, but after moving my
files, I got the dreaded exception:

2018-04-25 22:16:18 Opening KeyDB database
2018-04-25 22:16:18 Shutting down database
Fatal error: exception Keydb.Unsafe.No_db
2018-04-25 22:16:18 DB closed

So, I will look into it tomorrow when I'm back at work. Worst case, I
will rebuild the database (although I have it still working in its
prior location, but moving a ~20GB file even via rsync is... quite
painful).

So, my server will be down for some hours, some days tops.

Greetings!


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] unplanified downtime for sks.neel.ch

[Gunnar Wolf]

Jeremy T. Bouse dijo [Fri, Feb 09, 2018 at 02:57:41PM -0500]:
> > Hi everybody,
> >
> >
> > I moved my database to a new disk 2 days ago. Since that, my database
> > is corrupted and I have to rebuild my database from a fresh dump.
> >
> > I'll do it in the beginning of the next week as my wedding is tomorrow :)
> >
> > Please stay peer. I'll be back soon.
> >
> 
> Wise man... Morning of my wedding 12 years ago I was in the resort
> business center on a computer fixing a clients server... We still
> haven't taken a honeymoon, but I'm still married so must have done
> something right :)
> 
> Oh, and congratulations!

If it's not broke, don't fix it! Avoid anything that sounds like a
honeymoon, you should be fine.

Congratulations to you both :)

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Hiding revoked keys in generated webpages

[Gunnar Wolf]

Hi,

I know this is most likely undoable (unless I do some ugly
post-parsing to the HTML before sending it to the user), but I'll ask
anyway: I just sent another message "motivated" by the Evil32
keys. This one follows the same motivator.

Users of SKS are generally not interested in revoked keys. I would
like to have an option for hiding (or at least styling — Both could be
achieved by CSS) revoked keys from the listing. Unfortunately, the
listing is not generated from a template (as the index is), but
hardwired in the source, in htmlTemplates.ml

Now, speaking as a complete OCaml non-user, would the developers be
interested in me patching this file to generate a more CSS-friendly
output? Or is there any other way to achieve what I'm looking for?

Thanks,


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Long keyids (64-bit) instead of short (32-bit)?

[Gunnar Wolf]

Hi,

When queried for a key, SKS answers with just the short keyid — Just
32 bits. In my case, just "C1DB921F". We have already been "attacked"
(each of us will say whether it's a true attack or just an academic
excercise) by the Evil32 keyring.

Even more, as keys are presented in reverse creation time order,
naturally, Evil32 keys are always presented before the keys they
"cloned". Fortunately, yes, they have all been revoked.

Anyway — I was looking for a way to make SKS present 64-bit long
keyids (say, 673A03E4C1DB921F) instead of only 32-bit ones — Not only
for the two keys to be clearly different, but to help get our users to
change their mindset and identify long keyids as the default. I know
that is still not optimal and that there is a long discussion in that
regard, but it is clearly better than an easily forgeable 32-bit ID.

Any ideas on how to do this? Is it a configurable option even (or
should we expect this change only for a new release)?

Thanks!


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Advertising temporary disconnections?

[Gunnar Wolf]

Travis Megee dijo [Wed, Jan 11, 2017 at 08:33:17AM -0600]:
> I followed Alain's tip and configured UptimeRobot many moons ago.
> 
> http://lists.nongnu.org/archive/html/sks-devel/2016-06/msg00067.html

Sweet! Added it myself as well.

FWIW, thanks to all for your answers to my head-scratching!


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Advertising temporary disconnections?

[Gunnar Wolf]

Hi,

I have seen several messages lately on this list regarding temporary
(i.e. a day or two, AFAICT) server disconnections.

Every now and then, I get such a disconnect. My SKS server runs as a
container in my desktop computer, so hardware changes or power outages
do impact it more than what would be in a data center. But given that
telling people, "oh, I am recompiling my kernel and will reboot soon"
(a bit of an exaggeration, I know) means that either they won't act on
it, or that they will need to manually disable/re-enable my server in
their membership files... I never felt the need to say publicly.

Now, what would the general feeling be on this? Do we expect
privately-run SKS servers to have a four-nines, five-nines or such
uptime?

Thanks for sharing your thoughts.


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] keyserver.globale-gruppe.de is gone! / two new Keyserver / Update Membership file

[Gunnar Wolf]

Ramón Goeden dijo [Mon, Nov 28, 2016 at 03:02:03PM +0100]:
> Dear keyserver operators,
> my keyserver "keyserver.globale-gruppe.de" is gone. (Shutdown 31.10.2016) 
> Please de-peer the server!
> 
> BUT:
> I am running two new keyserver and would like to peer with other servers. 
> Please add me to your 'membership':
> 
> key1.dock23.de  11370 # Ramón Goeden  0xb7c51fd6
> key2.dock23.de  11370 # Ramón Goeden  0xb7c51fd6

Done. In case you want to add mine as well:

pgp.gwolf.org 11370 # Gunnar Wolf  0x673A03E4C1DB921F

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] SKS and containers

[Gunnar Wolf]

Jeremy T. Bouse dijo [Fri, Nov 18, 2016 at 02:29:12PM -0500]:
> I'm just curious if anyone has looked at running SKS within
> containers using Docker? I've seen a couple images on the Docker hub
> that appear to be based on Alpine Linux but was curious if anyone on
> here had attempted.

Not using Docker, but using its main underlying technology — my server
has always been a Debian system under LXC. Why?


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] peer request for pgp.uplinklabs.net

[Gunnar Wolf]

Andrew Gallagher dijo [Wed, Aug 31, 2016 at 10:14:01AM +0100]:
> I'm sceptical of the utility of ECC keys personally. They were first
> proposed as a way of reducing work and storage space (because the
> space of usable ECC keys is more compact than the sparsely
> distributed RSA primes). But they've taken so long to catch on that
> technology advancement has made their original justification largely
> irrelevant (the only exception to my knowledge being DNSSEC, where
> signature length restrictions are still important). And because the
> ECC keyspace is more efficiently packed, it is theoretically *more*
> susceptible to quantum attacks.

I'm far from a worthy crypto geek myself, but still — Storage space is
not the decisive issue; storing a million 4096-bit keys is only an
order of magnitude more than storing a million 256-bit keys (the same
proportion would naturally apply for a single key), and information
appended to the keys themselves (such as photo attributes and the
signatures that constitute the web of trust) make the difference quite
unnoticeable.

What is really a difference is the arithmetic operations upon which
they are based: Encryption and decryption under RSA are based on long
series of multiplications (or rather, huge exponentiation). Under ECC,
the operations are "just" series of additions. Adding is way cheaper
for a computer than multiplying, so your hardware will be able to
perform many, many more cryptographic operations with ECC than with
RSA.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached

[Gunnar Wolf]

Kristian Fiskerstrand dijo [Sat, Jun 04, 2016 at 01:16:16AM +0200]:
> > For the full version, please read my post:
> > 
> > http://gwolf.org/node/4070
> 
> This doesn't seem to reference the [evil32] keyring that seems to have
> been [included in the public network], btw. Nothing new there and
> irrelevant from a security perspective.

Yes, I saw that, and was intrigued not to find any suspicious matching
keys in the public network. I guess I didn't know how to look — Do you
have an example of keys coming from evil32?



___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached

[Gunnar Wolf]

Hi all,

For the full version, please read my post:

http://gwolf.org/node/4070

In short: In Debian, we found two keys sharing the «9F6C6333» short
ID, sporting the same name in them, but one of them is *not*
recognized by the supposed owner. Not only that, this key is signed by
three keys (not (yet?) uploaded to the global keyring) B29B232A,
F2C850CA and 789038F2 — Those are also the three short IDs for the
keys signing the legitimate key.

There are several tools relying on this (now very) weak 32-bit scheme;
the first such tool we found was precisely the «PGP pathfinder & key
statistics» service, which fails badly: Even specifying the full
fingerprints, I do get three (absolutely fake!) trust path into the
impostor:


http://pgp.cs.uu.nl/mk_path.cgi?FROM=AB41C1C68AFD668CA045EBF8673A03E4C1DB921F&TO=88BB08F633073D7129383EE71EA37A0C9F6C6333&PATHS=trust+paths

And the main reason I am writing this mail: SKS listings all show this
32-bit ID only. It does differentiate when keys collide on their short
keyids, but it promotes users using a weak representation; IMO we
should change SKS to show either long keyids or the full fingerprint.

Greetings,

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Oh, Jeeez...!

[Gunnar Wolf]

Andrew Gallagher dijo [Fri, May 27, 2016 at 04:24:33PM +0100]:
> On 27/05/16 15:19, Daniel Kahn Gillmor wrote:
> >  we have to ask the question of who a PoW scheme
> > protects.  It basically privileges those who have access to more compute
> > power, in an attempt to defend the network against malicious flooders.
> 
> PoW is a demonstration that you're willing to waste precious resources
> performing a calculation of no conceivable utility. It's the IT
> equivalent of lighting a cigar with a hundred dollar bill.

Ah, but it looks so elegant!

/me ducks

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seemingly corrupted DB, not syncing

[Gunnar Wolf]

Arnold dijo [Fri, Aug 07, 2015 at 12:16:32AM +0200]:
> > OK, this *seems* to have worked: After removing and creating a new,
> > *empty* /var/lib/sks/PTree directory, I started sks,
> 
> You did run something like
> $ if ! /usr/sbin/sks pbuild -cache 20 -ptree_cache 70; then echo "fail"; else 
> echo
> "OK"; fi; tail /var/log/sks/pbuild.log
> 
> to rebuild the PTree database, did you? I would be surprised if it works 
> without
> (but it might just as well do :-) ).

I tried, first, to no avail. I just did a 'rm -r PTree;mkdir PTree; 
chown...;chmod...'
as everything was lost already, and it worked :-)

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seemingly corrupted DB, not syncing

[Gunnar Wolf]

Daniel Kahn Gillmor dijo [Thu, Aug 06, 2015 at 03:29:05PM -0400]:
> On Thu 2015-08-06 12:03:28 -0400, Gunnar Wolf wrote:
> > Gunnar Wolf dijo [Thu, Aug 06, 2015 at 10:50:59AM -0500]:
> >> OK, this *seems* to have worked: After removing and creating a new,
> >> empty /var/lib/sks/PTree directory, I started sks, and am getting
> >> several such log messages:
> >
> > Umh, spoke too fast:
> >
> > 2015-08-06 10:56:46  error in callback.: End_of_file
> > 2015-08-06 10:56:46  error in callback.: End_of_file
> > 2015-08-06 10:56:46  error in callback.: End_of_file
> > 2015-08-06 10:57:45  error in callback.: 
> > Sys_error("Connection reset by peer")
> 
> fwiw, the above is usually just one of your sks peers (or the netwokr
> between you) being flakey.  It's not a symptom of a failed sks
> installation.

Right. I gave it some time while I was working on other stuff, and it
synced correctly. I have an up-to-date SKS server again! \o/

> > Ok, one more 'service sks restart', and found that:
> >
> > 2015-08-06 10:59:49 Malformed entry  EF5
> 
> This i've never seen before, and have no idea what it represents.

/me silently crosses fingers...

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seemingly corrupted DB, not syncing

[Gunnar Wolf]

Gunnar Wolf dijo [Thu, Aug 06, 2015 at 10:50:59AM -0500]:
> OK, this *seems* to have worked: After removing and creating a new,
> empty /var/lib/sks/PTree directory, I started sks, and am getting
> several such log messages:

Umh, spoke too fast:

2015-08-06 10:56:46  error in callback.: End_of_file
2015-08-06 10:56:46  error in callback.: End_of_file
2015-08-06 10:56:46  error in callback.: End_of_file
2015-08-06 10:57:45  error in callback.: Sys_error("Connection 
reset by peer")

Ok, one more 'service sks restart', and found that:

2015-08-06 10:59:49 Malformed entry  EF5

So... Without further ado, I'll stop wasting time and fetch a new dump :-P

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seemingly corrupted DB, not syncing

[Gunnar Wolf]

Daniel Kahn Gillmor dijo [Wed, Aug 05, 2015 at 07:22:26PM -0400]:
> > So... In your experience, what should be done? Is my best bet to just
> > drop my DB and download a set of dumps again?
> 
> You might be able to just drop your PTree (not the DB) and have sks
> rebuild it, without needing a new set of dumps.  I'm sorry to not have
> any more sophisticated suggestions.  bdb's failure modes continue to
> perplex me. :/

OK, this *seems* to have worked: After removing and creating a new,
empty /var/lib/sks/PTree directory, I started sks, and am getting
several such log messages:

==> /var/log/sks/db.log <==
2015-08-06 10:49:16 Sending LogResp size 5000

==> /var/log/sks/recon.log <==
2015-08-06 10:49:16 Added 5000 hash-updates. Caught up to 1425051646.231266

PTree has already 137M (and growing), so... Time will tell. But it
feels as if it were working \o/

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Seemingly corrupted DB, not syncing

[Gunnar Wolf]

Hi,

I noticed today my keyserver has been failing to sync for several days
(to say the least – it still reports knowing only about 3920177 keys,
while I see 4005128 in other servers I supposedly peer with).

Looking at the SKS logs, I see entries such as:

==> db.log <==
2015-08-05 18:01:27  error in callback.: 
Bdb.DBError("BDB0060 PANIC: fatal region error detected; run recovery")

(but I don't know what recovery it talks about — BDB's?)

Or:

==> recon.log <==
2015-08-05 18:02:40 Raising Sys.Break -- PTree may be corrupted: 
Failure("remove_from_node: attempt to delete non-existant element from prefix 
tree")
2015-08-05 18:02:40 DB closed

So... In your experience, what should be done? Is my best bet to just
drop my DB and download a set of dumps again?

Thanks,


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] normalbuild segfaults

[Gunnar Wolf]

ma...@wk3.org dijo [Fri, May 01, 2015 at 12:16:27PM +0200]:
> Hi,
> 
> normalbuild just segfaulted on me on a 64bit machine running Debian
> 7 with enough everything (RAM and CPU). How do I best investigate?

Hi,

FWIW, Debian 7 ships with SKS 1.1.3, while Debian 8 has 1.1.5. I
understand the difference is quite significative, and if you don't
have a specific reason to use the older version, you should use the
one provided with Debian 8.

Hopefully even your problems will go away!

Greetings,

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] sks.disunitedstates.com down and out

[Gunnar Wolf]

John Marshall dijo [Tue, Apr 14, 2015 at 10:58:47AM +1000]:
> > I have just seen way too many problems with Berkeley DB in way too  
> > many situations. It seems to be fine for small applications: postfix  
> > uses it for really small files, for example. But anything big and it  
> > becomes unmanageable.
> > 
> > Again and again and again. I'm convinced it's just a really bad idea.
> 
> If *the problem* was in fact BDB, it would be biting many more folks
> really hard and David wouldn't be the only one giving up.  I have been
> running SKS on FreeBSD servers for something like 7 years and I can't
> remember having any BDB problems at all.  The databases are on local
> UFS2 filesystems and I don't mess with keydumps.  Back when I started I
> went through the pain of doing a full database import from a keydump,
> and then trashed the keydump.  Perhaps the folks who have BDB problems
> are the ones who mix keydump and BDB key storage?

FWIW I had my share of BDB issues long time ago, maybe four years ago,
when I had set up my SKS server on bare-metal hardware. I've not had
any issues since I set it up in a LXC, even having had a HDD failure
in the meantime.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seeking gossip partners for new keyserver pgp.gwolf.org

[Gunnar Wolf]

Brian Minton dijo [Wed, Mar 11, 2015 at 10:25:53AM -0400]:
> First of all, Thanks for your contribution to Debian! :-)

Thanks! :-D

> You can peer with me.  Just add the following to your membership file:
> 
> keyserver.brian.minton.name 11370 # Brian Minton 
> 0x0424DC19B678A1A9

Done, thanks a lot!


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Seeking gossip partners for new keyserver pgp.gwolf.org

[Gunnar Wolf]

Hi,

I have set up an SKS server at x-hkp://pgp.gwolf.org (with the usual
Web interface at http://pgp.gwolf.org:11371/). I would like to add
some peers to become a part of the keyserver network.

I am running SKS 1.1.5-3 on a Debian Jessie LXC host. I populated my
server from a dump on February 25; it currently knows 3,866,122
keys. The keyserver runs (with due permission) from UNAM, the
University I work at.

Several years ago I ran a keyserver at a different machine in this
same university, but after a hardware failure I didn't find time to
set up a new one — Time to fix this issue! :)

Thanks a lot!

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seeking peers for gpg.debian.unam.mx

[Gunnar Wolf]

> On Mon, Sep 27, 2010 at 06:01:41PM -0500, Gunnar Wolf wrote:
> > So, I am looking for extra peers. Who is interested in adding me to
> > their peers? Please add:
> > 
> > nisamox.fciencias.unam.mx 11370 # Gunnar Wolf  
> > 0xC1DB921F
> 
> Did you mean that to say gpg.debian.unam.mx?

Ugh, I'm very sorry - Yes, gpg.debian.unam.mx is the right alias, and
points to nisamox.fciencias.unam.mx. While both will work as it is,
the "right" one is gpg.debian.unam.mx.

PS, thanks to forwarding the reply to me, I'm not subscribed to the list.

___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Seeking peers for gpg.debian.unam.mx

[Gunnar Wolf]

Hi,

I have set up a SKS keyserver at gpg.debian.unam.mx (CNAME for
nisamox.fciencias.unam.mx, 132.248.181.148). I have had it running and
connected to the SKS network since a couple of weeks, via two friends
I asked to peer with me while I tested some details and got the NS
record approved by the University. It has been stable and completely
uneventful. 

I am running SKS 1.1.0 (from Debian Stable).

So, I am looking for extra peers. Who is interested in adding me to
their peers? Please add:

nisamox.fciencias.unam.mx 11370 # Gunnar Wolf  0xC1DB921F

to your membership files, and let me know. 

Thanks a lot,


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel