On 06/04/2017 03:26 AM, Phil Pennock wrote: > So we have newer-OCaml cleanup in the first branch "build-cleaner" and > then some desirable feature changes in a subordinate branch > "opt-long-keyids". > > Anyone with commit on the main repo want to consider merging these?
Should be a pull request against the main repo for that. The build-cleaner patches are likely most interesting, and dkg has some work on it already. The last time I looked into it a number of the issues we're seeing in build is related to cryptokit, and we likely should discuss whether its time to dis-embed the library from the source ( https://bitbucket.org/skskeyserver/sks-keyserver/issues/42/unbundle-cryptokit-sks-incompatible-with ) to begin with. The 64 bit keyid references etc are not necessarily material, we use those for internal identifiers anyways but don't display it in the WebUI. One issue here is that people seem to put too much trustworthiness in the keyservers to begin with, which they shouldnt. So changes to the webui that gives the impression it is secure is a malservice. People should download the public keyblocks and do their own operations on them given their own trustdb/wot calculation rather than relying on a third party that doen't provide a security assertion to begin with. -- ---------------------------- 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 ---------------------------- "Knowing is not enough; we must apply. Willing is not enough; we must do." (Johann Wolfgang von Goethe)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
