harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Date Wed, 15 Feb 2006 11:12:47 GMT
Mikhail Loenko wrote:
> Sounds reasonable.
> 
> Sure, I can make 'getInstance'  functionality visible as an internal API.
> 
> So we put classes that has many internal dependencies into the same component,
> but not only that. For example java.lang.Error and java.lang.Ecxeption do not
> have internal dependencies but we put them into the same component.

I agree, let's not split a package across multiple modules(*)

(*) the exception that proves the rule here is KERNEL, which does
contain package fragments.  But KERNEL is special.

> Having internal dependency is not the only reasong to go into the same
> component. Other reasons could be belonging to the same package or having
> some semantical connection.

I agree.

> For example I'd put java.security.cert and javax.security.cert into the same
> component.

Sounds great.  (In this case the 'x' is merely an artifact of Java's
history.)

> What do you think?

+1

Regards,
Tim

> On 2/15/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> Mikhail Loenko wrote:
>>> There is coupling.
>>> BTW... Could you give an example of "close" and "weak" coupling?
>> Sure.  The goal is to define modules that represent functional units
>> whose implementation can be contained within the module as much as
>> possible.  The measure of coupling is the number of internal-API
>> dependencies shared between two modules.  (Internal-APIs are those that
>> Anton described, and that we are proposing to put into
>> org.apache.harmony.<module_name>.<whatever> packages and explicitly
>> export from the module.)
>>
>> For example, we have code like LUNI and NIO that require some
>> non-Java-API dependencies upon one another, but these are 'weakly'
>> coupled because they are coupled by a small number of 'internal APIs'.
>>
>> Where the code has a large number of implementation dependencies that
>> you would not want to export then that is an indication of close
>> coupling.  So, for example, if we tried to separate java.io into its own
>> module we would have lots of impl dependencies between that module and
>> LUNI that would indicate poor modularity.  Similarly trying to move the
>> NIO buffers impls out to a separate module to NIO would result in those
>> two modules being closely coupled.
>>
>>> The following two groups of classes use the same internal stuff:
>>> GROUP1 (use/provide inernal implementation of 'getInstance' ):
>> Can you make this visible as an internal API (e.g. exported factory type)?
>>
>>> java.security.AlgorithmParameterGenerator
>>> java.security.AlgorithmParameters
>>> java.security.KeyFactory
>>> java.security.KeyPairGenerator
>>> java.security.KeyStore
>>> java.security.KeyStoreSpi
>>> java.security.MessageDigest
>>> java.security.Provider
>>> java.security.SecureRandom
>>> java.security.Security
>>> java.security.Signature
>>> java.security.cert.CertPathBuilder
>>> java.security.cert.CertPathValidator
>>> java.security.cert.CertStore
>>> java.security.cert.CertificateFactory
>>> javax.crypto.Cipher
>>> javax.crypto.ExemptionMechanism
>>> javax.crypto.KeyAgreement
>>> javax.crypto.KeyGenerator
>>> javax.crypto.Mac
>>> javax.crypto.SecretKeyFactory
>>> javax.net.ssl.KeyManagerFactory
>>> javax.net.ssl.SSLContext
>>> javax.net.ssl.SSLServerSocketFactory
>>> javax.net.ssl.SSLSocketFactory
>>> javax.net.ssl.TrustManagerFactory
>>>
>>> GROUP2 (all use internal implementation of ASN.1):
>>
>> The ASN.1 code is a good example of an internal-API that we would want
>> to expose to other module developers.
>>
>> To be clear, we are not extending the Java API here, just making it
>> visible as a contract that replacements to <whatever module implements
>> it> must conform.
>>
>>> java.security.cert.PolicyQualifierInfo
>>> java.security.cert.TrustAnchor
>>> java.security.cert.X509CRLSelector
>>> java.security.cert.X509CertSelector
>>> javax.crypto.EncryptedPrivateKeyInfo
>>> javax.security.auth.kerberos.KerberosKey
>>> javax.security.auth.kerberos.KerberosTicket
>>>
>>> All other dependencies seem to be public ones.
>> Sounds good.
>>
>> Regards,
>> Tim
>>
>>
>>> On 2/14/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>> Mikhail Loenko wrote:
>>>>> Tim
>>>>>
>>>>> On 2/13/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>>>> Mikhail Loenko wrote:
>>>>>>> It looks good but it is not clear where would you put certification
stuff.
>>>>>>> According to SUN's guide it is splitted between JSSE and general
security.
>>>>>>> (According to SUN general security includes also crypto architecture)
>>>>>> I wouldn't get too hung up about where Sun put it.  There is likely
a
>>>>>> different partitioning about where the architectural/semantic boundaries
>>>>>> are best placed, and how we componentize the implementation.
>>>>>>
>>>>>> Looking into this a bit more, the certificate management
>>>>>> (java.security.cert.*) code should likely go in 'general security'.
>>>>>>
>>>>>> It is mostly instinct behind the decision, but that was formed by
the
>>>>>> following reasoning:
>>>>>>
>>>>>> Historical - JCE, JSSE and JAAS used to be optional packages for
the JDK
>>>>>> at a time when the certificate management code was included in the
JDK
>>>>>> By process of exclusion - the other modules ('crypto', 'x-net' and
>>>>>> 'jaas') are self-contained and can be removed without breaking any
other
>>>>>> APIs.
>>>>> That was in the past. In 1.5 for example
>>>>>     java.security.KeyStore.SecretKeyEntry.getSecretKey()
>>>>> returns
>>>>>     javax.crypto.SecretKey
>>>>>
>>>>> Method
>>>>>     java.security.AuthProvider.login()
>>>>> takes  arguments
>>>>>     javax.security.auth.Subject and javax.security.auth.callback.CallbackHandler
>>>>>
>>>>> Another example
>>>>>     java.net.SecureCacheResponse.getPeerPrincipal()
>>>>> throws
>>>>>     javax.net.ssl.SSLPeerUnverifiedException
>>>>>
>>>>> So, none of the components is self-contained.
>>>> Right, but these are all public type dependencies, for sure the modules
>>>> will have many dependencies on other modules' public types.
>>>> Do you see a close coupling of the implementation types too?
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>> Removing certificate management would break APIs in java.util.jar
>>>>>> and java.security so it doesn't make sense to separate it from them.
>>>>>>
>>>>>> US Export Control office is less interested in digital
>>>>>> signing/verification than they are in the cryptography and secure
>>>>>> communications packages.  Keeping them pluggable makes sense.
>>>>>>
>>>>>> Perhaps we should name the 'jaas' package 'auth'.  JAAS may be a
>>>>>> protected trademark.  The org.ietf.jgss package may belong in 'auth'
as
>>>>>> well.
>>>>>>
>>>>>> Regards,
>>>>>> Tim
>>>>>>
>>>>>>> I'd rather put it  into crypto (or maybe into x-net) - all of
them use
>>>>>>> service-provider architecture. What do you think?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mikhail
>>>>>>>
>>>>>>> On 2/10/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>>>>>> Mikhail Loenko wrote:
>>>>>>>>> What I'd like to propose is:
>>>>>>>>>
>>>>>>>>> 1. separate Authentication and Authorization stuff (javax.security
>>>>>>>>> package) from general security
>>>>>>>> Ok, so I can see this.
>>>>>>>>
>>>>>>>>> 2. unite crypto (java.security) and crypto extension
(javax.crypto)
>>>>>>>> but this makes no sense to me.  Why would you want to unite
JCE with
>>>>>>>> general security?  There is no close coupling afaict.
>>>>>>>>
>>>>>>>> How about
>>>>>>>>  - general security
>>>>>>>>  - crypto
>>>>>>>>  - x-net
>>>>>>>>  - jaas
>>>>>>>>
>>>>>>>> there may be good reason to want to replace crypto independently
of
>>>>>>>> general security.  Am I missing something?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Tim
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>>>>>> IBM Java technology centre, UK.
>>>>>>>>
>>>>>> --
>>>>>>
>>>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>>>> IBM Java technology centre, UK.
>>>>>>
>>>> --
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message