Hi Darin, > However, we've made some local patches to Pluto that we'll need to > re-evaluate and drop obsolete ones, re-implement necessary ones in > Charon, or maybe come up with better solutions, hopefully upstream.
> * crosbug.com/16252: initialize supplementary groups I think porting this to charon shouldn't be a problem, as it uses the same user/group switching as pluto. > * crosbug.com/24476: disable peer ID check If I understand correctly, this just accepts any identity the responder uses? If yes, this can be achieved by setting "rightid=%any". However, keep in mind that this has security implications; if you trust a CA certificate, any peer with a valid certificate can act as a responder, as we don't check the identity. This is why you usually want to enforce a strict identity. > * crosbug.com/25675: disable XAUTH ID State handling is completely different in charon than in pluto, so I'm not sure if this still applies. We currently always send the XAuth vendor ID in the first ISAKMP message. But this shouldn't be hard to change if it is problematic. However, from the bug report it's not clear to me why the responder sends an XAuth request while we negotiated PSK authentication. > * crosbug.com/32738: ISAKMP commit bit I don't have enough information to comment on this; it might or might not be an issue with charon. > Do you think some of these issues can be addressed properly upstream, > to ease the upgrade path? Yes, we'd be happy to help you fixing these issues and integrate it upstream. We don't have much third party equipment on the responder side to test against, though. Kind regards Martin _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
