Just some quick notes: The policy so far has been (and I think we should keep it this way) that core has only 2 dependencies: slf4j-api.jar for logging and commons-beanutils for INI config, and that's it. Commons beanutils isn't even really a dependency if you don't use INI config.
Any other 3rd-party dependency is relegated to a support module. In fact, it could be argued that we should move the commons-beanutils dependency into its own module at some point (or refactored to do our own reflection and not depend on beanutils, but that could be a lot of unnecessary work). HTH, Les On Mon, May 24, 2010 at 10:23 AM, Brian Demers <[email protected]> wrote: > Also, After taking a very quick look at the patch. > > This requires a dependency on bouncycastle ( sort of the obvious choice ). > But this means the core will depend on bouncycastle. > > Les, what is the _policy_ for this type of dependency, I don't think it > should be a core dep. > > A couple of options are: > 1.) Push this realm to its own sub-module. > 2.) Mark the dep as optional/provided/etc ( not a big fan of this one ) > 3.) Nothing, leave it as a dep > > > On Mon, May 24, 2010 at 1:11 PM, Brian Demers <[email protected]>wrote: > >> Yeah, the comparing of two public keys confused me (still does actually) >> but I emailed the apache sshd list of conformation (hasn't hit the archive >> yet, so no link) >> >> Anyone else have any thoughts on these realms? >> >> >> On Mon, May 24, 2010 at 12:56 PM, Paul Merlin <[email protected]> wrote: >> >>> Le lundi 24 mai 2010 18:26:39, Brian Demers a écrit : >>> > Here is what we have: >>> > >>> http://github.com/sonatype/security/tree/master/security-realms/security-pu >>> > blic-key-realm/ >>> > >>> > Note this just compare two public keys, ( so this assume something else >>> is >>> > doing the hand shaking with the private key ) >>> > >>> >>> Thanks for sharing Brian. >>> >>> Some things are similar to my implementation (already attached as a patch >>> in >>> jira). Looking at PublicKeyWithEquals, it could be related to my second >>> matching >>> strategy, fingerprint, except that you compare the public key data >>> (pk.getEncoded()) and not the certificate data. >>> >>> Be aware that a KeyPair can be certified several times and so a PublicKey >>> can be >>> used in several X509Certificate 'instances'. >>> >>> IOW the ssl engine had the proof that the client own the PrivateKey and >>> that >>> it's certificate is trusted. You then match only the PublicKey that's >>> inside the >>> certificate, not the certificate itself. >>> >>> Use cases leading to a security hole in your implementation will certainly >>> by >>> awkward and depend a lot on deployment and certification policies but one >>> can >>> imagine such a scenario. >>> >>> We could say the very same about my Simple strategy. >>> >>> /Paul >>> >>> >>> >> >
