Unifying trust and even more private key storage has reasonable solutions in other operating systems. These solutions make sense for app-developers to use.
I don't think that a quick fix can compensate for the more over-arching issue which really is a lack of product management. Fixing JDK would be great but it won't happen because there is nothing to connect to in the *NIX world. This forced Google inventing a new key-store scheme (and lots of other non-JDK stuff as well), which caused a major split in the Java world. It is possible that playing with lib*.so or sqllite can make a difference but personally I think it just a waste of cycles. That Apple trow out Tokend is an example of that there's something is really wrong here. Apple IMO did the right thing, smart cards simply doesn't work for normal users. Anders On 2012-07-27 11:03, David Woodhouse wrote: > On Fri, 2012-07-27 at 10:53 +0200, Anders Rundgren wrote: >> I think you need to take a step back and consider which >> market and user-base you are targeting. > > No, I believe that's been clear from the beginning. Apologies if I > didn't make it explicit enough. > >> Linux on the desktop? Why bother with that? > > Linux distributions in general. I'll treat the second cited question as > a rhetorical one. > >> Linux servers? Well, *that* could be interesting. Unfortunately it >> doesn't help much since most servers run JBoss etc so it is >> actually more a JDK problem. > > I did explicitly mention that the intention is to achieve consistency of > the trust database across SSL implementations (including OpenSSL, > GnuTLS, etc.). > > Yes, I suppose Java should be included in that, although I may leave > that as an exercise for someone else. > > > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto