Hi Eric, > I've already tracked changes for the 1.4.4 release. Obviously, this library > being as sensitive as it is, I don't want it to fall too far out-of-step > with the official releases.
1.4.5 will be going out pretty soon, so I recommend porting the changes made for this as well. I guess this is an obvious problem with forking code, e.g. if you were to leave that project, would the next maintainer bother merging security fixes etc. > Yes. We would consider that a wonderful outcome. However, GenXDM, at the > moment, isn't an Apache hosted project. We're trying to prove out GenXDM's > value. Mind you, we're eventually hoping to get enough interest that GenXDM > that it can make for a viable Apache project. Cool! I think this would be the best outcome, to mitigate concerns about forking the codebase I raised above. One could envisage making the current Santuario codebase into a multi-module maven project to accommodate both approaches, or it could stay as a separate sub-project. What kind of process do you envisage happening to turn GenXDM into an Apache project? Does it really matter for the santuario-genxdm project whether the GenXDM code is in Apache or not? > I have considered one functional change. In canonicalization, there's a > workaround for a bug in the Xalan XPath engine. That work-around requires > modifying the input document to propagate namespace declarations down the > tree. With GenXDM, that work-around is completely unnecessary, because that > propagation is handled simply by passing a "true" value for a boolean to the > method that traverses the namespace axis. I've been told by a colleague that > that particular work-around has a serious performance impact, so switching > to GenXDM's capability might have a benefit. I plan on removing Xalan altogether from the code on trunk for a 1.5.0 release. I've already removed it from all of the tests, but I haven't gotten around to tackling some of the lower-level stuff in the source code yet. Thanks, Colm. On Thu, Apr 28, 2011 at 7:16 PM, Eric Johnson <[email protected]> wrote: > Hi Colm, > > Thanks for the response! > > On 4/28/11 7:38 AM, Colm O hEigeartaigh wrote: >> >> Hi Eric, >> >> Apologies for not replying to you on this earlier. Congrats on the >> achievement of getting everything working with Axiom. I have a couple >> of questions.... >> >> 1) Have you considered using DDOM? This is more interesting to me than >> non-standard APIs such as gen-xdm/AXIOM/etc. > > DDOM, is of course, one path to look at. GenXDM has larger goals (it > supports the XQuery Data Model, so is a good library to work underneath an > XPath 2, XQuery, or XSLT 2.0 engine, for starters), and the port of the XML > Security library is just one step in those goals. > > Having made this port work for Axiom, I'm confident we can do a bridge for > XOM, JDOM, DOM4J, and internal XML APIs, all without difficulty. > >> 2) Are you going to create a build which is a port of the Apache XML >> Security for Java 1.4.4 release? What is your release plan going >> forwards in terms of tracking Santuario releases? Are you going to >> pick up on the (fairly extensive) changes made on trunk? How will you >> merge bug fixes to your code? > > I've already tracked changes for the 1.4.4 release. Obviously, this library > being as sensitive as it is, I don't want it to fall too far out-of-step > with the official releases. > > >> 3) Have you considered whether it might be a good idea to submit this >> project as a subproject of Apache Santuario? > > Yes. We would consider that a wonderful outcome. However, GenXDM, at the > moment, isn't an Apache hosted project. We're trying to prove out GenXDM's > value. Mind you, we're eventually hoping to get enough interest that GenXDM > that it can make for a viable Apache project. > >> 4) There may potentially be trademark issues with the current name of >> "santuario-genxdm" - I'll have to check on this. > > Although I'm not a lawyer, I've encountered enough legal concerns over my > career that I'm not particularly concerned on this point. At this moment, > the labeling is merely factual - effectively "port of Santuario to GenXDM." > Long term, either this port merges back with the official code base, or we > have to come up with a name. Of course, at least in the US, you can always > sue about anything, however baseless. So if someone puts up a fuss, we'll > happily concoct a name, but we'll still be saying "Project _____, a port of > the Santuario XML Security library to use GenXDM." > > Now that I'm looking at an actual binary deliverable, the names will be > different on the JAR files. > >> Lastly, if you have come across any particularly inefficient code etc. >> when doing the port, then I'd certainly be interested to hear about >> it, as I'm doing some work in this area on the current trunk code. > > Since I want to keep this port as easy to maintain as possible, I've been > making minimal changes to functionality. I found a bug in the 1.4.3 code > base as a consequence of adding generic parameters everywhere. That bug, > however, was fixed in 1.4.4, so I didn't have to do anything but port the > delta. > > I have considered one functional change. In canonicalization, there's a > workaround for a bug in the Xalan XPath engine. That work-around requires > modifying the input document to propagate namespace declarations down the > tree. With GenXDM, that work-around is completely unnecessary, because that > propagation is handled simply by passing a "true" value for a boolean to the > method that traverses the namespace axis. I've been told by a colleague that > that particular work-around has a serious performance impact, so switching > to GenXDM's capability might have a benefit. > > As yet, I've been much more focused on getting the functionality exactly > right, and not so much on the performance (although notably, some of the > test cases I've ported to use GenXDM run *faster* than their DOM > counterparts). So I don't have any insights on performance as yet. > > -Eric. >> >> Thanks, >> >> Colm. >> >> On Thu, Apr 21, 2011 at 5:49 PM, Sean Mullan<[email protected]> >> wrote: >>> >>> On 4/20/11 1:43 PM, Eric Johnson wrote: >>>> >>>> A quick email to note an interesting milestone that we just achieved. >>>> >>>> For those who missed my previous emails, over at Apache Extras [1], >>>> we've >>>> been >>>> working on the santuario-genxdm [2] project, which is a port of the >>>> Santuario >>>> project to work using GenXDM [3]. >>>> >>>> With our latest release of GenXDM, we introduced support for a new >>>> "bridge" to >>>> the Axiom [4] data model. That meant, in theory, that the >>>> santuario-genxdm >>>> project could now work with three different data models - Axiom, DOM, >>>> and >>>> our >>>> reference implementation we call "Cx". >>>> >>>> In practice, Axiom didn't quite work. One security test case was >>>> failing. >>>> Yesterday, we fixed that bug, so the next release of GenXDM, coupled >>>> with >>>> santuario-genxdm, means that you can encrypt, decrypt, sign, and >>>> canonicalize >>>> Axiom-based tree models with full compliance. >>>> >>>> In any case, one reason for writing this post is that it seems like >>>> we've >>>> passed >>>> a crucial milestone, and ought to do an "official" build of >>>> santuario-genxdm, so >>>> that others don't have to grab the source to build it and play with it. >>>> >>>> The trick is, the port really should be a drop-in replacement (plus the >>>> requisite GenXDM JARs). We've attempted to maintain full API >>>> compatibility. >>>> Except that actual drop-in replacement would imply keeping the same >>>> names >>>> as the >>>> existing JARs. Not wanting to step on any toes, or pretend this release >>>> is >>>> something it isn't, keeping the existing xml-security JAR file names >>>> seems >>>> like >>>> a bad idea. What name changes should I introduce? >>> >>> I agree that you should avoid using the existing xmlsec.jar name. But >>> other >>> than that, I don't have any specific recommendations, and I think the >>> name >>> is completely up to you. >>> >>> --Sean >>> >>>> -Eric. >>>> >>>> [1] https://code.google.com/a/apache-extras.org/hosting/ >>>> [2] https://code.google.com/a/apache-extras.org/p/santuario-genxdm/ >>>> [3] https://code.google.com/p/genxdm/ >>>> [4] https://ws.apache.org/axiom/ >>>> >
