santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Small milestone for genxdm-based port of Santuario - works with Axiom!
Date Fri, 29 Apr 2011 13:51:38 GMT
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 <eric@tibco.com> 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<sean.mullan@oracle.com>
>>  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/
>>>>
>

Mime
View raw message