[Sks-devel] I'm seeking peers for pgp.freiwuppertal.de :-)

[Tobias Frei]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I am looking for peers for my new SKS keyserver installation at
pgp.freiwuppertal.de.

I am running SKS version 1.1.4 from the Ubuntu repositories. This is a
private virtual server which also hosts some other services and my
personal website, freiwuppertal.de (German).
The server is physically located in Munich, Germany (Europe):
http://geoip.flagfox.net/?host=pgp.freiwuppertal.de
The machine theoretically has IPv6 connectivity, but I'm currently
trying to solve some problems with it. At the moment, please use IPv4
instead (109.239.48.152). As long as IPv6 doesn't work reliably, there
won't be an  record for freiwuppertal.de and/or
pgp.freiwuppertal.de, so you can also safely use the hostname.

The HTTP HKP server is accessible via port 11371 and 80. Port 11371 is
reverse-proxied by nginx; port 80 is reverse-proxied by Varnish+nginx.
The recon server listens on port 11370.

I have loaded a keydump from ftp.prato.linux.it, dated 2014-01-01.
I see 3.493.714 keys loaded.

For operational issues, please contact me directly.

pgp.freiwuppertal.de 11370 # Tobias Frei tob...@freiwuppertal.de
0xB1817DA0

(Enigmail added an unwanted newline character there, I think. :-/)


Thanks in advance!

Best regards,
Tobias Frei

PS: I mainly followed the steps in these tutorials:
http://www.keysigning.org/sks/
https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQYcBAEBCAAGBQJSy1ahAAoJECSb9+6xgX2g7g8v/RASwwEBlY3VqKJ+v4LPE1Fa
mOx6/132Pyfeh0Su0QLmJnRvH4Dc3da1QbJDzIkrDeCmXXRaBiCcW08BaGl6s0po
Whr/xwTnf02GXX2XMN1h6QjrdhH8jAQ2ROxiLDuaqgqmYCKzYbxFDeB+2xwdaCoU
Zapw75KQ0GnxOKCokXVTstI2ex/q1qSlQ5mXIRLPFbTpHqFu7OLfc7KhEmZmsxNR
f3YfK9/DiXtbgAQO6/4qkGcm3yLwXis9bT1xq9W2m67/E+awXrxDaMnHaIJY6p6+
h+uxRkKhoQcNGSocJEK2vpJjujJC0AZ2tdWzlYmnoN/Ntw1fZhz/JAfsW0WUrMSn
1LpEWK0af6HFF1lF2B3Aa+Adx8JLRiZoldVy5bUs3wCPSB7kYud3aSy5uVFIz2Gq
S+4vFgutK4Aia+p/YXEssulVcvx6nU6pp3qJFhpOUMpymrCdWF3wb+klChE4vvCg
zdezYHtDs5qlwBjZPzFCvn/iOaKnQH4QVZNG+UZmOGzqDKUhVoBR/nwgzp9KbsUf
4nb1TdreOx73d2nEy7FCtaSSQuAyjw3FCeS/hJplq8uWJTFyjMjhiNKKn8dKoBcn
As5bd7P/gL3vR8Bnx4ge77EAruIp3rBwEcPgBAMJobVTzpdQnbBQC2zgRGXVozRa
hfAThhnleQ75R2u58opldY1KEDHFoVd0CqASDVnlzc4qzLKqLLD/77Yo7NbcrmhE
Esyn16jeARzXBok1ysZtJMJs/acDeykSx//JqLeRKQJuYtnfkDWTHnN000Mj8eW8
+RClXC8yEyUoOR6ETAH/Ss6q19ScHqQatF0BbeYvBY45VbLNgWoYh7OqFpWRtGdc
qlMTzMuE4C/yyQt54bHXL59LZL29IoxIXrNrD+cBQvLxKJyxYYDaF0vDW4SSegQ0
sDqoUlHiX+LmZmEFS3XG7EM/lwNJy10vUcnyIKLkAJYhfVJyZKXvTxQKa38D4KYL
fYJdTFsySCLJr4dLwxllpyU196qqBlNaeBC6rY9zooXLJBu9UPNUx8oZgSUxpDgd
F0sOEdoZ6VNJKpNAiDGAOOSy0dNm6y+SUdbaV9dKDev8TMHfasdHY7dG9sqkbSka
bPpN8VTconfB/vANjRhfLncV9W+oxRiqPkYWae0/jhCETXbTSCnqD10M844SDbDX
H9PdJxicVKPJxhQbdUvF6h/uowf8YT/4wDGscJvQPEF5Ls5ml17AQkZh1FxYc9fu
PUdU51e+HXZROIzhujmNnm7ZbQrAVvKs2itQ17ATVKlo0cTF9zKkxIavhRSvv0oa
2T6FM6PtZvjJxm8yJXTvXzZcEV5RQolZ164VHpqovTx7MTCriLCwfEnydjZp76Il
iIGzwxnFa11ZxJZInVqPTaUHLvU8qpQFfJ3Pbp1lIfe67qBCImCQnVASZzZK5hpg
27Z1BFH0NEhZ2zBWz+2CsG0W8rfG3zaXbExSEGJd0Z5XYFCn6a67thcM5wWQl+Bq
O9OLSqgLTGQ6j5H62pH50xfkF+sds25VdF105jaq2h4dg7jI/LahRiHFUd+OD3f1
fNL0GNrzTPyfbMg5IOD05zbdG77oiKrjaQAB0hQPIZI/+pUOxEyQRft8eq7bqH6I
Dg7z2ubIL5UBAjWt4LBRlwHtkiZqsMtT6LPLvLwEaW2jCKxs9vinUXm544Q1uDhA
82UwmrDPJl1szJ8Wj76BomY0m4w6EOqxfHj3gu6wZPEPqBN7yxsBc+nm23aAO+Rk
NoYBEOluepFE1imYFprGLzonElXTi3P/6UQoMI5WyYtdnwmUMExsNobBdl24FcJx
jklHPhqrqp2kWlwTDqFRPYCGxfgg1YUHYIDz4Akuh0GnBV91dDVUohQRHEem1x5j
JHnrdTPHLBga8YBN7AWc/ljUM0L1layGG69Va+iYXxoKMcw24uL2jsp94aisiZO3
zIqzJAnZyzffJc12r0B/A5s+zr+Y1dHPozGEL1ZOnSK9o7/yUHYYsH5Vbr14jMkv
PpCNo39INK9AzlIB0MJgYc+Dww7jDwpQBOT51T1E+w==
=0XOz
-END PGP SIGNATURE-

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

[Sks-devel] IPv6 running on pgp.freiwuppertal.de - thanks to Daniel Plominski! :D

[Tobias Frei]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi again,

that's awesome: huge thanks to Daniel DP. Plominski who helped me to
get IPv6 running on pgp.freiwuppertal.de. I've now also added an 
record for the main domain and the PGP keyserver.

The IPv6 address is:
2a00:1158:3::1a2

I actually wasn't correctly configuring it as a static IPv6 address...

@ Filip Stefaniak and David Benfell, thank you, I've now also added
your entries to my membership file. :-)



Best regards,
Tobias Frei

(PS: This mailing list is awesome. 8 new peers and a working IPv6
configuration within just two days! :D)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQYcBAEBCAAGBQJSzXVHAAoJECSb9+6xgX2gNsMwAJwpn4Ig6agOSBGJ17RTN7q9
9hyqJLBU1ruAgWjj5SbVZBe60vLEKu33yCtAu9x1na5hZ+CdEqG2N8hzY3ObM4Be
QAAWfQZceJZLpZ7LGZ0CE5FNHoesRqsNy4qCc6K2Rz4929J/Slm7xy8Ym7mmTW13
c6d60TIcMmZpkQzyJCjFZWN5hJHzva1VZFdhQCqHi9dnObOSd2wdF91R/zpGxLE1
h6Mc+c5KxyI9BYtAHf9TqJE9kng5L6cYlH37aGYEVN6Y3WeGkPGO/Ui2OzcTgng9
cSzauFW8I5SLKdz3rTiet8LZ6a/72kIXjOocoYG0b93AbL1n8RfRnapuMRPzPyUu
aq6mx+9maXk7PCXulrm2F8rypHaUsyz7rvkIGy3q5eEnJCRK9JlS2SOU/mthCNnB
Qo7dGLx0a7GBh/ShB4ZY0HEZDu+/OslfWgmoQZnpQ0ywIPOdlaaf9JCqSCSelmaq
FWMtYxruxJGEWP0CDhOCmmvYQhZxv8eEnVIwBhDgKb1FYOWmgSFs3NQOG9USbbnE
0ZQtfEsaTZ30EpNG4OCnyavq8en3IF15OAKzc6gb3CB5fger0GkyVrpHLKkxeSWh
YLxi00KcEhWjNcFOC/r+0QdxqqkH8r9JEaYCQr9+g2xylbrc1sW2pHeWXsPoCPys
6M7b/8aSTqkIUM1VmyPss4+cQ4Pom23q7Y1N/KJa5296lhGsSmgZ8E91hyEVcXyE
ek9jfXe0xHv8t+fuNoZaFZVkkv/gFjeoEsmpSa+JrsKC725WYqfZIHqIUMTEZcID
U7QpRyhJuW6OMYDKw30UDpAbsnt+y3rtby+Dv85l7PluSs+atlPpf0gySVV245Z0
WnpGfzxw6rYxAR0vbaIMf1oJDTC/y7RxRm377MK1sk9pkZeOuOTXoIv8ObDJgu9j
/B+uha5jEwsJ13M74OcLla2kkh3ueZqjzEtfOLUWe4K/gFkd7IXHDnc9klftb1K2
4dPhO8G0awxtk2abpY3ugLQidcaRxwruWUtJ1c+EuvnN454+kVF+GsD5hmjGNgMz
FYZM89fHfKvvOi5cPxAuK7ZqBU5Keyfd8xQu16t8jjsX6R3vEfPCSSsVY6bfnfjT
ZHHaKPgzooTVwna4+tmFFsc9nBGrGpPklta58gYUBESqt0rb7RVNwyBM185IXnDT
90dShguhRX/XZYOdWlaNmvlqALXCelmDh2FIrwlaIIvag6ZdLMC1Z+4H3r6bgU1D
ol04B0hz8R+jnZ5Pg+gQ1PqMeaaNFfqbUzyNy9GfsUeCSIcF9cnDjZJ8/ZFTg/v+
pTuxVXYsA2rJdMqLVjD12CXh57VxXYpDtnR0UNjVikGA0QpZJKAziI2jOA5kvkKx
FdsVHpAg+2rlMLQP9tLBGQggLidLXq9hBAeqH/FGDuECJHK+XSsq8bs7T5X3XAaR
nk4956JgsNCVVijImcRRyWJx8RcTszKOVtaGC9UtbRoItbHdH5DGXBqn4n/OAOeh
JcLX0PfeMVYXdbGNeRcp1BQE0c6sht+rnJSAfe4a3xsnJxR9qhx63jH2MpdlEU1h
n6CCTVrpXHFuDsT5UIIi2UJjKXNRBBmqNb42mDsnbPUzB6xSrK4Lk58A0my3xBfX
IdlI1YCMID3MlGHQ3FUOmxXSP2szCn0wTz8gW7mBsQ6ewSnB5+r8T0FurXWFB816
8MCs74RZgMf3pEdMgFppHW2eV9SpNATTMJ4iSrlT1Wp5KScAZ2oKcJ/ispXWsXAw
Erd6faPy/xyc5OIfYRQk6VDmr8DuiwundrIXlqMHwKz9jDSqp+0sVr2ftVDKL39/
IVEdT/BjElExi5573NOd4suC1porAB/t2wGK/t/EoVEfFL1J9RYL+zc2cGL+qikk
IBZqMXqJuTVGl582DNPOi9xwcZ42hlRuLZV1QCef+CaA1j1Ip5Supn9S2k8F/FAK
wXfM9zKra84eURC7AtaPNlqbHyzz8DXmdX6Px52Y3dV599cqHuIIgPJoRXogLxdw
8jr603C57aDbaCSMzng7OP+ys24Uk81Pob4HajkpXQ==
=KFjQ
-END PGP SIGNATURE-

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

Re: [Sks-devel] Tuning

[Tobias Frei]

Hi Christian,

thank you for offering the dumps! :-)

About the -nodiskptree option... please correct me if I am wrong,
but wouldn't the operating system's disk reading cache render this
option useless? At least it seems to be like this on my Kubuntu
desktop - with sufficient free memory, I can read any recently read
file with a ramdisk-like performance.


Best regards,
Tobias Frei

Am 11.02.2014 14:38, schrieb Christian Reiß:
 Hey folks,
 
 I have some questions on which I need some pointers.
 
 First, -nodiskptree: To my understanding this would result in
 longer startup-times, more memory consumption but faster lookups.
 So the ptree is generated, but kept in ram. Final analysis:
 Enabling this option would speed up lookups on the tradeoff of
 consuming ram. So: turn on
 
 pagesize and ptree_pagesize. These options are used for importing/ 
 generating the db and have no effect on a running server (or?).
 What would be good pointers in setting those?
 
 stat_hour: As far as I understand, stats are generated each hour.
 Why specify this? Are some more special stats generated here?
 
 
 In other news:
 
 I am dumping my DB each week each monday. 
 (http://sks.alpha-labs.net/dump/) - if someone wants to restart /
 recover.
 
 Also I am using puppet to deploy the sks server. Anyone else using 
 puppet? membership file (et all) is managed over hiera. So if we
 have any puppet3 users I am glad to share.
 
 Lastly, I wrote a (10 liner) php-script that queries the
 sks-keyserver stats page for (my) server checking keydiff, status
 and port-status (80, hkps) and exits with error/warning. Used in my
 case for bi-hourly icinga checks. Same here: I'll share. Drop me a
 line.
 
 -Christian
 
 
 
 ___ Sks-devel mailing
 list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 

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

Re: [Sks-devel] Debian SKS Upgrad Problem - Bdb.DBError

[Tobias Frei]

Hi,

it's not a real fix and it might be annoying, but one possibility
would be to simply re-build everything from a keydump again. Maybe
something has actually been corrupted in your key database; it might
actually be a faster solution to re-build everything instead of
spending hours on troubleshooting. I personally would do that, I
think, but that's just my personal opinion. :-/


Best regards,
Tobias Frei

Am 24.02.2014 11:49, schrieb Ronny Wagner:
 Dear Community,
 
 i upgrade my two sks server from squeeze to wheezy with sks 1.1.4
 (wheezy backport).
 
 After the update, I become following failed message: Requesting 2
 missing keys from ADDR_INET [80.101.216.220]:11371, starting with
 61AA86A0328D7DF39FC96E13B0A18B83 1 keys received Ctrl-C.  Exiting
 eventloop Raising Sys.Break -- PTree may be corrupted:
 Bdb.DBError(unable to allocate memory for mutex; resize mutex
 region) get_missing_keys.catchup callback interrupted by break.
 
 I found this entry 
 http://lists.nongnu.org/archive/html/sks-devel/2012-07/msg00107.html
 an recover my database, but the fail is come again.
 
 Have anybody a idea?
 
 ii  sks1.1.4-2.1 i386
 Synchronizing OpenPGP Key Server ii  db4.8-util
 4.8.30-12 i386 Berkeley v4.8 Database Utilities ii
 libdb4.6   4.6.21-16 i386
 Berkeley v4.6 Database Libraries [runtime] ii  libdb4.7
 4.7.25-9 i386 Berkeley v4.7 Database Libraries [runtime]
 
 
 
 ___ Sks-devel mailing
 list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 

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

Re: [Sks-devel] SKS peering request [sks-server.randala.com]

[Tobias Frei]

Hi,

if you'd be using the latest Ubuntu, you would probably also have
access to the newest SKS version in the repositories. ;-)

Ubuntu 14.04 LTS will come out soon; upgrading to that should give you
1.1.4.


If your server is running on amd64, you can use this .deb for now, if
you want to:
http://freiwuppertal.de/sks_1.1.4-2.1ubuntu1_amd64.deb



Best regards,
Tobias Frei


Am 05.04.2014 16:17, schrieb Martin Papik:
 
 Thank you, I've upgraded to 1.1.3, although why Ubuntu didn't
 install that one without an explicit parameter boggles me a bit. Oh
 well. Is that sufficient, or will I have to install the very latest
 from source?
 
 The web server is enabled, there's just no main page in the
 directory yet.
 
 I see Error fetching key from hash  : Not_found messages in
 the log though, is this normal? The hashes update, so I'm not
 overly worried, just want to know if this is normal.
 
 Anyway, thanks again for taking the time to assist me.
 
 Martin
 
 On 04/05/2014 04:38 PM, BluKeyserver wrote: Hi Martin,
 
 Quoting from 
 https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering
 
 'Versions prior to 1.1.2 have a severe interoperability bug (POST 
 requests for exchanging keys are HTTP/0.9, does not work with
 modern setups having reverse HTTP proxies in front as a best
 practice.'
 
 Perhaps it's a time to ditch the 1.1.1 and try to compile 1.1.4
 instead ?
 
 Also, I have noticed, that you did not enable the built-in www
 server:
 
 'Page not found: /var/lib/sks/www/index.html'
 
 Regards, H.Storm [TheBluProject]
 
 On 05/04/2014 07:52, Martin Papik wrote:
 Thank you very much Jerzy, however I'm facing some problems.
 I wonder if you have any insight. I'm new to sks, but it
 seems to me that there might be an apache proxy intercepting
 the connections and interfering somehow. I don't see my
 server in 
 http://keyserver.kolosowscy.pl:11371/pks/lookup?op=stats, but
 the sks servers are talking to each other on 11370 so I'm
 assuming there's some kind of asymmetric setup.
 
 Any help would be appreciated.
 
 Martin
 
 In the log I see  (after incrementing http_fetch_size to 1000
 to reduce the number of entries).
 
 2014-04-05 08:43:40 address for
 keyserver.kolosowscy.pl:11370 changed from [] to [ADDR_INET
 [176.241.243.15]:11370, ADDR_INET 
 [2002:b0f1:f30f::1]:11370] 2014-04-05 08:44:06 6064 hashes 
 recovered from ADDR_INET [176.241.243.15]:11371 2014-04-05 
 08:44:11 Requesting 1000 missing keys from ADDR_INET 
 [176.241.243.15]:11371, starting with 
 0005AB14802673F046EC31CC93AC36DC 2014-04-05 08:44:11 Error
 getting missing keys: Failure(!DOCTYPE HTML PUBLIC
 \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11
 Requesting 1000 missing keys from ADDR_INET
 [176.241.243.15]:11371, starting with 
 29DF15D7EF250667DE9012CDF6891CE7 2014-04-05 08:44:11 Error
 getting missing keys: Failure(!DOCTYPE HTML PUBLIC
 \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11
 Requesting 1000 missing keys from ADDR_INET
 [176.241.243.15]:11371, starting with 
 54ABD9C187E4555DB2377ABFCD29D8B8 2014-04-05 08:44:11 Error
 getting missing keys: Failure(!DOCTYPE HTML PUBLIC
 \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11
 Requesting 1000 missing keys from ADDR_INET
 [176.241.243.15]:11371, starting with 
 7E819BE55160DDBD06E480F74F1D6017 2014-04-05 08:44:11 Error
 getting missing keys: Failure(!DOCTYPE HTML PUBLIC
 \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11
 Requesting 1000 missing keys from ADDR_INET
 [176.241.243.15]:11371, starting with 
 A7E5518397DB6A961E9FB8B59C1391D6 2014-04-05 08:44:11 Error
 getting missing keys: Failure(!DOCTYPE HTML PUBLIC
 \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12
 Requesting 1000 missing keys from ADDR_INET
 [176.241.243.15]:11371, starting with 
 D348A85B40F5C08C3CA2E9AB09EF2CB0 2014-04-05 08:44:12 Error
 getting missing keys: Failure(!DOCTYPE HTML PUBLIC
 \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12
 Requesting 64 missing keys from ADDR_INET
 [176.241.243.15]:11371, starting with 
 FD40B34ECD8971CFCECF9E79D48772F0 2014-04-05 08:44:12 Error
 getting missing keys: Failure(!DOCTYPE HTML PUBLIC
 \-//IETF//DTD HTML 2.0//EN\)
 
 The tcpdump output contains (looks like HTTP 0.9, no host
 header in the request, no HTTP headers in the response).
 
 Request to 176.241.243.15:11371
 
 POST /pks/hashquery content-length: 24
 
 Response from 176.241.243.15:11371
 
 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
 htmlhead title502 Proxy Error/title /headbody
 h1Proxy Error/h1 pThe proxy server received an invalid
 response from an upstream server.br / The proxy server
 could not handle the request ema 
 href=/pks/hashqueryPOSTnbsp;/pks/hashquery/a/em.p
 Reason: strongError reading from remote
 server/strong/p/p hr addressApache Server at
 keyserver.kolosowscy.pl Port 80/address /body/html
 
 
 
 
 On 04/05/2014 04:21 AM, Jerzy Ko?osowski wrote:
 Hi,
 
 I added your server. My line to add:
 
 keyserver.kolosowscy.pl 11370 # Jerzy Kolosowski 
 je...@kolosowscy.pl
 
 Rgds,
 
 Jerzy Ko

Re: [Sks-devel] status page

[Tobias Frei]

Hi,

from the status page you've linked:

Latest status: Not OK
Reason: Not running a reverse proxy


Best regards,
Tobias Frei

Am 17.04.2014 01:13, schrieb Simon Lange:
 Hi,
 
 im a it supprised. i just stumbled over: 
 https://sks-keyservers.net/status/info/keys.s-l-c.biz
 
 which says that my keyserver was last seen three days ago. im not 
 enlisted anymore and the status page cannot even say what server
 im running etc etc
 
 im a bit wondered. why? i can reach it via 11370 11371 and 443
 
 proof? simon@entertain:~$ gpg --keyserver hkp://keys.s-l-c.biz
 --search-key m...@simonlange.eu gpg: searching for
 m...@simonlange.eu from hkp server keys.s-l-c.biz (1) Simon
 Lange m...@simonlange.eu 2048 bit RSA key BDD503BE, created:
 2009-09-04 Keys 1-1 of 1 for m...@simonlange.eu.  Enter
 number(s), N)ext, or Q)uit 
 
 works like charme.
 
 via browser? see attachment (screenshot). works too. ;)
 
 recon works too 2014-04-17 01:12:04 Beginning recon as server,
 client: ADDR_INET [162.243.102.241]:59001 2014-04-17 01:12:04
 Joining reconciliation 2014-04-17 01:12:04 Reconciliation complete 
 2014-04-17 01:12:04 2 hashes recovered from ADDR_INET 
 [162.243.102.241]:11371 2014-04-17 01:12:04
 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:04
 1177F736C69004B45FA475ACB149F894 2014-04-17 01:12:04 Disabling
 gossip 2014-04-17 01:12:14 Requesting 2 missing keys from
 ADDR_INET [162.243.102.241]:11371, starting with
 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:14 2 keys
 received
 
 
 so why is my server not enlisted anymore? what are the exactly port
 protocols you are checking?!
 
 id like to prevent such a status page although keyserver is still
 up n running. oO
 
 thanks for your help
 
 Simon
 
 
 
 
 ___ Sks-devel mailing
 list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] status page

[Tobias Frei]

Hi,

maybe you need to send a correct Via: header to allow automatic
detection of the reverse proxy. If proxying is done completely
transparent, there is probably no way to see that there is actually a
proxy in front of sks. That's what I would assume, at least.


Best regards,
Tobias Frei


Am 17.04.2014 16:20, schrieb Simon Lange (BIT):
 well, but there IS a reverse proxy. ;)
 
 tcp0  0 78.46.21.218:11371  0.0.0.0:*  
 LISTEN  8804/lighttpd
 tcp0  0 127.0.0.1:11371 0.0.0.0:*  
 LISTEN  10018/sks
 tcp6   0  0 2a01:4f8:201:22e3:11371 :::*   
 LISTEN  8804/lighttpd
 
 
 Am 2014-04-17 15:56, schrieb Tobias Frei:
 Hi,

 from the status page you've linked:

 Latest status: Not OK
 Reason: Not running a reverse proxy


 Best regards,
 Tobias Frei

 Am 17.04.2014 01:13, schrieb Simon Lange:
 Hi,

 im a it supprised. i just stumbled over:
 https://sks-keyservers.net/status/info/keys.s-l-c.biz

 which says that my keyserver was last seen three days ago. im not
 enlisted anymore and the status page cannot even say what server
 im running etc etc

 im a bit wondered. why? i can reach it via 11370 11371 and 443

 proof? simon@entertain:~$ gpg --keyserver hkp://keys.s-l-c.biz
 --search-key m...@simonlange.eu gpg: searching for
 m...@simonlange.eu from hkp server keys.s-l-c.biz (1) Simon
 Lange m...@simonlange.eu 2048 bit RSA key BDD503BE, created:
 2009-09-04 Keys 1-1 of 1 for m...@simonlange.eu.  Enter
 number(s), N)ext, or Q)uit 

 works like charme.

 via browser? see attachment (screenshot). works too. ;)

 recon works too 2014-04-17 01:12:04 Beginning recon as server,
 client: ADDR_INET [162.243.102.241]:59001 2014-04-17 01:12:04
 Joining reconciliation 2014-04-17 01:12:04 Reconciliation complete
 2014-04-17 01:12:04 2 hashes recovered from ADDR_INET
 [162.243.102.241]:11371 2014-04-17 01:12:04
 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:04
 1177F736C69004B45FA475ACB149F894 2014-04-17 01:12:04 Disabling
 gossip 2014-04-17 01:12:14 Requesting 2 missing keys from
 ADDR_INET [162.243.102.241]:11371, starting with
 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:14 2 keys
 received


 so why is my server not enlisted anymore? what are the exactly port
 protocols you are checking?!

 id like to prevent such a status page although keyserver is still
 up n running. oO

 thanks for your help

 Simon




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



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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] status page

[Tobias Frei]

Er, sorry, I see you already do that. Then maybe the automatic
detection failed for whatever reason.

And I just noticed that your status changed to OK. Weird^^


Best regards,
Tobias Frei

Am 18.04.2014 13:30, schrieb Tobias Frei:
 Hi,
 
 maybe you need to send a correct Via: header to allow automatic 
 detection of the reverse proxy. If proxying is done completely 
 transparent, there is probably no way to see that there is actually
 a proxy in front of sks. That's what I would assume, at least.
 
 
 Best regards, Tobias Frei
 
 
 Am 17.04.2014 16:20, schrieb Simon Lange (BIT):
 well, but there IS a reverse proxy. ;)
 
 tcp0  0 78.46.21.218:11371  0.0.0.0:*
  LISTEN  8804/lighttpd tcp0  0 127.0.0.1:11371
 0.0.0.0:* LISTEN  10018/sks tcp6   0  0
 2a01:4f8:201:22e3:11371 :::* LISTEN  8804/lighttpd
 
 
 Am 2014-04-17 15:56, schrieb Tobias Frei:
 Hi,
 
 from the status page you've linked:
 
 Latest status: Not OK Reason: Not running a reverse proxy
 
 
 Best regards, Tobias Frei
 
 Am 17.04.2014 01:13, schrieb Simon Lange:
 Hi,
 
 im a it supprised. i just stumbled over: 
 https://sks-keyservers.net/status/info/keys.s-l-c.biz
 
 which says that my keyserver was last seen three days ago. im
 not enlisted anymore and the status page cannot even say what
 server im running etc etc
 
 im a bit wondered. why? i can reach it via 11370 11371 and
 443
 
 proof? simon@entertain:~$ gpg --keyserver
 hkp://keys.s-l-c.biz --search-key m...@simonlange.eu gpg:
 searching for m...@simonlange.eu from hkp server
 keys.s-l-c.biz (1) Simon Lange m...@simonlange.eu 2048
 bit RSA key BDD503BE, created: 2009-09-04 Keys 1-1 of 1 for
 m...@simonlange.eu.  Enter number(s), N)ext, or Q)uit 
 
 works like charme.
 
 via browser? see attachment (screenshot). works too. ;)
 
 recon works too 2014-04-17 01:12:04 Beginning recon as
 server, client: ADDR_INET [162.243.102.241]:59001
 2014-04-17 01:12:04 Joining reconciliation 2014-04-17
 01:12:04 Reconciliation complete 2014-04-17 01:12:04 2 hashes
 recovered from ADDR_INET [162.243.102.241]:11371 2014-04-17
 01:12:04 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17
 01:12:04 1177F736C69004B45FA475ACB149F894 2014-04-17 01:12:04
 Disabling gossip 2014-04-17 01:12:14 Requesting 2 missing
 keys from ADDR_INET [162.243.102.241]:11371, starting with 
 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:14 2 keys 
 received
 
 
 so why is my server not enlisted anymore? what are the
 exactly port protocols you are checking?!
 
 id like to prevent such a status page although keyserver is
 still up n running. oO
 
 thanks for your help
 
 Simon
 
 
 
 
 ___ Sks-devel
 mailing list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 
 
 
 ___ Sks-devel
 mailing list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 
 
 
 
 ___ Sks-devel mailing
 list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] status page

[Tobias Frei]

Hi,

sorry for my naivity, but I can't really think of a scenario where it
would be a problem that your PGP keyserver (and only that one,
keys.s-l-c.biz) is accessible under any other domain name.

If your keyserver is accessible at insert-racist-domain-name-here.tld,
so what? Does that make you a racist? Does that make the keyserver racist?

I personally don't really get that logic.


Best regards,
Tobias Frei

Am 18.04.2014 21:37, schrieb Simon Lange:

 i prefer that because that way i can avoid that ppl use my services with
 their fqdn i dont like (like raccists facists and other bad ppl).
 
 i opened it temporaly so we are enlisted in the pool again. but in a
 couple of days i close that door again allowing ONLY those fqdm who did
 contact me before. so i got at least a minimum control who is using my
 services with their fqdn and who not. ;)
 in a couple of days the fqdn written above will work. others not.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] status page

[Tobias Frei]

Hi,

okay, I hope I don't need to explain why this e-mail caused me to remove
you, Simon Lange, from my peering list.

It makes me sad to see such childish behavior on a mailing list like
this one.

btw, ur english doesnt make u look more kewl. c y?


Best regards,
Tobias Frei


Am 19.04.2014 02:21, schrieb Simon Lange:
 
 Am 18.04.2014 23:16, schrieb Phil Pennock:
 On 2014-04-18 at 20:24 +0200, Simon Lange wrote:
the reason why a reverse proxy is required is, because some
 require additional security at the nodes.
 
 False.
 ehm. nope. thats is what ive been told when i asked y the reverse proxy. ;)
 but good to know. :=)
 
yesterday i learned i
 have to give up control who is using his domain with my services. :/
 
 False.  As long as you can find people who will peer with you, you do
 not need to be in any pools at all.
 
 thats not the topic. and its rude btw.
 
 
 currently for :80 i do accept all for ^(.*)pool.sks-keyservers.net and
 
 Note that Kristian's pool is considered well-run and is used as the
 target of CNAMEs by other people.  Most notably, `keys.gnupg.net` is a
 CNAME to `pool.sks-keyservers.net`.
 
 So if you only whitelist for a pattern which, when unbroken, is:
 
  ^(?:.+\.)?pool\.sks-keyservers\.net
 
 then you've broken access by people using the default configuration of
 GnuPG.  Kristian doesn't want those people to experience a broken
 service, so you don't get listed.
 
 and that is written where exactly? see? thats why i req techdoc?!
 but keys.gnupg.net is already covered too. ;)
 
 
 Kristian _could_ decide to only support certain CNAMEs, then
 exhaustively test for all of those working, then going through the
 song-and-dance of de-listing most sites when he adds one more CNAME.
 Instead, he just says to be listed in my pools, then on port 11371, all
 HTTP requests under `/pks/` should be passed to SKS, no matter what is
 in the Host: header.  This creates less stress, less bureaucracy, less
 of a culture of having to ask permission for every action.
 
 allowing ALL is not a really good option. i already explained y. and a
 page with techdoc which hostnames should be allowed is not much.
 y using less procedure for pool reg than for gossip? whats the point
 with this? because less bureaucracy? less stress?
 i dont think its much stress and bureaucracy to tell ppl what hostnames
 should be able to use the service.
 
 
 domains using our services. its a matter of respect AND security. its an
 optin feature not a optout.
 
 Absolutely: you don't need to be listed in a pool, there is no hard
 requirement for it.
 
 right and you dont need to learn anything anymore since u know
 everything. oh wait. ;)
 try being less rude and try please to follow arguments.
 
 
 _I_ won't give away _my_ bandwidth for free to provide others with keys
 if they're not giving back to the community by being listed in public
 pools.  That's my choice, in not subsidising other peoples' businesses
 and hobbies from my own pocket more than I already do with my time on
 open source projects.
 
 that just proved that you didnt understand anything i wrote. this is not
 against good ppl. you dont protect your servers and your environment
 against good ppl. you protect it against bad ppl. so hard to
 understand?!
 and exactly THATS WHY i dont allow fqdn like keys.npd.de to use my
 keyserver. i dont support racist or inhuman parties/organizations. if
 you dont care for your community. okay. but for ppl who do care, its a
 maybe a problem to allow those ppl to advertise with services which are
 not run by them.
 
 all others are invited. gimme a short notice and i put them on. thats
 the concept of optin. this is how you configure firewalls too. deny all
 and tell whats allowed. in this case easy to do. thats why i really dont
 unerstand ur attitude.
 
 
 
 That's okay.  You and I don't have to peer.  There is no one right way,
 
 nobody talks about peering. m)
 
 no authority saying everyone must peer, no right to peering, no
 expectation that everyone agree.
 
 m)
 
 
 You can probably find other people who will peer with you.
 
 you dont get it. the topic is NOT peering. m)
 
 
 (11371). there is absolutely no reason for a via (which may exposes the
 used software)
 
 You don't need to expose full version, but revealing Apache/2 provides
 enough for most debugging.  If revealing even that much makes you
 vulnerable, then you have bigger problems, because more intrusive
 platform fingerprinting by those of malicious intent will identify your
 platform anyway.
 
 you are derailing the topic.
 
 
 FQDNs to use that specifiy service. dont allow anyone except fqdn which
 did ask before is far more secure. (e.g. i dont want any raccist website
 to advertise with MY services under THEIR domain, but because i cannot
 KNOW all such domains, its better to deny all and allow a few).
 
 Go ahead, use that policy.  Find others who agree, create pool
 definitions

Re: [Sks-devel] status page

[Tobias Frei]

Hi Robert,

I love that story; saved it in my Documents folder! :D

When one of my female friends refers to me or another male friend, they
usually use Kumpel (buddy) as workaround term for this problem.
Another possibility is:
Das ist ein Freund von mir (that's a friend of mine)
The ein (a / one) in this example sentence implies that it won't be a
boyfriend (because that usually wouldn't be one of many other boyfriends).

For female friends, I have no equivalent to Kumpel which I could use
as replacement. Instead, I either try to use the female version of the
example sentence above:
Das ist eine Freundin von mir (that's a [female] friend of mine)
...or, if that is applicable, I use gute Freundin (good [female]
friend), which also implies that I'm not referring to a girlfriend. :)


Best regards,
Tobias Frei


Am 20.04.2014 17:43, schrieb Robert J. Hansen:
 You've seemingly overlooked that the message was typed on a cell and
 the autocorrect isn't designed for English. 'This message was sent from
 my Android phone via K-9 Mail.' And because you instantly become
 personal in your first post and aren't engaging with the real issues,
 you're dead as a conversational partner to me.
 
 Ah, thank you for the correction!  :)
 
 With respect to the German language -- I spent a good bit of my 18th and
 19th years in Saxony, and it literally changed my life.  I found Germany
 to be a warm and welcoming place, and the vast majority of your
 countrymen were kind to me.  I haven't been back since, although I'd
 like to.
 
 And what the hell.  This list has had enough drama and bad feelings as
 of late, so I'll share a funny story from Hildesheim.
 
 ---
 
 I was on a bus with my host sister, who had a major English test the
 next day.  She asked if we could speak English so that she could get
 some practice in before the Prüfung, so there we were chatting away.
 Sitting across from us was a mother with her young daughter, and the
 girl's eyes were wide as saucers as she watched me.
 
 She tugged on her mother's sleeve and whispered to her, Mutti, Mutti!
 Ein Ausländer!  Hier!  Er ist Ausländer!
 
 For non-German speakers, that's a pretty rude thing to say.  Mom, Mom!
  A foreigner!  Here!  He's a foreigner!  My host sister and I gave her
 a quizzical we're right here and we can hear you look, her mother made
 fulsome apologies, and tried to hush her daughter.
 
 The daughter just repeated it, louder, so everyone on the bus could
 hear.  The mother looked as if she was about to die of embarrassment.
 
 Finally I spoke to the little girl directly.  Ich bin nicht 'ein
 Ausländer,' I said, scare-quoting the phrase with my fingers.  Ich bin
 Amerikaner, ein Exchangestudent, und ein Freund zu meiner Freundin.
 
 My host sister elbowed me suddenly and I knew I'd committed some gaffe,
 but I went on anyway.
 
 Ich bin Robert.  Was ist deine Name?  Wer ist deine Mutti?
 
 The little girl looked as if I'd just slapped her.  She turned away,
 stuck her nose high in the air, and said in an imperious voice --
 /That's/ all right.  /I/ speak /English/.  She looked like a little
 queen, really, and her accent was straight-up Alistair Cooke.
 
 The entire bus broke out laughing.  After the laughter subsided I asked
 my host sister what was wrong.  Nothing, she said irritatedly.  You
 just kind of implied we're dating.  I'm your Freundin?
 
 I blinked.  What?  It's the feminine of Freund...
 
 Yes, and it's used for girlfriends.
 
 So what's used for friends who happen to be women?
 
 Freundin, of course.
 
 I shook my head.  But it's the /same word!/
 
 She shrugged.  It's more about how you say it, I guess.
 
 I stared at her a moment.  Your language makes absolutely no sense, you
 know that?
 
 She gave me a glower and a smile.  This, from the English-speaker.
 
 The bus had a second round of laughter over that.  :)
 
 ___
 Sks-devel mailing list
 Sks-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413

[Tobias Frei]

Hi,

thanks for the information; I have now updated my nginx configuration. :)

Best regards,
Tobias Frei



Am 28.04.2014 18:25, schrieb Kristian Fiskerstrand:
 I've received reports that uploading some (large) keys to some of the
 keyservers in the pool (my test shows failure on 30 servers after
 trying to run against 115: These are listed in [A]) results in a
 gpgkeys: HTTP post error 22: The requested URL returned error: 413
 Request Entity Too Large
 
 In this case the Content-Length is 1377406, seemingly exceeding the
 default nginx configuration. The fix for nginx is to set
 client_max_body_size 2m; (or larger) in the http context of nginx.conf.
 
 I have not yet implemented an automated check for this in the pool
 (and a bit unsure how I'd do it without actually sending large amount
 of data to the server during the check, something I generally want to
 avoid), but might run a semi-manual / scripted check and add affected
 servers to the blacklist if the issue persists after some time.
 
 gpg2 --send-key DE7AAF6E94C09C7F can be used to test.
 
 Please consider re-configuring the servers accordingly.
 
 [A] non-exhaustive list of servers affected
 sks.spodhuis.org
 zimmermann.mayfirst.org
 vm-keyserver.spline.inf.fu-berlin.de
 keyserver.mesh.deuxpi.ca
 sks.fidocon.de
 keys.exosphere.de
 keys.sflc.info
 pgpkeys.mallos.nl
 keyserver.uz.sns.it
 openpgp.andrew.kvalhe.im
 pgp.gmu.edu
 keyserver.compbiol.bio.tu-darmstadt.de
 keys2.alderwick.co.uk
 keys.alderwick.co.uk
 keyserver.advmapper.com
 sks.undergrid.net
 keys.jhcloos.com
 sks.alpha-labs.net
 pgpkey.org
 keys.indymedia.org
 pgp.freiwuppertal.de
 keyserver.linuxpro.nl
 keyserver.secure-u.de
 sks.stsisp.ro
 key.ip6.li
 keys-01.licoho.de
 key.adeti.org
 keys-02.licoho.de
 keyserver.durcheinandertal.ch
 keyserver.blupill.com
 
 
 --
 
 Kristian Fiskerstrand
 Blog: http://blog.sumptuouscapital.com
 Twitter: @krifisk
 
 Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
 fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
 
 Varitatio delectat
 Change pleases
 
 ___
 Sks-devel mailing list
 Sks-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seeking peers for sks.static.lu

[Tobias Frei]

Hi,

you might want to generate these statistics when the daemon starts:
http://j.mp/sksinitstats

Also, making the web interface available at port 80 might be nice. :-)

Do you have a reverse proxy running in front of the HKP port (11371)
already, too? I'm unable to find a Via: header.
http://j.mp/sksperformance



Best regards,
Tobias Frei


Am 02.05.2014 14:30, schrieb Martin A.:

 Waiting for stats to get the number of imported keys.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Seeking peers for sks.static.lu

[Tobias Frei]

Hi,

thank you for the information - that's bad news to me. :(

Assuming that GnuPG was dead, what would be the implications? What would
be a good free replacement which also supports ECC (one day)? :/

Best regards,
Tobias Frei

Am 03.05.2014 01:55, schrieb benf...@parts-unknown.org:
 Tobias Frei writes:

 The key will change (hopefully) soon, when GnuPG introduces ECC keys. I
 will then add some other new servers to my membership list, too. Of
 course, I will send an email to the list when my key changes.
 
 It's entirely too possible somebody knows something I don't, but I
 wouldn't hold my breath on this. The ECC code has been out there for a
 couple years, supposedly it's in gnupg 2.1, which has apparently been in
 beta for a couple years, and this development cycle is moving so slowly
 that I'm inclined to call it dead.
 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] (no subject)

[Tobias Frei]

Hi Jonathan,

as far as I know, most keyservers which offer dumps update them weekly.
However, if these dumps don't take longer than 24 hours (that should
hopefully be the case, although David Benfell mentioned that dumps
[are] taking progressively *much* longer than 8 minutes over time), I
see no reason not to create them every day if you want to do so. It
might be a waste of resources, but if that's okay because nothing else
runs on the server, why not?^^

You just might want to consider switching to a cheaper server with less
powerful hardware one day, I think. If you have enough spare resources
to create daily dumps, this sounds to me like you're investing too much
for a server which is only meant to serve PGP keys. :/


Best regards,
Tobias Frei

Am 13.07.2014 12:50, schrieb Jonathan Zhang:
 [...] Is taking daily dumps reasonable? I'm not running anything else
on that machine. Suggestions welcome.


[Sorry for the double e-mail, I forgot to send the answer to the list
instead of using a simple reply :)]



smime.p7s
Description: S/MIME Cryptographic Signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Not ok??

[Tobias Frei]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[Edit: First of all, please get rid of that SORBS blacklist or switch
to an email provider that does not make use of this shitty nonsense.
Do not expect to receive any answers to your e-mails if your email
provider makes use of this aggressive, irrational blacklist.

You might not even receive this e-mail; I already failed sending it
through my perfectly fine paid email provider. Someone using the SORBS
blacklist should probably not even run a mailserver.

This is a (sadly German) article about the SORBS controversy:
http://heise.de/-1152258

This English one mentions it in the second paragraph, at least:
http://www.theregister.co.uk/2009/11/06/sorbs_sold/ ]

Hi David,

please have a look at your status page:
https://sks-keyservers.net/status/info/keyserver.dacr.hu

There seem to be at least three problems with the server:

- - it is vulnerable to a critical bug; you should probably update your
SKS software.
- - it does not seem to respond to the status queries (at least the
status page states that as reason)
- - your server is missing 3,753,402 keys.

Please read the following page to see the first needed steps to create
a server that can be used in the pool:
https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

Specifically, you'd need to import a keydump.
https://bitbucket.org/skskeyserver/sks-keyserver/wiki/KeydumpSources


Best regards,
Tobias Frei


Am 27.10.2014 um 18:16 schrieb Horváth Dávid:
 Hi,
 
 my server is available but the pool status page say that it is not
 OK. What is the problem?
 
 My status: 3753535 Pool's median: 3753549
 
 Regards, David
 
 
 ___ Sks-devel mailing
 list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUTolDAAoJEOaAxTHjKzK7TnAP/is/ImpMWEDAbMegcSEgLgkx
yp1UTzF/qVipJJKv0MPM0xO17ZoPn1gSqXON7coWxtqYJlKL5FciuWdJL2E4/5zU
GSKuy1CuhcW2iKnDc5+LEW0EYtTaJZ24vn+fAkQeKS0iLuB2GIJGZUnDJ0bjvcpB
WC/VqK8VeNhIPIEzryo5PeyiwA0yczIV0tgjxge18OrE/V/cRDb+bMpfgii9c66A
EMcguWyf69A1gAhC9lPX9WcIDLabJ5hsK96J7TqIUtts4F3/lpi2gRoed6jUweM5
JaBV04NTKKOAetjpIXFTfjq0EHPitOizkt/a2rpOh2KllpgK1+0oVuW/q6XLWMMX
vuyYS9ve7MLQc/CIQi2MMn5Jt6Xsm5l3zF3JD80RvImtWndDFn+5lhQs7EKXQup6
BJCo+NIa1xzr1TtvkcKqi9o0S4to0D1Z8CJlmEiDDwhroOL3v29HOy45NbinSSE7
GJA9+6Y6yKsdriL9yOpCLdtu2HzBPU+kiKVdAIV+NTRaTqKkzpCWzuzoovFeIJ5U
BX48T+3R6Q596/4EN3EWerLqxk6qhaAus4fqiqfa4kKsHi8np0ai1AEaLKuNZxd4
nQj1CPF6UIDrbHxaEFzYoaQctXblGOJ4FAzFImADW5APYad4sTpJiMSfcd3UijLS
IAcv/PnYK3sOFTblmqPV
=R7Sw
-END PGP SIGNATURE-

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

Re: [Sks-devel] Not ok??

[Tobias Frei]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi^^

I'm sorry for my weird response; such blacklists happen to be my
personal pet peeve. :/
Once I tried to report a (D)DoS attack at the abuse@ address of a
server that caused each of its clients to download thousands of copies
of a website I'm administrating, and the automatic response just was
that both Gmail, my paid email provider and whatever else I tried were
blacklisted. Maybe that caused me to have a general aversion to
aggressive email blacklists. I see that there might actually be
reasons for using such lists; just using them in this case just seems
to be wrong and causes legitimate email to be dropped for political
reasons which I will probably never understand.

About the status page that now shows that everything is fine: If it
was like that before, I assume it was caused by caching delays. :)

If you're looking for peers, feel free to add this line to your
membership configuration file:

pgp.freiwuppertal.de 11370 # Tobias Frei tob...@freiwuppertal.de

If you do so, I'd need your line in return, so that I can add it to my
own configuration.

The line does not contain a key fingerprint because I currently have
no long-term GPG key. I'm waiting for GPG to add support for elliptic
curves. :D


Best regards,
Tobias Frei




Am 27.10.2014 um 19:25 schrieb Horváth Dávid:
 Hi,
 
 Vulnerable to CVE-2014-3207: No Latest status: OK Last status
 change: 2014-10-27 17:37
 
 Hm Atmospheric front was... :)
 
 David
 
 
 
 2014. 10. 27, hétfő keltezéssel 19.11-kor Tobias Frei ezt írta:
 Oh, this irony. =P
 
 Dear Ari,
 
 my message was definitively not SPAM. I assume the large amount
 of links made it seem like that. Maybe even the PGP signature, so
 I'm omitting that.
 
 Best regards, Tobias Frei
 
 Am 27.10.2014 um 19:05 schrieb Ari Trachtenberg:
 My profound apologies but your e-mail has ended up in my Spam
 folder.  If this has occurred in error, please either e-mail me
 again with a distinctive, individual e-mail or else call me at 
 my office number so that I may manually fix my spam filter.
 
 Again, my apologies if you receive this e-mail in error - I
 have a rather aggressive spam filter due to the large number
 of e-mails that I receive.
 
 Many thanks, -Ari
 
 --- 179424673
 
 
 ___ Sks-devel mailing
 list Sks-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/sks-devel
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUTqkfAAoJEOaAxTHjKzK77dUP/ii9S0zuyvbkI2oyv20DVsuI
WkYO452YefqMILl3iCP1C48cYt8nyhlAHlBSKTvv3xHB1CFOS3KNKx97q89FavDj
39SFD4MJ0FrnKaf03cna+T0Ry6/cHKY911Czq+8p9fR0IWC5pGLJFxjqJWhZb7Lp
POG2ZPwmb5yTBSp6zIsPQynPhb0hpKC5FiJ3olDfqZLmUkUVwS7zWbK43KuHsVU/
V+weexsCN6BQ1o0+9GTxy/LHkUlXIw0dkKAtOYtUGvqCjFFd5bnr9u+sKIKZm7kL
YsTrQD2pNo1dVfpAMrB6UMSGW3ve2oUB4CiATmNmaYKJnc9bykrcn3KcA5tkJzEa
NShqUmBTrzgV85nF4yx9/JkPE6t98Xv37c0ODMRxwSX68b8/DYeM61g2MyZXTuvY
NJpyP+9adi5EIqou5Are4lEf7sK9p1SgZ+w5TIdrInJRE/alrOgu45ojyGOeaJBU
HJBc1zH8ztga6JL9CsQWgtsPE5OBlwXVzn/NI/aH7PD5Rdfjca8YoN4VoEfW8KpU
X8s4oNt//L4uBURUX+dcISNHmb7Hkto5OwOzY0K+vdjAw+OurWmFMWbgUuF8KbN8
nRzuLw2Y7kS3sZFM98zRDp1izTSA1zZSeRRtF/WYX6A5Xex6BQcqWSZ1IjSFXyfy
IqJS6iGsBbhGoSM0am6M
=gp3u
-END PGP SIGNATURE-

___
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

[Tobias Frei]

Hey David,

it makes me sad to see you leaving the pool, and I really hope that you'll
try to run SKS again in a few years, when the relevant problems might be
solved and bugs have been fixed. See you; don't leave us forever! :)

Best regards,
Tobias Frei

On Sat, Apr 11, 2015, 01:31 David Benfell benf...@parts-unknown.org wrote:

 Quoting Michael Sinatra michael+li...@burnttofu.net:

  On 04/10/15 15:44, David Benfell wrote:
 
  I'm giving up.
 
  When there is an sks that uses a reliable database system, I'll be happy
  to rejoin. But Berkeley DB is not sane in my environment, has never
  proven scalable in any environment I've had in the past, and I'm not
  messing with it any more.
 
  I had terrible stability problems when trying to run an SKS server on a
  VM platform (VMware ESXi 5.x).  Once I moved it to standalone hardware,
  it has been rock solid.
 
  Just a datum--not trying to talk you out of it...

 This is on the biggest, most powerful server I've ever owned, a
 relatively new system--not a VPS.

 If I have to give sks its own system, then I can't run it anyway. I'm
 happy to be generous with what I have, but when it comes to buying a
 system just for sks, that's more than I can do.

 Thanks!

 --
 David Benfell benf...@parts-unknown.org
 ___
 Sks-devel mailing list
 Sks-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/sks-devel

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

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

[Tobias Frei]

Hi,

to be honest, it somehow makes me happy that we're finally being forced to
find a solution for this. It could have started worse.

I think the only reasonable solution is that every server operator gets a
local blacklist that can be filled with keys / signatures / regex etc. and
that only prevents matched entries from being saved to the database. To
remove a key from all servers, all operators would need to add it to the
blacklist then. This prevents abuse of the mechanism while giving easy,
effective control over the own database to every server operator.

We could then discuss or suggest entries for the blacklist that everyone
should add, but it would be the responsibility and choice of every admin to
follow the suggestions.

Best regards,
Tobias Frei

On Tue, May 24, 2016, 06:34 Kiss Gabor (Bitman) <ki...@ssg.ki.iif.hu> wrote:

> Guys,
>
> Have you remembered I'm continuosly worrying about
> trolls pumping 10-20 millions of dummy keys into key servers?
> It is started...
>
> http://keys.niif.hu/pks/lookup?op=vindex=0x0B7F8B60E3EDFAE3
> (Scroll over the whole page.)
>
> So we must hard think how to delete keys/signatures.
>
> Gabor
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Tobias Frei]

Hi,

Adding proof of work can only prevent an attack that depends on a huge
number of useless keys. Someone else once mentioned that a single key with
an illegal image ID can already cause huge problems, and deleting such a
key can become the only way to be legally allowed to continue running a
keyserver.

About lacking keys, well, if the pool selection mechanism causes working
keyservers to be removed, that's a separate problem that needs to be solved
after this one, I think. It should not be an argument for or against this
suggestion, but instead needs to adapt to the current situation.

Best regards,
Tobias Frei

(sorry, I accidentally sent this as direct reply instead of list reply
before)

On Tue, May 24, 2016, 17:00 Pascal Levasseur <pascal.levass...@topette.eu>
wrote:

> Le 24/05/2016 06:33, Kiss Gabor (Bitman) a écrit :
> > Guys,
> >
> > Have you remembered I'm continuosly worrying about
> > trolls pumping 10-20 millions of dummy keys into key servers?
> > It is started...
> >
> > http://keys.niif.hu/pks/lookup?op=vindex=0x0B7F8B60E3EDFAE3
> > (Scroll over the whole page.)
> >
> > So we must hard think how to delete keys/signatures.
> >
> > Gabor
> >
> > ___
> > Sks-devel mailing list
> > Sks-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/sks-devel
> >
>
> Can we add a proof of work mechanism to make adding a key to the server
> more "costly" ?.
>
> Pascal
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Request: Install an efficient robots.txt file

[Tobias Frei]

Hi,

If you don't want your name to appear on Google, don't upload it to a
service that permanently spreads it to hundreds of public websites.
Especially don't rely on every server admin to "block" crawlers from these
pages, because this fails as long as at least one admin doesn't.

Have a nice day anyway.

On Tue, Jun 20, 2017, 10:36 robots.txt fan 
wrote:

> Dear Sirs and Madams,
>
> I would like to thank all of you for doing this. You are a necessary
> pillar to PGP and it is awesome that you are there to provide the
> infrastructure to host everyone's key.
>
> Without attempting to diminish the previous sentence, I have a request to
> make to some of you.
>
> Most of the SKS serve an efficient robots.txt that prevents everyone's
> un-deletable name and email showing up on search engines. However, there
> are some exceptions. I like to keep a low profile, but when searching for
> my name, for example on Google, a significant amount of results are from
> SKS pages, or to be more specific, these:
>
> keyserver.nausch.org
> pgp.net.nz
> pgp.circl.lu
> keyserver.rayservers.com
> sks-keyservers.net
> keyserver.mattrude.com (special case: blocks /pks, but not /search, a
> non-standard (?) directory)
>
> I would like to ask the owners of these pages to take the time to install
> an efficient robots.txt file, for example something like this:
>
> User-agent: *
> Disallow: /pks/
>
> To all others, I would like to ask you to take the time to check if your
> server serves an efficient robots.txt file, and if it does not, to please
> install one.
>
> If there is any doubt that a robots.txt file is a good idea, I can
> elaborate on that.
>
> Thank you for your time.
>
> RTF
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Request: Install an efficient robots.txt file

[Tobias Frei]

Hi robots.txt fan,

I just wondered what happened if I removed robots.txt from my server, to
reduce the whole discussion to absurdity. :)

Best regards,
ToBeFree

On Thu, Jun 22, 2017, 13:08 Kristian Fiskerstrand <
kristian.fiskerstr...@sumptuouscapital.com> wrote:

> On 06/22/2017 10:40 AM, robots.txt fan wrote:
> > Kristian, you have responded to this thread, I believe you manage the
> first one on the list. Is there a reason why only /status is blocked and
> not /pks?
> >
> > https://sks-keyservers.net (blocks /status, but not /pks)
>
> The real reason is that /pks didn't exist when the robots.txt file was
> created, so I've [added it now], granted more for site resource
> management reasons than privacy reasons.
>
> From a privacy perspective robots.txt doesn't make sense, the data is
> already public, bad actors ignore robots.txt and crawl the site just the
> same; and the full data set is available and part of regular workflow
> for bootstrapping own servers.
>
> References:
> [added it now]
>
> https://git.sumptuouscapital.com/?p=sks-keyservers-pool.git;a=commit;h=b98e7522990961541165dfc23781a45a1a5e05a9
>
> --
> 
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> 
> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> "Whatever you do in life, surround yourself with smart people who'll
> argue with you."
> John Wooden
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Maintenance on sks.neel.ch

[Tobias Frei]

Hi :)

About these short maintenance emails, I've always wondered... no offense,
but what is the use of this information? If one of my many peer servers
does not respond, and it's not for many days or months, where is the
problem? It could be an unexpected downtime as well as a scheduled
maintenance - the other SKS servers won't have a problem with it, would
they? :)

I personally do not care about temporary maintenance notifications of SKS
servers. I'm not a professional administrator, but what are the others
doing? Monitoring all their peers 24/7 and receiving emergency e-mails when
one of the SKS peers goes down for an hour? What for?

Will the e-mail cause the server to be taken out of the pool for an hour?
That's the only reason I could think of, and if that's it, notifying the
pool admin would be sufficient?

Best regards
Tobias Frei

David Néel <da...@neel.ch> schrieb am Fr., 10. Nov. 2017 um 20:45 Uhr:

> Hi again,
>
>
> Maintenance operation is done. Everything is running smoothly.
>
>
> Have a nice week end.
>
> Best regards,
>
> David Néel
>
> Le 10/11/2017 à 20:16, David Néel a écrit :
>
> Hi folk,
>
>
> sks.neel.ch will be down for maintenance (~1 hour).
>
> VM is moving from one datastore to another (from hdd to ssd)
>
>
> Best regards,
> --
> *David Néel*
> XMPP <da...@neel.ch>
> PGP key <https://sks.neel.ch/pks/lookup?op=get=0x8E7644E0B1C7CFCB>
>
>
> ___
> Sks-devel mailing 
> listSks-devel@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
> --
> *David Néel*
> XMPP <da...@neel.ch>
> PGP key <https://sks.neel.ch/pks/lookup?op=get=0x8E7644E0B1C7CFCB>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Question re: GDPR

[Tobias Frei]

Hi Eric,

http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=GDPR=Search%21=sks-devel=100=normal=date%3Aearly

Hope this helps :)

Best regards
Tobias Frei
...who already gave up running a server when realizing that hosting a huge
distributed unmoderated publicly searchable text- and image-wall for anyone
to abuse is unlikely to be a future-proof concept.

On Sat, May 26, 2018, 01:04 Eric Germann <ekgerm...@semperen.com> wrote:

> Good evening colleagues,
>
> Has anyone explored the implications of GDPR as it relates to keys stored
> on servers in the EU?
>
> Wondering how that all fits in, or how you would even get them out of the
> servers, short of getting the servers out of the EU.
>
> Thx
>
> EKG
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
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

[Tobias Frei]

Hey,

that's a wonderful downtime reason. :D

Congratulations & best regards
Tobias Frei

On Fri, Feb 9, 2018, 20:59 Jeremy T. Bouse <jeremy.bo...@undergrid.net>
wrote:

> On 2/9/2018 10:15 AM, David Néel wrote:
>
> 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!
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Tobias Frei]

Just saying...

...the person who created that key has finally started a long overdue
process. They are likely reading this as well, so: Thank you. This could
otherwise have ended much worse.

To the other readers, but only to those of them who do not agree with the
following sentences: Please avoid trying to fix symptoms. Go for the root
issue, even if it hurts. Don't deny that it does; the whole design of what
you have been taking for granted when you learned about PGP needs to be
fundamentally rewritten. Until that has happened, I personally believe that
every (!) key server administrator should shut down their keyservers, with
no exception.

Users, especially commercial ones, are very welcome to notice the impact of
the sudden lack of a convenient, free service provided as a voluntary
donation by people who are risking their freedom and risking going to jail,
on the users' daily work. Users are very welcome to finally notice the
problem as well, and users are very welcome to contribute suggestions and
code to the further fixing of the fundamentally flawed keyserver network
design.

My personal suggestion: Complete pool shutdown until the underlying problem
is completely fixed. If it can't be fixed, keep the pool offline. It has
been a good, happy time, and one of the next steps can (doesn't have to!)
be realizing that it has irrevocably reached its end.

PGP works without keyservers, by the way. It can't be bad for users to
finally learn how.

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

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

[Tobias Frei]

Hi Ryan,

that would probably be an incomplete mitigation:

-people can use the photo id field instead
-people can use valid e-mail addresses under an own domain ("catch-all")
-your keyserver suddenly can be abused for email spamming

Best regards
Tobias Frei


Am 14.07.2018 um 02:57 schrieb Ryan Hunt:

Could this be mitigated by validating email addresses as they come in? Like 
sending an encrypted mail to the said address with a return token, If the token 
is not provided the key is never put into the SKS rotation?

I think a solution like this would be much more effective, and if there was 
some desire to conform to GDPR at some point it would be pretty much required 
first step because I cannot see how we could possibly remove keys without a 
command signed by that key, and putting this in place would make that ‘no more 
difficult to remove than it was to add’..

Regards,
-Ryan Hunt


On Jul 13, 2018, at 11:20 AM, Phil Pennock  wrote:

Signed PGP part
Heads-up:

https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
https://github.com/yakamok/keyserver-fs
https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under

This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
what appears to be a deliberate attack on the viability of continuing to
run a keyserver.

The author is upset that there's no deletion, so is pissing in the pool.

-Phil





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



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

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

[Tobias Frei]

Hi Kristian, hi Andrew,

that email conversation was scary, informative and relieving at the same
time. Thank you for sharing.

Best regards
Tobias Frei

On Fri, Mar 8, 2019, 16:08 Kristian Fiskerstrand <
kristian.fiskerstr...@sumptuouscapital.com> wrote:

> On 3/8/19 3:19 PM, Andrew Gallagher wrote:
> > 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?
>
> It was a relatively good summary of situation including the data being
> shared voluntarily and the nature of the keyserver gossipping network
> also containing nodes being outside of the reach of GDPR. An important
> factor in the treatment is however timely response to erasure request
> with sufficient information.
>
>
> --
> 
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> 
> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> Corruptissima re publica plurimæ leges
> The greater the degeneration of the republic, the more of its laws
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Tobias Frei]

Hi,

Isn't Mozilla Thunderbird in a similar state? I'm still happily using it
*because* it has reached a point where further updates are rarely needed.

Best regards
Tobias Frei

On Wed, Feb 6, 2019, 14:22 Steffen Kaiser  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I picked up this sentence here on the list in a thread about poison
> key(s):
>
> "> Any chance that sks will be fixed some day?
>
> "Short answer, no. SKS is effectively running as end-of-life software at
> this point. It gets emergency bugfixes but little else. The improvements
> you are talking about would require an enormous refactoring of the
> codebase, likely requiring migration to a different database engine.
> Given that there are fundamental design flaws (poison keys) that aren't
> getting fixed, performance issues just aren't on the radar. Sorry."
>
> Is it meant litterally? The current SKS project is end of life and,
> effectively, we have to look into another direction? Other software, new
> fork with rewrite?
>
> Kind regards,
>
> - --
> Steffen Kaiser
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEVAwUBXFrc6iOjcd6avHZPAQI8iAgAhMVSiTvPdMARX20Kqkt7BQAIFwcnqi/K
> GncegVdHZqf6PkyogVwXxMDxExOm+dJmkyJDD8IOsc6SQW+Tx7YDOcTynLsvFPQ9
> NjehfxC6+O0Himxr1AAm75HZ3oU82e9GMteebbbyLc2pr0ggx7BNtIf81YjCwzxy
> clLLCLZOCb8HAuXBYGi0X7z0iD9511nWQ6vbbpNEuTdz4rv/Fsvgre6SMQ8blYS6
> mYlCsSv8AoL3vFux3E+8gsDUn/uOFzdvL+W6Ei5ETMd4zt4OVfyuGX/P1SBEGl+5
> 7Wfo3ev7F7ZaY7cJy1aOfF9lTKNF8Fuweq+wvBCnhL1B3dLuZ8Gqjw==
> =Id3h
> -END PGP SIGNATURE-
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] A brief recap

[Tobias Frei]

Additional note: Even when restricting append-only mode to the email field,
someone could upload keys for krypton...@domain.org to permanently store
the word "kryptonite" in the database. Also, one could use the first
characters of key IDs to store information, linking the keys together as
signatures or by alphabetical sorting.

00D...
01E...
02A...
03D...
04B...
05E...
06E...
07F...

You couldn't even blacklist them without storing the information in your
blacklist.

Best regards
Tobias Frei

On Thu, Feb 7, 2019, 01:58 Robert J. Hansen  wrote:

> > I disagree that we have to do a trade off, mostly for technical
> > reasons.
>
> Let's call forbidden information 'kryptonite'.  Kryptonite is bad stuff.
>  We don't want it on moral grounds or legal grounds.  We would rather
> shut down keyservers than have kryptonite on our systems.  We then have
> three choices:
>
> * Keep it from entering the system (vetted users, approved submitters)
> * Find a way to purge it from the system (ending append-only)
> * Shut down keyservers
>
> Saying "we can use blacklists to avoid serving up data" leaves you still
> in possession of the data.  This has bad consequences for certain kinds
> of kryptonite.  And the moment you say, "well, if you're not going to
> serve it up then you don't need to store it, either" you've just agreed
> to waive the append-only property.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Keyservers and GDPR

[Tobias Frei]

Hi ilf,

https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00070.html

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

Re: [Sks-devel] The pool is shrinking

[Tobias Frei]

I guess I'm pointing out the obvious to most readers, but despite that official-looking domain name, "This is not an official EU Commission or Government resource. The europa.eu webpage concerning GDPR can be found here [link removed]. Nothing found in this portal constitutes legal advice." On Aug 15, 2019 00:29, Stefan Claas  wrote:Robert J. Hansen wrote:
> Enforcement is the sine qua non of law.  GDPR does not apply to purely
> US-based operators because there is no way for the EU to either compel
> our compliance or punish our noncompliance.
Please have a read:
https://gdpr.eu/compliance-checklist-us-companies/
If this applies to US companies do you think non-profit US SKS operators are
excempted?
I kindly request that Mr. Rude, for example, no longer provides key dumps to
the whole world, containing EU citizens data, without EU citizens consent.
https://keyserver.mattrude.com/dump/
Regards
Stefan
-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

Re: [Sks-devel] The pool is shrinking

[Tobias Frei]

Hi Yakamo,

Have you already seen these two messages?

https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00070.html

https://lists.nongnu.org/archive/html/sks-devel/2019-03/msg00026.html

Best regards
Tobias Frei

Am 13.08.19 um 15:41 schrieb st...@yakamo.org:

Hi Boti,

SKS servers are breaking the GDPR in multiple ways, its just a matter of time 
before something happens.

All it would take is one motivated person and things get serious real quick.

Especially i would say right now for the admin of mattrude or any others 
allowing the free distribution to any third party of the keys via dumps, 
without user consent which doesnt work with the GDPR at all, this is sure to 
turn to a nightmare real fast for those admins.

Yakamo


On Tue, 13 Aug 2019 09:02:20 +0200
b...@makacs.duf.hu wrote:


In many country of EU there were a period of patience to let firms fully covers 
their GDPR implementation.

However we have GDPR in effect last two years but authorities still had a so called 
"soft" penalty or no penalty just warn practice which is nearly over.

In mid and longer term the penalty fees will be harmonized. Today every country 
has its own penalty fees and penalty practice.

There is no more exceptions anymore such as it is technically impossible to 
delete data, etc.

So will the blockchain illegal among with sks in EU if stored data has PI 
records?

Cheers,
Boti




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

Re: [Sks-devel] GDPR (equine corpse)

[Tobias Frei]

On Aug 17, 2019 19:11, Stefan Claas  wrote:Interesting! If understood correctly the advantage then would be no changes
in the SKS code and simply using a front-end key parser, with a defined rule
set, right?
And false positives. And ineffectiveness against new attacks. And vulnerability through peering unless everyone runs the same frontend parser, which, if distributed together with SKS, is basically an amendment (I would say "change"?) to the SKS code. Interesting mainly for the reasons it fails for.Besr regards Tobias Frei___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] searching for new peers

[Tobias Frei]

A brave bastion of calm, a tower of strength, and the wonderful irony  
of "seemingly currently down" keyservers. To be commended, with a  
smile. Have a nice day! ~ Tobias Frei


Zitat von Francisco Monserrat :


Hello ,


It seems that all the peers my keyservers are currently down so both  
keyserver are outside the sks network, so please can anyone add the  
keyserver to their membership  and tell me



gozer.rediris.es 11370 # Francisco.monserrat 0xE50EEC8419067756  
francisco.monser...@rediris.es
zuul.rediris.es  11370 # Francisco.monserrat 0xE50EEC8419067756  
francisco.monser...@rediris.es


Both machines reply to the DNS cname pgp.rediris.es


regards

paco





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