Re: [Sks-devel] Gossip protocol mentor?
I'm also happy to answer questions on the list too. The advantage to that is that the answers are then searchable for others. y On Sat, Jun 29, 2019 at 8:42 PM Daniel Roesler wrote: > Great! Will email you separately. > > On Sat, Jun 29, 2019 at 7:40 PM Yaron Minsky wrote: > > > > I don't have a lot of time to contribute, and I haven't really thought > about the implementation or the algorithms for 20 years. But I'd be happy > to answer questions. > > > > y > > > > On Fri, Aug 26, 2016 at 11:34 AM Daniel Roesler > wrote: > >> > >> Howdy all, > >> > >> I've read through the academic paper several times, but I'm having a > difficult time going from the math to the code in the actual sks-keyserver. > Is anyone who knows the actual implementation details and mechanics of the > gossip protocol willing to be a mentor as I learn it? I'd like to just have > someone I can ping with questions as I work through the code. > >> > >> Thanks, > >> Daniel > >> > >> ___ > >> 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] Gossip protocol mentor?
I don't have a lot of time to contribute, and I haven't really thought about the implementation or the algorithms for 20 years. But I'd be happy to answer questions. y On Fri, Aug 26, 2016 at 11:34 AM Daniel Roesler wrote: > Howdy all, > > I've read through the academic paper several times, but I'm having a > difficult time going from the math to the code in the actual sks-keyserver. > Is anyone who knows the actual implementation details and mechanics of the > gossip protocol willing to be a mentor as I learn it? I'd like to just have > someone I can ping with questions as I work through the code. > > Thanks, > Daniel > ___ > 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 apocalypse mitigation
FWIW, while I'm effectively no longer involved in SKS development, I do agree that this is a problem with the underlying design, and Andrew's suggestions all sound sensible to me. On Fri, Mar 23, 2018 at 7:10 AM, Andrew Gallagher wrote: > Hi, all. > > I fear I am reheating an old argument here, but news this week caught my > attention: > > https://www.theguardian.com/technology/2018/mar/20/child-abuse-imagery-bitcoin-blockchain-illegal-content > > tl;dr: Somebody has uploaded child porn to Bitcoin. That opens the > possibility that *anyone* using Bitcoin could be prosecuted for > possession. Whether this will actually happen or not is unclear, but > similar abuse of SKS is an apocalyptic possibility that has been > discussed before on this list. > > I've read Minsky's paper. The reconciliation process is simply a way of > comparing two sets without having to transmit the full contents of each > set. The process is optimised to be highly efficient when the difference > between the sets is small, and gets less efficient as the sets diverge. > > Updating the sets on each side is outside the scope of the recon > algorithm, and in SKS it proceeds by a sequence of client pull requests > to the remote server. This is important, because it opens a way to > implement object blacklists in a minimally-disruptive manner. > > An SKS server can unilaterally decide not to request any object it likes > from its peers. In combination with a local database cleaner that > deletes existing objects, and a submission filter that prevents them > from being reuploaded, it is entirely technically possible to blacklist > objects from a given system. > > The problems start when differences in the blacklists between peers > cause their sets to diverge artificially. The normal reconciliation > process will never resolve these differences and a small amount of extra > work will be expended during each reconciliation. This is not fatal in > itself, as SKS imposes a difference limit beyond which peers will simply > stop reconciling, so the increase in load should be contained. > > The trick is to ensure that all the servers in the pool agree (to a > reasonable level) on the blacklist. This could be as simple as a file > hosted at a well known URL that each pool server downloads on a > schedule. The problem then becomes a procedural one - who hosts this, > who decides what goes in it, and what are the criteria? > > It has been argued that the current technical inability of SKS operators > to blacklist objects could be used as a legal defence. I'm not convinced > this is tenable even now, and legal trends indicate that it is going to > become less and less tenable as time goes on. > > Another effective method that does not require an ongoing management > process would be to blacklist all image IDs - this would also have many > other benefits (I say this as someone who once foolishly added an > enormous image to his key). This would cause a cliff edge in the number > of objects and, unless carefully choreographed, could result in a mass > failure of recon. > > One way to prevent this would be to add the blacklist of images in the > code itself during a version bump, but only enable the filter at some > timestamp well in the future - then a few days before the deadline, > increase the version criterion for the pool. That way, all pool members > will move in lockstep and recon interruptions should be temporary and > limited to clock skew. > > These two methods are complementary and can be implemented either > together or separately. I think we need to start planning now, before > events take over. > > -- > Andrew Gallagher > > > ___ > 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] hg workflow pointers
Without saying anything about how to use hg (though this is a nice tutorial: http://hginit.com/), I have no objection to moving the whole thing to git and/or github. I was the one who chose hg long ago, and I no longer work on SKS enough for my opinion on such things to matter. y On Tue, Aug 1, 2017 at 5:30 PM, Daniel Kahn Gillmor wrote: > hey folks-- > > i'm comfortable with git. i'm even comfortable on github, gitlab, and > other similar platforms. > > I'm not as comfortable with mercurial (hg), or with bitbucket's hg > interface, but i think i'm educable. This is a request for pointers for > simple workflow help. > > i find that every time i want to propose a simple change to the sks > project in a convenient way for upstream (e.g. as a pull request), i > spend hours beating my head against the wall. > > with git, i would do something like: > > git clone $UPSTREAM_REPO > cd $REPO_NAME > git checkout -b $FEATURE_BRANCH_NAME > $EDITOR example.source > git add example.source > git commit -m 'explanation of change' > git push origin $FEATURE_BRANCH_NAME > > Then i would go to whatever goofy webui the project uses and > clicky-clicky through to make a "merge request" or a "pull request". > > In situations where i don't have push access to the $UPSTREAM_REPO > (which is fine) i make a "fork" (i.e. my own copy) of the repo on the > upstream hosting platform, and i pull from there and push to there > instead. (the clicky-clicky bit of making a "merge request" or "pull > request" is then slightly more complicated) > > I've even tried to do this on bitbucket for sks, with: > > https://bitbucket.org/dkgdkg/sks-keyserver.old > > But it's possible that i've screwed that repo up badly enough that i > can't get it to do what i'd want to do. and i can't convince bitbucket > to let me make a new "fork" of the upstream sks-keyserver either :/ > > Is there a comparably simple tutorial someone can point me to for > contributing to sks? > > or, would sks folks be interested in moving to git for revision control? > > --dkg, frustrated at having spent too much of the day on > administrivia instead of actual contributions > > ___ > 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] Key subsets (was: Proposal: Start verifying self-signatures)
This seems like a very nice idea. There are some algorithmic challenges, though. Right now, SKS maintains an incrementally updated data structure corresponding to a kind of magic checksum of different subsets of keys. These magic checksums are computed on subsets determined by a pre-arranged partitioning of the space. To do the reconciliation you propose, you'd need to be able to instead get your hands on the checksum of every key in a given range that passes a given filter criterion. If we have a known set of filters, well, then we can compute those incrementally in advance. If the filters are small (e.g., ban the following 30 keys) we can do them on demand. But if you have filters that are not known in advance but make big changes to the set of admissable keys (e.g., drop all keys minted before the following date), well, that's trickier. Changes along these lines are totally doable, but would require someone to really dig seriously into the SKS codebase. I'm not going to have the time to do it myself. y On Thu, May 21, 2015 at 3:29 PM Arnold wrote: > On 20-05-15 00:18, Yaron Minsky wrote: > > Let's think about a simpler question: deletion. > > Hmm, simple? This question alone has at least two flavours: > A) local deletion > B) global, network wide deletion > > > Can SKS support outright deletion of keys? > > I think a fundamental question is one of trust: is there a trusted set of > > people who could do the deletions? > > Perhaps it's better to forget about deletion... It is no longer necessary > once we > leave the idea of a "single set of keys" :-) > > > If so, then one could pretty easily add the > > notion of a deletion certificate that could be gossiped around like a > key, and > > would essentially eat some set of keys, causing them to be deleted from > the database. > > > > The problem is, I don't know that such a universally trusted set exists. > So, what > > do we do? We could imagine having people volunteer to manage sets of > banned keys. > > It came up before, multiple operators want to ban different kind of keys > for > different reasons. There is no "single set" of banned keys. > > > You could subscribe to a banned key service, and just always reject any > banned keys > > from your store. > > The question then is, what happens during reconciliation? Maybe > > at reconciliation time, everyone just pretends to have all of the banned > keys in > > their store, and so no one ever detects a difference based on banned > keys. > > > I haven't really thought much about the literature in this area for a > few years. > > If real progress is to be made here, someone has to think carefully > about what > > would be an effective protocol. To think about SKS, you don't really > have to know > > anything about the fancy math behind reconciliation. Just think of it > this way: > > you need to represent your knowledge as a set, and SKS gives you a cheap > way to > > discover the symmetric difference of your set and someone else's set, > and then you > > can synchronize based on that knowledge. Deletion certificates just act > as another > > thing in the set, and so everything works pretty straightforwardly from > there. > > > > If you want to design a better SKS, you should think about whether you > can build > > the semantics you want on top of this basic set-based model. > > Yes, thank you Yaron! This brings me to another way of thinking. Just > forget about > the idea of deletion. Think in "sets" instead! :-) > > It might be possible to make SKS a key server with a "dynamic set" of keys > it wants > to gossip with peers. > > Each SKS operator can configure SKS to be limited to keys with (or > without) certain > (predefined) properties. Examples might be: > - not on some URL-based ban-list, > - no picture uid over 1 kbyte, > - etc. > > Upon reconciliation both peers exchange their filter settings. The fancy > math for > reconciliation is applied on the subset of keys passing the filter rules > of *both* > peers (the common set of keys they both want to have). > > For example a US-server filters out certain keys on a US ban list, while a > EU-server filters out certain keys on a EU ban list. If both servers peer, > they do > set reconciliation on those keys that are not on one of the ban lists. It > does not > matter both servers have more keys than they advertise to their peer. > If the EU-server later on peers with another EU-servers, they happily > include all > keys on the US ban list in their set reconciliation. > > This way, we *only gossip about
Re: [Sks-devel] Proposal: Start verifying self-signatures
Let's think about a simpler question: deletion. Can SKS support outright deletion of keys? I think a fundamental question is one of trust: is there a trusted set of people who could do the deletions? If so, then one could pretty easily add the notion of a deletion certificate that could be gossiped around like a key, and would essentially eat some set of keys, causing them to be deleted from the database. The problem is, I don't know that such a universally trusted set exists. So, what do we do? We could imagine having people volunteer to manage sets of banned keys. You could subscribe to a banned key service, and just always reject any banned keys from your store. The question then is, what happens during reconciliation? Maybe at reconciliation time, everyone just pretends to have all of the banned keys in their store, and so no one ever detects a difference based on banned keys. I haven't really thought much about the literature in this area for a few years. If real progress is to be made here, someone has to think carefully about what would be an effective protocol. To think about SKS, you don't really have to know anything about the fancy math behind reconciliation. Just think of it this way: you need to represent your knowledge as a set, and SKS gives you a cheap way to discover the symmetric difference of your set and someone else's set, and then you can synchronize based on that knowledge. Deletion certificates just act as another thing in the set, and so everything works pretty straightforwardly from there. If you want to design a better SKS, you should think about whether you can build the semantics you want on top of this basic set-based model. That said, another completely honorable, and in some ways simpler, approach, would be to give up on SKS' clever synchronization, and go back to a model closer to the old PKS one: do some kind of mostly-reliable broadcast. This would allow individual keyserver maintainers to freely delete whatever they wanted. Replication won't be perfect in such a world, but at least figuring out how to delete keys in this world requires no new ideas. y On Tue, May 19, 2015 at 4:50 PM Robert J. Hansen wrote: > > Even if we did have a better understanding of the filter code, the > > difficulty with phasing in filters like this (as you've noticed in > > your description) is that either the whole pool opts in, or the > > filter doesn't work. Peers with different filtersets cannot gossip > > with each other, aiui. > > This is my understanding as well, and if I recall some past > conversations with John Clizbe correctly, he shares in this. However, > before we bet the farm I think we should see what Yaron thinks -- maybe > he has an idea for a next-generation SKS that would permit this. I > don't know how it would be done, but then again, I'm not Yaron. :) > > > So if we're going to introduce new filters, we are going to cause a > > major disruption with the existing SKS network. While such a > > disruption may be warranted, it is probably not something we want to > > do twice, so we should roll all the desired filter changes into one > > massive disruption. > > Something seems to be handwaved here. This seems to be about the same > level of effort as moving the keyserver to an entirely new protocol. > (In effect, it would be.) So perhaps we should first ask, "can we do > better than SKS?" > > If we're going to go down this route I think we should start by looking > at academic research and seeing if there's some new idea that could > possibly be used to resolve some of SKS's problems. > > I completely agree that we only want to do this once. For that reason, > I think it would be prudent to give serious thought to whether there was > something better than SKS to switch over to. > > My impression is there is not, but I haven't done an in-depth search, > either. > > > So the questions i have for a proposal like this: > > I think limiting this discussion to just filters is a little premature. > If we decide that SKS is the best thing going and we need to keep it, > then yes, some sort of filter set seems appropriate. But see above > regarding keeping our eyes open to other options. > > ___ > 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] Rationalization (Was: Questions regarding blocking ...)
Also, why does having more peers take more resources? The rough algorithm (IIRC) is: pick a random host from your list of peers; reconcile; wait a fixed period of time and try again. The set of hosts from which you pick a peer seems like it adds no cost. y On Sun, Aug 3, 2014 at 4:15 AM, Robert J. Hansen wrote: > On 8/3/2014 3:06 AM, Kiss Gabor (Bitman) wrote: >> I'm thinking on structure of graph of key servers for a long time. >> IMHO it is too scale free and not designed knowingly enough. > > If you haven't read this paper, start with it. > > * Watts, Duncan J.; Strogatz, Steven H. (June 1998). "Collective > dynamics of 'small-world' networks". Nature 393 (6684). Available > online at: http://labs.yahoo.com/files/w_s_NATURE_0.pdf > > It's three pages and is plenty worth reading. If you haven't already > learned about small-world networks, it'll completely change the way you > view things like the keyserver network. > > > > ___ > 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] Questions regarding blocking with regards to stats generation & gossip
I think that increasing the number of gossip peers only improves things. The probability of collisions I think does not systematically go up when you increase the number of peers, and it reduces the chance that you've chosen an unusually busy set of peers. y On Sat, Aug 2, 2014 at 4:06 PM, Pete Stephenson wrote: > Hi all, > > I was reviewing the mailing list archives recently and had a few questions: > > 1. From what I've read, generating DB stats block the DB and SKS does > not respond to search/submit queries while the generation is ongoing. > > What happens to queries during the blocking period? Are they rejected or > dropped? Do they hold waiting for the DB to come back online? > > In my case, the server is using Apache as a reverse proxy. It uses an > SSD for storage, so stats generation takes <5 seconds or so. Is it > problematic to generate stats more frequently than once per day? > > 2. SKS can only gossip with one peer at a time. Additional gossip > traffic made while the server is gossiping with another peer fail and > must be retried. > > Is there some optimal number of peers that a server should have that > would balance between increasing the degree of interconnection and > gossip collisions? Is there a critical number of peers beyond which > collisions become an issue? > > Cheers! > -Pete > > > ___ > 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-Devel mailing-list and keyserver implementations
A minor point --- I think Phil put my name on this by mistake, since I didn't actually sign-on to this email. That said, I would like to encourage the Hockeypuck people to post here to discuss the reconciliation protocol. The protocol seems like a shared interest, and this seems like the best place to discuss it. Also, I think it would be useful for Hockeypuck release announcements to be sent here, since this is probably the best way to reach the current keyserver operators. Beyond that, discussions of Hockeypuck development are probably off-topic. y On Sat, Jan 26, 2013 at 11:39 PM, Phil Pennock wrote: > This is just something pre-emptive, to forestall any complaints that > might arise. > > The sks-devel mailing-list is about SKS the protocol as much as SKS the > implementation, and as long as people are seeking SKS-protocol peers > here, we deem it on-topic for folks to do so, no matter which software > they use to run their keyserver. > > We're happy to see a second implementation emerging and want reconciling > keyserver operators to feel welcome here. > > Should this prove problematic in the future, then we might finally split > off keyserver operations to a new mailing-list open to all, but for the > time being it seems most sensible to have the discussions be where the > operators actually are, so that peers can work through any teething > issues that arise with the introduction of a second implementation. > > Regards, > -John, Kristian, Phil & Yaron > > ___ > 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] Hockeypuck 0.8.1, recon development update
Awesome! I'm glad to hear you've made progress on the reconciliation algorithm. Maybe at the end of this we'll have a well specified protocol for SKS... y On Thu, Jan 24, 2013 at 11:44 PM, Casey Marshall wrote: > Hi sks-devel, > This week I've released Hockeypuck 0.8.1. It can be installed from > ppa:hockeypuck/ppa on Ubuntu/Mint. For all other platforms, I have > compiled tarballs of the full system installation layout at > https://launchpad.net/hockeypuck/+download. This is a pretty minor > release as I've been focusing most of my spare time on the recon > protocol. > > Hockeypuck 0.8.1 supports the PKS mail protocol. My server at > http://keyserver.gazzang.net can receive keys sent to > pgp-public-k...@keyserver.gazzang.net. Peers would be most welcome. > I've also added a statistics page similar to SKS/GnuKS: > http://keyserver.gazzang.net/pks/lookup?op=status. > > I'm developing recon support in a separate project called Conflux > (https://github.com/cmars/conflux), a set reconciliation > library/framework for content-addresses databases in general. The > mathematical aspects are functioning and passing unit tests (ported > from SKS tests such as decode_test.ml). Right now I'm in what I > believe to be the home stretch, currently working on the server-side > of the protocol and the prefix tree. > > Cheers, > Casey > > ___ > 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] Hockeypuck: OpenPGP Key Server, Golang ?
Good luck on creating a new keyserver. A few quick thoughts: First, it shouldn't be too hard to improve upon SKS. I'd say the key weakness of SKS is that it is written in a very naive style without taking advantage of more modern asynchronous programming toolkits in OCaml like LWT[1] or Async[2]. I basically rolled my own not very good event-driven programming model. (Ah, to be young and foolish) That means that it basically blocks out when answering a single HTTP request. Any vaguely modern toolkit should clean SKS's clock in this regard. Second, SKS's communication protocol shouldn't be that hard to grok. If you read reconMessages.ml and cMarshal.ml, you'll see that messages are structured quite simply. Tags are used for separating different message types. Substructures are written out by first writing out an integer size, followed by the contents. Understanding the messages requires understanding the sync protocol and the math behind it, which is a bit harder, made more so by the fact that it never had a clear written specification. I'm happy to answer questions, but I'm not going to have time to really dig back in and understand all the details myself, and it's been a decade since I've really looked at the code. Finally, I recommend you think carefully about deletion. SKS's protocol does a wonderful job of synchronizing keys, but it doesn't offer any way of deleting keys. I think that a well-run keyserver system should have some mechanism for deleting keys, both by key owners and by some coalition of administrators. I've written a few posts on this list about how to do it, but, again, I can't dedicate the time to do the work. (Also, this is as much a social as a technical question, as you can no doubt imagine.) Anyway, best of luck. y [1]: http://ocsigen.org/lwt/ [2]: https://bitbucket.org/yminsky/ocaml-core/wiki/Home On Fri, Nov 9, 2012 at 1:18 AM, Casey Marshall wrote: > On Wed, Nov 7, 2012 at 11:57 PM, Phil Pennock > wrote: >> Anyone here tracking / aware of Hockeypuck? >> > > Hi Phil & sks-devel, > I'm the creator of Hockeypuck. > >> https://code.launchpad.net/hockeypuck >> >> OpenPGP keyserver, loads dumps made by SKS. Written in Golang, has >> backends for PostgreSQL and MongoDB. Project created 2012-07-20, >> currently at version 0.5, working on 0.6. >> > > Thanks for the introduction :) > > My employer is also hosting an instance at > http://keyserver.gazzang.net if you'd like to try it out. > >> Doesn't _yet_ have inter-keyserver sync, but it's on their todo list: >> >> https://bugs.launchpad.net/hockeypuck/+bug/1044767 >> >> "Support keyserver synchronization. Interoperate with SKS gossip >>protocols if practical." >> >> I stumbled across this while searching Google for something else. >> >> Anyone here know anything more about this, or helping out? >> >> (For myself: if I had time, I'd love to help out, it would be great to >> get two interoperable but independent code-bases) >> > > Help would be most appreciated! I am making progress with > understanding the SKS sources, but I could really use an explanation > of the protocol & comparison in layman's terms. The academic papers > are difficult for me to follow. > > It looks like SKS is using a prefix tree to index fingerprints for > comparison, but how exactly? How do I roll that prefix tree up into a > recon message, and compare it with the message from another peer? > > Contributors are welcome, please direct reply to me if interested. > > -Casey > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel Good luck on creating a new keyserver. I don't have much time to h On Fri, Nov 9, 2012 at 1:18 AM, Casey Marshall wrote: > On Wed, Nov 7, 2012 at 11:57 PM, Phil Pennock > wrote: >> Anyone here tracking / aware of Hockeypuck? >> > > Hi Phil & sks-devel, > I'm the creator of Hockeypuck. > >> https://code.launchpad.net/hockeypuck >> >> OpenPGP keyserver, loads dumps made by SKS. Written in Golang, has >> backends for PostgreSQL and MongoDB. Project created 2012-07-20, >> currently at version 0.5, working on 0.6. >> > > Thanks for the introduction :) > > My employer is also hosting an instance at > http://keyserver.gazzang.net if you'd like to try it out. > >> Doesn't _yet_ have inter-keyserver sync, but it's on their todo list: >> >> https://bugs.launchpad.net/hockeypuck/+bug/1044767 >> >> "Support keyserver synchronization. Interoperate with SKS gossip >>protocols if practical." >> >> I stumbled across this while searching Google for something else. >> >> Anyone here know anything more about this, or helping out? >> >> (For myself: if I had time, I'd love to help out, it would be great to >> get two interoperable but independent code-bases) >> > > Help would be most appreciated! I am making progress with > understanding the SKS sources, but I could really use an explanation > of the protocol
[Sks-devel] Moving the main repo
Just a quick note. We've moved the main repo from it's old location at https://bitbucket.org/yminsky/sks-keyserver to this one https://bitbucket.org/skskeyserver/sks-keyserver This is to use bitbucket's "team" system, so multiple people can manage the repo and downloads and such. I've made the older link private, so people shouldn't be able to see it anymore. Please update your links! y ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] bitbucket transition
The bitbucket transition seems complete. Any objections to deleting the google-code project? It seems like a source of confusion... y ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Bitbucket?
On Wed, May 30, 2012 at 11:08 PM, John Clizbe wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1,SHA256 > > Yaron Minsky wrote: > > John? Seems like you're the main person who I haven't heard a response > > from. How do you feel about switching to bitbucket? > > > Sorry for the late reply, Long weekend at BF's place. And a slew of catch > up > once I got home. > > Haven't had a lot of time to look at it. There is a nice centrality to > Google, but I'm really tired of Google's SSL cert of the week when I push. > > How difficult will it be to migrate existing repos: trunk, me, Kristian, > etc? > > That's my only question. Other than that, for now I'm site-agnostic. > I think it's quite easy. I migrated my trunk, and it was very straightforward. I just got a pull request from Kristian, which I put some comments on before including, which was also pretty easy. > - -John > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12-git-509fe4ce-2012-01-31 (Windows XP) > Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! > Comment: Be part of the £€€7 ECHELON -- Use Strong Encryption. > Comment: It's YOUR right - for the time being. > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPxuCWAAoJECMTMVxDW9A0ax0H/0MR3ZrjTz5HlSe+p1t6lN8g > gDc72XlFqOxhFm3SHRIe9CJ42nUjJgu6G2VIpNEMOnm0B4MZIsfiaxKNqrbkzew+ > 5mVscZT19QKzGPjvWARkNVO3pC6240XAtl8DLHiHB0E3ykRJ2iuXyRVH/LVW1nR5 > gktmgxZCSKs9pjnVckI0w7uERShlsT/13FBaOhiSEO+Q6xm/T+ZlQ9ddIqTu5pAa > zXFj5aZ2v+cJzo1tcb/4dMNcOy0xQgPPvDeqIdiiOzPrK9YOw9g+BDoYsDbOFgcQ > YS46bWrt8vKHeBrtelfy+CRkObmJDAKChJPFk5AdYGJlA5rUkLXgs02E+6PyFO6I > XgQBEQgABgUCT8bglgAKCRDrXhnz1laYJQF/AP4k0cdd9NApsN+PLRfRV1VPUh0m > Dwh790wY2hX8cEpXBgD/UkpJ34u0sYkU3wFV6FpulYYLyYLcqQQ1GLYWBpyHY3M= > =mqnR > -END PGP SIGNATURE- > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On Wed, May 30, 2012 at 9:22 PM, Ari Trachtenberg wrote: > The problem with the second plan is that the potential number of > differences > between hosts could grow quite large, degrading performance. > The deleted keys would be considered as present from the point of view of the reconciliation algorithm, so I'm not sure it would truly degrade performance. The only issue is, what do you do if the first time you learn of a key is from someone who deleted it? That said, I think there is a reasonable heuristic one could use here: don't add the key for awhile, seeing if you're going to encounter someone in the reconciliation who actually has the key. And if you don't, eventually learn it as an "unknown" key, and add it to your Ptree. That said, GC'ing the deletions is an issue, but it's just the keyid you need to keep, so it's not so bad. > The easiest solution would be to auto-expire keys after a fixed time > (a good strategy anyway from a security perspective). > > Best, >-Ari > > On May 30, 2012, at 7:55 PM, Yaron Minsky wrote: > > > Here's my quick sense of what the reasonable solutions are: > > > > - Add a key-deletion authority, as Gabor suggested. These deletion > > certificates would be gossiped around, and would lead to deletion of > keys. > >The deletion certificates would stick around for a long time, but > they'd > > be small, so the cost would be low. One coud have them auto-expire at > a > > specified time out, so that you eventually can GC them. > > - Have SKS have a local key-deletion file. Keys listed in the key > > deletion file would be excluded from the local set, but would probably > be > > kept in the Ptree, so that they don't show up as a difference when > > reconciling. People can work together to distribute key-deletion files > > from a trusted source, but it's at the discretion of the manager of any > > individual key server. > > > > The second one seems more likely to work as a social matter, since > building > > an agreed, trusted authority is tricky. > > > > (To say the obvious, I don't have the time to work on implementing either > > approach. But I'm happy to have others do so. Something like this was > > part of my original plans for SKS, but it never got done.) > > > > y > > > > On Sun, May 27, 2012 at 6:15 AM, Robert J. Hansen >wrote: > > > >> On 5/27/12 5:50 AM, Giovanni Mascellani wrote: > >>> I'm just a newbie here, but actually I'd like to see the same concept > >>> applied in a more general way: I think there is much garbage in the > >>> keyservers, even behind the PGP robo-signer. > >> > >> The problem here is this violates one of the principle design features > >> of the keyserver network: > >> > >> "We never, never, never lose certificates." > >> > >> It is preferable for a keyserver to outright go down than it is for even > >> one certificate to be lost. If a certificate is lost then a malicious > >> actor could re-upload another key with the same short ID (a very easy > >> thing to do), and that could facilitate all different kinds of attacks > >> on people who don't properly validity-check certificates before using > them. > >> > >> If the keyserver goes down then everyone knows in short order there's a > >> problem. If a certificate is lost and silently replaced it might be a > >> long time before being discovered. (Discovery is more likely if the > >> keyserver is synchronizing with others, but there are a lot of > >> standalone servers.) > >> > >> Further, expired certificates are still useful. I have some emails more > >> than five years old that are still relevant and useful. If a > >> certificate gets removed just because it expires, how am I to check the > >> signature on those messages in order to ensure they haven't been > >> tampered with? If the expired certificate remains on the servers, > >> though, I can download it, validity-check it, and be confident in the > >> integrity of my message. > >> > >> The same logic applies to revoked certificates: they're still useful for > >> the same reasons. > >> > >> The keyservers never, never, never lose certificates. That's a design > >> goal and one that the SKS maintainers believe is a good one. I agree > >> with them, and want to see this design goal maintained in all future > >> devel
Re: [Sks-devel] Div.
Thanks for creating a clearly separated fork. I look forward to seeing the source! Cheers, y On Fri, May 25, 2012 at 2:05 PM, Sebastian Urbach wrote: > Hi, > > Sorry, the usual friday dump is a bit late today but it's available > right now: > > http://key-server.org/dump/ > ftp://key-server.org/dump/ > > As a few people may have noticed, there is a GnuKS listed in the > pool as server software. This is the fork of sks which we ar working > on right now. Source Code, Website and all that will be up in a few > days time. > > -- > Mit freundlichen Grüßen / Yours sincerely > > Sebastian Urbach > > > Religion is something left over from the infancy of > our intelligence, it will fade away as we adopt > reason and science as our guidelines. > > > Bertrand Arthur William Russell (1872-1970), > British philosopher, logician, mathematician, > historian, and social critic. > > ___ > 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] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
Here's my quick sense of what the reasonable solutions are: - Add a key-deletion authority, as Gabor suggested. These deletion certificates would be gossiped around, and would lead to deletion of keys. The deletion certificates would stick around for a long time, but they'd be small, so the cost would be low. One coud have them auto-expire at a specified time out, so that you eventually can GC them. - Have SKS have a local key-deletion file. Keys listed in the key deletion file would be excluded from the local set, but would probably be kept in the Ptree, so that they don't show up as a difference when reconciling. People can work together to distribute key-deletion files from a trusted source, but it's at the discretion of the manager of any individual key server. The second one seems more likely to work as a social matter, since building an agreed, trusted authority is tricky. (To say the obvious, I don't have the time to work on implementing either approach. But I'm happy to have others do so. Something like this was part of my original plans for SKS, but it never got done.) y On Sun, May 27, 2012 at 6:15 AM, Robert J. Hansen wrote: > On 5/27/12 5:50 AM, Giovanni Mascellani wrote: > > I'm just a newbie here, but actually I'd like to see the same concept > > applied in a more general way: I think there is much garbage in the > > keyservers, even behind the PGP robo-signer. > > The problem here is this violates one of the principle design features > of the keyserver network: > >"We never, never, never lose certificates." > > It is preferable for a keyserver to outright go down than it is for even > one certificate to be lost. If a certificate is lost then a malicious > actor could re-upload another key with the same short ID (a very easy > thing to do), and that could facilitate all different kinds of attacks > on people who don't properly validity-check certificates before using them. > > If the keyserver goes down then everyone knows in short order there's a > problem. If a certificate is lost and silently replaced it might be a > long time before being discovered. (Discovery is more likely if the > keyserver is synchronizing with others, but there are a lot of > standalone servers.) > > Further, expired certificates are still useful. I have some emails more > than five years old that are still relevant and useful. If a > certificate gets removed just because it expires, how am I to check the > signature on those messages in order to ensure they haven't been > tampered with? If the expired certificate remains on the servers, > though, I can download it, validity-check it, and be confident in the > integrity of my message. > > The same logic applies to revoked certificates: they're still useful for > the same reasons. > > The keyservers never, never, never lose certificates. That's a design > goal and one that the SKS maintainers believe is a good one. I agree > with them, and want to see this design goal maintained in all future > development. > > That said, welcome to the community, and please understand that although > I think your idea is awful I'm honestly happy to see you here. :) The > mailing list is a place where ideas come into violent collision, but we > try to be reasonable human beings to each other. Welcome! > > ___ > 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] Bitbucket?
John? Seems like you're the main person who I haven't heard a response from. How do you feel about switching to bitbucket? y On Wed, May 30, 2012 at 7:45 PM, Yaron Minsky wrote: > My mistake. It is now public, and allows forks and all. Tell me if you > have any further issues. > > > On Sun, May 27, 2012 at 4:50 AM, Kristian Fiskerstrand < > k...@sumptuouscapital.com> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 2012-05-26 18:49, Yaron Minsky wrote: >> > >> > Migrating the repos themselves is pretty easy, and I've actually >> > already done that. Here's the link: >> > >> > https://bitbucket.org/yminsky/sks-keyserver >> > >> > Any objections? >> >> No objections from me, at least. >> >> I'm not too familiar with bitbucket, but shouldn't be too difficult to >> catch up. However, a question. Is the bitbucket repo set to private? I >> seem to have difficulties creating a clone / fork . >> >> >> - -- >> - >> Kristian Fiskerstrand >> http://www.sumptuouscapital.com >> Twitter: @krifisk >> - >> Corruptissima re publica plurimæ leges >> The greater the degeneration of the republic, the more of its laws >> - >> This email was digitally signed using the OpenPGP >> standard. If you want to read more about this >> The book: Sending Emails - The Safe Way: An >> introduction to OpenPGP security is now >> available in both Amazon Kindle and Paperback >> format at >> http://www.amazon.com/dp/B006RSG1S4/ >> - >> Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.19 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQIcBAEBCAAGBQJPwerfAAoJEBbgz41rC5UIKW0P/15vIaQRVV+S1/ywnSh0RQTE >> VT1JNFqQlVrzU2rMlhSn6yyHUd7bMn+2ObtYOpP23tVNPV8Y1N2SvkTuFCfTQ23Y >> jnPYkt1NXrpp+BDLcOLVE6tMzfy1XVx9EFFqhedaMkcGxBoXBlaI3C03dAJK0sAO >> Ww8gNGwJuq3ZWE3NcM/TMPAFiKgTZy4IWVn49TyQgIzyYbnlF1tIYgj3e+YhroFD >> ERir1EuZDZ9PFXpvNw6qvWhJEHIWJpWK9IlMmwhfGo4jz4DFzzPTibDM79jm8zqC >> nS797GffwBZu0UuvyMWfxoW1mQ+m9a7swkPqKuGzeLC8OYwPxdM9XIlSNxAUbStm >> O1ZFY0qLriez9EkQLvG00vNOn4f5o654JLySuspb1VtO0UzMLY3J4zgLe1DKGI/g >> QXiME9aqnBwnynzPYDGOXBxK2yFppwq/E0nV1/fIRQc7TRpjCUgwun4vX5DSfQuI >> vFvH2DETbOtukJ1myDUHdCecYEj5u09SUo7e7Ev6GUe6xen10dTloctNh6N4jvJW >> HCD+wmuCprZ/6pXr9RIhwnbM+A9rFidEiBiXayS5LI7lzIICpBkv1uXe5ftxocTi >> 15c8/I7bQKGd809X2uc6SK0627ielDsDJSsSQO13UMyUWJfnw0N5hP1tnsSHJEyB >> W2nYyb8yum6rAS93Ehn9 >> =b/4C >> -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] Bitbucket?
My mistake. It is now public, and allows forks and all. Tell me if you have any further issues. On Sun, May 27, 2012 at 4:50 AM, Kristian Fiskerstrand < k...@sumptuouscapital.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2012-05-26 18:49, Yaron Minsky wrote: > > > > Migrating the repos themselves is pretty easy, and I've actually > > already done that. Here's the link: > > > > https://bitbucket.org/yminsky/sks-keyserver > > > > Any objections? > > No objections from me, at least. > > I'm not too familiar with bitbucket, but shouldn't be too difficult to > catch up. However, a question. Is the bitbucket repo set to private? I > seem to have difficulties creating a clone / fork . > > > - -- > - > Kristian Fiskerstrand > http://www.sumptuouscapital.com > Twitter: @krifisk > - > Corruptissima re publica plurimæ leges > The greater the degeneration of the republic, the more of its laws > - > This email was digitally signed using the OpenPGP > standard. If you want to read more about this > The book: Sending Emails - The Safe Way: An > introduction to OpenPGP security is now > available in both Amazon Kindle and Paperback > format at > http://www.amazon.com/dp/B006RSG1S4/ > - > Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCAAGBQJPwerfAAoJEBbgz41rC5UIKW0P/15vIaQRVV+S1/ywnSh0RQTE > VT1JNFqQlVrzU2rMlhSn6yyHUd7bMn+2ObtYOpP23tVNPV8Y1N2SvkTuFCfTQ23Y > jnPYkt1NXrpp+BDLcOLVE6tMzfy1XVx9EFFqhedaMkcGxBoXBlaI3C03dAJK0sAO > Ww8gNGwJuq3ZWE3NcM/TMPAFiKgTZy4IWVn49TyQgIzyYbnlF1tIYgj3e+YhroFD > ERir1EuZDZ9PFXpvNw6qvWhJEHIWJpWK9IlMmwhfGo4jz4DFzzPTibDM79jm8zqC > nS797GffwBZu0UuvyMWfxoW1mQ+m9a7swkPqKuGzeLC8OYwPxdM9XIlSNxAUbStm > O1ZFY0qLriez9EkQLvG00vNOn4f5o654JLySuspb1VtO0UzMLY3J4zgLe1DKGI/g > QXiME9aqnBwnynzPYDGOXBxK2yFppwq/E0nV1/fIRQc7TRpjCUgwun4vX5DSfQuI > vFvH2DETbOtukJ1myDUHdCecYEj5u09SUo7e7Ev6GUe6xen10dTloctNh6N4jvJW > HCD+wmuCprZ/6pXr9RIhwnbM+A9rFidEiBiXayS5LI7lzIICpBkv1uXe5ftxocTi > 15c8/I7bQKGd809X2uc6SK0627ielDsDJSsSQO13UMyUWJfnw0N5hP1tnsSHJEyB > W2nYyb8yum6rAS93Ehn9 > =b/4C > -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] Bitbucket?
On Sat, May 26, 2012 at 8:35 PM, David Benfell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/26/2012 05:12 PM, Matthew Palmer wrote: > > > > Given that (I believe) the source code to sks is already stored in > > a mercurial repository, it would make sense to use a mercurial > > hosting service. > > > > Just for my own idle curiousity, if the complaint about google code's > hosting is that its pull request architecture is inferior, wouldn't > that be a criticism of mercurial itself? > I don't think so. The pull-request architecture I'm talking about is really the web-interface to managing these things, which is built on top of the base system, be it git or mercurial. I think the two are roughly equivalent from this perspective. > - -- > David Benfell > benf...@parts-unknown.org > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPwXa5AAoJELT202JKF+xp4tgQAIE1HV7wBAN3vvjC5OJHUGpo > +pRYhYwu2c3JfA4c80Z1+iryFFBhAvXZEQpCRr/ZwIu+2E41TspaPx541RDsU9zW > VV4DhzvhgLqE7oHxR21TjEk+8xASPRGE29AzaGtvntZuzk1L3Fv20piDoc3kwq3O > HqqthUR0vCK0hGqnIBoZ3USDv4lVwxdVF7MxV6LAj1E/qX1TDq92SsqLL0dWIAYc > TLza7vucbz4Lua4mUtmeqOHQhsUFYqMZAXFggTt0dz+JAC+hvM9USsGCPrV7Pmdd > sLnsxYt1hMGuDsAojdajTSVrnJujG/1q+ZaoJwmvNrOWzM3EPbeklvlBBKc8trOm > qKP6Ylqo6G6bF3CKYGCJY0ZHtoXuIvo2fjbd4b9A9gYiEUXf+Jpj8+YOPdQBbUUr > NGGGnNMP0p28YKfCpmZ5K3Hg+ProC66whlKqzgEWDyzZpt2vlQSccnY9BmxEUW+Y > uLi4I3Gq29DKqExvkt5C5pT4+tVpOEDQcMXY0tqWn5kNSkKY6PVD3ioS7ihcp8/f > 3jrzl2KTEQVirxgHLqxWDC+xMFbS+3fN2ynVHn3zpTJD9gvmEZYVOSA7OAQHbXre > dzQw6qRUc8ctUnGyKgd1hgECOEhejieirQMZn3es0P0xz3xpRECAuI/sV/STf4rX > NVFf0gg4K8TfTkIsjasD > =DfD3 > -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
[Sks-devel] Bitbucket?
I'd like to consider migrating sks to bitbucket. Now that development has been picking up, with multiple people proposing patches, I've come to think that bitbucket's pull request infrastructure is sufficiently better than google code to be worth the migration costs. I think the main pain is in redirecting people from the old site to the new, and migrating the wiki. Migrating the repos themselves is pretty easy, and I've actually already done that. Here's the link: https://bitbucket.org/yminsky/sks-keyserver Any objections? y ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] simple DoS against SKS's HKP interface :/
There may be a way around this problem now, but really, to make SKS good at this kind of situation,s omeone needs to port SKS to a concurrency library like LWT or Async. That will make it much easier to deal with these problems, and to be able to handle multiple concurrent clients properly. Unfortunately, I don't expect to have the time to do such a port myself. y On Wed, Apr 25, 2012 at 4:40 AM, Kim Minh Kaplan wrote: > John Clizbe writes: > > > Oddly, I was looking at a different problem last night and noticed this > > snippet appearing twice in wserver.ml: > > > > 188-189 > > let rec parse_headers map cin = > > let line = input_line cin in (* DOS attack: input_line is unsafe on > > sockets *) > > > > 201-202 > > let parse_request cin = > > let line = input_line cin in (* DOS attack: input_line is unsafe on > > sockets *) > > > > So, it would appear to my barely apprentice level OCaml, that our > > solution lies in a socket-safe implementation of input_line > > I suspect it is more involved and that here all that "unsafe" really > means is that it can block. But you can not really avoid this blocking > with TCP: it is a consequence of the reliability it provides. All the > solutions for handling this blocking phenomenon will involve multiple > simultaneous sockets handling and therefore either multiprocessing or > select-like interface... That is Daniel Kahn Gillmor's suggestion. Also > note that blocking can also occur during writes so prints are also > "unsafe". > > Installing a proxy to handle all this sounds like the easiest way to go. > But I do not know enough about those to be certain that they handle all > cases of blocking. I'm specifically wary about malicious slow POST and > prints. > -- > Kim Minh > > ___ > 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 1.1.3 for Debian
I'll take a look, but it's worth noting that the thread-safety of lazy is not at issue here: sks is a single-threaded program. And if someone wanted to make it multi-threaded, I would propose using a cooperative threading library like async or lwt, which would preserve the safety of Lazy. y On Sat, May 5, 2012 at 10:57 PM, Jens Leinenbach wrote: > Hi John, > > I attached my changes as a patch. It should not break an existing SKS > installation and it should be easy to compile it for Debian with just a > few easy changes in settings.ml and adding the needed paths to sksconf. > (Changes for the example sksconf for Debian included.) > > Then I removed all those "lazy" instructions. I have no idea why they > were used and they just caused trouble here and it works great without > them. > > Additionally, "Lazy.force" was uses several times, but it is not > thread-safe: > http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lazy.html > > Please let me know what you think about my changes. > > > Cheers > Jens > > > ___ > 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] google-code is the home for SKS
Just to clear up any possible confusion, the home for the SKS software distribution is the google code site. http://code.google.com/p/sks-keyserver/ Please point there in preference to the old savannah site, minskyprimus.netand minsky-primus.net. y ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks.pod is missing from tarball for 1.1.2?
I'm not sure how I screwed that tarball up, but I regenerated it and it appears to have the .pod file there. Please try again. On Fri, Sep 30, 2011 at 3:39 AM, Eygene Ryabinkin wrote: > John, good day. > > Fri, Sep 30, 2011 at 01:56:26AM -0500, John Clizbe wrote: >> Until Yaron can get a new tarball uploaded, try these >> >> >> http://www.gingerbear.net/sks-1.1.2.tgz >> >> http://www.gingerbear.net/sks-1.1.2.tgz.asc >> >> >> Or pull directly from the repository with >> >> hg clone https://code.google.com/p/sks-keyserver/ -r cc5c1deed445 sks-1.1.2 > > Sure, I had just extracted the missing files from the repository, but > the thing is that I am updating the FreeBSD port for SKS, so it will > be rather good to have "official" tarballs downloaded from the usual > place to avoid people asking questions about the origin of the > software. > -- > rea > > ___ > 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] Wiki
Note that to contribute to the wiki, you need a google account, which you can get here if you don't have one: http://www.google.com/accounts/NewAccount On Sun, May 22, 2011 at 9:14 AM, Yaron Minsky wrote: > Not to discourage the creation of a new wiki, but it's worth noting that > there is a wiki available on the google code site: > >http://code.google.com/p/sks-keyserver/wiki/Documentation > > The wiki requires users to be permissioned, but I'd be happy to set up > those who are interested. I don't think I can throw the wiki wide-open, > sadly. > > y > > On Sun, May 22, 2011 at 7:53 AM, Sebastian Urbach > wrote: > >> Dear colleagues, >> >> There are a lot of information pieces floating around, regarding SKS. >> As i can tell from my own experience it is not very easy to find all >> the information you need. >> >> The appropriate solution for our community seems to be a wiki because >> everybody can edit everything, everytime and everywhere :-) >> >> Since hardware, software & traffic is not an issue for me i just went >> for it and set up a wiki: >> >> http://key-server.de/mediwiki >> >> Everybody on this list can create an account and will be accepted >> manually. Fromt that point on everybody is free to do whatever he wants. >> >> I also want to make clear that my intentions are not to screw with >> Kristians work / website. This should just be an easy to keep the >> informations acutal and easy to find for everybody here and out >> there ;-) >> >> Everything is open for discussion regarding the wiki even Layout and >> things like that. I also took the liberty to grab sks-keyservers.org >> if that wiki should become a success :-) >> >> Krstian: sks-keyservers.net >> Wiki:sks-keyservers.org (Some day) >> >> Please create your accounts now :-) >> >> -- >> >> Mit freundlichen Gruessen / yours sincerely >> >> Sebastian Urbach >> >> -- >> Convictions are more dangerous enemies of truth than lies. >> -- >> Friedrich Nietzsche (1844 - 1900) >> German philosopher, poet and classical philologist >> >> ___ >> 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] Wiki
Not to discourage the creation of a new wiki, but it's worth noting that there is a wiki available on the google code site: http://code.google.com/p/sks-keyserver/wiki/Documentation The wiki requires users to be permissioned, but I'd be happy to set up those who are interested. I don't think I can throw the wiki wide-open, sadly. y On Sun, May 22, 2011 at 7:53 AM, Sebastian Urbach wrote: > Dear colleagues, > > There are a lot of information pieces floating around, regarding SKS. > As i can tell from my own experience it is not very easy to find all > the information you need. > > The appropriate solution for our community seems to be a wiki because > everybody can edit everything, everytime and everywhere :-) > > Since hardware, software & traffic is not an issue for me i just went > for it and set up a wiki: > > http://key-server.de/mediwiki > > Everybody on this list can create an account and will be accepted > manually. Fromt that point on everybody is free to do whatever he wants. > > I also want to make clear that my intentions are not to screw with > Kristians work / website. This should just be an easy to keep the > informations acutal and easy to find for everybody here and out > there ;-) > > Everything is open for discussion regarding the wiki even Layout and > things like that. I also took the liberty to grab sks-keyservers.org > if that wiki should become a success :-) > > Krstian: sks-keyservers.net > Wiki:sks-keyservers.org (Some day) > > Please create your accounts now :-) > > -- > > Mit freundlichen Gruessen / yours sincerely > > Sebastian Urbach > > -- > Convictions are more dangerous enemies of truth than lies. > -- > Friedrich Nietzsche (1844 - 1900) > German philosopher, poet and classical philologist > > ___ > 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] Woohoo!
My apologies for being slow. Getting those patches uploaded had just slipped off my stack. I don't really have a lot of time to devote to sks these days. That said, I'll try to be more responsive than I have been in reviewing and accepting patches. Putting them up as clones on the google code site is a nice way to propose them. y On Sat, May 21, 2011 at 1:52 PM, John Clizbe wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John Clizbe wrote: > > Kim Minh Kaplan wrote: > >> http://code.google.com/p/sks-keyserver/updates/list shows 12 new > >> revisions (one merge) in the repository this week. > > > > No idea what happened to mine. Yaron said he'd look at them but never > heard back. > > D'OH!! There they are, the 10 pushed at one time. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12-svn5502-2010-12-23 (Windows XP) > Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! > Comment: Be part of the £€37 ECHELON -- Use Strong Encryption. > Comment: It's YOUR right - for the time being. > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBCAAGBQJN1/vqAAoJECMTMVxDW9A0w74H/jy/PktWUGf8H5HqXY9ydLTE > Vgftk5DK+WE6MK2nIp+oWOMp42xtouxktliIyGLNB/TamID3IZxhCmjzCUlNb9Ox > 3Zi5DC2dasek+TRIZrRlvauYiFFjjbnZu/x7OUSrtfwH4VjIRL8CxZs83KKY26be > YuurCGwKczLSVKzvajeJ+3VCJa4pkx+088Ye6uzw/TJ7FYcegjk0TTJFVffb8YDA > Ydj5lXlttG44Lz5oZo53aCsGR4xBTPeuJ1ZN0cblZ7PdIWFDOFY1uT/tftcV6xtw > SRTFGW0wJcAP2zew46FY1qdPmLw7oZDoMLtj0u0KWAr+AkN3Jdjp4LmSawD8CFKI > XgQBEQgABgUCTdf76gAKCRDrXhnz1laYJT4xAP9GL0rcjWkF1JdPEUc4PdjBvND7 > p0fWzfplO9MhndhXCQD/c0WFd7VQS7FV5rG6IwyrnhVbMVr3njRRJuszTeTJvYY= > =CpXE > -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] minskyprimus.net domain expired
My apologies. I'm in the process of transferring the domain, and will reinstate it. It's worth noting that the best place for keeping info about sks is I think the google code site: http://code.google.com/p/sks-keyserver That has the hg repos, links to the papers, and some documentation. All told, I think that's where people should go. y On Thu, May 12, 2011 at 4:40 PM, Daniel Kahn Gillmor wrote: > hey sks people-- > > You might (like i did) have one of the following busted links in your > SKS server index.html: > > http://www.nongnu.org/sks/ appears to redirect to > http://minskyprimus.net/sks/ > > but the minskyprimus.net domain name appears to have expired last week. > > The content that used to live there appears to be found at > http://minsky-primus.homeip.net/sks > > You might want to update your links. > > Whoever used to control the minskyprimus.net: do you plan to reinstate > the domain? Do we have a place to store the canonical documents about > the gossip protocol if these domains go away? > >--dkg > > > ___ > 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] Re: Delete key from keyserver
On Wed, Sep 8, 2010 at 3:09 AM, wrote: > Granted this could be mitigated if only 'trusted introducers' (TI) are > able to add deletion tokens ( but as long as the protocol is open, this, > itself, would require a lot of thought on implementation. E.g by adding an > element to the key to be deleted that is signed by the TI. > I think it would be a mistake to implement deletion in the way I described without some notion of trusted introducers. And that should I think be implemented by having a set of keys that the full network trusts to introduce deletions. As I said, there is real work getting the code to make this happen, and also doing the social work of choosing the trusted sources. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Delete key from keyserver
I'm not sure that inserting the new tag in the offending key is really the simplest way of encoding this. Here's a short description of the algorithm I have in mind. The basic thing to understand about SKS is that it works by agreeing on sets of values. When node A and B (with sets S_A and S_A) communicate, they figure out the hash-values that each is missing from the other, i.e., S_A - S_B and S_B - S_A. Then, based on those hash values, A and B request the missing data. Currently, the set elements are keys. To support deletion, you would want to extend the values so they logically were a union type: type set_element = | Key of Key.t | Deletion of Hash.t where Key.t is a PGP key, and Hash.t is the type of the hash of a set_element. The idea is that when a key-server adds a Deletion to its set of keys, it actually deletes the corresponding element from its data set. Now, consider what happens if A has a deletion for a value that B still has. A will discover it's missing the key in question, and B will discover it's missing the deletion. Each will request the missing element from the other. A's request will succeed, but will have no effect, since A will know to delete the key. B's request will succeed, and it will as a result delete the key in question from its database. If we want to delete the deletions, we can extend set_element with one more variant: type set_element = | Key of Key.t | Deletion of Time.t * Hash.t | Deletions_stable of Time.t We've added a time to the Deletion, which is the time the deletion was added to the system. The Deletions_stable element is meant to indicate that all deletions sent before the specified time are assumed to be stable, and can thus be discarded (and older Deletions_stable elements can also be discarded). Thus, if someone periodically sends out a Deletions_stable after a decent time period, then this will clean out old deletions from the system. Presumably, the Deletion and Deletions_stable entries would need to be signed by some trusted key before they would be accepted by a given keyserver. But that goes to the policy question... y On Tue, Sep 7, 2010 at 10:28 PM, Jeff Johnson wrote: > > On Sep 7, 2010, at 9:50 PM, Yaron Minsky wrote: > > > I think that a basic form of deletion is pretty easy, and requires no > real research The algorithm is simple. You simply add a new kind of > pseudo-key to be gossiped around: a deletion token. In the simplest > version, the deletion token never expires; it's a permanent addition to the > database. But the effect of adding the deletion token is that the thing it > wants to delete is effectively removed. With a small amount of extra > cleverness, one can allow the deletion token to be removed eventually as > well. But given the small number of deletions that appear to be necessary, > it hardly seems urgent. > > > > Thanks. > > When I hear "pseudo-key" and "deletion token", I also hear a form of "white > out". > > Since RFC-2440/4880 already has well understood attributes of revocation > and expiry, > then I would hope that a "pseudo-key" could actually be grafted on as > another attribute tag > on an existing revoked/expired pubkey with the additional meaning >This pubkey is now a "pseudo-key deletion token" and should be > ignored while gossiping. > > If all the key packets except >the pubkey >the revocation >the additional attribute that indicates never distribute > are stripped out (specifically the userid and all certification > signatures), that might be sufficient > even for lawyers -- is it possible to "own" 1 or more MPI's if there are > no identifying marks to > indicate the owner? I'll leave that to others with the usual IANAL > disclaimer. > > So my next question would be: > >Is it feasible to craft up a special "pseudo key" as above that -- > when fed manually to >each SKS server -- would replace, not augment, the existing > offending pubkey and >NEVER be gossiped. > > I add "manually" solely to uncouple the token from its distribution. > > What I don't know is > 1) Can the deletion be handled as an attribute? > 2) How should that attribute be represented as a RFC 2440/4880 tag? > > The next step would be to relax the "fed manually" so that the pseudo-key > could be gossiped, > thereby replacing every occurrence of the offending pubkey with the "pseudo > key deletion token". > > Does that sound like the basic framework that would be needed? > > 73 de Jeff > > > There is a policy question: who gets to add a deletion token to the
Re: [Sks-devel] Re: Delete key from keyserver
I agree, if you want this to work, you want to have a path to deleting the deletions. That said, I think deleting the deletion tokens is not that big of a deal, as long as you have a set of people/institutions that the entire network trusts to introduce deletions. I think the hard bits are not coming up with the algorithm. They're writing the code and producing the social agreement among the people hosting the keyservers. y On Tue, Sep 7, 2010 at 10:46 PM, Robert J. Hansen wrote: > On 9/7/2010 9:50 PM, Yaron Minsky wrote: > > I think that a basic form of deletion is pretty easy, and requires no real > research The algorithm is simple. You simply add a new kind of pseudo-key > to be gossiped around: a deletion token. In the simplest version, the > deletion token never expires; it's a permanent addition to the database. > But the effect of adding the deletion token is that the thing it wants to > delete is effectively removed. With a small amount of extra cleverness, one > can allow the deletion token to be removed eventually as well. But given > the small number of deletions that appear to be necessary, it hardly seems > urgent. > > > I see no reason to think the number of deletions will be small. My > nightmare scenario involves people with an interest in illegal information > discovering the keyserver network makes a good vehicle for dissemination of > relatively small pieces of illegal information. All it takes is one person > discovering this and others thinking it's a good idea and the next thing you > know we've got keyservers drowned in spam. It's just that this spam could > get keyserver operators arrested for distribution of illegal information. > > (Note: although I see no reason to think the number of deletions will be > small, there is also no reason to think my nightmare scenario will come to > pass. We simply *do not know* how many deletions will be necessary. I > think we ought keep this lack of knowledge in mind when we discuss > solutions.) > > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Delete key from keyserver
I think that a basic form of deletion is pretty easy, and requires no real research The algorithm is simple. You simply add a new kind of pseudo-key to be gossiped around: a deletion token. In the simplest version, the deletion token never expires; it's a permanent addition to the database. But the effect of adding the deletion token is that the thing it wants to delete is effectively removed. With a small amount of extra cleverness, one can allow the deletion token to be removed eventually as well. But given the small number of deletions that appear to be necessary, it hardly seems urgent. There is a policy question: who gets to add a deletion token to the system? The owner of the key to be deleted? Or perhaps there are a set of trusted administrators shared by the whole network who can ask for deletions? And, of course, there's the question of who is going to do the work. I don't have the time to devote to SKS at this point, so if this feature is to be added, someone else needs to do it. y On Tue, Sep 7, 2010 at 6:31 PM, Jeff Johnson wrote: > > On Jul 8, 2010, at 11:34 AM, Ari Trachtenberg wrote: > > > The backend data structure supporting SKS does not yet support true > deletion. > > We are researching this (but it will take some time :-) > > Now would be a _PERFECT_ time for some research to be actively deployed. > ;-) > > OTHERWISE > > Since their are only 50-100 (just a rough estimate) SKS servers, a key > could > most definitely be dropped with a modest amount of coordination. > > Consider what happens if the reconciliation protocol version is incremented > and 2 machines > deploy with the version++ protocol on a store that DROPS the offending key > and actively filters that key going forward. > > So there would be 2 SKS nets, and a need to coordinate a switchover from > one store to the other. > > Please note that I am NOT suggesting that the SKS protocol be incremented > (though that would most definitely "work"). > > What I am suggesting is that -- with a modest amount of coordination -- > there are solutions that could be devised in order to solve a "real world" > problem. > > This isn't the first person who decided to lititigate, and won't be the > last. > > JMHO, YMMV, I'm game for version++ (though I think there are most > definitely easier > ways to drop a pubkey than rev'ing the SKS reconciliation protocol version) > if anyone else > is. > > 73 de Jeff > > > -Ari > > > > On Jul 8, 2010, at 6:37 AM, Sebastien wrote: > > > >> Since I have no web interface running, I did this: > >> > >> #-- exporting the public key I want to drop in SKS database > >> gpg --export --armor --output mykey.asc -- myname > >> > >> #-- getting the MD5 hash of that key > >> md5sum mykey.asc > >> > >> then > >> > >> #-- dropping the key from SKS using MD5 hash previousy retreived > >> sks drop > >> > >> Result: > >> > >> #-- key no longer exist in key server database > >> gpg --keyserver my_sks_server --seach-keys -- myname > >> > >> This could be fine... but I cannot add a new key anymore. Seems that SKS > >> database is corrupted now. Any idea ? > >> > >> > >> > >> ___ > >> Sks-devel mailing list > >> Sks-devel@nongnu.org > >> http://lists.nongnu.org/mailman/listinfo/sks-devel > > > > > > ___ > > Sks-devel mailing list > > Sks-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/sks-devel > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] taking down keyserver.fabbione.net for good
On Wed, May 12, 2010 at 1:34 PM, Kim Minh Kaplan > wrote: > Fabio M. Di Nitto writes: > > > I have decided to stop running the service. > > Whoever can modify http://code.google.com/p/sks-keyserver/ should remove > http://keyserver.fabbionne.net from the page. > Done. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Reconciling algorithm
On Wed, Apr 28, 2010 at 6:29 PM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 21/04/10 02:17, Yaron Minsky wrote: >>> I am interested in knowing the *exact* algorithm/protocol SKS uses for >>> reconciliation. I have read the two papers in the main SKS webpage, but >>> it is not enough to "clone" the wire protocol and implement another >>> independent keyserver. >>> >>> I can not read ocaml sourcecode :-(. >> >> Sorry. I'm afraid the source is the only available documentation for >> the protocol. > > This is not good. An undocumented *key* feature, written in a obscure > programming language :). > > I know it is not very appropiate to post this in this mailing list but... > > I was wondering if there is any kind of demand of an alternative OpenPGP > keyserver, with a different but documented syncronization technology, > like Merkle trees. Implemented in Python. > > I apology for the off-topic and the attack to sks :(. No apologies necessary! That said, I humbly suggest you consider just hacking on SKS. OCaml is a surprisingly pleasant language, once you get the hang of it. And it's really not as hard to learn as you might think. SKS could benefit from more developers... y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Reconciling algorithm
On Tue, Apr 20, 2010 at 7:54 PM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, everybody. > > I am interested in knowing the *exact* algorithm/protocol SKS uses for > reconciliation. I have read the two papers in the main SKS webpage, but > it is not enough to "clone" the wire protocol and implement another > independent keyserver. > > I can not read ocaml sourcecode :-(. Sorry. I'm afraid the source is the only available documentation for the protocol. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)
On Fri, Feb 26, 2010 at 6:56 PM, Jason Harris wrote: > On Fri, Feb 26, 2010 at 09:58:17PM +, Kim Minh Kaplan wrote: > > Jeff Johnson writes: > > > > From the 3 deadlocks I've seen, I'd guess that any moderately large > > > (>500 keys) is likely to encounter a partition tree deadlock if > > > DB_INIT_LOCK is enabled. > > Fortunately, I don't have these problems with pks even though mine > still uses BDB 2.x. I know Hironobu (OpenPKSD) and Jonathan (onak) > report massive speed slowdowns with SQL-everything (that they used), > but I don't recall if they tried sqlite3. I believe that BDB is a > solid DB with proper use of the API, having seen it in pks, but am > very hopeful that SKS will do quite well when converted to sqlite3. > I'm a big fan of sqlite, and Markus Mottl has written an excellent binding for the library --- far better than the mediocre binding I wrote for bdb. I think porting sks to use sqlite instead of bdb would be great, although I would think some thinking about migration would be in order. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)
On Wed, Feb 24, 2010 at 6:01 PM, Kim Minh Kaplan > wrote: > Jeff Johnson: > > > BTW, can someone describe -- even superficially -- what is > > being attempted with the PTree store? Any details are welcomed, > > I'm not yet able to read OCAML code well enough to recognize > > what type of store is being attempted. > > The use of the prefix tree is described in the two articles Set > Reconciliation with Nearly Optimal Communication Complexity and > Practical Set Reconciliation. You will find them on the Google code > page¹. The mathematics are quite involved though. It is the > information that is needed for two servers to know what keys they need > to exchange. > Indeed. The data structure is called a prefix-tree in the paper (hence PTree). Basically, it's a binary tree that holds a special kind of checksum for different subsets of the keyspace, dividing the space of keys up as you go down the tree. > The PTree deadlock is easily reproduced, and (with db_stat) a > > detailed deadlock diagnosis could be attempted. > > How would that be? > > > Is there interest in adding DB_INIT_LOCK to the PTree store? > > While I do not see any practical interest in doing this, the symptom > smells like a bug hanging in there that could very well be related to > the problem Arnold experienced recently. There would definitely be > interest in correcting it. > > ¹ http://code.google.com/p/sks-keyserver/ > -- > Kim Minh > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [PATCH] Use domain names with hkp_address and recon_address
The patches look good. They've been pushed to the main repo. y On Mon, Aug 31, 2009 at 5:41 PM, Kim Minh Kaplan > wrote: > John Marshall writes: > > On Sun, 30 Aug 2009, 23:02 +, Kim Minh Kaplan wrote: >> >> may be the documentation change I did is not right and should read "Can >>> be a list of whitespace separated IP addresses or domain names." >>> >> >> Yes, changing the documentation patch as you suggest above would be good. >> > > OK I committed it as 95926d02fe80 in http://www.kim-minh.com/hg/sks/please > consider for inclusion in SKS. > > > Kim Minh. > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [PATCH]: fix cursor leak (was: [Sks-devel] Improving the SKS development model)
Nice catch! It's been pushed to the central repo. y On Sun, Aug 30, 2009 at 4:28 AM, Kim Minh Kaplan > wrote: > There is a cursor leak in keydb.ml. Attached patch fixes it. It is > available in my repository (http://www.kim-minh.com/hg/sks/) as > d351d05877dc. > > Kim Minh. > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Improving the SKS development model
The diffs look good, and the resulting tree builds. I've pulled your changes into the repo. y On Sat, Aug 15, 2009 at 4:33 AM, Kim Minh Kaplan > wrote: > Yaron Minsky writes: > > > Neither of those revisions appear to be in the hg repo you mentioned: > > > > [ymin...@minskyprimus sks]$ hg log http://www.kim-minh.com/hg/sks/ -r > > 977e38781686 > > abort: unknown revision '977e38781686'! > > [ymin...@minskyprimus sks]$ hg log http://www.kim-minh.com/hg/sks/ -r > > c67b2f226c24 > > abort: unknown revision 'c67b2f226c24'! > > > > Are you sure the changes you're talking about are in there? > > Ouch, I was trying to cleanup the repository and overdid it a bit. I > still have to get used tu Mercurial. The patches are back in. > > Kim Minh. > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Improving the SKS development model
On Thu, Aug 13, 2009 at 1:40 PM, Kim Minh Kaplan > wrote: > The only interesting patches are word index patch (977e38781686) as well > as a tail recursion fix (c67b2f226c24), the two last commits. I still > have some other commits in a private repository but I do not thing they > should be published (except may be a reverse signature index but I have > to investigate more first). Neither of those revisions appear to be in the hg repo you mentioned: [ymin...@minskyprimus sks]$ hg log http://www.kim-minh.com/hg/sks/ -r 977e38781686 abort: unknown revision '977e38781686'! [ymin...@minskyprimus sks]$ hg log http://www.kim-minh.com/hg/sks/ -r c67b2f226c24 abort: unknown revision 'c67b2f226c24'! Are you sure the changes you're talking about are in there? You might want to clone my main repo, apply your patches, and serve that repo up for me to pull from. That way, you'll get rid of all the cruft that you don't care about anymore. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Improving the SKS development model
Sounds like another good patch! On Fri, Aug 14, 2009 at 2:45 PM, Kim Minh Kaplan > wrote: > Dinko Korunic writes: > > > I reckon this is because of initial import duration (build vs pbuild) > > only. Personally, I am against using pbuild exactly for reasons you said. > > Are you talking of build vs fastbuild? You can not do without pbuild > for the recon process. Note that one reason of the excessive slowness > of build is because of a strange tuning of database, namely pagesize. > By default it is set to 2Kbytes. Changing to 8Kbytes yields better > results (most keys are above 1Kbytes in size and well below 2Kbytes). > > Kim Minh > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Improving the SKS development model
I did not update the CHANGELOG properly. I'll do that for the 1.1.2 release. y On Thu, Aug 13, 2009 at 3:52 AM, John Clizbe wrote: > Yaron Minsky wrote: > > One other note: I finally cut a 1.1.1 release. It is on the google code > > site. > > What patches are included? > > I didn't see any entries for 1.1.1 in the CHANGELOG > > -- > John P. Clizbe Inet:John (a) Mozilla-Enigmail.org > You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or > mailto:pgp-public-k...@gingerbear.net?subject=help > > Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" > A:"An odd melody / island voices on the winds / surplus of vowels" > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Improving the SKS development model
Wow! You've been working hard. Your repo contains 30-some patches consisting of 3k lines of diffs! Are you proposing pushing all of that to the mainline tree? y On Thu, Aug 13, 2009 at 1:06 AM, Kim Minh Kaplan > wrote: > Yaron Minsky writes: > > If people would put up public hg repos containing their patches and >> emailed me when they thought they were ready for inclusion in the mainline, >> I would be happy to manage the process of pulling that in and of cutting >> releases. >> > > My repository (http://www.kim-minh.com/hg/sks/) now includes the recent > index patch (977e38781686) as well as a tail recursion fix (c67b2f226c24). > > Kim Minh. > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Editing the wiki
If anyone is interested in contributing to the documentation wiki on the google code site, please send me an email personally, and I will permission you for that. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Improving the SKS development model
Let's hold off a bit on the mailing list migration. I'd like to focus first on getting the google code site in good shape... y On Wed, Aug 12, 2009 at 10:17 PM, John Marshall < john.marsh...@riverwillow.com.au> wrote: > On Wed, 12 Aug 2009, 22:09 -0400, Yaron Minsky wrote: > > On Wed, Aug 12, 2009 at 10:06 PM, John Marshall < > > john.marsh...@riverwillow.com.au> wrote: > > > > > Is there any need to move the mailing list from where it is? I am not > > > in favour of mailing lists that encourage "rich" mail messages. I > don't > > > want to see list email full of HTML crud. > > > > > > I mostly want to move the list because savannah is an administrative > > disaster (I still can't get them to set up a damn redirect to my new > website > > for sks), and I'd like high-quality list archives, which can not be had > at > > savannah. > > Fair enough. Is it possible to configure a Google Groups mailing list > to be text only? How much of one's life history (real or fake) does one > have to divulge to sign up to a Google Groups list? At least with > Mailman all you need to give is an email address. I refuse to use > Yahoo! groups but I haven't looked at Google groups. > > -- > John Marshall > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Improving the SKS development model
On Wed, Aug 12, 2009 at 10:06 PM, John Marshall < john.marsh...@riverwillow.com.au> wrote: > Is there any need to move the mailing list from where it is? I am not > in favour of mailing lists that encourage "rich" mail messages. I don't > want to see list email full of HTML crud. I mostly want to move the list because savannah is an administrative disaster (I still can't get them to set up a damn redirect to my new website for sks), and I'd like high-quality list archives, which can not be had at savannah. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Re: Improving the SKS development model
One other note: I finally cut a 1.1.1 release. It is on the google code site. y On Wed, Aug 12, 2009 at 9:07 PM, Yaron Minsky wrote: > As y'all have no doubt have noticed, I haven't had a ton of time to spend > on SKS development of late. But people on the list have started filling the > gap, coming up with various patches to improve things. I think we need to > get a more organized development model to make it easier to put together > releases and keep track of what's going on, and I think Jason's proposal is > the right one: we should use mercurial for sharing development rather than > just passing patches around. > > If people would put up public hg repos containing their patches and emailed > me when they thought they were ready for inclusion in the mainline, I would > be happy to manage the process of pulling that in and of cutting releases. > > So, what do people think? > > A couple of other small changes I'm contemplating: start using google code > as the hosting site for the main sks repository, and for other things like > issue tracking and a wiki. I've done the very basic setup, and you can find > the site here: > >http://code.google.com/p/sks-keyserver/ > > And I'm thinking of potentially moving the sks mailing list to google > groups. I'm also curious what people think about that. I've already > registered sks-us...@googlegroups.com for that purpose. > > y > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Improving the SKS development model
As y'all have no doubt have noticed, I haven't had a ton of time to spend on SKS development of late. But people on the list have started filling the gap, coming up with various patches to improve things. I think we need to get a more organized development model to make it easier to put together releases and keep track of what's going on, and I think Jason's proposal is the right one: we should use mercurial for sharing development rather than just passing patches around. If people would put up public hg repos containing their patches and emailed me when they thought they were ready for inclusion in the mainline, I would be happy to manage the process of pulling that in and of cutting releases. So, what do people think? A couple of other small changes I'm contemplating: start using google code as the hosting site for the main sks repository, and for other things like issue tracking and a wiki. I've done the very basic setup, and you can find the site here: http://code.google.com/p/sks-keyserver/ And I'm thinking of potentially moving the sks mailing list to google groups. I'm also curious what people think about that. I've already registered sks-us...@googlegroups.com for that purpose. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [PATCH] unqueue the tqueue database even when mailsync is empty (was: [Sks-devel] [PATCH] Bundle IPv6, DNS fixes, sks dump fix)
In the original design of the system, repeatedly stuffing an error in the log when there were no partners available was done on purpose. The idea was that not having mailsync peers is a serious error for a public SKS server, since it means that the keys submitted to SKS will never make it into the PKS system. That's why there's no way of turning the error off. Do people think that the error should be made optional? If we have lots of SKS keyservers that don't have mailsync's, I'm afraid the PKS network will get left behind... On Fri, May 1, 2009 at 10:18 AM, Kim Minh Kaplan > wrote: > When you don't have mailsync partners the db.log file fills up with > "" error messages and the KDB/tqueue database is > never dequeued. The attached patch fixes this. > > Kim Minh. > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Cut a new release
Are people content with the current state of the repo? Are there other patches I've missed that people think should go in? Maybe the biggest question is whether the IPv6 support is now in an acceptable state. If no one objects, in a couple of days I will bless 1.1.1. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [CONTRIB] sks.pod text for enabling IPv6
2009/3/31 Phil Pennock > Do you want to mandate O'Caml 3.11 for SKS 1.1.1 ? Otherwise, the C > call is: I'd be in favor of switching to 3.11, if people don't find that too painful. Objections? y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [CONTRIB] sks.pod text for enabling IPv6
2009/3/30 Phil Pennock > If I cared more for the O'Caml language than I do, I'd look into > contributing back patches to the language maintainers to solve this > problem. But that doesn't solve the immediate problem, unless an SKS > release will be delayed pending a new language compiler release and time > for everyone to move across to it. > For what it's worth, we could just wrap up the C functions using OCaml's FFI. That's how I got bdb support in there. I'm not saying it's necessarily worth the effort, but it is distinctly doable. OCaml is a good UNIX citizen and allows one to use C functions without too much pain. Certainly no need to wait for the next compiler release to use those functions. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] More patches
I just integrated a couple more patches from the list, with some minor modifications. (I also added in an mli to the membership module. SKS is sadly short on interface files, which makes it a real pain to go back and think about the code. I'd be happy to accept more patches adding mlis...) People should take a look and see if this is up to snuff. If there are no complaints and no other patches I've missed, this will likely become the next release. Here's the repo: http://hg.minskyprimus.net/sks/trunk y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Patches imported
I can wait. On Thu, Mar 26, 2009 at 3:36 AM, Kim Minh Kaplan > wrote: > Yaron Minsky writes: > > > I imported the proposed patches into the hg repo, with some minor > changes. > > People should try it out, and if the reports are good, I'll bless it as > the > > next release. > > I still have the auto-refresh membership DNS patch to prepare. If you > can wait until this weekend, I will have it ready. > > Kim Minh. > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Patches imported
I imported the proposed patches into the hg repo, with some minor changes. People should try it out, and if the reports are good, I'll bless it as the next release. The repo can be found here: http://hg.minskyprimus.net/sks/trunk y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [PATCH] HKP Timeout
I'm OK with that.
2009/3/25 Peter Pramberger
> Just remembered this - maybe SKS' internal default value should be
> increased?
>
>
> Br,
> Peter
>
>
> Original-Nachricht
> Betreff: [Sks-devel] HKP Timeout
> Datum: Tue, 13 Jun 2006 17:00:23 +0200
> Von: Peter Pramberger
> An: sks-devel@nongnu.org
>
> Hi all!
>
> I recently got a complaint from a user not able to download certain large
> PGP
> keys. It turned out that he has a slow Internet connection (56k modem) and
> always got a 408 error ("Timed out after 60 seconds") from SKS for at least
> the following keys:
>
> 0x94C09C7F
> 0x74E0B766
> 0x248AEB73
> 0x307D56ED
>
> This keys are quite large, eg. 0x94C09C7F has about 450KB thus exceeding
> the
> default HKP timeout of 60s on slow connections. Increasing the timeout
> value
> to 180s solved the problem (this way it should even work with 28.8 links).
>
> I'd suggest that all operators set "wserver_timeout: 180" in sksconf to
> remove
> this limitation.
>
> Any thoughts?
>
>
> Peter
>
>
>
> diff -Naurp sks-1.1.0.orig/settings.ml sks-1.1.0/settings.ml
> --- sks-1.1.0.orig/settings.ml 2008-05-08 03:05:54.0 +0200
> +++ sks-1.1.0/settings.ml 2009-03-25 19:49:21.0 +0100
> @@ -149,7 +149,7 @@ let set_ptree_thresh_mult value = ptree_
> let recon_thresh_mult = ref 30
> let set_recon_thresh_mult value = recon_thresh_mult := value
>
> -let wserver_timeout = ref 60
> +let wserver_timeout = ref 180
> let set_wserver_timeout value = wserver_timeout := value
>
> let reconciliation_config_timeout = ref 45
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [PATCH] Bundle IPv6, DNS fixes, sks dump fix
Maybe now is the time for putting together a release. Could everyone who has a patch they'd like to see included please email to the list with an up-to-date patch, and I can review them and bring them all together. I'd ideally like to get one patch for each fix, so one for sks dump, one for DNS staleness, one for IPv6, etc. If people have conflicting ideas as to which patches should go in, we should try to resolve them. y 2009/3/25 Kim Minh Kaplan > > Hello, > > I have finally bundled recent changes into a single patch against Yaron > Minsky's repository. It includes sks dump fix[1], DNS staleness fix[2] > and IPv6 support as Phil Pennock suggested it[3] but with additional > rewritings: > > * work with the other fixes. > > * no specific configuration for using IPv6. But you can have > multiple addresses in your hkp_address and recon_address. If you > have IPv4 addresses then IPv4 is enabled, if you have IPv6 > addresses then IPv6 is enabled. For example I use: > >recon_address: 91.121.167.18 2001:41d0:1:e812:1c:c0ff:fe65:2cd4 >hkp_address: 91.121.167.18 2001:41d0:1:e812:1c:c0ff:fe65:2cd4 > > Or you can download a patched source tree at > >http://www.kim-minh.com/pub/sks/sks-kmkaplan-1.tgz > > Would a backport to stable version help for wider adoption? > > Regards, > Kim Minh. > > [1] http://lists.gnu.org/archive/html/sks-devel/2009-03/msg00091.html > [2] http://lists.gnu.org/archive/html/sks-devel/2009-03/msg00118.html > [3] http://lists.gnu.org/archive/html/sks-devel/2009-03/msg2.html > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [PATCH] auto-refresh membership DNS
On Mon, Mar 23, 2009 at 12:13 AM, Phil Pennock wrote: > On 2009-03-22 at 22:40 -0400, Yaron Minsky wrote: > > 2009/3/22 Phil Pennock > > > The gotcha here is async DNS support in O'Caml. > > > > I'm sure I'm missing something here, but why is asynchronous DNS a > > requirement? Why not do the DNS queries using threads? > > You're not missing anything, I was. I was sticking to the > event-handling stuff already done in SKS and I know nothing about how > cleanly O'Caml lets you use threads and combine the two models. If it's > easy and clean, then my oversight was ... glaring. > > None of the current membership has any kind of locking against > concurrent updates -- how much is needed, with O'Caml, and how much > locking done automatically? I don't quite know what you mean by "automatically", but there are threads, mutexes and condition variables, all in easy reach. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] problems with SKS 1.0.10 when searching by key ID from GnuPG
Sorry, this is all explained by me getting all confused with the version numbers. Ignore my last post (except to point out that a new release needs to come soon...) y 2009/3/22 Daniel Kahn Gillmor > On 03/22/2009 10:29 PM, Yaron Minsky wrote: > > I'm really confused. People have piped in in both directions on this > one, > > so does someone have the definitive story? Is 1.0.10 the one that > behaves > > correctly, or 1.0.9? > > So far i haven't heard anyone claim that 1.0.10 works correctly. 1.1.0 > works correctly, and david shaw just pointed out that 1.0.9 works > correctly. I believe 1.0.10 is the only version with this particular bug. > > > And yes, we should get a 1.0.11 release out soon. I was waiting for the > > IPv6 patch to settle down and for everyone to agree that it worked for > IPv4 > > and IPv6 installations alike. > > > do you mean you're hoping to release 1.1.1 soon? Or is there some sort > of branched development process going on? > >--dkg > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [PATCH] auto-refresh membership DNS
2009/3/22 Phil Pennock > The gotcha here is async DNS support in O'Caml. I'm sure I'm missing something here, but why is asynchronous DNS a requirement? Why not do the DNS queries using threads? y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] problems with SKS 1.0.10 when searching by key ID from GnuPG
I'm really confused. People have piped in in both directions on this one, so does someone have the definitive story? Is 1.0.10 the one that behaves correctly, or 1.0.9? And yes, we should get a 1.0.11 release out soon. I was waiting for the IPv6 patch to settle down and for everyone to agree that it worked for IPv4 and IPv6 installations alike. y 2009/3/22 Daniel Kahn Gillmor > On 03/22/2009 06:41 PM, David Shaw wrote: > > The 'exact=on' problem is specific to 1.0.10. It worked properly in > 1.0.9. > > > > See: http://www.mail-archive.com/sks-devel@nongnu.org/msg00287.html > > Ah, thanks for the pointer, David. > > Given that this causes problems for users of gnupg, has any thought been > given to requiring members of the keyserver pools to not run that > version of SKS? keys.gnupg.net itself contains several keyservers > running 1.0.10, which misbehave in response to standard gpg searches by > keyid. > >--dkg > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Dump recurses to dumpsize on stack?
Man, that's an embarrassing mistake. (In my defense, i did write that code a long time ago.) Kim's patch is precisely right. y 2009/3/22 Kim Minh Kaplan > > [ apologies if you see this twice I had put a wrong address in the first > one ] > > Phil Pennock: > > > Is it known that when you do "sks dump ", you end up with up to > > 10 stack frames per N, plus the calls into the DB layer, etc? > [...] > > I was suspecting db problems, and it's not. Looks as though something > > was expecting tail recursion optimisation but not getting it. I really > > don't know enough about programming in functional languages to look into > > this properly. I don't even know if things like shuffling exception > > handling around would let the tail recursion optimisation kick in and > > where things like integrity of backup dumps are concerned, I play around > > less. > > I highly suspect that the inside of a try block is not a tail position > and that "shuffling exception handling around" is the right thing to do > here. Try this. > > Kim Minh. > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [PATCH] IPv6 support
On Sat, Mar 7, 2009 at 2:53 AM, Phil Pennock wrote: > On 2009-03-06 at 23:06 -0500, Yaron Minsky wrote: > >- Cleaned up the way that IPv4 and IPv6 logic was chosen in the code > so > >as to reduce boilerplate > > "let foo = bar in" in the middle of a list. I have a lot to learn. ;) Yup. Expressions are lurking everywhere > > >- Got rid of incorrect use of ==. In OCaml, == is physical equality, > >whereas = is ordinary structural equality. > > I discovered this at some point while writing the patch and thought I'd > cleaned things up; I think I left == only on things like character > tests, for which pervasives.mli documented == as identitcal to =. I > guess it's better to just get in the habit of always using =, since they > are identical. Exactly. You should pretty much only use == when there's a reason, that is, specifically when the semantics are different. > > >- streamlined some repetitive code in membership.ml > > I had somehow missed 'a option and Some; I just had an O'Caml-speaker > explain it to me. *sigh* I so wish I'd known about Some at the time. Yeah, options are fantastic. Much much cleaner and more explicit than sprinkling nulls around everywhere, which is what you need to do in most languages. > > >- other minor tweaks > >- Defined the |! operator (used for creating function pipelines) and > used > >that to make the code more readable in a few spots. > > Nice. > > So, is there an easy way to detect from OCaml if there's a routable IPv6 > service available, or should we provide knobs to disable IPv4 or IPv6? > > In C, I'd use > addrinfo_obj.ai_flags |= AI_ADDRCONFIG > for the getaddrinfo() call, so that addresses are only returned for > those address families for which such an address is configured on the > local system. I couldn't see a way to do that in O'Caml. I'm running > 3.10.2 (FreeBSD port, ocaml-notk-3.10.2_1) and the socket handling in > unix.mli leaves somewhat to be desired, both in setsockopt for anything > other than socket-level options and flags for some of the newer > interfaces such as getaddrinfo(). :-/ This is the part I need to think about. I actually know next to nothing about IPv6. I really only looked at the code for very broad readability issues. You should take a look at 3.11 and see if it fixes any of your issues. That's what I"m currently compiling against. If we really need to, we can write some C code to set the socket options and then wrap that up so we can call it from OCaml. y > > -Phil > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [PATCH] IPv6 support
I've managed to do a quick look-over the patch. It's pretty good for a first foray into OCaml. I did some surface cleanups of the code, but I haven't yet thought carefully about the behavior of the new code. I've attached a cleaned up version of your patch. It compiles but is otherwise untested. The main changes I made were: - Cleaned up the way that IPv4 and IPv6 logic was chosen in the code so as to reduce boilerplate - Got rid of incorrect use of ==. In OCaml, == is physical equality, whereas = is ordinary structural equality. - streamlined some repetitive code in membership.ml - other minor tweaks - Defined the |! operator (used for creating function pipelines) and used that to make the code more readable in a few spots. I'd be happy for feedback on the modified patch. y On Thu, Mar 5, 2009 at 7:33 AM, Yaron Minsky wrote: > I'm really happy to see these changes being tried out. I'll read over the > diff today and try to get you some feedback. > > y > > On Thu, Mar 5, 2009 at 2:24 AM, Phil Pennock > wrote: > >> On 2009-03-02 at 02:52 -0800, Phil Pennock wrote: >> > Can those with more experience in OCaml please take a look over this and >> > tell me if I'm heading down the right path? >> > >> > This patch theoretically adds support for IPv6 in recon; it adds the >> > settings hooks for hkp too, but doesn't add anything that uses that yet. >> > It should both listen on IPv6 and connect outbound too. >> > >> > It compiles. It runs. I see both listening sockets with lsof. It >> > doesn't do anything soon enough for me to see tonight how well I've >> > done, as I need to go get some sleep. I'm not sufficiently comfortable >> > to leave sks-peer.spodhuis.org running this code overnight, so I've >> > reverted to 1.1.0. >> > >> > It's my first OCaml hacking and my style sucks and I spend more time >> > debugging to get it to compile than I care to think about. >> > >> > A critical eye and constructive comments appreciated. >> > >> > Oh, and I've no idea how recent support for IPv6 in OCaml is and have >> > made no effort to gracefully degrade to either old OCaml environments or >> > systems without IPv6 support. First, I want to get it working for >> > anyone, *then* I can worry about making it conditional. >> >> I've now extended the code to implement IPv6 for hkp, not just recon, >> and to make outbound connections fine. >> >> People have a choice: >> >> * Kim's simpler patch, which relies upon the OS supporting IPv6-mapped >> IPv4 addresses; the *BSD systems disable this by default, but you can >> change this system-wide by setting sysctl net.inet6.ip6.v6only to 0. >> I believe that OCaml lacks the necessary support in its setsockopt >> shim to set this option, so it can't be worked around >> >> * My larger patch, which opens separate sockets for each stack and >> which adds recon6_address and hkp6_address options to sksconf if you >> want to use a binding address other than :: (the IPv6 equivalent to >> 0.0.0.0). >> >> In particular, if anyone has an IPv4-only system, I would like to know >> what problems are caused by my patch, but I'll fully understand if >> people don't want to try that out. :) >> >> I'm now running my patch live, eating my own dogfood. I've used gpg to >> get a key from the HKP port over IPv6, but not yet seen recon, in part >> because my DNS didn't include an record. I've updated my DNS and >> we're now past the TTL expiry. >> $ gpg --keyserver 'hkp://[2001:980:fff:31::10]' --recv-key $keyid >> >> I am not providing a Mercurial repository, as I'm not sufficiently >> familiar with the system to assess the security risks of doing so and >> don't want to leave up a daemon which I'd access so rarely. If I used >> Mercurial on a regular basis, that would be a different matter. >> >> So, attached, please find what I currently believe to be a complete IPv6 >> support patch. Unless you define "complete" to mean "can disable it". >> >> I would have sent this mail 2 hours ago but I realised that the >> membership code just taking the first address found was a bad plan, as >> then there would be a 50% chance of a connection from a mutually IPv6 >> host failing -- if they connected over IPv4 and you only record the IPv6 >> address, that would be rejected. So I've just broken my brain on >
Re: [Sks-devel] [PATCH] IPv6 support
I'm really happy to see these changes being tried out. I'll read over the diff today and try to get you some feedback. y On Thu, Mar 5, 2009 at 2:24 AM, Phil Pennock wrote: > On 2009-03-02 at 02:52 -0800, Phil Pennock wrote: > > Can those with more experience in OCaml please take a look over this and > > tell me if I'm heading down the right path? > > > > This patch theoretically adds support for IPv6 in recon; it adds the > > settings hooks for hkp too, but doesn't add anything that uses that yet. > > It should both listen on IPv6 and connect outbound too. > > > > It compiles. It runs. I see both listening sockets with lsof. It > > doesn't do anything soon enough for me to see tonight how well I've > > done, as I need to go get some sleep. I'm not sufficiently comfortable > > to leave sks-peer.spodhuis.org running this code overnight, so I've > > reverted to 1.1.0. > > > > It's my first OCaml hacking and my style sucks and I spend more time > > debugging to get it to compile than I care to think about. > > > > A critical eye and constructive comments appreciated. > > > > Oh, and I've no idea how recent support for IPv6 in OCaml is and have > > made no effort to gracefully degrade to either old OCaml environments or > > systems without IPv6 support. First, I want to get it working for > > anyone, *then* I can worry about making it conditional. > > I've now extended the code to implement IPv6 for hkp, not just recon, > and to make outbound connections fine. > > People have a choice: > > * Kim's simpler patch, which relies upon the OS supporting IPv6-mapped > IPv4 addresses; the *BSD systems disable this by default, but you can > change this system-wide by setting sysctl net.inet6.ip6.v6only to 0. > I believe that OCaml lacks the necessary support in its setsockopt > shim to set this option, so it can't be worked around > > * My larger patch, which opens separate sockets for each stack and > which adds recon6_address and hkp6_address options to sksconf if you > want to use a binding address other than :: (the IPv6 equivalent to > 0.0.0.0). > > In particular, if anyone has an IPv4-only system, I would like to know > what problems are caused by my patch, but I'll fully understand if > people don't want to try that out. :) > > I'm now running my patch live, eating my own dogfood. I've used gpg to > get a key from the HKP port over IPv6, but not yet seen recon, in part > because my DNS didn't include an record. I've updated my DNS and > we're now past the TTL expiry. > $ gpg --keyserver 'hkp://[2001:980:fff:31::10]' --recv-key $keyid > > I am not providing a Mercurial repository, as I'm not sufficiently > familiar with the system to assess the security risks of doing so and > don't want to leave up a daemon which I'd access so rarely. If I used > Mercurial on a regular basis, that would be a different matter. > > So, attached, please find what I currently believe to be a complete IPv6 > support patch. Unless you define "complete" to mean "can disable it". > > I would have sent this mail 2 hours ago but I realised that the > membership code just taking the first address found was a bad plan, as > then there would be a 50% chance of a connection from a mutually IPv6 > host failing -- if they connected over IPv4 and you only record the IPv6 > address, that would be rejected. So I've just broken my brain on > O'Caml's type system while making sure that the membership handling will > track _all_ the IP addresses of each peer. > > Note that one side-effect is that in theory, with this, you could peer > with a cluster of hosts where one name has multiple IPs. But you > wouldn't want to do that normally, especially since the "that's myself" > test will drop any item where any of the IP addresses are any of the > local recon addresses (either the one configured address or any of the > addresses for hostname). Oh, and that would possibly not be a good plan > from the point of view of the synchronisation protocol itself. > > With this latest fix, I'm not rejecting so many recon connects now. ;) > > If you try my patch out, I'd appreciate feedback. If you're peering > with sks-peer.spodhuis.org then you might want to keep an eye on > recon.log and see if you get an IPv6 peering. :) But please, keep a > safe copy of your normal binary to fall back to. > > Thanks, > -Phil > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS RAM usage gone haywire
On Sat, Feb 14, 2009 at 6:14 PM, Phil Pennock wrote: > > I begin to wonder if recon is sub-optimal with a large delta of keys to > send and also to wonder if I should bump "learn to read OCaml" up my > priority list -- I'm managing to navigate the sks source faster already, > but I'm still mostly in the dark. For what it's worth, I would strongly encourage this. I have not had much time of late to support sks, and having someone else learn the codebase would be great. I'd be happy to help out if you wanted to learn more and had questions about the internals... y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS RAM usage gone haywire
Ari is right: there's nothing inherent about the algorithm that should require an ever-growing use of memory. OCaml itself is very careful about reclaiming unreferenced memory, but that of course does not preclude a memory leak in the code. So far, I have no real clue as to what is going wrong. I could imagine that the caching at some level is overly aggressive. There are a number of configuration variables that control how much caching there is. Some of these are explicit caching numbers that are used by the actual DB, and some if it is caching that the prefix-tree datastructure does on its own. For instance, there is a bound (defaulted to 1000) on the number of in-memory nodes of the prefix-tree. The idea that some weird query or a server in an unusual state is exercising some bug that blows up the memory utilization seems possible as well. Has anyone confirmed if it's the db or recon process that is blowing up in memory? That would help figure out what's going on. For instance, it's pretty unlikely that a query from a web-crawler would cause the recon process to explode in size. y On Sat, Feb 14, 2009 at 7:14 PM, Ari Trachtenberg wrote: > From memory, the theory predicts that recon running time and memory > should grow roughly linearly with delta; only interaction should > increase. In practice, everything depends on the actual implementation > and how careful OCAML is in reclaiming unused memory. Maybe Yaron can > chime in. >-Ari > > Phil Pennock wrote: > >> On 2009-02-14 at 17:45 -0500, Daniel Kahn Gillmor wrote: >> >>> Maybe someone who knows the source and/or is proficient with the use of >>> valgrind could assess whether sks recon is actually leaky? >>> >> >> I had been running without *noticing* any increase for some time and am >> inclined to believe that it's a change in observed behaviour. >> >> I saw recon size go to 3GB again, but the RSS was only 11MB, so not so >> painful. Thus I'm inclined to think that most of this is DB backing >> (/pending/sks/PTree/ptree mmap'ing) and therefore mostly not paged in >> and harmless. So, what has changed the working set? >> >> In trying to visit my peers' stats pages, one has no data (DB recent >> restart) and one has ... 25503 keys. However, I added that peer in >> November, shortly after I myself set up my server. So unless bazon.ru >> only recently lost its keys, that looks less likely. >> >> I begin to wonder if recon is sub-optimal with a large delta of keys to >> send and also to wonder if I should bump "learn to read OCaml" up my >> priority list -- I'm managing to navigate the sks source faster already, >> but I'm still mostly in the dark. >> >> I'm fairly sure that the only other recentish change in my setup is >> innocent; I set up db_recover to run weekly, but that's on a Saturday >> and since I didn't set $PATH to include the tools, automatic runs >> wouldn't work until I fixed that today so it has only happened the first >> time when I wrote the wrapper script and I restarted the DB server >> shortly thereafter anyway because I'd played with sks dump before >> discovering that it couldn't be done online. >> >> -Phil >> >> >> >> >> ___ >> Sks-devel mailing list >> Sks-devel@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/sks-devel >> > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] How to delete single keys from the SKS keyserver
Ari is right that it's not trivial, but I do think there are some technically reasonable solutions if you can find some way of having everyone agree on which keys should be removed. For instance, if you had a trusted set of "deleters", they could sign certificates that indicated which keys should be deleted, and these certificates could be gossiped around with everything else, and used to delete keys from the network. Unfortunately, the decentralized nature of the SKS network makes this a bit hard to manage, since it's not clear who the trusted deleters should be. (Also, there's the small matter of who should implement the functionality in the keyserver. I'm happy to do maintenance work on SKS, but I don't have time for implementing significant new functionality). y On Wed, Jun 4, 2008 at 12:28 PM, Ari Trachtenberg <[EMAIL PROTECTED]> wrote: > We had talked about approaches to this ... it turns out to be an > non-trivial problem to > integrate this with the efficient synchronizer without breaking the > synchronizer's efficiency. > > Best, > _Ari > > > Yaron Minsky wrote on 06/04/2008 07:25 AM: > > On Wed, Jun 4, 2008 at 2:56 AM, Patrick Rother <[EMAIL PROTECTED]> wrote: > > > > > >> Hello. > >> > >> > >>>> You can use the "sks drop" command with a key hash as a parameter. > >>>> > >> You'll need to have a running SKS server. > >> > >> Althouhg having read "sks help", "sks --help" and the man page at > >> least two times each, I really overlooked the sks drop command. > >> > >> Thank you! > >> > >> > >>> But if the key is already on other servers you will get it back with > the > >>> next sync. > >>> > >> Yes, I'm aware of that, but I have to comply with a users request to > >> delete the key. > >> > >> BTW, is there a way to block specific keys from being synced into my > >> server? > >> > >> > > > > There's nothing in theory to prevent it, but I never got around to > > implementing blocks like this. > > > > y > > > > > > > >> Thank you. > >> > >> > >> > >> ___ > >> Sks-devel mailing list > >> Sks-devel@nongnu.org > >> http://lists.nongnu.org/mailman/listinfo/sks-devel > >> > >> > >> > > > > > > > > > > ___ > > Sks-devel mailing list > > Sks-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/sks-devel > > > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] How to delete single keys from the SKS keyserver
On Wed, Jun 4, 2008 at 2:56 AM, Patrick Rother <[EMAIL PROTECTED]> wrote: > Hello. > > > > You can use the "sks drop" command with a key hash as a parameter. > You'll need to have a running SKS server. > > Althouhg having read "sks help", "sks --help" and the man page at > least two times each, I really overlooked the sks drop command. > > Thank you! > > > But if the key is already on other servers you will get it back with the > > next sync. > > Yes, I'm aware of that, but I have to comply with a users request to > delete the key. > > BTW, is there a way to block specific keys from being synced into my > server? > There's nothing in theory to prevent it, but I never got around to implementing blocks like this. y > > Thank you. > > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] A new wiki
I was thinking SKS could benefit from a wiki. I've set up a very simple instiki installation for people to play around with: http://minskyprimus.net:2500/sks People should feel free to contribute or propose an alternate wiki technology if instiki is for some reason unsuitable... y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Some bugs
On Thu, May 22, 2008 at 4:56 PM, Joseph Oreste Bruni <[EMAIL PROTECTED]> wrote: > The "dump" command doesn't appear to be parsing command line arguments > correctly. > > First, if I omit the "dumpname" option, it appears that some random value > is used for the prefix to the filename of the output files. I'm guessing > that the filename portion is uninitialized in "sksdump.ml". The "name" > value on line 77 doesn't appear to get set. What was the command-line option you used? When I run, for example: sks dump 10 ~/foobar snoobar then I see messages saying: Dumping keys to file /home/yminsky/foobar/snoobar-.pgp which is precisely the way I expect it to work. What happens when you try it? > > Secondly, it appears that the "numkeys" value isn't parsed properly. When I > try to dump one key, I get all. If I try to dump five keys I get 15. Not > sure what is happening here. I think you're misunderstanding the feature. numkeys determines not how many keys get dumped, but how many get included in each file. The dump always dumps everything. > > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS 1.1.0
On Wed, May 21, 2008 at 12:06 AM, Joseph Oreste Bruni <[EMAIL PROTECTED]>
wrote:
>
> 2) I'm running my server as a stand-alone for the time being. I have
> "-disable_mailsync" and "-dontgossip" as command-line options.
>
> After adding my first key, I start seeing this in the log:
>
> 2008-05-20 17:48:04 error in callback.: Failure("No
> partners specified")
> 2008-05-20 17:48:14 error in callback.: Failure("No
> partners specified")
> 2008-05-20 17:48:24 error in callback.: Failure("No
> partners specified")
>
> I checked how the value "send_mailsyncs" is used and it doesn't appear to
> be tested correctly in "dbserver.ml" on line 642. It doesn't appear to be
> checked at all near the code that produces the above error messages. I'm not
> at all familiar with the ocaml language, so I'm probably not reading this
> correctly.
This does appear to be busted. In particular, the wrong feature is
disabled. It disables the loading of keys received by email, not the
attempt to send keys by email. I've put in a patch which I think fixes this
in the hg repo. Feel free to try it out.
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks 1.1.0
On Sun, May 11, 2008 at 4:09 PM, John Clizbe <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yaron Minsky wrote:
> > A new release of SKS (version 1.1.0) is now available, and can be
> > downloaded from
>
>
> > * Numerix is no longer required. This should simplify the build
> > process on a number of different platforms. SKS relies instead on
> > OCaml's native Big_int implementation.
>
> I had thought about maybe using gmp, but if OCaml has a native
> implementation, why not use it?
Indeed. And the performance is just fine for SKS, since transferring the
keys is considerably more expensive than discovering which keys need to be
brought over (and that's the part that uses bignums.)
> "Just for grins" I built SKS on Cygwin. It builds fine, but trying to
> build the database dies with:
>
> $ sks build -n 5 -cache 100 /var/sks/dump/*.pgp
> Loading keys...Fatal error: exception Failure("Bit 7 of packet tag was
> not 1 as expected: 3f")
>
> Any ideas? -mms-bitfields?
>
Hmm. I have no idea offhand why that would happen. The bitwise operations
should be perfectly portable...
> > Enjoy. If people have further patches, I would be happy to consider
> > them for inclusion into the distribution.
>
> Running fine on keyserver.gingerbear.net since ~20:00 US/Central Saturday.
>
> One little nagging problem: How do I set a name for a keydump?
> When I specify a name I get an argument count error:
Hmm. This seems to work for me:
[EMAIL PROTECTED] sks]$ sks dump 100 ~/dump fooname
Dumping keys to file /home/yminsky/dump/fooname-.pgp
are you sure you're using the latest executable?
y
>
> [EMAIL PROTECTED]:/var/sks# sks dump 26000 /var/sks/dump sks-keydump
> wrong number of arguments
> usage: sksdump numkeys dumpdir [dumpname]
> [EMAIL PROTECTED]:/var/sks# time sks dump 26000 /var/sks/dump
> Dumping keys to file /var/sks/dump/1-.pgp
> - --
> John P. Clizbe Inet: JPClizbe(a) tx DAWT rr DAHT con
> Ginger Bear Networks PGP/GPG KeyIDs:0x608D2A10/18BB373A
> "Be who you are and say what you feel because those who mind don't
> matter and those who matter don't mind."
> - Dr Seuss, "Oh the Places You'll Go"
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10-svn4754-2008-04-30 (Windows XP)
> Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG
> Comment: Be part of the £33t ECHELON -- Use Strong Encryption.
> Comment: It's YOUR right - for the time being.
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iJwEAQECAAYFAkgnUo4ACgkQvh+YERi7NzoEEwQAq7oeEbBsULWD21hkAIBH+AYz
> ANNjwy0xc/9N49N1SwhlhxC+CrZG9fsolVcwNdJ0U9U6Nlg3tiltkzDDMNje9zh9
> 7k/R58KmJrz98huUIPGN344X/RgSZLsyySzDxHpOLbRQkTkLZITzy9ii8900bxxw
> l6kKLwmPjR4y/su5WwmIRgQBEQIABgUCSCdSjgAKCRAdBKxKYI0qENoYAJ0UBrU6
> vRtY68FMxmYddBBW1Dt7CQCcCXy2xiTx8HGY/3Q1S3Fl/FasRI4=
> =Ydwl
> -END PGP SIGNATURE-
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] sks 1.1.0
A new release of SKS (version 1.1.0) is now available, and can be downloaded from http://minskyprimus.net/sks/releases There are a few notable changes: - Numerix is no longer required. This should simplify the build process on a number of different platforms. SKS relies instead on OCaml's native Big_int implementation. - SKS now uses version 4.6 of Berkeley DB. - A number of external patches have been integrated, including a patch from Peter Pramberger affecting how signatures are displayed, and a patch from debian adding a horizontal rule to the index page. I'm currently running 1.1.0 on minskyprimus.net, and it seems to work fine. You can get an hg repo with the code here: http://hg.minskyprimus.net/sks/trunk Enjoy. If people have further patches, I would be happy to consider them for inclusion into the distribution. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Looking for gossip peers
I'm setting up a new keyserver at minskyprimus.net and I'm looking for gossip peers. Note, this is a new experimental version of the codebase. y ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] An embarrassing question
On Wed, May 7, 2008 at 10:48 PM, John Clizbe <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yaron Minsky wrote: > > This is an embarrassing question to ask about software that I wrote, but > > here it is. I've been poking around with the sks code trying to get it > > to compile on a reasonably modern system, and having some real trouble > > getting it up. I'm trying to build on a 64-bit centos 5 box using OCaml > > 3.10.2, and I'm wondering if anyone has run into the same problems I'm > > seeing. When I try to build, I get the errors shown below. > > A post showed up on GnuPG-Users yesterday: > http://lists.gnupg.org/pipermail/gnupg-users/2008-May/033395.html > He gave no other details than "Fedora 9 on an x86_64 box with 4 gigs of > ram and Numerix blows up on compile with "out of memory" errors" > > In a reply, Todd Zullinger posted a patch that updates bdb from > 4.1 to 4.6 > > I've been using a couple other patches and the 1.010 source tarball is > missing sks.pod. > > Maybe it's time for a 1.0.11 Not a bad idea. I'll try out 4.6. I'll also consider other patches that people send in. y > > - -- > John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con > Ginger Bear Networks hkp://keyserver.gingerbear.net > "Be who you are and say what you feel because those who mind don't > matter and those who matter don't mind." > - Dr Seuss, "Oh the Places You'll Go" > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10-svn4754-2008-04-30 (Windows XP) > Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG > Comment: Be part of the £33t ECHELON -- Use Strong Encryption. > Comment: It's YOUR right - for the time being. > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iJwEAQECAAYFAkgiaewACgkQvh+YERi7NzrZZAP/RfD66/G8e/MXfRqVHL6YzjsP > Us8ejrPi2DQwu/IWWzm7HHbhSb5uOS187j+0ki8x7utcC5znPpkwiIJ3aJBa+A2r > WoykmehU0I4PiasE9rZzOIczy+YcZYGAq2H/BGDtsrWvNzPClSQvsi4mAi446uj7 > yiRqjPGqJ5xkD+vCHRaIRgQBEQIABgUCSCJp7AAKCRAdBKxKYI0qELVNAKDCHCzs > mN8lroBe86vBY1ey0kD1NwCg+xbtPHeLuJZoVosofjnL5v8RlJo= > =u4vY > -END PGP SIGNATURE- > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] An embarrassing question
This is an embarrassing question to ask about software that I wrote, but here it is. I've been poking around with the sks code trying to get it to compile on a reasonably modern system, and having some real trouble getting it up. I'm trying to build on a 64-bit centos 5 box using OCaml 3.10.2, and I'm wondering if anyone has run into the same problems I'm seeing. When I try to build, I get the errors shown below. Thanks, y ocamlopt -thread -o sks -I lib -I bdb -ccopt -L/home/\ yminsky/local/lib -ccopt -Lbdb -dtypes -inline 40 unix.cmxa str.cmxa bdb.cmxa nums.cmxa bi\ garray.cmxa cryptokit.cmxa crc.o pSet.cmx pMap.cmx utils.cmx heap.cmx mList.cmx mTimer.cm\ x mArray.cmx settings.cmx pstyle.cmx getfileopts.cmx common.cmx channel.cmx eventloop.cmx \ ehandlers.cmx bitstring.cmx meteredChannel.cmx number.cmx prime.cmx zZp.cmx rMisc.cmx line\ arAlg.cmx poly.cmx decode.cmx fqueue.cmx prefixTree.cmx msgContainer.cmx nbMsgContainer.cm\ x cMarshal.cmx reconMessages.cmx server.cmx client.cmx reconCS.cmx number_test.cmx decode_\ test.cmx poly_test.cmx packet.cmx parsePGP.cmx sStream.cmx bdbwrap.cmx key.cmx keyHash.cmx\ keyMerge.cmx fixkey.cmx fingerprint.cmx keydb.cmx armor.cmx dbMessages.cmx htmlTemplates.\ cmx wserver.cmx membership.cmx tester.cmx request.cmx index.cmx mRindex.cmx pTreeDB.cmx se\ ndmail.cmx recvmail.cmx mailsync.cmx stats.cmx clean_keydb.cmx build.cmx fastbuild.cmx pbu\ ild.cmx merge_keyfiles.cmx sksdump.cmx incdump.cmx dbserver.cmx reconComm.cmx recoverList.\ cmx catchup.cmx reconserver.cmx update_subkeys.cmx sks_do.cmx unit_tests.cmx sks.cmx /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /home/yminsky/local/lib/libdb-4.1.so: undefined reference to `pthread_mutex_trylock' /home/yminsky/local/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_setpshared\ ' /home/yminsky/local/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_destroy' /home/yminsky/local/lib/libdb-4.1.so: undefined reference to `pthread_condattr_setpshared' /home/yminsky/local/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_init' collect2: ld returned 1 exit status Error during linking ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Optimum number of gossip peers; mailsync with PKS network
I think the optimal thing would simply to have everyone in your peer list. I don't think you lose anything to that, but it's a pain to maintain. I think there are some theoretical results suggesting that one can do with O(log n) peers where n is the size of the network, assuming the peers are chosen at random. In practice, gossip is pretty damn robust. I generally think 5-10 peers is about right, and one shouldn't need to change that too much as the system grows. For reasonable values of n, log n is constant. I like a sync frequency of roughly a minute. That means the overall network distributes updates pretty quickly -- basically you should expect an update to have fully percolated within 10 minutes. Since each gossip reconciles -all- differences, you don't need to change the gossip rate as the update rate changes. And updating once a minute is pretty light in terms of resource usage. y On 10/29/07, Jonathan Oxer <[EMAIL PROTECTED]> wrote: > > Thanks to all the peering offers I now have 6 gossip partners for > keys.keysigning.org, which got me thinking about the optimal number in a > mesh network. There's obviously overhead in the sync protocol and it's > wasteful to check more frequently than there are changes to propagate, > so the theoretical optimum check frequency would vary inversely with the > number of peering partners and proportionally with the rate of changes. > > Short version: how many peering partners is normal? > > Also, now that SKS gossip is working I want to set up mailsync to the > PKS network. The 2004 docs on the wiki said that permission should be > requested before adding a PKS server to the mailsync file, but then says > that [EMAIL PROTECTED] can be added without requesting > permission. > > Is there more up-to-date information about PKS sync? What's the current > best approach? > > Cheers :-) > -- > Jonathan Oxer > Ph +61 3 9723 9399 > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS - FreeBSD Patch & Questions
There is a version available that can be checked out using bzr: bzr checkout http://minsky-primus.homeip.net/sks-archive/mainline that supports Numerix 0.22. I don't currently run an SKS server so I haven't been able to test this myself, but if some adventerous soul wants to try it out and yell at me about bugs, I would be happy to do some work on it. y On 10/29/07, Johan van Selst <[EMAIL PROTECTED]> wrote: > > Proskurin Kirill wrote: > > Could someone write a port of a sks 1.0.10 for FreeBSD?... > > I had tried this but failed. The numerix changes were too painful as I > recall. It would be nice indeed if somebody could get this working. > > There has been some talk in the past about replacing numerix with > BigNum. But I don't believe this was ever implemented. > > > Greetings, > Johan > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Build failure
I just checked out revno 51 on my FC6 box running OCaml 3.10.0, and it built
cleanly. I just committed revno 52 which fixes a different problem,
unrelated to your building issues. What exact platform are you running on,
and what revno and what ocaml release?
For what it's worth, I don't know if anyone has actually tested out the tip
of the SKS tree, but if anyone has, I would be interested in feedback. The
tip of the tree is really quite untested at present.
y
On 8/24/07, Joerg Jaspert <[EMAIL PROTECTED]> wrote:
>
> On 11120 March 1977, Yaron Minsky wrote:
>
> > Try the new version, and tell me if you have problems.
>
> If i simply type make I get the following:
>
> --8<schnipp->8---
> gcc -O3 -Werror-implicit-function-declaration -I`ocamlc -where` -I . -c
> crc.c
> ocamlopt -I lib -I bdb -ccopt -Lbdb -dtypes -inline 40 unix.cmxa str.cmxa
> bdb.cmxa nums.cmxa numerix.cmxa bigarray.cmxa cryptokit.cmxa -c
> int_comparators.ml
> ocamlopt -I lib -I bdb -ccopt -Lbdb -dtypes -inline 40 unix.cmxa str.cmxa
> bdb.cmxa nums.cmxa numerix.cmxa bigarray.cmxa cryptokit.cmxa -c pSet.ml
> File "pSet.ml", line 1, characters 0-1:
> Could not find the .cmi file for interface pSet.mli.
> make: *** [pSet.cmx] Error 2
> --8<schnapp->8---
>
>
> If i try make dep i get:
>
> --8<schnipp->8---
> ocamldep -pp camlp4o *.ml *.mli > .depend
> File "int_comparators.ml", line 4, characters 8-9:
> Lexing error: character '<' expected
> Uncaught exception: Token.Error("character '<' expected")
> Preprocessing error
> make: *** [dep] Error 2
> --8<schnapp->8---
>
>
> --
> bye Joerg
> [...] some would argue that too much free beer with hamper your ability to
> free
> speech; this is an opinion.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Build failure
Development isn't terribly active, but it's not quite dead yet. The CVS archive is quite dead, though. You can pull the latest sources from a bzr repository here: http://minsky-primus.homeip.net/sks-archive/mainline/ The server it's on is sadly a bit unreliable, but the tree has been updated as late as 2007-06-18. I upgraded the system to use numerix 0.22, but haven't really tested it yet. I don't run an SKS server anymore, so it's a bit inconvenient for me. I'd love to have someone take a hack at it. Revision 51 is the last version, and Revision 48 is the latest one before the new numerix was added in. Try the new version, and tell me if you have problems. y On 8/22/07, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > > Hi > > Seems like sks development is dead? Last cvs commit is from 3 years ago, > and with "recent" versions of libraries it just fails to build: > > File "zZp.ml", line 54, characters 21-28: > This expression has type int but is here used with type > Nx.t = Numerix.Dlong.t > make[1]: *** [zZp.cmx] Error 2 > > > There is also the following a bit earlier, but its only a warning: > > mxa bigarray.cmxa cryptokit.cmxa -c bitstring.ml > File "bitstring.ml", line 161, characters 2-44: > Warning X: this record is defined by a `with' expression, > but no fields are borrowed from the original. > > > Does someone have a patch for it? I dont speak ocaml, so cant fix it > myself, but until this is fixed keyserver.ganneff.de is (sks) down. > > -- > bye Joerg > Aqua mach mal man brain > maxx: schon probiert das gibts ned > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > > > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Interesting key merging bug with searching
On 11/6/05, David Shaw <[EMAIL PROTECTED]> wrote: Good point. I see this on the PKS servers as well. Here's an exampleof two different keys with colliding short key IDs sharing user IDs: http://keyserver.kjsl.com:11371/pks/lookup?op=vindex&fingerprint=on&search=0x1EFFBA41Been a while since I looked at the pksd code, but I would certainlybelieve it could do this. It seems that this only happens if the key parameters are in common: I can't find a case where, for example, aDSA and RSA key were merged. If that's true, it's hard to imagine SKS creating that issue, since things like RSA/DSA aren't even looked at by SKS. y DavidOn Sun, Nov 06, 2005 at 10:49:57PM -0500, Yaron Minsky wrote:> I can't see offhand how this would show up as a result of a bug in the > search mechanism: the word searches are indexed by full key hashes, and so> the word search should pull up the correct answer. But what it actually> looks like is that the keys of these people have been inadvetantly merged. I > have no reason to think offhand that the merging was done by SKS. SKS only> merges keys when the public key packet is identical, not merely when the> keyids match. But some other piece of software could have done this and fed > it to SKS, which would then propagate it happily. Does this show up only in> the SKS servers, or do other servers have the same bad key?>> y>> On 11/6/05, David Shaw < [EMAIL PROTECTED]> wrote:> >> > This was originally reported as a GnuPG bug, but it seems that SKS is> > actually making the odd response here.> >> > Basically there are two keys, both with key ID A56E15A3 (a natural > > collision). One has various user IDs indicating ownership by "Hubert> > Figuiere". The other one has a user ID for "Pedro R. Fernandez". If> > you search for "Figuiere" in SKS, you get both keys, and the user IDs > > are joined so each key has IDs from the other.> >> > $ curl '> > http://keyserver.ubuntu.com:11371/pks/lookup?op=index&options=mr&search=Figuiere > > '> > info:1:2> > pub:A56E15A3:17:1024:1012389324::> > uid:Hubert Figuiere <[EMAIL PROTECTED]>:1119055887::> > uid:Hubert Figuiere < [EMAIL PROTECTED]>:1130648607::> > uid:Hubert Figuiere <[EMAIL PROTECTED]>:1028015454::> > uid:Hubert Figuiere < [EMAIL PROTECTED]>:1130648605::> > uid:Pedro R. Fernandez (GNU/Linux User #000.204.555> > http%3A//counter.li.org/) <[EMAIL PROTECTED]>:::> > pub:A56E15A3:17:1024:1002062559:: > > uid:Hubert Figuiere <[EMAIL PROTECTED]>:::> > uid:Hubert Figuiere <[EMAIL PROTECTED]>:::> > uid:Pedro R. Fernandez (GNU/Linux User #000.204.555 > > http%3A//counter.li.org/) <[EMAIL PROTECTED]>:1002062559::> >> > David> >> >> > ___ > > Sks-devel mailing list> > Sks-devel@nongnu.org> > http://lists.nongnu.org/mailman/listinfo/sks-devel > >> ___> Sks-devel mailing list> Sks-devel@nongnu.org> http://lists.nongnu.org/mailman/listinfo/sks-devel___Sks-devel mailing listSks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Interesting key merging bug with searching
I can't see offhand how this would show up as a result of a bug in the search mechanism: the word searches are indexed by full key hashes, and so the word search should pull up the correct answer. But what it actually looks like is that the keys of these people have been inadvetantly merged. I have no reason to think offhand that the merging was done by SKS. SKS only merges keys when the public key packet is identical, not merely when the keyids match. But some other piece of software could have done this and fed it to SKS, which would then propagate it happily. Does this show up only in the SKS servers, or do other servers have the same bad key? yOn 11/6/05, David Shaw <[EMAIL PROTECTED]> wrote: This was originally reported as a GnuPG bug, but it seems that SKS isactually making the odd response here.Basically there are two keys, both with key ID A56E15A3 (a naturalcollision). One has various user IDs indicating ownership by "Hubert Figuiere". The other one has a user ID for "Pedro R. Fernandez". Ifyou search for "Figuiere" in SKS, you get both keys, and the user IDsare joined so each key has IDs from the other. $ curl 'http://keyserver.ubuntu.com:11371/pks/lookup?op=index&options=mr&search=Figuiere'info:1:2 pub:A56E15A3:17:1024:1012389324::uid:Hubert Figuiere <[EMAIL PROTECTED]>:1119055887::uid:Hubert Figuiere <[EMAIL PROTECTED]>:1130648607:: uid:Hubert Figuiere <[EMAIL PROTECTED]>:1028015454::uid:Hubert Figuiere <[EMAIL PROTECTED]>:1130648605::uid:Pedro R. Fernandez (GNU/Linux User #000.204.555 http%3A//counter.li.org/) < [EMAIL PROTECTED]>:::pub:A56E15A3:17:1024:1002062559::uid:Hubert Figuiere <[EMAIL PROTECTED]>:::uid:Hubert Figuiere < [EMAIL PROTECTED]>:::uid:Pedro R. Fernandez (GNU/Linux User #000.204.555 http%3A//counter.li.org/) <[EMAIL PROTECTED]>:1002062559:: David___Sks-devel mailing listSks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks using dev/random
This appears to come from cryptokit, xavier leroy's ocaml crypto library. I'm pretty sure the RNG is actually used, so it's just an open file, and it's at least not obvious to me that that sucks out randomness from /dev/random. (maybe it does on initialization, if there is some prefetching from /dev/random at the OS level when it's opened. But I can't imagine there's any ongoing drain.) On 10/6/05, Peter Palfrader <[EMAIL PROTECTED]> wrote: > My box was getting a little low on entropy sometimes, so I wondered > which applications used the random devices. > > I found out that sks has dev/random open. I guess there's no good > reason for sks to require that strong randomness, is there? At least > urandom should be used. Or do I miss something? > > [EMAIL PROTECTED]:~$ sudo lsof -n | grep random > sks1314 debian-sks3r CHR1,8 > 1048810 /dev/random > sks1316 debian-sks3r CHR1,8 > 1048810 /dev/random > > Cheers, > Peter > -- > PGP signed and encrypted | .''`. ** Debian GNU/Linux ** > messages preferred.| : :' : The universal >| `. `' Operating System > http://www.palfrader.org/ | `-http://www.debian.org/ > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Recon failure
The DNS theory does so far seem like the best one. I think a filter mismatch would end up with a different error. It would be ideal to get the logs from the other side, since that might clear up why the other side is terminating the connection. Without that information, it's a little hard to debug what's going on. YaronOn 9/24/05, Daniel Johnson <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Jason Harris wrote: > How often is your IP address changing? Ask your other peers to > add a cron entry like this: > > # keep up with ...'s dynamic IP > 0 * * * * touch /.../sks/membership > /dev/null > > for hourly updates.My address is usually quite stable, I've had occasions where I held anIP for two months. The last change was on the 19th when I replaced the UPS.According to the wiki, SKS versions higher than 1.0.7 (at least)reload their membership file automatically every few hours. Sincemost of the network is at least 1.0.9 (according tosks_network_today.png), and the oldest is 1.0.6 (keyserver.hadiko.de)I don't think that this is the issue. That said, I've still got asimilar entry in my crontab from when I first installed SKS. :)I was chatting with a friend about this (okay, I was venting) and he brought up a good question: Has the filter set been changed? Idon't recall seeing anything about adding on to yminsky.dedup andyminsky.merge.Good news: Peered with ice.mudshark.org , and syncing appears to work.Between mudshark and aaiedu I'm staying in sync.Daniel Johnson[EMAIL PROTECTED]-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2 (GNU/Linux)iD8DBQFDNaqG6vGcUBY+ge8RArz2AKC/oBgbrAF/40dwYdoP76goJ9LBoQCgprXUaIfbwgAcBjonX9EH4oktPl0==Vc/O-END PGP SIGNATURE-___ Sks-devel mailing listSks-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Permanent diff with pgp.srv.ualberta.ca
On 8/28/05, Marco Nenciarini <[EMAIL PROTECTED]> wrote: On Sat, Aug 27, 2005 at 03:11:31PM -0400, Jason Harris wrote:> On Sat, Aug 27, 2005 at 02:20:37PM +0200, Marco Nenciarini wrote:> > On Fri, Aug 26, 2005 at 03:25:18PM -0400, Jason Harris wrote:> > > > > When you invoke sks cleandb the first time it creates the file> > > > KDB/meta where is written that KDB database is clean. Any subsequent> > > > invocation of sks cleandb return immediately without doing any > > > > work.> > > > Only deleting KDB/meta you can force another cleandb cycle.> > >> > > Indeed, and I never liked this EVIL(TM) misfeature. :) So, finally, > > > here's a quick patch:> > >> > [snip patch]> >> > I made this more "politically correct" patch (attached).> >> > With this patch, you don't need to delete KDB/meta, but only specify > > -force_cleaning on command line.>> This just overcomplicates things. When you need to run cleandb, you> want it to just run. It isn't like build/fastbuild or pbuild, which> actually protect you from destroying existing dbs. Even worse, and > I've said this before on this list, "sks merge" doesn't filter,> making cleandb necessary after merging.This is a bad thing. If sks merge leave the KDB in an unclean state, Ithink it should reset all filters stored in KDB/meta. Yeah, "sks merge" is generally a hack, and not well supported. I think Jason's idea of simply always reapplying all cleaners when doing cleandb, is a good one, as is invalidating the meta flags. I'd accept patches for btoh. >> So, what are you (first Yaron, and now Marco) protecting against? >Ok, I think you are right. ATM if an user run sks cleandb, it shoulddo its work.Yaron, what do you think about?Ciao--- |Marco Nenciarini| Debian/GNU Linux Developer - Plug Member || [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia |-Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFDEYeQaGRzDfCV5eQRAqNlAJ9sroqhrt/nbVSUBogW7DjmrRrP0ACghVOwiBjCGT2gbDViamXkKyCL/YA==f8E5-END PGP SIGNATURE-___ Sks-devel mailing listSks-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] tla archive unerachable?
That should be fixed. Tell me if you have further problems.On 8/30/05, Yaron Minsky <[EMAIL PROTECTED]> wrote: Hmmm. I probably busted the firewall config. I'll get it fixed this evening. yOn 8/30/05, Marco Nenciarini < [EMAIL PROTECTED]> wrote: Ia about one week that minsky-primus.homeip.net i unreachable.[EMAIL PROTECTED]:~$ lynx -dump http://minsky-primus.homeip.net/archives/2004/ Looking up minsky-primus.homeip.netMaking HTTP connection to minsky-primus.homeip.netAlert!: Unable to connect to remote host. lynx: Can't access startfile http://minsky-primus.homeip.net/archives/2004/ [EMAIL PROTECTED]:~$ ping -c4 minsky-primus.homeip.net PING minsky-primus.homeip.net ( 24.215.197.251) 56(84) bytes of data.--- minsky-primus.homeip.net ping statistics ---4 packets transmitted, 0 received, 100% packet loss, time 2999msWhat's up?Ciao---|Marco Nenciarini| Debian/GNU Linux Developer - Plug Member | | [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia |- Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFDFEc6aGRzDfCV5eQRAgLCAJ9W9Tu7+txvjC4mt1faoF5RPa/9LACbBQ5U kGgbiRikT53hczPvWpnLB/M==EpzZ-END PGP SIGNATURE-___Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] tla archive unerachable?
Hmmm. I probably busted the firewall config. I'll get it fixed this evening. yOn 8/30/05, Marco Nenciarini <[EMAIL PROTECTED]> wrote: Ia about one week that minsky-primus.homeip.net i unreachable.[EMAIL PROTECTED]:~$ lynx -dump http://minsky-primus.homeip.net/archives/2004/ Looking up minsky-primus.homeip.netMaking HTTP connection to minsky-primus.homeip.netAlert!: Unable to connect to remote host. lynx: Can't access startfile http://minsky-primus.homeip.net/archives/2004/[EMAIL PROTECTED]:~$ ping -c4 minsky-primus.homeip.net PING minsky-primus.homeip.net (24.215.197.251) 56(84) bytes of data.--- minsky-primus.homeip.net ping statistics ---4 packets transmitted, 0 received, 100% packet loss, time 2999msWhat's up?Ciao---|Marco Nenciarini| Debian/GNU Linux Developer - Plug Member | | [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia |- Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFDFEc6aGRzDfCV5eQRAgLCAJ9W9Tu7+txvjC4mt1faoF5RPa/9LACbBQ5U kGgbiRikT53hczPvWpnLB/M==EpzZ-END PGP SIGNATURE-___Sks-devel mailing listSks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Sks and mailsync
On 8/22/05, Marco Nenciarini <[EMAIL PROTECTED]> wrote: I'm investigating why my sks send so little number of sync email.I'm not a good ocaml reader, but if I have correctly undestod thecode, sks send a sync email only when a _new_ key is submitteddirectly to it via email or /pks/add web command. This is by design. SKS is designed to receive updates from PKS, not propogate them. It seems to me that the PKS network should be responsible for its own replication. And SKS requires very few incoming PKS connections, since any updates that come in to any SKS server will eventually be distributed everywhere by SKS's own distribution network. New keys that arrive from the SKS recon process should _not_ be propagated to PKS. That would create storms of traffic when an out-of-date server gets back up to date, so it would be bad for PKS. The reason for forwarding new keys is simply to ensure that things submitted to SKS are also submitted to the PKS network, thus keeping the networks roughly in-sync. That doesn't mean that it's appropriate to spam the PKS network every time an SKS server gets an update. It's correct?If it's correct, i think it isn't a good behavior because we don't propagate to pks network any key from hkp updates nor new keys fromother sks servers via recon process.Ciao---|Marco Nenciarini| Debian/GNU Linux Developer - Plug Member | | [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia |- Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFDCe6kaGRzDfCV5eQRAo/LAJwKhiLCYJdqfhhdTwYbOCUbi/X3HQCffw1B 4Tw2Oucs+p3I45YGzYuNw+U==ukEe-END PGP SIGNATURE-___Sks-devel mailing listSks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] New SKS release
SKS 1.0.10 has now been released and is out on the savannah site. Here are the changes since 1.0.9: 2005-08-21 21:39:03 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-47 Summary: updated FILES Revision: sks--mainline--1.0--patch-47 modified files: FILES 2005-08-20 16:43:33 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-46 Summary: yet another fix for keytext bug, improved string/array slicing and spider Revision: sks--mainline--1.0--patch-46 modified files: dbserver.ml pstyle.ml spider.ml 2005-08-14 01:49:13 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-45 Summary: Added spider Revision: sks--mainline--1.0--patch-45 new files: .arch-ids/spider.ml.id spider.ml modified files: Makefile 2005-08-13 23:51:28 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-44 Summary: cleaned up exact search implementation a bit Revision: sks--mainline--1.0--patch-44 modified files: VERSION dbserver.ml 2005-08-13 23:29:36 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-43 Summary: Added support for exact searches Revision: sks--mainline--1.0--patch-43 modified files: dbserver.ml parsePGP.ml request.ml utils.ml 2005-08-10 01:52:42 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-42 Summary: Patch from Jason Harris to fix HTTP header parsing bug Revision: sks--mainline--1.0--patch-42 modified files: reconComm.ml 2005-08-10 01:48:40 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-41 Summary: simplified (and more correct) version of keytext fix Revision: sks--mainline--1.0--patch-41 modified files: dbserver.ml 2005-08-09 01:13:59 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-40 Summary: fixed bug in URL scanning Revision: sks--mainline--1.0--patch-40 modified files: dbserver.ml 2005-04-26 03:43:05 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-39 Summary: modified ptree to sort elements before insertion. Should speed things up. Revision: sks--mainline--1.0--patch-39 modified files: pbuild.ml 2005-01-19 15:02:11 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-38 Summary: Patch fixing membership bug (from Marco Nenciarini) Revision: sks--mainline--1.0--patch-38 Membership files can now handle blank lines or lines containing only comments modified files: membership.ml 2005-01-19 17:23:16 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-37 Summary: Modified basedir functionality. Revision: sks--mainline--1.0--patch-37 Basedir is probably still buggy, but it is somewhat more sensible now. modified files: build.ml clean_keydb.ml dbserver.ml fastbuild.ml getfileopts.ml incdump.ml mailsync.ml membership.ml merge_keyfiles.ml pbuild.ml reconserver.ml settings.ml sksdump.ml tester.ml update_subkeys.ml 2005-01-18 12:57:33 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-36 Summary: Build ptree using keyid database instead of key (makes it faster) Revision: sks--mainline--1.0--patch-36 modified files: keydb.ml 2005-01-18 02:53:20 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-35 Summary: Updated SKS to be compatible with 3.08 and Berkeley DB 4.2 Revision: sks--mainline--1.0--patch-35 new files: .arch-ids/numerix-0.19c.tar.gz.id numerix-0.19c.tar.gz removed files: .arch-ids/mRandom.ml.id .arch-ids/mRandom.mli.id .arch-ids/numerix-0.19-3.tar.gz.id mRandom.ml mRandom.mli numerix-0.19-3.tar.gz modified files: Makefile bdb/bdb.ml bdb/bdb_stubs.c keydb.ml pTreeDB.ml rMisc.ml zZp.ml 2004-12-13 17:04:14 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-34 Summary: Update to logfile creation, fixed malformed hash error message Revision: sks--mainline--1.0--patch-34 modified files: build.ml clean_keydb.ml common.ml dbserver.ml fastbuild.ml incdump.ml keyHash.ml merge_keyfiles.ml pbuild.ml reconserver.ml sksdump.ml update_subkeys.ml 2004-10-30 19:34:55 GMT Yaron Minsky <[EMAIL PROTECTED]> patch-33 Summary: Fixed bug insufficiently strict parsing of public key packets Revision: sks--mainline--1.0--patch-33 Old parsing of public key packets did not look at all the MPIs, and so the Fixkey filter didn't throw out broken pubkey packets. Now it does. modified files: Makefile dbserver.ml parsePGP.ml ___ Sks-devel mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Permanent diff with pgp.srv.ualberta.ca
You can also use "sks drop" to delete keys that you know are bad. "sks drop" requires the "sks db" process to be running. yOn 8/21/05, Chris Kuethe <[EMAIL PROTECTED]> wrote: On Sun, 21 Aug 2005, Jason Harris wrote:> On Sun, Aug 21, 2005 at 09:32:24AM -0600, Chris Kuethe wrote:>>> Not sure what's going on there... Last reconciliation run was less than 10 minutes ago, and my keyserver >> thinks it has all the keys that you have. # ls -l diff-62.94.26.10_11371.txt>> -rw-r--r-- 1 sks sks 0 Aug 21 09:08 diff-62.94.26.10_11371.txt What if you remove the diff file? Does sks show the same keys after the >> next reconciliation attempt?>> We've had this happen several times before. Check the archives and> you should learn that you need to force a "sks cleandb" on your end,> Chris. Okie dokie. I just ran cleandb, though I ran it immediately after loadingmy keys but before bringing the keyserver up.CK--Chris Kuethe, GCIA: Secure Systems Specialist - U of A CNS office: 157 General Services Bldg.+1.780.492.8135 [EMAIL PROTECTED] GDB has a 'break' feature; why doesn't it have 'fix' too?___Sks-devel mailing list [EMAIL PROTECTED]http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Permanent diff with pgp.srv.ualberta.ca
If you want to debug this, try fetching the missing keys from the other server, and then try submitting them directly and see what happens. The SKS hash is enough to request the key, so that should give you a pretty good idea of what is going on. YaronOn 8/21/05, Marco Nenciarini <[EMAIL PROTECTED]> wrote: Watching my sks.recon.log i see many lines linke the following:2005-08-21 07:40:18 Recon partner: 129.128.98.22:11370>2005-08-21 07:40:18 Initiating reconciliation 2005-08-21 07:40:19 Reconciliation complete2005-08-21 07:40:19 19 hashes recovered from 129.128.98.22:11371>2005-08-21 07:40:20 Requesting 19 missing keys from 129.128.98.22:11371>, starting with 08AA24E2F387480CB210BDCB873941FB2005-08-21 07:40:22 19 keys receivedrepeated many and many times.The canonical name of 129.128.98.22 is pgp.srv.ualberta.ca (theadministrator is in CC).The content of diff-129.128.98.22_11371.txt is unchanged for about aweek and is:08AA24E2F387480CB210BDCB873941FB 13E37C592A17EA2A345ED114BEA5D28114D0F46517A209FB45E99D561CF4416C21CD2A0C412A5E822E9B0CC429B4D5BB30F5C7DD658BD5168D1DF47B3FA25764414C5C056C71CACAAF30B2778BDCA96664959A13B6CC708AF132EDEE1EC52BA66BAE0BF0C03265DC2903AA63DD0B38EC 8644C5708FCCBAC8557D377B69A4D00D8CB12BFECF3A176C187C0313114766E78FA7BECE01316DAD8F8A304053D11279A9FF155F4570A9DD0929A1B454B0A91AABBE3124E9FC4C03E806BDE571A65835BF291C42AE681A88EDC2EDAB06A0A3B9CAE7CBB890F2941B2397DA2838D6C559 D2D924E26902BC4F25DCA201357D49F3DD220AFE54B50E4B72D3A32CEC9E8E84E6EDE5ED1B30E10092A140AEDBA89AC2F77745FECCE6A3C8D0CB717504A7761FAny idea on how to handle this problem?Bye--- |Marco Nenciarini| Debian/GNU Linux Developer - Plug Member || [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia |-Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFDCIG/aGRzDfCV5eQRArjGAJ9E6TuuRcogwIgb3GXbODU3jOYhtQCfS9UluGVM8qHv5GKGy36AcpuFRcU==/35W-END PGP SIGNATURE-___ Sks-devel mailing list[EMAIL PROTECTED]http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
OK, I just applied another patch that I think should work better. Tell me if it looks good. yOn 8/20/05, David Shaw <[EMAIL PROTECTED]> wrote: On Sat, Aug 20, 2005 at 07:00:30AM -0400, Yaron Minsky wrote:> On 8/19/05, David Shaw <[EMAIL PROTECTED]> wrote:> >> > I just tried it. It does not work. >>> Harumph. So I'm just confused. Here's the code in the current version:>> match request with> "/pks/add" ->> let keytext = Scanf.sscanf (Wserver.decode body) "keytext=%s" (fun s -> s) > in> let keys = Armor.decode_pubkey keytext in>> This looks right to me. It handles "keytext=" as well as> "keytext%3D". Jason's first patch seemed to handle the cases > "keytext=" and "keytext%". Jason later proposed> the following patch:>> let keytext = Wserver.decode body in> let tosser = Scanf.sscanf keytext "keytext=" (fun s -> s) in> let keytext = Str.string_after keytext 8 in>> Which seems like the same thing as my most recent patch. So what's the right> behavior? Can someone explain to me what I'm doing wrong? Handling "keytext% is definitely incorrect. The % isjust to escape the = sign as %3D.I'm not the best at reading ocaml, but it doesn't seem that your codewill handle arbitrary %-escaping elsewhere in . The HTTP spec allows any character to be escaped. Some clients (like libcurl)are a little more agressive about escaping. For example, the actualstream that is sent from curl during the HTTP POST begins:keytext%3D%2D%2D%2D%2D%2DBEGIN%20PGP%20PUBLIC%20KEY%20BLOCK%2D%2D%2D%2D%2D%0AVersion%3A%20GnuPG (etc)David___Sks-devel mailing listSks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
On 8/20/05, David Shaw <[EMAIL PROTECTED]> wrote: On Sat, Aug 20, 2005 at 07:00:30AM -0400, Yaron Minsky wrote:> On 8/19/05, David Shaw <[EMAIL PROTECTED]> wrote:> >> > I just tried it. It does not work. >>> Harumph. So I'm just confused. Here's the code in the current version:>> match request with> "/pks/add" ->> let keytext = Scanf.sscanf (Wserver.decode body) "keytext=%s" (fun s -> s) > in> let keys = Armor.decode_pubkey keytext in>> This looks right to me. It handles "keytext=" as well as> "keytext%3D". Jason's first patch seemed to handle the cases > "keytext=" and "keytext%". Jason later proposed> the following patch:>> let keytext = Wserver.decode body in> let tosser = Scanf.sscanf keytext "keytext=" (fun s -> s) in> let keytext = Str.string_after keytext 8 in>> Which seems like the same thing as my most recent patch. So what's the right> behavior? Can someone explain to me what I'm doing wrong? Handling "keytext% is definitely incorrect. The % isjust to escape the = sign as %3D.I'm not the best at reading ocaml, but it doesn't seem that your codewill handle arbitrary %-escaping elsewhere in . The HTTP spec allows any character to be escaped. Some clients (like libcurl)are a little more agressive about escaping. For example, the actualstream that is sent from curl during the HTTP POST begins:keytext%3D%2D%2D%2D%2D%2DBEGIN%20PGP%20PUBLIC%20KEY%20BLOCK%2D%2D%2D%2D%2D%0AVersion%3A%20GnuPG (etc) Why don't you think I handle that case correctly? I apply a Wserver.decode to the whole string, and then do sscanf on it to extract the keytext. Like this: # Wserver.decode "keytext%3D%2D%2D%2D%2D%2DBEGIN%20PGP%20PUBLIC%20KEY%20BLOCK%2D%2D%2D%2D%2D%0AVersion%3A%20GnuPG";; - : string = "keytext=-BEGIN PGP PUBLIC KEY BLOCK-\nVersion: GnuPG" Actually, now I think I understand the bug. The %s in the sscanf doesn't capture everything, just the next word (as broken by spaces). That's why Jason's patch does the right thing but mine is wrong. I'll fix that right up. y David___Sks-devel mailing list Sks-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
On 8/19/05, David Shaw <[EMAIL PROTECTED]> wrote:
I just tried it. It does not work.
Harumph. So I'm just confused. Here's the code in the current version:
match request with
"/pks/add" ->
let keytext = Scanf.sscanf (Wserver.decode body) "keytext=%s" (fun s
-> s) in
let keys = Armor.decode_pubkey keytext in
This looks right to me. It handles "keytext="
as well as "keytext%3D". Jason's first patch
seemed to handle the cases "keytext=" and
"keytext%". Jason later proposed the following
patch:
let keytext = Wserver.decode body in
let tosser = Scanf.sscanf keytext "keytext=" (fun s -> s) in
let keytext = Str.string_after keytext 8 in
Which seems like the same thing as my most recent patch. So
what's the right behavior? Can someone explain to me what I'm
doing wrong?
Confusedly,
Ron
DavidOn Fri, Aug 19, 2005 at 09:22:27PM -0400, Yaron Minsky wrote:> I still haven't heard back. Does the
> sks.dnsalias.net<http://sks.dnsalias.net>keyserver work with> gpg+libcurl? Has any one tried it?>> y>
> On 8/13/05, Yaron Minsky <[EMAIL PROTECTED]> wrote:> >> > I've put the server at sks.dnsalias.net <
http://sks.dnsalias.net> back up> > (just the sks db, not the reconciliation server). Could someone try it to> > see whether it fixes the gpg/curl bug described here?> >> > y
> >> > On 8/10/05, Jason Harris <[EMAIL PROTECTED]> wrote:> >> > > On Wed, Aug 10, 2005 at 10:53:35AM +0200, Dinko Korunic wrote:
> > > > On Tue, Aug 09, 2005 at 09:54:07PM -0400, Yaron Minsky wrote:> > >> > > > > mentioned. Could a couple people try out the latest release and see> > > if it
> > > > > seems OK? If no one complains over the next few days, I will put out> > > a new> > > >> > > > Seems to be working fine on
pks.aaiedu.hr <http://pks.aaiedu.hr>.> > >> > > Are you sure? Sending a key using GPG 1.4.2+libcurl to my (test) SKS> > > server with Yaron's latest patches now breaks with:
> > >> > > Error handling request> > > (POST,/pks/add,[+accept:*/*+content-length:45716+content-type:application/x-www-form-urlencoded+expect:100-continue+host:> > >
skylane.kjsl.com:21371 <http://skylane.kjsl.com:21371>]): Failure("Error> > > while decoding ascii-armored key: text terminated before reaching PGP public
> > > key header line")> > >> > > Interestingly, gpg-1.4.3-cvs reports:> > >> > > gpgkeys: HTTP post error 22: Failed to connect to 2001:1868:205:1::100:
> > > Connection refused> > >> > > (even though SKS confirms contact and generates the above error)> > > while gpg-1.4.2 reports:> > >> > > gpgkeys: HTTP post error 22: The requested URL returned error: 500
> > >> > > Your server is also bouncing keys from gpg-1.4.2 and gpg-1.4.3-cvs:> > >> > > gpg: sending key ... to hkp server pks.aaiedu.hr
<http://pks.aaiedu.hr>> > > gpgkeys: HTTP post error 22: The requested URL returned error: 500> > >> > > Both GPGs are linked with curl-7.14.0
.> > >> > > --> > > Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it?> > > [EMAIL PROTECTED] _|_ web:
http://keyserver.kjsl.com/~jharris/<http://keyserver.kjsl.com/%7Ejharris/>> > > Got photons? (TM), (C) 2004> > >> > >
> > > ___> > > Sks-devel mailing list> > > Sks-devel@nongnu.org> > >
http://lists.nongnu.org/mailman/listinfo/sks-devel> > >> > >> > >> > >> >> ___> Sks-devel mailing list
> Sks-devel@nongnu.org> http://lists.nongnu.org/mailman/listinfo/sks-devel___
Sks-devel mailing listSks-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/sks-devel
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
I still haven't heard back. Does the sks.dnsalias.net keyserver work with gpg+libcurl? Has any one tried it?
yOn 8/13/05, Yaron Minsky <[EMAIL PROTECTED]> wrote:
I've put the server at sks.dnsalias.net back up (just the sks db, not
the reconciliation server). Could someone try it to see whether
it fixes the gpg/curl bug described here?
yOn 8/10/05, Jason Harris <
[EMAIL PROTECTED]> wrote:
On Wed, Aug 10, 2005 at 10:53:35AM +0200, Dinko Korunic wrote:> On Tue, Aug 09, 2005 at 09:54:07PM -0400, Yaron Minsky wrote:> > mentioned. Could a couple people try out the latest release and see if it
> > seems OK? If no one complains over the next few days, I will put out a new>> Seems to be working fine on
pks.aaiedu.hr.Are you sure? Sending a key using GPG
1.4.2+libcurl to my (test) SKSserver with Yaron's latest patches now breaks with: Error handling request (POST,/pks/add,[+accept:*/*+content-length:45716+content-type:application/x-www-form-urlencoded+expect:100-continue+host:
skylane.kjsl.com:21371]):
Failure("Error while decoding ascii-armored key: text
terminated before reaching PGP public key header line")Interestingly, gpg-1.4.3-cvs reports: gpgkeys: HTTP post error 22: Failed to connect to 2001:1868:205:1::100: Connection refused(even though SKS confirms contact and generates the above error)
while gpg-1.4.2 reports: gpgkeys: HTTP post error 22: The requested URL returned error: 500Your server is also bouncing keys from gpg-1.4.2 and gpg-1.4.3-cvs: gpg: sending key ... to hkp server
pks.aaiedu.hr gpgkeys: HTTP post error 22: The requested URL returned error: 500Both GPGs are linked with
curl-7.14.0.--Jason
Harris
| NIC: JH329, PGP: This _is_
PGP-signed, isn't it?[EMAIL PROTECTED] _|_ web:
http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004
___Sks-devel mailing list
Sks-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/sks-devel
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Search only for complet mail address
Right, so this doesn't fix the "Too Many Responses" issue. If the underlying query has too many answers, then the extra exact filter on top won't change anything. It's a configuration variable (set by default to 500), but it can be raised. As for the Matthias.Mayer query, you clearly didn't search sks.dnsalias.net, since that machine has only one entry for "matthias.mayer", and goes to zero when you specify exact. In any case, this doesn't solve the deep problem of making all exact queries efficient. yOn 8/15/05, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: Hi, well, I tried but even after using the exact command, it still works to search for domains. Search for "microsoft.com" and the answer will be "Too many response" Search for "matthias.mayer" and the answer will be 3 responses I know the responses like, gmx.de, yahoo.de , do not work but the problem is still not solved, because it's still possible to look for domains L Greetings Markus Von: Yaron Minsky [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 14. August 2005 01:35 An: Scheffknecht, Markus Cc: sks-devel@nongnu.org Betreff: Re: [Sks-devel] Search only for complet mail address Try out the server running at sks.dnsalias.net. It should have support for exact searches now. Right now it's case-sensitive, though that's easy to change, or to make configurable. y On 8/11/05, Yaron Minsky <[EMAIL PROTECTED]> wrote: Hmm. That's a bug, I guess. The thing to do when you're looking for exact is to implement a filter of the kind I described. I'll take a look at it eventually, but it will likely take me a while to get to. I'll happily accept a patch, though... y On 8/11/05, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: Hi, thanx a lot for your idea, I managed to check if the request is a mail address. It needed indeed some changes in the code, I had to use a filter over the results. Problem is: It slows down the request very much, but I guess I have to live with that. But now I got another question: SKS uses more or less the same commands like PKS. Within PKS you got the possibility to extend the request with "&options=exact" which would solve all my problems. While checking the source code I found that there is a parameter like that in SKS (&exact=on). Correct me if I am wrong, but this command doesn't change anything, does it? Will this be used in the next version? Greetings Markus Von: Yaron Minsky [mailto: [EMAIL PROTECTED]] Gesendet: Mittwoch, 10. August 2005 20:29 An: Scheffknecht, Markus Cc: sks-devel@nongnu.org Betreff: Re: [Sks-devel] Search only for complet mail address It would require a code change. Probably the right thing to do is search first using the keywords in the email address, and then filter down to things that match the email address precisely. On 8/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi, I look for a solution, to search only by an eMail Address. It should only be possible, to get search results, if you commit a correct MailAddress. It must not be possible to search by keywords, like gmx.de or web.de. Can I configure this feature or do I have to make changes in the code. Greetings, Markus ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Re: Improved spider, new results
Actually, that count was too optimistic. Here's a more accurate one, I think: 29 servers found stinkfoot.org 11370 keyserver-sks.kjsl.com 21370 keyserver.noreply.org 11370 sks.keyserver.penguin.de 11370 sks.dnsalias.net 11370 pks.gpg.cz 11370 dannyj.dynip.com 11370 keys.se.linux.org 11370 keyserver.fabbione.net 11370 pgp.sjbcom.com 11370 pgpkeys.telering.at 11370 pgp.srv.ualberta.ca 11370 pks.aaiedu.hr 11370 keyserver.gurski.org 11370 gpg-keyserver.de 11370 keyserver.stack.nl 11370 keyserver.rootbash.com 11370 minsky.surfnet.nl 11370 ice.mudshark.org 11370 keyserver.mine.nu 11370 keyserver.afoyi.com 11370 keyserver.linux.it 11370 skylane.kjsl.com 21370 pgp.uni-mainz.de 11370 pgpkeys.pca.dfn.de 11370 keyserver.ubuntu.com 11370 keyserver.dotorg.org 11370 www.linux-geeks.de 11370 keyserver.sascha.silbe.org 11370On 8/13/05, Yaron Minsky <[EMAIL PROTECTED]> wrote:I improved my spider by a bit, and have a new and improved list of SKS servers. Also, the spider is now checked into the archive. If you're not here and should be (or are here and shouldn't), please let me know. 40 servers found stinkfoot.org 11370 keyserver-sks.kjsl.com 21370 keyserver.noreply.org 11370 sks.keyserver.penguin.de 11370 sks.dnsalias.net 11370 pks.gpg.cz 11370 dannyj.dynip.com 11370 keyserver.hadiko.de 11370 keys.se.linux.org 11370 keyserver.fabbione.net 11370 pgp.sjbcom.com 11370 pgpkeys.telering.at 11370 pgp.srv.ualberta.ca 11370 pks.aaiedu.hr 11370 misterl.net 11370 pgp.ael.be 11370 keyserver.gurski.org 11370 gpg-keyserver.de 11370 keyserver.stack.nl 11370 keyserver.rootbash.com 11370 minsky.surfnet.nl 11370 ice.mudshark.org 11370 sks.asociacion-aecsi.es 11370 keyserver.mine.nu 11370 keyserver.wetnet.net 11370 keys.kadath.com.ar 11370 keyserver.afoyi.com 11370 keyserver.linux.it 11370 skylane.kjsl.com 21370 pgp.uni-mainz.de 11370 pgpkeys.pca.dfn.de 11370 keyserver.ubuntu.com 11370 admin-log01.jccc.net 11370 keyserver.dotorg.org 11370 www.linux-geeks.de 11370 pgp.lu.gnu.org 11370 keyserver.sascha.silbe.org 11370 pgp.demonserver.de 11370 elephant.finux.org 11370 thor.chguernsey.com 11370 ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
