Some questions

[Berin Lautenbach <be...@ozemail.com.au>]

OK all you experienced Apache developers.....

A couple of questions :

1.  Is there a formal release process for new "releases" of code inside 
Apache?

2.  Is there, for xml-security, a conformance suite of tests that should 
be run?  If not, should we set one up?  (I would say yes?)

3.  The GUMP process is, as I understand it, a Java based system for 
auto-building/testing code.  Is there anything equivalent for C/C++ code 
that anyone is aware of (might be one for general@xml.apache.org)?  The 
real value of GUMP is it auto tests changes to other libraries, and I'm 
already starting to run into interesting problems when changes happen to 
xerces/xalan.

4.  Is there any interest in creating a release signing process that 
creates an XML based .sig file as well as the standard PGP sig? 
 Probably a bit mickey mouse, but if we are creating libraries that do 
signatures it might be a nice way to show how they work?

Enough for one night.

Cheers,
    Berin

Re: Some questions

[Berin Lautenbach <be...@ozemail.com.au>]

For the C code things are a bit more problematic :<.

The code currently uses OpenSSL as the crypto implementation, but with 
an abstraction layer so that we can easily tie in other libraries.

 From memory, the Cryptix libraries are Java only (Perl?), so I'd 
probably need to look at something like GnuPG.

Not a trivial thing, but I think worth doing.

My thought would be that if all of us agree that signing the code should 
be done using PGP keys, then there is probably sound value in making 
sure that both implementations can support PGP based signing/validation.

I will do some research, but it won't happen for the 0.1 release that 
I've been trying to plan.

Cheers,
    Berin

Erwin van der Koogh wrote:

>>>That's shouldn't be too much of a problem, it's been a while since I was
>>>developing PGP code in Cryptix, but it shouldn't take too long to get
>>>back into it. Were you trying to use the OpenPGP one?
>>>      
>>>
>>I didn't even try it ;-( I only saw that the PGP code was deeply nested in 
>>Cryptix and I didn't invest more time on plying around with it.
>>    
>>
>
>Well the Cryptix 3.2 has PGP stuff deeply nested inside it, but it's only PGP 2.6 and not OpenPGP compatible. OpenPGP is fairly self contained, but never really got completely finished.
>
>I'll see what I can do if I have some free time to play around with it at some point :)
>
>Erwin
>
>  
>

Re: Some questions

[Erwin van der Koogh <er...@koogh.com>]

> > 4.  Is there any interest in creating a release signing process that
> > creates an XML based .sig file as well as the standard PGP sig?  Probably
> > a bit mickey mouse, but if we are creating libraries that do signatures
> > it might be a nice way to show how they work?
> 
> Definetively yes ;-)) "Eat your own cooking!" Sign releases using XML 
> Signature. The point is: To do that, I would like to use my PGP key for 
> creating these signatures, and I didn't play around with the cryptix stuff 
> to get my PGP key as DH or RSA key usable in Java...

That's shouldn't be too much of a problem, it's been a while since I was developing PGP code in Cryptix, but it shouldn't take too long to get back into it. Were you trying to use the OpenPGP one?

Erwin

Re: Some questions

[Berin Lautenbach <be...@ozemail.com.au>]

Christian Geuer-Pollmann wrote:

> GUMP starts the 'ant gump' target which compiles everything, makes the 
> full documentation and runs *ALL* unit tests (including interop) each 
> time.
>
Which makes me even more interested in a C version - that's *exactly* 
what I want to do.  I will wait with interest to see what Sam comes back 
with.

Cheers,
    Berin

Re: Some questions

[Christian Geuer-Pollmann <ge...@nue.et-inf.uni-siegen.de>]

--On Dienstag, 25. Februar 2003 20:22 +1100 Berin Lautenbach 
<be...@ozemail.com.au> wrote:
> Christian Geuer-Pollmann wrote:
>>
>> But now that we have multiple developers, we should have a process. Do
>> you have a good suggestion on that?
>
> A very good question.  Would anyone have any objections if I posted a
> query on general@xml to see whether there are some guidelines for other
> projects that we can easily re-use?

Of course no objection ;-))

>> Yes, there exists a conformance suite which is 'hidden' in the unit
>> tests. The XML-Signature interop tests are in
>> xml-security/src_unitTests/org/apache/xml/security/test/InteropTest.java
>> ,  the canonicalization stuff is in
>> xml-security/src_unitTests/org/apache/xml/security/test/c14n/implementat
>> ions/.
>
> I think I have already gone through all of these anyway (other than
> xpath-filter).
>
> Do you use the GUMP process to test validation of these, or is this a
> "by-hand" thing whenever you want to do a release?

GUMP starts the 'ant gump' target which compiles everything, makes the full 
documentation and runs *ALL* unit tests (including interop) each time.


Christian

Re: Some questions

[Berin Lautenbach <be...@ozemail.com.au>]

Dirk-Willem van Gulik wrote:

>Sofar we've not yet
>had a serious desire for such. But it is possible.
>
>Perhaps a good start would be a simple perl script on cvs.apache.org which
>'knows' about the 9 KEYS files and provides a single interface to them.
>
Worth doing?  If there is no serious desire then hard to justify. 
 However if there is a desire, then we can definitely have a good look 
at what can be done.  To start with it should be fairly simple - even if 
we just import everything to a common key-ring that all Apache 
committers can import.  I would have thought might be useful?

>
>But yes - given the rare-ness of x509 native signing tools for XML doc's
>you'd have to either use PGP -or- develop a tool chain (and the procedures
>to go with it) for this problem which would need to be accessible to all
>the ASF committers. Given the wide range of hardware they use (from PC to
>mainframe) for their releases - that is far from trivial.
>
Unfortunately whatever way we go, this same problem is going to rear 
it's ugly head.  The tools will need to interface to the security 
libraries, even if we use PGP, as we need to build the constructs and do 
the xml transformations to get a good signature.

So (at the risk of over-complicating things - this started out simple!) 
there are two ways we can go -

1.  We can develop a basic capability in xml-security around a simple 
xml document based on the W3C standard and PGP.  We can then make this 
available to the wider community and change it on the basis of 
desire/needs/wants.

2.  We can put the question to the broader (maybe XML to start with?) 
community to see what the desires might be and head down that track from 
the start.

Either way, I think it's a valuable exercise for the xml-security 
project.  If we can create something useful for the Apache project, then 
the likelyhood is it is useful for a broader audience.

Cheers,
    Berin

Re: Some questions

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Tue, 25 Feb 2003, Berin Lautenbach wrote:

> thing we would need to define was any additional fields we want in terms
> of licenses etc, then we put them in the document with the signature.

Aye - this was why I stress *VERY* simple :-)

> preference I think?  The beauty is that if it's done right, it should
> still be human readable.

Aye, human, pointy haired boss and laywer readable too.

> But you indirectly raise a very good point.  Would there be any broader
> interest in this in the Apache community?  If so, would the preference
> be similarly to stick with PGP/GPG as the key mechanism?

I would guess so.

> BTW - Is there any central Apache Keyring with cross-signed keys of
> developers?  I know the keys exist in the CVS, but it's harder to
> extract them from there.

No - each PMC generally has a KEYS file (pgp keys) which are resonably
cross signed. Someone could write an interface of apache committer keys
across it all.

Also note that the ASF has enough of a corperate infrastructure do do
more; i.e. have KEYS on (paper) file, connect them to people their paper
signatures on the contributors agreement and what not. Sofar we've not yet
had a serious desire for such. But it is possible.

Perhaps a good start would be a simple perl script on cvs.apache.org which
'knows' about the 9 KEYS files and provides a single interface to them.

But yes - given the rare-ness of x509 native signing tools for XML doc's
you'd have to either use PGP -or- develop a tool chain (and the procedures
to go with it) for this problem which would need to be accessible to all
the ASF committers. Given the wide range of hardware they use (from PC to
mainframe) for their releases - that is far from trivial.

Dw

Re: Some questions

[Berin Lautenbach <be...@ozemail.com.au>]

Dirk,

You've obviously heard about my cooking :>.

The XML-DSIG standard lays out exactly what the signature format would 
look like (including where the digest values would go etc.)  The only 
thing we would need to define was any additional fields we want in terms 
of licenses etc, then we put them in the document with the signature.

So I wasn't thinking of defining a new signature format just for signing 
files - given the main aim of the xml-security projects is to create 
implementations of the W3C signature standards, that would be the 
preference I think?  The beauty is that if it's done right, it should 
still be human readable.

But you indirectly raise a very good point.  Would there be any broader 
interest in this in the Apache community?  If so, would the preference 
be similarly to stick with PGP/GPG as the key mechanism?

BTW - Is there any central Apache Keyring with cross-signed keys of 
developers?  I know the keys exist in the CVS, but it's harder to 
extract them from there.

Cheers,
    Berin

Dirk-Willem van Gulik wrote:

>  
>
>>>>4.  Is there any interest in creating a release signing process that
>>>>creates an XML based .sig file as well as the standard PGP sig?
>>>>Probably
>>>>a bit mickey mouse, but if we are creating libraries that do signatures
>>>>it might be a nice way to show how they work?
>>>>        
>>>>
>>>Definetively yes ;-)) "Eat your own cooking!" Sign releases using XML
>>>Signature. The point is: To do that, I would like to use my PGP key
>>>for creating these signatures, and I didn't play around with the
>>>cryptix stuff to get my PGP key as DH or RSA key usable in Java...
>>>      
>>>
>
>If you are eating your own dog foot - how about thinking about a *very*
>simple dtd/schema for auxilary distribution files; along the lines of what
>Ted has been doing for automated dependency resultions. Ideally it would
>also list an MD5, a reference to a license, etc, etc. Readable by humans
>and by computers alike.
>
>Dw
>
>
>  
>

Re: Some questions

[Dirk-Willem van Gulik <di...@webweaving.org>]

> >> 4.  Is there any interest in creating a release signing process that
> >> creates an XML based .sig file as well as the standard PGP sig?
> >> Probably
> >> a bit mickey mouse, but if we are creating libraries that do signatures
> >> it might be a nice way to show how they work?
> >
> >
> > Definetively yes ;-)) "Eat your own cooking!" Sign releases using XML
> > Signature. The point is: To do that, I would like to use my PGP key
> > for creating these signatures, and I didn't play around with the
> > cryptix stuff to get my PGP key as DH or RSA key usable in Java...

If you are eating your own dog foot - how about thinking about a *very*
simple dtd/schema for auxilary distribution files; along the lines of what
Ted has been doing for automated dependency resultions. Ideally it would
also list an MD5, a reference to a license, etc, etc. Readable by humans
and by computers alike.

Dw

Re: Some questions

[Berin Lautenbach <be...@ozemail.com.au>]

More comments in line!

Cheers,
    Berin

Christian Geuer-Pollmann wrote:

>
> But now that we have multiple developers, we should have a process. Do 
> you have a good suggestion on that?

A very good question.  Would anyone have any objections if I posted a 
query on general@xml to see whether there are some guidelines for other 
projects that we can easily re-use?

> Yes, there exists a conformance suite which is 'hidden' in the unit 
> tests. The XML-Signature interop tests are in 
> xml-security/src_unitTests/org/apache/xml/security/test/InteropTest.java, 
> the canonicalization stuff is in 
> xml-security/src_unitTests/org/apache/xml/security/test/c14n/implementation 
>
> s/.

<snip>

I think I have already gone through all of these anyway (other than 
xpath-filter).

Do you use the GUMP process to test validation of these, or is this a 
"by-hand" thing whenever you want to do a release?

>
> I'm not sure about that. You should ask Sam Ruby <ru...@apache.org> 
> about that.

Have done - will wait and see.

>
>> 4.  Is there any interest in creating a release signing process that
>> creates an XML based .sig file as well as the standard PGP sig?  
>> Probably
>> a bit mickey mouse, but if we are creating libraries that do signatures
>> it might be a nice way to show how they work?
>
>
> Definetively yes ;-)) "Eat your own cooking!" Sign releases using XML 
> Signature. The point is: To do that, I would like to use my PGP key 
> for creating these signatures, and I didn't play around with the 
> cryptix stuff to get my PGP key as DH or RSA key usable in Java...


See later e-mail.

Cheers,
    Berin

Re: Some questions

[Christian Geuer-Pollmann <ge...@nue.et-inf.uni-siegen.de>]

Hi Berin,

comments inline...

Christian

--On Montag, 24. Februar 2003 22:29 +1100 Berin Lautenbach 
<be...@ozemail.com.au> wrote:

> 1.  Is there a formal release process for new "releases" of code inside
> Apache?

Since I was the only developer in the past, there was no formal schedule or 
release process. I simply packed a new version when I 'felt' that it was 
time to do so as CVS contained significant changes.

But now that we have multiple developers, we should have a process. Do you 
have a good suggestion on that?

> 2.  Is there, for xml-security, a conformance suite of tests that should
> be run?  If not, should we set one up?  (I would say yes?)

Yes, there exists a conformance suite which is 'hidden' in the unit tests. 
The XML-Signature interop tests are in 
xml-security/src_unitTests/org/apache/xml/security/test/InteropTest.java, 
the canonicalization stuff is in 
xml-security/src_unitTests/org/apache/xml/security/test/c14n/implementation
s/.

All these tests are evaluated against the test vectors in the directories

xml-security/data/interop/xfilter2/merlin-xpath-filter2-three/
xml-security/data/interop/c14n/Y1/
xml-security/data/interop/c14n/Y2/
xml-security/data/interop/c14n/Y3/
xml-security/data/interop/c14n/Y4/
xml-security/data/ie/baltimore/merlin-examples/
xml-security/data/at/iaik/ixsil/

> 3.  The GUMP process is, as I understand it, a Java based system for
> auto-building/testing code.  Is there anything equivalent for C/C++ code
> that anyone is aware of (might be one for general@xml.apache.org)?  The
> real value of GUMP is it auto tests changes to other libraries, and I'm
> already starting to run into interesting problems when changes happen to
> xerces/xalan.

I'm not sure about that. You should ask Sam Ruby <ru...@apache.org> about 
that.

> 4.  Is there any interest in creating a release signing process that
> creates an XML based .sig file as well as the standard PGP sig?  Probably
> a bit mickey mouse, but if we are creating libraries that do signatures
> it might be a nice way to show how they work?

Definetively yes ;-)) "Eat your own cooking!" Sign releases using XML 
Signature. The point is: To do that, I would like to use my PGP key for 
creating these signatures, and I didn't play around with the cryptix stuff 
to get my PGP key as DH or RSA key usable in Java...

Kind regards,
Christian