Hockeypuck 2.2 released

We are pleased to announce the release of Hockeypuck 2.2. Hockeypuck is a modern synchronising keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose. Hockeypuck 2.2 is a significant upgrade that includes the following changes: #

Re: Seeking peers for keys.dryusdan.net

On 5 Apr 2024, at 18:36, Dryusdan wrote: > > I double check and no, HAP_BEHIND_PROXY wasn't set. But > HAP_BEHIND_PROXY_EXCEPT_HKP is (in /etc/default/haproxy I directly set > variable and it loaded by systemd service) > > Is now ok :) > So that would imply that ports 80 and 443 are behind

Re: Seeking peers for keys.dryusdan.net

On 5 Apr 2024, at 17:34, Dryusdan wrote: > > I change my setup today and add HAProxy and standalone configuration. > Actually it is behind nginx for both, keys.dryusdan.net > and gpg.4n0ny.me . Great stuff! Did you make sure to uncomment

Re: Seeking peers for keys.dryusdan.net

On 31 Mar 2024, at 21:25, William Hay wrote: >> > Do you have protections against flooding attacks in place on your > keyservers(appropriately > configured rate limiting proxy)? Hi, guys. According to the spider at https://spider.pgpkeys.eu/sks-peers, keys.dryusdan.net and gpg.4n0ny.me

Hockeypuck 2.2

Hi, all. I have a stable development branch for Hockeypuck 2.2 that is ready for beta testing. If anyone wants to help test, please pull the latest branch at https://github.com/pgpkeys-eu/hockeypuck/tree/branch-2.2.0 onto a test machine, and restore from a fresh dump (this is important). For

Re: Key server status

On 7 Mar 2024, at 16:47, Skip Carter wrote: > > I have found that the keyservers are not properly synced: > > The MIT server has my key from 2023-03-29 > but the Ubuntu server has only my old expired key 2019-04-10 (4 years > out of date!). The MIT server is effectively running unmaintained at

Re: Seeking Peers

On 23 Jan 2024, at 20:38, Gerald Stueve wrote: > > On Tue, 2024-01-23 at 18:35 +, Andrew Gallagher wrote: >> >> I can see it now! It’s reporting version 1.1.6 though, have you overridden >> it in the hockeypuck.conf file? I’d recommend against doing that - it used

Re: Seeking Peers

On 23 Jan 2024, at 02:35, Gerald Stueve wrote: > Please try again, it appears accessible from outside my local > network > hockeypuck 2.1.2 > 6613215 keys from pgp.cyberbits.eu last week I can see it now! It’s reporting version 1.1.6 though, have you overridden it in the hockeypuck.conf file?

Re: Seeking Peers

On 18 Jan 2024, at 01:57, Gerald Stueve via SKS development and deployment list wrote: > > I am finally replacing my old sks keyserver keys.stueve.us with a > hockeypuck based system and would appreciate any peers. > > [hockeypuck.conflux.recon.partner.keys_stueve_us] > #

Re: Flooding attack against synchronising keyservers

recovering your system, please get in touch. Thanks, A > On 27 Mar 2023, at 18:47, Andrew Gallagher via Gnupg-users > wrote: > > Signed PGP part > Hi, everyone. > > The synchronising keyserver network has been under an intermittent flooding > attack for the past five days, r

Flooding attack against synchronising keyservers

Hi, everyone. The synchronising keyserver network has been under an intermittent flooding attack for the past five days, resulting in the addition of approximately 3 million obviously-fake OpenPGP keys to the SKS dataset. The fake keys are currently being submitted multiple times per second

Some proposals for future synchronising keyserver development

Hi, all. It’s been quiet in keyserver land recently, but I recently published four proposals for how to move forward on the Hockeypuck github blog, and all feedback is welcome: HIP 2: SKS v2 protocol Sync using hashes of self-sig packets rather than hashes of TPKs would mitigate

Re: How much storage is required?

> On 7 Aug 2022, at 17:19, Samuel Sloniker wrote: > > On 8/7/22 05:17, Andrew Gallagher wrote: >> >> sks-keyserver can be run on a smaller disk (by using fastbuild and using the >> dump directly instead of importing it), however I would not recommend it

Re: How much storage is required?

On 07/08/2022 04:03, Samuel Sloniker wrote: Hello! I'm thinking about setting up a keyserver, but I'm concerned about storage space. How much is required? A recent keydump of the SKS dataset is a little over 15GB in size. To run a copy of Hockeypuck with the full dataset loaded takes around

Re: oneway sync with hockeypuck

> On 23 Jun 2022, at 12:01, Steffen Kaiser wrote: > > I did not found any references about such feature in hockeypuck, but > does somebody has a solution for a one-way sync between hockeypuck servers? > > So, the internal server may pull changes from the outside one, but the > outside one does

Re: hockeypuck recommended key size limit setting?

On 15 Jun 2022, at 14:36, Steffen Kaiser wrote: > > I see lots of > > level=warning msg="dropped packet" length=16471 max=8192 > > which is a key exceeding the limit of 8KB, if I'm not mistaken. That’s a single packet exceeding the packet size limit of 8k, whereas the total key size limit is

Re: pgp.uni-mainz.de Takedown

On 24/05/2022 17:55, Christoph Martin wrote: > If I understand correctly, Hockeypuck would have the same issues with > GDPR and key remove request. Please correct me if I am wrong. Hockeypuck is (since v2.1) capable of dealing with key deletion requests, however the interface to do so is not

Re: sks.infcs.de take down // Re: keyserver.insect.com GDRP takedown request

> On 30 May 2022, at 21:18, Steffen Kaiser wrote: > > On 2022-05-30 the stats are: > new: 1326382updated: 3113 > > so, the hockeypuck server updated 3113 keys from a SKS server, which > cannot receive new key information? There’s a known issue in hockeypuck where repeated recon can cause

Re: sks.infcs.de take down // Re: keyserver.insect.com GDRP takedown request

> On 28 May 2022, at 16:08, Steffen Kaiser wrote: > > I didn't followed the thread right now, but if somebody has a hacked > hockeypuck server (I do not know go at all), which does not download > blacklisted keys, please send a link Install hockeypuck 2.1.0 or later and follow Alexandre’s

Re: keyserver.insect.com GDRP takedown request

> On 27 May 2022, at 11:38, Marcel Waldvogel > wrote: > > (Not included here, as I do not want to be responsible for his personal > information to be archived by the list.) Indeed. Please everyone refrain from identifying (or jigsaw-identifying [1]) any particular individuals on the list,

Re: Reconcile recovered items too high for some of my peers

erhaps due to packet reordering. I don't currently understand the code well enough to debug this properly (but perhaps somebody else here does?). -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Reconcile recovered items too high for some of my peers

or Hockeypuck? -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: State of the graph

On Tue, 2021-12-14 at 18:53 +0100, Marcel Waldvogel wrote: > Andrew, > > thanks for the visualization! NP, it's mostly Gunnar's code. He has a much more extensive history of the mesh going back nearly three years now, at sks-status.gwolf.org > I'm feeling flattered that keyserver.trifence.ch is

State of the graph

count of < 6.3 million. (Note that both these resources are built from a snapshot in time and may therefore contain some inaccuracies). You may wish to check your own keyserver and contact any of your peers that have fallen out of sync with you. Thanks, A -- Andrew Gallag

Re: filter errors

g. :-) Set filters=["yminsky.dedup","yminsky.merge"] and you should be fine. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Hockeypuck troubles

low you to put a reverse proxy in front. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Hockeypuck logging

On 15/09/2021 18:44, Skip Carter wrote: But MY logs look like: INFO[169329] lookupfp=63af7aa15067c05616fddd88a3a2e8f 226f0bc06 length=1219 op=get INFO[169329] GET=/pks/lookup?op=ge

Re: number of keys reported by hockeypuck

On 14/09/2021 16:51, Gunnar Wolf wrote: 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

Re: number of keys reported by hockeypuck

]: hockeypuck.service: Scheduled restart job, restart counter is at 80. I've never seen that before. We should take this one to the hockeypuck github repo. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: number of keys reported by hockeypuck

On 10/09/2021 18:52, Gunnar Wolf wrote: > 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

Re: number of keys reported by hockeypuck

On 07/09/2021 17:42, Skip Carter wrote: > > 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.

Re: keyserver.taygeta.com on hockeypuck

de(s). Yes, there are a few of us doing that, it reduces the recon load considerably. @Skip, would you mind changing your membership entry from `sks.pgpkeys.eu` to `pgpkeys.eu` please? I've swapped it at my end already. Thanks! -- Andrew Gallagher OpenPGP_signature Description: OpenPGP dig

Re: keyserver.taygeta.com on hockeypuck

> On 30 Aug 2021, at 20:38, Skip Carter wrote: > > I finally gave up on keeping the plates spinning and stopped using SKS and > switched to hockeypuck at keyserver.taygeta.com. > > The switchover was gratifyingly trouble free. Welcome to the dark side! :-) > At the moment there are no keys

Re: No DNS records anymore - alternative ?

!). To be really useful to end users, we should collect not just the existence and connectedness of keyservers, but also their reliability, responsiveness etc. The distinction between "fit for purpose" and "fit for use" is vital. -- Andrew Gallagher OpenPGP_signature

Re: No DNS records anymore - alternative ?

mmunity of keyserver operators is still valuable. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Peering new keyservers

Just as a general community announcement, if you want to sync your new keyserver with existing peers, it is not just polite to notify them, it is *required* - otherwise your connection attempts will be automatically rejected. Don't be afraid to ask. :-) -- Andrew Gallagher

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

the migration to the 21st century... we must be willing not to kill the network to begin with! I agree. We need to be careful though to distinguish between the decentralised peering/sync model and the load-balanced multi-operator pool. The first does not imply or require the second. -- Andrew

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

On 23/06/2021 10:36, Gabor Kiss wrote: On Wed, 23 Jun 2021, Andrew Gallagher wrote: Actually sks-keyservers.net (or its successor) is just a web page that shows statistics about key servers. That should not public at all so it would not attract any GDPR complaints. In the context

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

ort. 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. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

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

. :-) -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Livelihood statistics of the SKS keyserver network

On 13/05/2021 18:16, Gunnar Wolf wrote: Andrew Gallagher dijo [Thu, May 13, 2021 at 12:34:20PM +0100]: 1. produce a connectivity graph with only working nodes Added, as "Success" graph. It purty. :-) 2. ignore localhost and private IPs, they will never work :-) Of course.

Re: Livelihood statistics of the SKS keyserver network

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. :-) -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Livelihood statistics of the SKS keyserver network

be using a DNS name. Thanks! A -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: High rate of updated keys

SKS peers and haven't suffered to the same extent. I suspect it may be an artifact of the topology - perhaps pgpkeys.eu is getting different update sets from two different sources and they keep overwriting each other, or some such. Investigations continue... :-) -- Andrew Gallagher

High rate of updated keys

to manifest as "End_of_file" errors in the SKS logs as the reverse proxy gives up. Has anyone else seen similar issues? Thanks, A -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Simulating SKS best practice [Was: keyserver.dobrev.eu is back running Hockeypuck]

using the lowercase version. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Simulating SKS best practice [Was: keyserver.dobrev.eu is back running Hockeypuck]

On 23/03/2021 12:58, Andrew Gallagher wrote: On 21/03/2021 21:48, Martin Dobrev wrote: I had to play with mod_rewrite and force a redirect from //pks/lookup?op=stats=mr/ to //pks/lookup?op=stats /to let the script parse HTML. I don't have a proper explanation why peers and recon port

Re: Pool dried up

d this morning). I think caching (of everything) is the way to go, and will experiment with it later. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Lying about Hockeypuck being SKS?

whichever keyserver has the best reputation, rather than relying on a random pool member to be an honest one. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: keyserver.dobrev.eu is back running Hockeypuck

33e9391466;hb=668504fbc685cf84ebc822fea71388b4999edd68#l323> in the stats page. Got it. Applied now in pgpkeys.eu for consistency. Thanks! (And I've also fixed its ipv6...) -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: keyserver.dobrev.eu is back running Hockeypuck

(line 286/287). I can confirm this works, and it has the unexpected side effect that pgpkeys.eu is now recognised as SKS, even though it is still declaring itself Hockeypuck. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Pool dried up

Hi, Todd. On 23/03/2021 03:37, Todd Fleisher wrote: On Mar 22, 2021, at 13:28, Andrew Gallagher <mailto:andr...@andrewg.com>> wrote: I happened to check the pool just now, and there are only three nodes in it: 1pgpkeys.uk <http://pgpkeys.uk>[@] 2sks.pod01.fleetstre

Re: Lying about Hockeypuck being SKS?

t preclude their Sounds good to me, will change that on pgpkeys.eu now. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Pool dried up

", "sks.b4ckbone.de", "keyserver.opensuse.org"); > keyserver.dobrev.eu is peered to two of them and yet dropped from the list. Of those, only zimmermann is functional, and it isn't paired with any other functional servers. I'm pretty sure the running copy of the spider is using a

Pool dried up

orphan all other nodes, no matter how well-behaved. It should probably also be noted that pod02.fleetstreetops has been the only node in the HKPS pool now for some time. This certainly can't be good for its load. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: Lying about Hockeypuck being SKS?

to help the network run and minimize the administrative effort to get rid of poisoned keys, aka recover from dumps. I intend to do this also, as soon as I get pgpkeys.eu's hockeypuck into a more highly-available state. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: pgpkeys.eu is back (and seeking peers)

On 08/03/2021 18:19, Andrew Gallagher wrote: Hi, all. pgpkeys.eu is back online under new management (thanks, Dan!). For the same load-balancing reasons that Marcel outlined in his recent mail, pgpkeys.eu runs separate hockeypuck and SKS instances. SKS nodes please peer using: # Andrew

Re: keyserver.kim-minh.com si going offline permanently

to hear about your server. I'm a customer of OVH and it's only luck that I didn't have any servers in that particular location. I hope you didn't lose anything irreplaceable. A -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

pgpkeys.eu is back (and seeking peers)

Hi, all. pgpkeys.eu is back online under new management (thanks, Dan!). For the same load-balancing reasons that Marcel outlined in his recent mail, pgpkeys.eu runs separate hockeypuck and SKS instances. SKS nodes please peer using: # Andrew Gallagher

Re: Seeking peers for openpgp.circl.lu

ourg i...@circl.lu <mailto:i...@circl.lu> - www.circl.lu <http://www.circl.lu> - (+352) 247 88444 -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: pgpkeys.eu going offline

I’ll take it if nobody else wants it. I’m an Irish citizen based in Dublin. I won’t be able to spin up a keyserver on it straight away, but I have been planning to do some hockeypuck experimentation so this will be a good kick up the backside. :-) Thanks! Andrew Gallagher > On 9 Jan 2

Re: [Keyserver] Hockeypuck 2.1.0 released (Andrew Gallagher)

> On 11 Dec 2020, at 05:11, Casey Marshall via Gnupg-users > wrote: > > Peers across these more divergent cohorts may still peer at a lower > frequency, so key material accepted by both may still propagate. But the problem with divergence isn’t loss of efficiency - divergent servers don’t

Re: [Keyserver] Hockeypuck 2.1.0 released

ockeypuck/releases/tag/2.1.0> [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f <https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f> -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature

Re: [Sks-devel] The pool is shrinking

> On 16 Aug 2019, at 20:31, Stefan Claas wrote: > > You guys need a lot of brainstorming IMHO on how to improve the SKS > infrastructure to get back users. I dunno, I’ve been brainstorming pretty hard on this list recently... :-p > Maybe it would be a good idea to > get the hockeypuck author

Re: [Sks-devel] The pool is shrinking

> On 16 Aug 2019, at 19:48, Stefan Claas wrote: > > People, like me, do not > like the idea of sharing dumps to 3rd parties (hello GDPR), without our > consent. There is no net difference between distributing a dump and peering with another sks server. I don’t understand why you keep going on

Re: [Sks-devel] The pool is shrinking

not be *wrong*, but it would be a fundamental change to the entire premise of the system. And as Hendrik pointed out above, you can't bootstrap a new SKS keyserver without a dump. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-

Re: [Sks-devel] Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation

> On 18 Jul 2019, at 17:46, Todd Fleisher wrote: > > "Unfortunately, there is currently no > good way to distribute revocations that doesn't also reveal the revoked > identity itself. We don't want to distribute revoked identities, so we can't > distribute the identity at all." We can kill two

Re: [Sks-devel] Gossip protocol mentor?

>> I really like the idea of having a decentralized PKI and Web of Trust. >> Is anyone else doing that? > > Not that I'm aware of. > > I hope someone would piggyback on Namecoin, which has been doing > decentralized identity storage for a while now. You want to save the ecosystem from the

Re: [Sks-devel] Launching a new keyserver on keys.openpgp.org!

atibility purposes. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Launching a new keyserver on keys.openpgp.org!

vers that support a different subset of key material would require a full implementation of fake-recon as discussed in the mega-thread here: http://nongnu.13855.n7.nabble.com/SKS-apocalypse-mitigation-td228252.html tl;dr: you probably have better things to do with your life. :-) --

Re: [Sks-devel] Launching a new keyserver on keys.openpgp.org!

> On 16 Jun 2019, at 22:32, Vincent Breitmoser wrote: > > Anyone got some good idea on how to continuously sync certificate updates from > the SKS pool? Run your own SKS server, sync it with the pool, and monitor its logs. You can then schedule a job to request each updated packet in turn

Re: [Sks-devel] Keyservers and GDPR

On 27/05/2019 14:47, Jim Popovitch wrote: > On Mon, 2019-05-27 at 14:28 +0100, Andrew Gallagher wrote: >> On 27/05/2019 12:47, deloptes wrote: >>> it is a matter of an agreement between the person and the authority >>> hosting the information of the public key >

Re: [Sks-devel] Keyservers and GDPR

eement. Keyservers are distributed not just operationally and geographically, but also legally. Furthermore, it is not always the data owner who uploads it to the keyserver network, so neither party to the GDPR consent model need be present during the transaction, or need even exist. -- Andrew Gal

Re: [Sks-devel] Data protection concern[Ref. RFA0751305]

On 08/03/2019 14:15, Kristian Fiskerstrand wrote: > The ICO has concluded in this case and no further action will be taken > from them. Was there any legal reasoning attached to this decision? -- Andrew Gallagher signature.asc Description: OpenPGP digital sig

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

> On 8 Feb 2019, at 19:02, Daniel Kahn Gillmor wrote: > > Figuring out how to do the partial-sync for a limited time sounds > difficult to me, and i wonder whether it might be better/faster/cheaper > to just deploy such an update-only network, and don't bother with the > partial sync. Parse

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

On 2019/02/06 23:51, Robert J. Hansen wrote: > No. Keyserver reconciliation is 90% of the problem. Fixing this would > make it impossible for older keyservers to reconcile with a next-gen design. I have had a long think about this problem, and I reckon that the biggest bar to progress is the

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

On 2019/02/07 11:01, Martin Dobrev wrote: > My idea for blacklists is in a sense similar - during recon process > consolidate hashes from the blacklists with whatever is in the live > database and report this to peers. This way it won't trigger continuous > *recon/fetch/drop due to blacklist*

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

On 2019/02/07 05:35, Gabor Kiss wrote: > And all these programs can talk each to other due to RFC 821 (1982). Well, yes. A good protocol is everything. The implementation is relatively easy. Ensuring that the protocol doesn't result in a cascade failure is the Really Hard Problem. We're still

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

> On 6 Feb 2019, at 23:15, robots.txt fan wrote: > > To answer my first question, I guess that it is possible to implement a > keyserver with the same interface for GPG users that can still recon with > older servers. The older servers might try to send them keys that are on the > blacklist

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

uld be a good start. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Key updates not propagating

> On 18 Jan 2019, at 17:47, Alain Wolf wrote: > > While sks1.cryptokeys.org.za is listing pgpkeys.urown.net as peer. It > is not cross-peered back by pgpkeys.urown.net. Of course. Please don’t take anything I say as an accusation against either yourself or any other particular keyserver

[Sks-devel] Key updates not propagating

edirection service? This would remove the requirement for the keyservers to host any data at all, solving multiple problems in one stroke. The main disadvantage would be that it would be simple to block timely distribution of revocations - but right now this isn't happening anyway. Thoughts? -- And

Re: [Sks-devel] Another Poison Key?

On 18/01/2019 11:17, Simon Lange wrote: > Am 18.01.2019 11:01, schrieb Andrew Gallagher: >> On 18/01/2019 06:09, Gabor Kiss wrote: >>> Is "... while gossip disabled. Ignoring." is normal? >> >> Yes. SKS is single-threaded, so while it is in the middle o

Re: [Sks-devel] Another Poison Key?

On 18/01/2019 06:09, Gabor Kiss wrote: > Is "... while gossip disabled. Ignoring." is normal? Yes. SKS is single-threaded, so while it is in the middle of a task it politely ignores incoming network requests. -- Andrew Gallagher signature.asc Description: OpenPGP digi

Re: [Sks-devel] Withdrawal of Service - keys.flanga.io

n the most learned advice will be hedged with a thicket of qualified assumptions. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] [openpgp-email] Keyservers and GDPR

> On 7 Nov 2018, at 16:43, Yegor Timoshenko wrote: > > It's not just storage, it's also immutable and distributed. In the keyservers, removing immutable content is a Very Hard Problem, but it is theoretically possible. With blockchain, it is impossible by design. A

Re: [Sks-devel] [openpgp-email] Keyservers and GDPR

> On 7 Nov 2018, at 10:16, Yegor Timoshenko wrote: > > World-writable storage is problematic even if there is no search. > Proof of work and some operator-controllable data removal > mechanism (like opt-in key blacklists) can help limit this attack > vector. > > Storing immutable data,

Re: [Sks-devel] [openpgp-email] Keyservers and GDPR

> On 6 Nov 2018, at 20:09, Mike wrote: > > I don't think "resilient" can be used any more in relation to sks-keyservers > as they drop offline on and off and even one malicious individual could take > the whole network down if motivated enough. Individual servers drop on and offline but the

Re: [Sks-devel] setting up hockeypuck keyserver

ove my peers into the hockeypuck server eventually > assuming I see its working with my sks and gossiping ok. Standby. I for one would be most interested if you could collate your experiences into a howto... :-) -- Andrew Gallagher signature.asc Description: OpenPGP di

Re: [Sks-devel] Blacklisting on UID?

> On 29 Aug 2018, at 17:52, Thorsten Bro | openSUSE Heroes > wrote: > > Are there any plans for blacklisting or filtering specific GPG UIDs by > pattern in the sks server or database? I think filtering out UIDs by bad-pattern is a fool’s errand. Anyone can put anything they want in the real

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> On 14 Jul 2018, at 09:34, Human at FlowCrypt wrote: > > > > Could this be mitigated by validating email addresses as they come in? > > > No, because ID fields are not required to be email addresses. > > Then let's drop keys that don't contain a valid email address in the key id. You do

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> On 14 Jul 2018, at 01:57, Ryan Hunt wrote: > > Could this be mitigated by validating email addresses as they come in? No, because ID fields are not required to be email addresses. A ___ Sks-devel mailing list Sks-devel@nongnu.org

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

> On 13 Jul 2018, at 22:43, Moritz Wirth wrote: > > FWIW, has anybody even started working on a fix for any of the bugs? There has been a fair bit of discussion, but no consensus has been reached, apart from a general agreement that major changes to the recon model will be required, and that

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

to be a lost cause. DNS, WKD and proprietary services like keybase are probably the only way this can be done without opening pandora’s box. Andrew Gallagher > On 13 Jul 2018, at 18:34, Phil Pennock wrote: > > Folks, with immediate effect, I am withdrawing sks.spodhuis.org from

Re: [Sks-devel] One Way replication (for test environments)

On 18/06/18 11:11, Hendrik Visage wrote: >> On 17 Jun 2018, at 14:59 , Andrew Gallagher > <mailto:andr...@andrewg.com>> wrote: >> >> You can’t do it using recon, because any additions to the test server >> will cause the key delta to diverge and recon wi

Re: [Sks-devel] One Way replication (for test environments)

> On 17 Jun 2018, at 11:41, Hendrik Visage wrote: > > I’m considering setting up some test environments for the “researchers” to > test the SKS keyservers, but I was wondering about one way replication, ie. > one server that will only sent out to the test server(s), but not receive > from

Re: [Sks-devel] disk full, keys.niif.hu crashed

> On 16 Jun 2018, at 17:32, Paul Furley wrote: > > This is a serious, serious flaw... I'm grateful to the individual for taking > the time to research and highlight this issue. Sure, not ideal that the > network is struggling as a result, but at least we'll have to find a way to > fix it!

Re: [Sks-devel] disk full, keys.niif.hu crashed

On 2018/06/15 22:42, tiker wrote: > Well, it turns out that the cause of our issues, the method to re-create > these keys and make things worse is already posted publicly. There are two main ways in which critical internet infrastructure goes on fire: a government TLA takes it down for nefarious

Re: [Sks-devel] disk full, keys.niif.hu crashed

On 2018/06/16 00:49, James Cloos wrote: > It is hard to check w/o knowing the key hash, but can iconv(1) decode > that uid into utf8? Perhaps it is in one of the legacy 16bit encodings? According to the person responsible, it's just random noise. A signature.asc Description: OpenPGP digital

Re: [Sks-devel] SKS apocalypse mitigation

Hi, all. There has been a lot of chatter re possible improvements to SKS on the list lately, and lots of ideas thrown around. So I thought I'd summarise the proposals here, and try to separate them out into digestible chunks. I've ordered them from less to more controversial. My personal

  1   2   >