Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On Fri 2019-02-08 20:44:33 +, Andrew Gallagher wrote: > Parse the syslogs of an old style SKS server, fetch any updated > packets, filter them and submit to the new server. ah yes, the SMOP (it's a "Simple Matter of Programming") argument :) > Sync from the old network to the new one only needs to work in one > direction. thanks, this is a good insight. --dkg signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> On 8 Feb 2019, at 19:02, Daniel Kahn Gillmor wrote: > > Figuring out how to do the partial-sync for a limited time sounds > difficult to me, and i wonder whether it might be better/faster/cheaper > to just deploy such an update-only network, and don't bother with the > partial sync. Parse the syslogs of an old style SKS server, fetch any updated packets, filter them and submit to the new server. Sync from the old network to the new one only needs to work in one direction. A ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On Thu 2019-02-07 23:15:18 +0100, Kristian Fiskerstrand wrote: > The current discussions we're having (e.g during OpenPGP email summit in > brussels in october and lately on FOSDEM last weekend) is eventually not > storing UIDs at all on the keyservers, but require the user to do key > discovery through WKD, directly on a website or the like. This still > allows using keyservers to distribute revocation certificates and > updates to subkeys etc, but not as a discovery mechanism. thanks for this summary, kristian. it roughly matches my recollection of these discussions as well. It's conceivable that such a constrained updates-only-keyserver network could also host self-signed user IDs, with reasonable constraints (e.g. valid UTF-8 only, no more than 512 octets), but no third-party certifications. This would permit keyserver-based updates of expirations, since primary key expiration timestamps are currently stored in the self-signatures over the User IDs. Alternately, we could encourage OpenPGP implementations to issue primary key expiration timestamps as direct-key signatures, not involving a user ID at all. Critically, though, this updates-only keyserver network would *only* permit retreival of keys by fingerprint, and would not provide a web-based tool for browsing based on User ID, to avoid the usability failures that we've seen attributed to SKS in the past. Each node in this proposed updates-only network would also need to be able to cryptographically verify the OpenPGP packets that it synchronizes, and should reject packet that cannot be cryptographically verified. > Pool-wise it'd be setting up a separate keyserver network that will > gossip with the existing network for a time, with separate pool for the > with-uid and without-uid servers, before the full switch is done... Figuring out how to do the partial-sync for a limited time sounds difficult to me, and i wonder whether it might be better/faster/cheaper to just deploy such an update-only network, and don't bother with the partial sync. > The new network would be running on software replacing SKS, using more > suited database backend that and multi-threaded implementation. The > current disagreement are really with regards to whether this should be > "validating keyservers" or not, and how such servers could interact with > non-validating ones. "validating keyservers" form an entirely distinct interaction model, since they are focused on User IDs. They should not be conflated with this updates-only proposal. There's no need to coordinate their development. --dkg ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2/6/19 8:28 PM, Robert J. Hansen wrote: > What we don't have is *consensus* -- not only among ourselves, but in > the larger community. The current discussions we're having (e.g during OpenPGP email summit in brussels in october and lately on FOSDEM last weekend) is eventually not storing UIDs at all on the keyservers, but require the user to do key discovery through WKD, directly on a website or the like. This still allows using keyservers to distribute revocation certificates and updates to subkeys etc, but not as a discovery mechanism. Pool-wise it'd be setting up a separate keyserver network that will gossip with the existing network for a time, with separate pool for the with-uid and without-uid servers, before the full switch is done... The new network would be running on software replacing SKS, using more suited database backend that and multi-threaded implementation. The current disagreement are really with regards to whether this should be "validating keyservers" or not, and how such servers could interact with non-validating ones. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "A committee is a group that keeps minutes and loses hours." (Milton Berle) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2019/02/06 23:51, Robert J. Hansen wrote: > No. Keyserver reconciliation is 90% of the problem. Fixing this would > make it impossible for older keyservers to reconcile with a next-gen design. I have had a long think about this problem, and I reckon that the biggest bar to progress is the assumption that arbitrary members of the pool will upgrade to the new software at random, and that we need to ensure that all nodes stay synchronised with each other no matter what version they run, in a single mixed-version network. We can simplify this problem considerably. Instead of an operator upgrading their sks server to "new-sks" and expecting to still be able to peer with traditional sks servers, they should install the "new-sks" software *in parallel* with the traditional one (on the same or a different machine, doesn't matter) and this "new-sks" node should only be able to peer with other "new-sks" nodes. This means that our new recon protocol can be efficient, because it doesn't have to keep a record of blacklisted hashes. If we further assume that key material does not flow back from the "new-sks" network to the old one, then we can write a relatively simple cron job that finds updated keys on an old-style sks server (by parsing its logs, for example) and copies them (suitably censored) to the corresponding "new-sks" server. At some point, when the "new-sks" network is sufficiently stable, the pools are redefined and the old sks network becomes irrelevant. The above allows us to ignore broad categories of problematic material by policy, simply by defining a narrow set of allowed packets in the new protocol. Any compliant "new-sks" server will simply not be capable of processing packets of unapproved types, e.g. image IDs, 3rd party signatures, and keys with invalid self-sigs. Also, any peer that tries to serve too many unapproved packets via recon can be twitted. What the above will not do is allow individual operators to blacklist arbitrary packets by hash, not without either some central authority defining a shared blacklist, or a fake-recon process that maintains local blacklist caches and runs the risk of split-brain. So the threat of shutdown by court order is not completely removed. I still think this may be enough to be getting started with. A signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2019/02/07 11:01, Martin Dobrev wrote: > My idea for blacklists is in a sense similar - during recon process > consolidate hashes from the blacklists with whatever is in the live > database and report this to peers. This way it won't trigger continuous > *recon/fetch/drop due to blacklist* loops. I wrote a doorstop post on blacklist mechanisms some time back on this list. The implementation planning is a rabbit-hole, and that's before you even start thinking about higher-level problems like split-brain. Eventual consistency is a harsh mistress. :-) A signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2019/02/07 05:35, Gabor Kiss wrote: > And all these programs can talk each to other due to RFC 821 (1982). Well, yes. A good protocol is everything. The implementation is relatively easy. Ensuring that the protocol doesn't result in a cascade failure is the Really Hard Problem. We're still trying to mitigate the unintended side-effects of RFC821, 37 years after the fact... :-) A signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 07/02/2019 08:02, robots.txt fan wrote: > On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher > wrote: >> Because you can reject a key, but then what happens is it just keeps trying >> to come back. Pretty soon there are so many rejected keys floating around >> that the network stops reconciling. Also, what happens if I reject certain >> keys and you don’t, but your only connection to the rest of the network is >> through me? Once nodes start implementing different policies you can go >> split-brain surprisingly easily. > I shouldn't have written "reject". If you already have this key in your > blacklist, just tell the other keyserver that you already have it, but do not > store it. Store only the hash. > > Of course it might still be possible to code information into the hashes like > Tobias wrote, but at least generating exactly the right hash is extremely > expensive (if not impossible) from the attacker's perspective so I do not > think it is feasible for them at all. Storing hashes of kryptonite should be > okay. My idea for blacklists is in a sense similar - during recon process consolidate hashes from the blacklists with whatever is in the live database and report this to peers. This way it won't trigger continuous *recon/fetch/drop due to blacklist* loops. There is only the risk that downstream servers that don't use blacklists will keep asking not just for the hash but the key too. This is something that can be mitigated in the next-gen gossip protocol: server A asks for a key belonging to a hash, it gets a response that server B is not actually having it due to blacklist flag. Server A can ask another member from the membership pool to provide the key. If all peers flag it as blacklisted set a flag and give up retries until membership file changes. Is this going to work? Most probably yes. Is it going to cause some issues (see above) due to backwards compatibility in the short term - yes, but then operators will be keen to upgrade to next-gen server implementation and the problem gets solved in the long run. >> It’s not a simple matter of just coding it up. > Of course not, and I wouldn't dare claiming that. I agree with Martin in that > I also am glad to see that there is a will to invest time in developing a new > server. The Synchronising Key Servers should not vanish from earth. > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
Robert, No doubt it's risky to implement things that there is no consensus on. But the device I'm writing this on was invented by *not a consensus*, and a consensus to design it would not have emerged on this list nor elsewhere. The risk may be lowered: 1) on behalf of our company I'm excited to run whatever not-sks testnode you prototype 2) fwiw there's Hockeypuck written in a popular language and popular db. The sks recon is separated into a module, and could be swapped out. All the other bells and whistles of a ks are there. 3) find one more person and we can call it a test network As an alternative to Hockeypuck, we also use a keyserver on the backend written in Node/TypeScript and postgres that I'd be happy to strip/clean up and contribute. It has no sync nor consensus built in. Based on OpenPGP.js. I wrote it purely out of my frustration with sks. I think this list needs resolute action, not consensus. Resolute action is risky, sure. My company will issue a modest grant to get a ball rolling on whatever is not-sks, implemented by a person with a brain (you're overqualified!). Cheers, Tom On Thu, 7 Feb 2019, 08:46 Robert J. Hansen > It is no use to wait a great consensus. > > Without exception, I have never met someone who was reluctant to > volunteer someone else's time. I think this is unfortunate. I'd rather > we were as reluctant to urge other people to commit their time and > effort to a project as we are to commit our own. > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher wrote: > Because you can reject a key, but then what happens is it just keeps trying > to come back. Pretty soon there are so many rejected keys floating around > that the network stops reconciling. Also, what happens if I reject certain > keys and you don’t, but your only connection to the rest of the network is > through me? Once nodes start implementing different policies you can go > split-brain surprisingly easily. I shouldn't have written "reject". If you already have this key in your blacklist, just tell the other keyserver that you already have it, but do not store it. Store only the hash. Of course it might still be possible to code information into the hashes like Tobias wrote, but at least generating exactly the right hash is extremely expensive (if not impossible) from the attacker's perspective so I do not think it is feasible for them at all. Storing hashes of kryptonite should be okay. > It’s not a simple matter of just coding it up. Of course not, and I wouldn't dare claiming that. I agree with Martin in that I also am glad to see that there is a will to invest time in developing a new server. The Synchronising Key Servers should not vanish from earth. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> It is no use to wait a great consensus. Without exception, I have never met someone who was reluctant to volunteer someone else's time. I think this is unfortunate. I'd rather we were as reluctant to urge other people to commit their time and effort to a project as we are to commit our own. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> There are a handful of people with the background and skills to write a > next-generation keyserver. I looked into it a dozen years ago and wrote > up a whitepaper on it. I know Phil Pennock has put a lot of thought > into it. Andrew, likewise. There are easily five or six people on this > list who have the time and ability. > > What we don't have is *consensus* -- not only among ourselves, but in > the larger community. > > Let's say I decide to implement my whitepaper from 2007. It would take, > oh, call it 200 hours of work to implement. So I write it, put it out > there, and nothing happens because there's no consensus my idea is the > direction we should go. > > The problem here is not a lack of manpower or skill. > > It's a lack of community consensus on what a redesign should look like. My 2 cents: It is no use to wait a great consensus. The working model of open source development is: 10 publishing a formal protocol description[1] 20 some peoples implement it 30 collecting experiments 40 years later other peoples write a different implemantation that is compatible with the original 50 GOTO 30 [1]: The famous paper describes the _algorithm_. A protocol description writes bit-by-bit what is transferred on the wire, what to in case of any errors, what must to do and what is optional etc. See RFCs. If there would be _competing_ implementations operators could choose which one they run. This is an evolution. Remember Sendmail. 30-40 years ago it was virtually the only (non proprietary) mail transfer agent (MTA). Eric Allman did a great job. But later other guys had different ideas. Now there is a dozen MTAs on the market and almost nobody uses Sendmail. But some do. And all these programs can talk each to other due to RFC 821 (1982). Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> Is it possible to develop a keyserver thar uses the same interface as > the current one? Sort of. > Meaning that GnuPG-Clients don't need to change Yes. > and current keyservers can recon with the new keyservers (since they > are not all upgraded simultaniously)? No. Keyserver reconciliation is 90% of the problem. Fixing this would make it impossible for older keyservers to reconcile with a next-gen design. > Are there any more problems that need to be fixed? Like seriously, > everyone please write the problems they have with SKS. Please, *don't*. We have had this discussion so many times over the past ~15 years that I can't stand to go through it again. Go through the list archives, read those past discussions, and then if you come up with anything new post it to the list. > To answer my first question, I guess that it is possible to implement > a keyserver with the same interface for GPG users that can still > recon with older servers. Let's not make this situation worse by guessing. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
Hi On 06/02/2019 19:28, Robert J. Hansen wrote: >> If only it were open-source software and individuals with the extra time >> and talent to work on those design flaws were able to do so. Wouldn't >> that be a great world to live in? > Wouldn't it be great if people were to think before snarking? > > There are a handful of people with the background and skills to write a > next-generation keyserver. I looked into it a dozen years ago and wrote > up a whitepaper on it. I know Phil Pennock has put a lot of thought > into it. Andrew, likewise. There are easily five or six people on this > list who have the time and ability. I'm glad to see from server operator perspective that there is a will to invest time in developing the server. > > What we don't have is *consensus* -- not only among ourselves, but in > the larger community. > > Let's say I decide to implement my whitepaper from 2007. It would take, > oh, call it 200 hours of work to implement. So I write it, put it out > there, and nothing happens because there's no consensus my idea is the > direction we should go. > > The problem here is not a lack of manpower or skill. > > It's a lack of community consensus on what a redesign should look like. > Is there a place where white-papers and draft proposals can be found? I remember seeing proposals to change the backend database with something that supports transactions, the likes of postgresql or mysql. Without it multi-threaded server is not possible. If I had the knowledge of OCAML I'd start like immediately a fork and implement it in order to save disk space and more important cut on redundant Iops. Nearly 21K keys have been added for the past month. Looking at the graph again I don't see a single plunge just steady growth. As it stands I'm running two physical servers with four Docker containers each that take approximately 95GB. Even with a single-thread server implementation I can still run multiple containers with a shared database, isn't it? I agree redesign is inevitable if we want to address legislation changes like GDPR for example. A lot of servers in Europe ceased operation because of it. Today I read the news that criminals are using block-chain network to upload child abuse photos. According to UK law hosting such content can lead to large convictions. I don't want to be forced to stop my clusters if criminals exploit the photo field in the protocol. In my opinion there must be a way to remove content that's not legal from the network. The way I see this happening is by introducing blacklists that a) prevent a key from being fetched during recon and b) delete the local copy of it. Is this a censorship?! For what I know some of us are already using blacklists to mitigate the poison key issues, the very least I am. Building upon the previous suggestion I'm actually envisioning different types of blacklists in terms of legislation framework they comply with. Subdomains like .pool.sks-keyservers.net can be introduced as well. Then individual keyserver operators can configure what blacklists to use. A public register will keep the audit trail justifying every blacklist entry and used as a seed for the servers in the network. And before you ask who's going to be responsible for keeping that register up-to-date and accurate I have an answer for you - the very same law enforcement agencies that in the very first place demanded that we remove content from the network. That being said I believe these changes will make the network a safer place not just for the operators but the users as well. That's something, I think, we as community can easily achieve consensus upon. Sadly I don't have a solution for the recent poison key issues that opened this thread in first place. We eventually need a brand new RFC that will define the next-gen server architecture. > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> On 6 Feb 2019, at 23:15, robots.txt fan wrote: > > To answer my first question, I guess that it is possible to implement a > keyserver with the same interface for GPG users that can still recon with > older servers. The older servers might try to send them keys that are on the > blacklist or are large, but the new server can reject those keys of course. Easier said than done. There is plenty of discussion in the archives about how difficult this would be technically. Because you can reject a key, but then what happens is it just keeps trying to come back. Pretty soon there are so many rejected keys floating around that the network stops reconciling. Also, what happens if I reject certain keys and you don’t, but your only connection to the rest of the network is through me? Once nodes start implementing different policies you can go split-brain surprisingly easily. It’s not a simple matter of just coding it up. A ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On Wednesday, February 6, 2019 8:28 PM, Robert J. Hansen wrote: > It's a lack of community consensus on what a redesign should look like. That can be changed. I do not know anything about the source code of this project, so forgive my naivety. Is it possible to develop a keyserver thar uses the same interface as the current one? Meaning that GnuPG-Clients don't need to change and current keyservers can recon with the new keyservers (since they are not all upgraded simultaniously)? Of course, that while also being able to not accept large keys. A first step might be limiting UIDs to a certain size, but then one could just generate lots of UIDs, or if you also limit the number of UIDs per key, they could generate lots of keys. Furthermore, what would be nice if content could be deleted. I'm thinking about GDPR requests from people who do not want their data online anymore, or illegal content coded into UIDs or User Attribute Packets. Perhaps this can be implemented through a blacklist of fingerprints that synchronises. Are there any more problems that need to be fixed? Like seriously, everyone please write the problems they have with SKS. To answer my first question, I guess that it is possible to implement a keyserver with the same interface for GPG users that can still recon with older servers. The older servers might try to send them keys that are on the blacklist or are large, but the new server can reject those keys of course. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On Wed, 6 Feb 2019, 20:28 Robert J. Hansen > It's a lack of community consensus on what a redesign should look like. > And, might I add, the desire for our efforts not to be ruined by others "proving a point" rather than actors actually seeking malicious intent. I've abandoned my keyserver, and only advertise my keys as a pointer in DNS to download it via http. M > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> If only it were open-source software and individuals with the extra time > and talent to work on those design flaws were able to do so. Wouldn't > that be a great world to live in? Wouldn't it be great if people were to think before snarking? There are a handful of people with the background and skills to write a next-generation keyserver. I looked into it a dozen years ago and wrote up a whitepaper on it. I know Phil Pennock has put a lot of thought into it. Andrew, likewise. There are easily five or six people on this list who have the time and ability. What we don't have is *consensus* -- not only among ourselves, but in the larger community. Let's say I decide to implement my whitepaper from 2007. It would take, oh, call it 200 hours of work to implement. So I write it, put it out there, and nothing happens because there's no consensus my idea is the direction we should go. The problem here is not a lack of manpower or skill. It's a lack of community consensus on what a redesign should look like. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2/6/2019 11:26 AM, Andrew Gallagher wrote: > On 06/02/2019 13:11, Steffen Kaiser wrote: >> Is it meant litterally? The current SKS project is end of life and, >> effectively, we have to look into another direction? Other software, new >> fork with rewrite? > I said "effectively", not literally. And I was in a grumpy mood that > day. But I stand by my point about design flaws not getting the > attention they deserve. You don't need to fork the codebase to make > improvements, but you do need to redesign the protocol to be > abuse-resistant, which is a Very Hard Problem. If we had some consensus > on the way forward it would be a good start. If only it were open-source software and individuals with the extra time and talent to work on those design flaws were able to do so. Wouldn't that be a great world to live in? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 06/02/2019 13:11, Steffen Kaiser wrote: > Is it meant litterally? The current SKS project is end of life and, > effectively, we have to look into another direction? Other software, new > fork with rewrite? I said "effectively", not literally. And I was in a grumpy mood that day. But I stand by my point about design flaws not getting the attention they deserve. You don't need to fork the codebase to make improvements, but you do need to redesign the protocol to be abuse-resistant, which is a Very Hard Problem. If we had some consensus on the way forward it would be a good start. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
Hi, Isn't Mozilla Thunderbird in a similar state? I'm still happily using it *because* it has reached a point where further updates are rarely needed. Best regards Tobias Frei On Wed, Feb 6, 2019, 14:22 Steffen Kaiser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I picked up this sentence here on the list in a thread about poison > key(s): > > "> Any chance that sks will be fixed some day? > > "Short answer, no. SKS is effectively running as end-of-life software at > this point. It gets emergency bugfixes but little else. The improvements > you are talking about would require an enormous refactoring of the > codebase, likely requiring migration to a different database engine. > Given that there are fundamental design flaws (poison keys) that aren't > getting fixed, performance issues just aren't on the radar. Sorry." > > Is it meant litterally? The current SKS project is end of life and, > effectively, we have to look into another direction? Other software, new > fork with rewrite? > > Kind regards, > > - -- > Steffen Kaiser > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEVAwUBXFrc6iOjcd6avHZPAQI8iAgAhMVSiTvPdMARX20Kqkt7BQAIFwcnqi/K > GncegVdHZqf6PkyogVwXxMDxExOm+dJmkyJDD8IOsc6SQW+Tx7YDOcTynLsvFPQ9 > NjehfxC6+O0Himxr1AAm75HZ3oU82e9GMteebbbyLc2pr0ggx7BNtIf81YjCwzxy > clLLCLZOCb8HAuXBYGi0X7z0iD9511nWQ6vbbpNEuTdz4rv/Fsvgre6SMQ8blYS6 > mYlCsSv8AoL3vFux3E+8gsDUn/uOFzdvL+W6Ei5ETMd4zt4OVfyuGX/P1SBEGl+5 > 7Wfo3ev7F7ZaY7cJy1aOfF9lTKNF8Fuweq+wvBCnhL1B3dLuZ8Gqjw== > =Id3h > -END PGP SIGNATURE- > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] "SKS is effectively running as end-of-life software at this point"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I picked up this sentence here on the list in a thread about poison key(s): "> Any chance that sks will be fixed some day? "Short answer, no. SKS is effectively running as end-of-life software at this point. It gets emergency bugfixes but little else. The improvements you are talking about would require an enormous refactoring of the codebase, likely requiring migration to a different database engine. Given that there are fundamental design flaws (poison keys) that aren't getting fixed, performance issues just aren't on the radar. Sorry." Is it meant litterally? The current SKS project is end of life and, effectively, we have to look into another direction? Other software, new fork with rewrite? Kind regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBXFrc6iOjcd6avHZPAQI8iAgAhMVSiTvPdMARX20Kqkt7BQAIFwcnqi/K GncegVdHZqf6PkyogVwXxMDxExOm+dJmkyJDD8IOsc6SQW+Tx7YDOcTynLsvFPQ9 NjehfxC6+O0Himxr1AAm75HZ3oU82e9GMteebbbyLc2pr0ggx7BNtIf81YjCwzxy clLLCLZOCb8HAuXBYGi0X7z0iD9511nWQ6vbbpNEuTdz4rv/Fsvgre6SMQ8blYS6 mYlCsSv8AoL3vFux3E+8gsDUn/uOFzdvL+W6Ei5ETMd4zt4OVfyuGX/P1SBEGl+5 7Wfo3ev7F7ZaY7cJy1aOfF9lTKNF8Fuweq+wvBCnhL1B3dLuZ8Gqjw== =Id3h -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
