Vincent Breitmoser writes:
>> - to do this keyservers will have to actually do cryptography
>
> Are you sure? I don't think there's any attack scenario here: If any
> such signature exists, you can't upload the key.
You can strip that signature. If you only consider accidental uploads of
the key
Hi!
Kim Minh Kaplan writes:
> Daniel Kahn Gillmor wrote:
>> I'd like the keyservers to reject keys with any self-sigs with the
>> "nokeyserver" notation. The novel thing is that this notation doesn't
>> exist yet :)
> - how does one propagates a "nokeyserver" annotation on a key in the
> SKS
Kristian Fiskerstrand writes:
> if you find any information un-expected send a response and request a signed
> confirmation]
> Unexpected IP change
Almost Ironic ;-)
Christoph
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.o
Danny Horne writes:
> # dig +norecurse +noall +stats @66.33.206.206 pgp.key-server.io
> ;; Query time: 136 msec
> ;; SERVER: 66.33.206.206#53(66.33.206.206)
> ;; WHEN: Fri Nov 18 17:51:19 UTC 2016
> ;; MSG SIZE rcvd: 62
>
> # dig +norecurse +noall +stats +tcp +time=20 @66.33.206.206
> pgp.key-se
Hi!
Kristian Fiskerstrand
writes:
> On 10/28/2016 02:22 PM, dirk astrath wrote:
>> Hello,
>>
Seems IPv6 connectivity is borked on https://sks-keyservers.net/status/
, no live keyservers are listed as having IPv6 available
>>> Yes, I'm experiencing IPv6 issues with sixxs tunnels atm
>>
Hi!
Gabor Kiss writes:
> Or don't you want to peer with servers having too few keys?
Having too few keys leads to practical problems .. it directly leads to
excessive resource usage during recon. Having a large delta and not
catching up is a very good reason to de-peer.
Christoph
___
Hi!
Danny Horne writes:
> I don't understand why you're seeing this error, can see it in my logs
> but test emails to my address (from GMail) are getting through
IPv4 vs IPv6
| $ swaks -6 --to da...@lockmail.net --from christoph.eg...@fau.de -q TO
| === Trying smtp.trisect.uk:25...
| === Conne
Gunnar Wolf writes:
> Andrew Gallagher dijo [Wed, Aug 31, 2016 at 10:14:01AM +0100]:
>> I'm sceptical of the utility of ECC keys personally. They were first
>> proposed as a way of reducing work and storage space (because the
>> space of usable ECC keys is more compact than the sparsely
>> distrib
Steven Noonan writes:
> On 31/08/16 07:07, Christoph Egger wrote:
>> Steven Noonan writes:
>>> Attempted doing a dump and rebuild of my database from that, but it didn't
>>> help
>>> with this problem. Still sees those same two keys out of sync:
>>
Hi!
Steven Noonan writes:
> Attempted doing a dump and rebuild of my database from that, but it didn't
> help
> with this problem. Still sees those same two keys out of sync:
Wild guess: ECC keys and your peer doesn't understand them and sends you
some data your server doesn't like
Christoph
SJ Zhu writes:
> 2016-08-27 13:54:52 Reconciliation attempt from unauthorized host [172.17.0.1]:39492>. Ignoring
Note that this is a private address from RFC 1918 space. So either
something is Nat'ing your incoming connections or this connection
attempt comes from within your (campus) network.
Pascal Levasseur writes:
> Any explanation available for this unusual behavior ?
Quoting #debian-devel
> evil32 keys got revoked https://news.ycombinator.com/item?id=12298230
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer
sig
Gabor Kiss writes:
>> > Out of curiosity, is there any Debian-type repository one can use to
>> > install updates automatically?
>> >
>> https://packages.debian.org/jessie/sks ???
>
> Jessie is the _stable_ version. Its sks package won't be upgraded
> unless a major security hole will be found i
Hi!
Gunnar Wolf writes:
> There are several tools relying on this (now very) weak 32-bit scheme;
> the first such tool we found was precisely the «PGP pathfinder & key
> statistics» service, which fails badly: Even specifying the full
> fingerprints, I do get three (absolutely fake!) trust path i
William Hay writes:
> On Thu, May 26, 2016 at 12:47:57AM +0200, Valentin Sundermann wrote:
>> Hi,
>>
>> I enforce HTTPS on all my domains by sending the HSTS header to my
>> visitors. HSTS forces the browser to use in future only secure
>> connections to this domain. More info on Wikipedia[1] :)
Ari Trachtenberg writes:
> Is there a common element to the bulk signatures that are being added?
> Can we, maybe, rate limit submissions per IP address?
These bulk bullshit submissions are the mostly-harmless branch of the
problem. The way more pressing thing is
a) distributing unlawfull / un
Tobias Frei writes:
> 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 c
Christoph Egger writes:
> AFAIR keys.gnupg.net has been discussed here and keyserver oeprators are
> expected to make this work -- at least for hkps.
sorry that was meant to read hkp / port 11371
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker |
Christoph Egger writes:
> of course -- if people use keys.gnupg.net with https, this advice should
> probably be fixed and/or the cname be moved to the "right" pool
Note that https://pool-sks-keyservers.net/ is also expected to not
work -- there's the hkps pool for that.
--
Hi!
"Kiss Gabor (Bitman)" writes:
> I found requests for https://keys.gnupg.net/ in my Apache logs
> on keys.niif.hu. Of course they were unsuccessful because
> my HTTP daemon is not set up to provide this virtual site.
>
> In the DNS we can see this:
> keys.gnupg.net CNAME pool.sks-ke
Hi!
Malte writes:
> On Friday, March 25, 2016 1:33:16 PM CEST Andrew Gallagher wrote:
>> Before we even *think* about a protocol, there are policy hurdles to be
>> overcome, e.g.:
>>
>> 1. What criteria should be met before a key is removed?
>
> Owner of private key or owner of UID/email address
Hi!
While iterating over all my peers and checking why some were down and
others no longer cross-peered I noticed lots of the PGP Keys I
originally wrote down are expired revoked. I guess it would make sense
for operators to announce key rotations onlist so people can keep their
membership file
Hi!
Douglas writes:
> It doesn't benefit anyone to retain keys uploaded with malicious
> intent, so I believe it's worth discussing a mechanism for key removal
> due to abuse of the system.
Sure. I suggest you start by reading the Minsky paper on how the
keyservers work and bring forward a feasi
Hi!
Kristian Fiskerstrand
writes:
> as mentioned in [0] an experimental tor hidden service based on
> onionbalance is running on hkp://jirk5u4osbsr34t5.onion . A Tor column
> is added to the status pages, and participation requires manual
> notification to me.
Is there some documentation publish
Hi!
Stephan Beyer writes:
> Does anyone of you have experience with MirageOS and knows what
> it takes to make a MirageOS unikernel from an "ordinary" OCaml program
> like sks?
You just have to rewrite any I/O code to the MirageOS library. So mostly
network and backend storage for BDB (which isn
Hi all!
Since some time I'm seeing a ever growing number of [0] when my
keyserver tries recon with mud.stack.nl. Note the "0 keys received". Is
anyone else seeing this as well? Is this a problem (anyone knows what
exactly?)?
Regards
Christoph
[0]
[...]
2015-09-26 17:57:25 Requesting 30 miss
Hi!
Daniel Roesler writes:
> Visualization:
> http://bl.ocks.org/diafygi/3f344c22f8a37a7b2151
How exactly does the green vs. red work given that keyservers cross-peer
and almost all edges should go in both directions?
Christoph
___
Sks-devel mailin
"Kiss Gabor (Bitman)" writes:
> Eeerrr... what is the risk of using a public service in
> TOR user's point of view? (Compared to using a hidden service.)
> His identity is hidden anyway.
End-To-End encryption and no CAs.
signature.asc
Description: PGP signature
_
Hi!
> Running it on a Raspberry Pi shouldn't be a problem as SKS is
> pretty low on resources (except for the building process).
Well sks needs rather decent storage (or maybe lots of RAM as caches?)
to performe remotely useable in my experience. In terms of "normal" RAM
and CPU usage it'
Hi!
The IP addresses configured for my keyserver[0] are about to
change. It will then also feature a static IPv4 address again.
Addresses are:
92.43.111.21
2a01:4a0:59:3151::f002
Regards
Christoph
[0] keyserver.siccegge.de / keyserver.christoph-egger.org
Just different names for t
Hi!
Matt Wagner writes:
> IPv6[1].
Looks good from here FWIW
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/
Arnold writes:
> People with a very large key can put their full key at a special place of
> their own
> (they are likely to be above average active internet users). They can still
> upload
> their key with exp. time and all textual UIDs. However, they should remove
> most of
> the signatures a
Hi!
Seems uploading my gpg key (d49ae731) to pool.sks-keyservers.net fails
for several of the hosts in rotation:
gpg: sending key D49AE731 to hkp server 213.206.252.51
gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request
Entity Too Large
gpg: keyserver internal error
gpg: k
"Kiss Gabor (Bitman)" writes:
>> - mitm attacks may manipulate up-/downloaded keys
>
> no
>
> Every uploaded key can be manipulated legally by anyone.
> (I.e. you attach a new signature to your friend's key
> and you send back to the key servers.)
> Moreover anybody can send a totally new key in
Pete Stephenson writes:
> On 8/3/2014 3:03 PM, Tyler Schwend wrote:
>> Building the sks database from a dump takes a very long time, a lot
>> of disk space, and a lot of CPU. Is there a way to just move the
>> whole BDB from one host to another? I am switching hosts.
>
> I'm not sure if it's recom
Ahoi!
Henning Kopp writes:
> Is it possible to get a keydump of all gpg-keys? Are there any usage
> restrictions? What would the size of the data be?
Take a look at
https://bitbucket.org/skskeyserver/sks-keyserver/wiki/KeydumpSources
I doubt any of the operators will mind a one-time download o
Todd Lyons writes:
> On Tue, Nov 12, 2013 at 6:45 AM, Filip Stefaniak wrote:
>>
>>> Your webserver doesn't return the sks interface when contacted as
>>> p80.pool.sks-keyservers.net or even pool.sks-keyservers.net so it
>>> can't be used as part of the port80 Pool
>>
>> Ok. So as I assume I have
Filip Stefaniak writes:
> W dniu 2013-11-12 14:12, Todd Lyons pisze:
>> On Tue, Nov 12, 2013 at 09:42:13AM +0100, Filip Stefaniak wrote:
>>
>>> I've tried to configure sks server with apache2 as described at
>>> https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering
>>> But I had a problem
Hi!
Clint Adams writes:
> keys.sflc.info 11370 # Clint Adams
> 0xDFFB8B0B5C6F5582
Added. Please add me back!
keyserver.siccegge.de 11370 # Christoph Egger
0xD49AE731
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert A
Hi!
Gaudenz Steinlin writes:
> Christoph Egger writes:
>> Unfortunately keyserver.siccegge.de lost it's static IPv4
>> configuration. DNS has been set up to follow the actually used IP
>> addresses (hopefully visible soon on a Nameserver near you). I will soon
>
Hi all!
Unfortunately keyserver.siccegge.de lost it's static IPv4
configuration. DNS has been set up to follow the actually used IP
addresses (hopefully visible soon on a Nameserver near you). I will soon
add a (static) IPv6 address again (allocated from
2001:a60:f01c::/48). If you are peering w
Moin!
John Clizbe writes:
> Patrick R McDonald wrote:
>> I would like to upgrade my sks on Debian Squeeze from 1.1.1 to 1.1.3
>> using Debian backports. Is there anything of which I need to be aware
>> when making this upgrade?
>
> if your 1.1.3 is linked with the same version of Berkeley DB as y
Michael Nausch writes:
> - RProx??? whats that? reverseproxy?
Jep
> - Port 80 it's colord false with red, 'cause you can reach my server
> http://keyserver.nausch.org as you can reach it as
> http://keyserver.nausch.org:11371
It's the pool.
Hi all!
Due to changes at the location the keyserver is hostet, I'll have to
use dynamic IP addresses for now (IPv4 only, the v6 address stays
static). I might be able to give it static addresses again in the future
but for now I'll have to dael with changing addresses.
Regards
Christoph
Hallo Ronny
Ronny Wagner writes:
> Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der
> angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie
> adressiert wurde, verständigen Sie bitte sofort den Absender und
> löschen danach die E-Mail. Das unerlaubte Kopieren sowie die
John Clizbe writes:
> Christoph Egger wrote:
>> Something weird happening when fetching 0xE33EC63DF983 -- it gets
>> 0x9CDF568F which doesn't even have a subkey called 0xE33EC63DF983 as
>> far as I can see. Anyone knows what's going on?
>>
>>
Hi!
Something weird happening when fetching 0xE33EC63DF983 -- it gets
0x9CDF568F which doesn't even have a subkey called 0xE33EC63DF983 as
far as I can see. Anyone knows what's going on?
Regards
Christoph
christoph@mitoraj {3} ~
11:07 0 % gpg --recv-keys 0xE33EC63DF983
gpg: r
Hi!
Christoph Egger writes:
> as your script is already tracking the status of keyservers on the
> web, maybe it would be possible to send the administrator a mail every
> time the keyserver drops out of the pool due to problems? Seems
> keyservers have the tendency to actuall
Hi!
as your script is already tracking the status of keyservers on the
web, maybe it would be possible to send the administrator a mail every
time the keyserver drops out of the pool due to problems? Seems
keyservers have the tendency to actually fail after running for some
time and need kicking
Hi all!
I hacked on pks2wot.py and created a .wot file using the current state
of my keyserver (keyserver.siccegge.de) [0]. I'm currently thinking of
wether running a weekly export would be usefull to others. I'll also
clean up the hack and publish the code once I find time. If there are
any pro
Hi!
"Joel Garske (ML)" writes:
> pgp.jjim.de 11370 # Joel Garske 0xA921EB20
I've just added you to my membership file, please also add my
keyserver to yours:
keyserver.siccegge.de 11370 # Christoph Egger
0xD49AE731
It is located in Erlangen
Grüße
Christoph
Hi!
The IPv6 Address for keyserver.siccegge.de has changed (it's now
2001:a60:f01c:0:42::1). IPv4 addresses are still the same.
Regards
Christoph
pgpxTWd2Djxam.pgp
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https
Hi all!
Christoph Egger writes:
> Due to random hangs I've stopped sks on keyserver.siccegge.de for now
> which seems to improve things a bit (I'd bet on network stack). Will be
> back after debugging stuff a bit / replacing hardware.
It's currently back online. Migh
Hi!
Due to random hangs I've stopped sks on keyserver.siccegge.de for now
which seems to improve things a bit (I'd bet on network stack). Will be
back after debugging stuff a bit / replacing hardware.
Regards
Christop
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer
virii writes:
> On 07/11/2012 05:56 PM, Marco Nenciarini wrote:
>> Il giorno mer, 11/07/2012 alle 17.34 +0200, virii ha scritto:
>>> Hi @ all
>>>
>>> Are there some news 'bout an updated SKS debian package for the repos?
>>>
>>
>> Are you talking about a backport of the package currently in unstab
Hi!
Kristian Fiskerstrand
writes:
> On 2012-07-06 11:03, Christoph Egger wrote:
>> Hi!
>>
>> I noticed keyserver.siccegge.de is not in the port80 pool. However I
>> can get the status page over port80 and
>>
>> gpg --keyserver hkp://keyserver.sicceg
Hi!
I noticed keyserver.siccegge.de is not in the port80 pool. However I
can get the status page over port80 and
gpg --keyserver hkp://keyserver.siccegge.de:80/ --recv-keys $KEYID
both works on IPv4 only hosts and IPv6 enabled systems.
Regards
Christoph
--
9FED 5C6C E206 B70A 5857 7
Hi!
Daniel Kahn Gillmor writes:
>> Backports of newer Berkeley DB "work" too, and likely
>> have some other usage cases than SKS because of bdb+sqlite3 API.
>
> right, this is one other path i considered, but i don't really want to
> have to maintain a bdb backport for the remaining lifetime of s
Hi!
John Clizbe writes:
> David Benfell wrote:
>> On 06/25/12 01:15, John Clizbe wrote:
> FWIW, I believe the current debian package for 1.1.3 is using 4.7
The 1.1.1 package in stable is at 4.7. The 1.1.3 in unstable uses 5.1
and the backported sks 1.1.3 in stable-backports will be using 4.8 jus
Hi!
Daniel Kahn Gillmor writes:
> On 06/25/2012 01:50 AM, Christoph Egger wrote:
>> Daniel Kahn Gillmor writes:
>>> On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
>>>> Please let me know if we should push the timeline some for the 1.1.2
>>>>
Hi!
Daniel Kahn Gillmor writes:
> On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
>> Please let me know if we should push the timeline some for the 1.1.2 minimum
>> to get more time for testing, as originally stated my primary goal is
>> getting to 1.1.3, so this shouldn't necessarily affe
Hi!
John Clizbe writes:
> I've never exceeded an inuse mutex count of ~42k, you shouldn't need that high
> of a number either. Tunables in DB_Config won't help you on build, the BDB env
> isn't created until 'sks clean'. Likewise the environment isn't created in
> PTree until it's used after 'sks
Hi!
I was talking with some folks at a GPG crashcourse / Keysigning event
last week where I was asked for a pool cointaining only keyservers
reachable through standard HTTP(s) ports (usefull for example behind
restrictive firewalls). As far as I know no such pool exists but maybe
one could be cr
Hi!
Recently I started to see failures in my recon.log:
2012-04-04 23:35:59 Error getting missing keys: Failure("")
2012-04-05 00:57:10 Error getting missing keys: Failure("\r")
Interestingly all peers I'm seeing this kind of failure are marked as
using reverse-proxies on http://sks-keyserve
Andrey Korobkov writes:
> That's good :)
> So, that was because SKS was listening on IPv4.
>
> But what about:
> 2011-04-07 00:57:02 Recon partner: [2001:a60:f01c:0:70:1:6:42]:11370>
> 2011-04-07 00:57:03 Initiating reconciliation
> 2011-04-07 00:57:05 error in callback.:
> Sys_error("Connecti
Andrey Korobkov writes:
> One more problem with IPv6 peering:
>
> 2011-04-07 00:23:44 address for keyserver.siccegge.de:11370 changed
> from [] to [, [212
> .114.250.148]:11370>, ]
> 2011-04-07 00:23:44 address for keyserver.serviz.fr:11370 changed from
> [] to [, [46.4.13
> 9.47]:11370>]
> 2011
Андрей Коробков writes:
> I'm using btrfs on server and reiserfs on desktop. May be, BDB do some
> very-low level things?...
Is one of them 64 bit and the other 32 bit? If so that'll break. If the
server is 32bit you could build it on your desktop using a 32bit chroot
environment.
> After more
Андрей Коробков writes:
>
> The only problem is to have such a huge key database being built from dump
> on my memory-limited 32-bit home server. When I tried to do the thing on my
> 64-bit desktop
> and then copy the DB files to server, SKS didn't want to start because of
> something like
> "_
Hi!
Андрей Коробков writes:
> I want to set up keyserver, but it's only IPv6.
> Would you accept it in the pool?
I don't see any reason to reject such a keyserver and would peer with
you as soon as yours is up!
Regards
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debia
"Kiss Gabor (Bitman)" writes:
> /etc/cron.daily/sks:
> db4.7_archive: Program version 4.7 doesn't match environment version 4.6
> db4.7_archive: DB_ENV->open: DB_VERSION_MISMATCH: Database environment
> version mismatch
> run-parts: /etc/cron.daily/sks exited with return code 1
% gunzip -c /usr/
Hi!
Hauke Lampe writes:
> On 12.10.2010 00:23, Christoph Egger wrote:
>
>> After some more fiddling the firewall's now fine with IPv4 gossip
>
> One problem remains:
>
>> Requesting 1 missing keys from , starting
>> with C11C28AEA21E0CBF4960BC150B2D62DC
Hi again!
Christoph Egger writes:
> I am running SKS version 1.1.1, on keyserver.siccegge.de.
>
> The server is physically located in Germany (Erlangen) (EU).
> The machine has IPv6 connectivity.
>
> keyserver.siccegge.de 11370 # Christoph Egger
> 0xD49AE731
After s
Christoph Egger writes:
> Hi!
>
> Gaudenz Steinlin writes:
>> Hi Christoph
>>
>> I would like to peer with your server but I can currently not connect
>> to it on IPv4. It works on IPv6 though. Is this intentional?
>
> No it's not intentional -- b
g stuff here.
Regards
Christoph
>> keyserver.siccegge.de 11370 # Christoph Egger > 0xD49AE731
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
pgp
For operational issues, please contact me directly.
keyserver.siccegge.de 11370 # Christoph Egger
pgp3znj5USLPW.pgp
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
75 matches
Mail list logo
