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

Reply via email to