jsdsi-devel Mailing List for JSDSI (Page 3)

Status: Pre-Alpha

Brought to you by: sajma

jsdsi-devel — JSDSI Developers

You can subscribe to this list here.

2003	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug (4)	_Sep	_Oct	_Nov	_Dec
2004	_Jan	_Feb (45)	_Mar (60)	_Apr (12)	_May (18)	_Jun (14)	_Jul (8)	_Aug (10)	_Sep	_Oct (12)	_Nov (16)	_Dec (15)
2005	_Jan	_Feb (2)	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov (2)	_Dec

Flat | Threaded

<< < 1 2 3 4 5 .. 9 > >> (Page 3 of 9)

Re: [Jsdsi-devel] Re: Sexp threading issue?

From: Sean R. <sra...@ae...> - 2004-08-24 12:57:26

Sean Radford wrote:

> Definately looking like a threading issue to me. I have a junit test 
> that creates 100 certificates and stores them as a List of byte 
> arrays. I then have a number of Threads that iterate through the list 
> and I intermittently get stack traces like the following (the input 
> string varies):
>
>
> java.lang.RuntimeException: Error generating certificate from byte array
>    at 
> jsdsi.sexp.CertificateParsingThreadTest$Runner.run(CertificateParsingThreadTest.java:135) 
>
> Caused by: java.lang.NumberFormatException: For input string: 
> "20042004200420042004"
>    at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) 
>
>    at java.lang.Long.parseLong(Long.java:406)
>    at java.lang.Long.parseLong(Long.java:452)
>    at java.text.DigitList.getLong(DigitList.java:149)
>    at java.text.DecimalFormat.parse(DecimalFormat.java:1068)
>    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1388)
>    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1156)
>    at java.text.DateFormat.parse(DateFormat.java:333)
>    at jsdsi.sexp.SexpUtil.parseDate(SexpUtil.java:104)
>    at jsdsi.Validity.parseValidity(Validity.java:254)
>    at jsdsi.Cert.parseCert(Cert.java:240)
>    at jsdsi.Element$Default.parseElement(Element.java:37)
>    at jsdsi.Sequence.parseSequence(Sequence.java:108)
>    at jsdsi.Obj.parseObj(Obj.java:206)
>    at jsdsi.Obj.parseObj(Obj.java:191)
>    at jsdsi.sexp.ObjInputStream.readObj(ObjInputStream.java:52)
>    at 
> jsdsi.sexp.CertificateParsingThreadTest$Runner.generateCertificate(CertificateParsingThreadTest.java:154) 
>
>    at 
> jsdsi.sexp.CertificateParsingThreadTest$Runner.run(CertificateParsingThreadTest.java:133) 
>
>
>
> Sean
>
Found the problem - will get the fix into CVS in an hour or so.

:-)


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/

[Jsdsi-devel] Re: Sexp threading issue?

From: Sean R. <sra...@ae...> - 2004-08-24 12:00:00

Definately looking like a threading issue to me. I have a junit test 
that creates 100 certificates and stores them as a List of byte arrays. 
I then have a number of Threads that iterate through the list and I 
intermittently get stack traces like the following (the input string 
varies):


java.lang.RuntimeException: Error generating certificate from byte array
    at 
jsdsi.sexp.CertificateParsingThreadTest$Runner.run(CertificateParsingThreadTest.java:135)
Caused by: java.lang.NumberFormatException: For input string: 
"20042004200420042004"
    at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Long.parseLong(Long.java:406)
    at java.lang.Long.parseLong(Long.java:452)
    at java.text.DigitList.getLong(DigitList.java:149)
    at java.text.DecimalFormat.parse(DecimalFormat.java:1068)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1388)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1156)
    at java.text.DateFormat.parse(DateFormat.java:333)
    at jsdsi.sexp.SexpUtil.parseDate(SexpUtil.java:104)
    at jsdsi.Validity.parseValidity(Validity.java:254)
    at jsdsi.Cert.parseCert(Cert.java:240)
    at jsdsi.Element$Default.parseElement(Element.java:37)
    at jsdsi.Sequence.parseSequence(Sequence.java:108)
    at jsdsi.Obj.parseObj(Obj.java:206)
    at jsdsi.Obj.parseObj(Obj.java:191)
    at jsdsi.sexp.ObjInputStream.readObj(ObjInputStream.java:52)
    at 
jsdsi.sexp.CertificateParsingThreadTest$Runner.generateCertificate(CertificateParsingThreadTest.java:154)
    at 
jsdsi.sexp.CertificateParsingThreadTest$Runner.run(CertificateParsingThreadTest.java:133)


Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/

[Jsdsi-devel] Sexp threading issue?

From: Sean R. <sra...@ae...> - 2004-08-24 10:16:04

Guys,

Need some help here...

I have an application that works a dream when one user is using it, but 
as soon as two are I repeatedly get the stack trace below.

Caused by: java.lang.NumberFormatException: For input string: ""
        at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
        at java.lang.Long.parseLong(Long.java:415)
        at java.lang.Long.parseLong(Long.java:452)
        at java.text.DigitList.getLong(DigitList.java:149)
        at java.text.DecimalFormat.parse(DecimalFormat.java:1068)
        at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1705)
        at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1156)
        at java.text.DateFormat.parse(DateFormat.java:333)
        at jsdsi.sexp.SexpUtil.parseDate(SexpUtil.java:104)
        at jsdsi.Validity.parseValidity(Validity.java:253)
        at jsdsi.Cert.parseCert(Cert.java:240)
        at jsdsi.Element$Default.parseElement(Element.java:37)
        at jsdsi.Sequence.parseSequence(Sequence.java:107)
        at jsdsi.Obj.parseObj(Obj.java:206)
        at jsdsi.Obj.parseObj(Obj.java:191)
        at jsdsi.sexp.ObjInputStream.readObj(ObjInputStream.java:52)
        at jsdsi.sexp.CertificateFactory.readObj(CertificateFactory.java:43)
        at 
jsdsi.sexp.CertificateFactory.readCertificate(CertificateFactory.java:48)
        at 
jsdsi.sexp.CertificateFactory.engineGenerateCertificate(CertificateFactory.java:59)
        ... 228 more

Here's some extra logging info to help show the certificate that it is 
trying to parse:

2004-08-24 10:47:49,109 ERROR [com.aegeus.spki.store.CertificateDAO] 
***** Original byte[] as a java.lang.String *****
2004-08-24 10:47:49,110 ERROR [com.aegeus.spki.store.CertificateDAO] 
(8:sequence(4:cert(7:display10:text/plain)(6:issuer(4:name(10:public-key(3:rsa(1:e3:^A^@^A)(1:n65:^@ÆÊ©4¬qC
IÄ)G^VW¬òY^TÉk%Y* XqRûÚw
tsÿÿÖ¶/C^\Äm^@^QB6<Ðz5àu5A:èI))(3:uri27:http://secure.aegeus.co.uk/))13:clairerussell))(7:subject(10:public-key(3:rsa(1:e3:^A^@^A)(1:n65:^@´ 
D^XO¡^Zù|¸F7X£A%j^Z^Lòz^?TÏ¯
ûOrn^XºS0z^ðz¬0aG}þ^W{-ð¹^EÝd1ùÄà^U))(3:uri27:http://secure.aegeus.co.uk/)))(5:valid(10:not-before19:2004-08-17_15:34:56)(9:not-after19:2014-08-17_15:34:56))(7:comment24:Shared
Workspace 
NameCert))(9:signature(4:hash3:md516:^@·^R]^\^Zñ^KÓ:^Zë)(10:public-key(3:rsa(1:e3:^A^@^A)(1:n65:^@ÆÊ©4¬qCIÄ)G^VW¬òY^TÉk%Y* XqRûÚw 

tsÿÿÖ¶/C^\Äm^@^QB6<Ðz5àu5A:èI))(3:uri27:http://secure.aegeus.co.uk/))(13:rsa-pkcs1-md564:¶:¤^_©WÜ6sÖåô¸¶¨c2     
D^P"xéB°)]Óù&á¾W1yÙmæîÛ^Ookõ^XØ^RÉsíT)))
2004-08-24 10:47:49,111 ERROR [com.aegeus.spki.store.CertificateDAO] 
**********

The certificate(s) are fine and as said all works well for one 
user/thread, but consistenly breaks with 2 or more...

I guess it is a multi-threading issue with Sexpression parsing. Has 
anyone seen such a thing before? And as I'm about to try to write a unit 
test to duplicate the error (and then hopefully fix it), does anyone 
have any ideas on its cause?

Regards,

Sean


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/

[Jsdsi-devel] Re: [Fwd: Branch-algo]

From: Sean R. <sra...@ae...> - 2004-08-13 13:47:10

Sameer Ajmani wrote:

>Sameer Ajmani wrote:
>
>  Can you tell me how to check out that branch?  I'll be out of town
>next week, but I'll check it out when I get the chance.
>
>Sameer
>
>  
>
Sorry, but looks like I didn't get round to answering this one...

Take a look at:

https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_5.html#SEC57

(the branch is called 'branch-algo')

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/

[Jsdsi-devel] Re: Fwd: [Jsdsi-users] KeyStore

From: Sean R. <sra...@ae...> - 2004-08-13 07:53:04

Sameer Ajmani wrote:

>
>Developers: could one of you add a *** big *** warning on Loader that
>it's just for testing purposes?  Thanks!
>
>Sameer
>  
>
Done

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/

[Jsdsi-devel] Re: [Jsdsi-users] KeyStore

From: Sameer A. <aj...@gm...> - 2004-08-11 12:15:31

Dav,

My guess is that the KeyStore is attempting to unmarshal the public
key and can't find the code to do it.  Make sure the JSDSI Provider is
loaded when you load from the KeyStore.  If that doesn't fix it, you
might look through the KeyStore docs to determine hwo to register new
key types with it.  Its possible we need to provide a new class to
make this work.

Sameer

On Tue, 10 Aug 2004 21:59:38 -0700, Dav Coleman <dav...@gm...> wrote:
> Hi,
> 
> I'm trying to save a Private Key and Certificate to a KeyStore and
> then load it back. I'm able to create the keystore on the file system
> without throwing any exceptions, but when I try to load it I get
> 
> java.security.cert.CertificateException: SPKI not found
>         at java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:191)
>         at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:670)
>         at java.security.KeyStore.load(KeyStore.java:652)
>         at com.s0ciety.demo.CLI.loadKeyStore(CLI.java:129)
> 
> Any ideas on what would cause that?
> 
> Here is the (I hope) relevant code snippets
> 
> create and save keystore:
> 
>      pair = jsdsi.RSAPublicKey.create();
>      java.security.PrivateKey privKey = pair.getPrivate();
>      java.security.PublicKey pubKey = pair.getPublic();
> 
>       jsdsi.RSAPublicKey jsdsiPubKey = (jsdsi.RSAPublicKey)pair.getPublic();
>      Date expire = new Date(now.getTime() + (86400 * 30));
>      jsdsi.Validity validity = new jsdsi.Validity(now, expire);
>      jsdsi.Cert cert = new jsdsi.NameCert(jsdsiPubKey, jsdsiPubKey,
> validity, "display hint", "blah... comment field", "my jsdsi pubkey");
>       jsdsi.Hash hash = new jsdsi.Hash("MD5", cert.toByteArray());
>       jsdsi.Signature signature = null;
>       jsdsi.Principal principal = (jsdsi.Principal) pair.getPublic();
>       signature = jsdsi.Signature.create(pair, cert, "MD5withRSA");
>       jsdsi.Certificate certificate = new jsdsi.Certificate(cert, signature);
>       jsdsi.Certificate[] certificate_chain = new jsdsi.Certificate[]
> { certificate };
>       // Create an empty keystore object
>       keystore = KeyStore.getInstance(KeyStore.getDefaultType());
>       keystore.load(null, password.toCharArray());  // null input
> stream to create empty keystore
>       keystore.setKeyEntry("myalias", privKey, password.toCharArray(),
> certificate_chain);
>       // Save the new keystore contents
>       FileOutputStream out = new FileOutputStream(keystoreFile);
>       keystore.store(out, password.toCharArray());
>       out.close();
> 
> load keystore:
> 
>       FileInputStream fis = new FileInputStream(file);
>       keystore = KeyStore.getInstance(KeyStore.getDefaultType());
>       keystore.load(fis, password.toCharArray());
>       fis.close();
>       System.out.println("- keystore loaded");
>       System.out.println("- contains "+keyStore.size()+" entries");
> 
> Are there any code examples available for integrating JSDSI into an
> application? I've read a lot of docs and published papers online and I
> think I have a basic understanding of SPKI/SDSI capabilities, but I'm
> completely new to PKI application development so I feel a little lost.
> 
> --
> Dav Coleman
> http://AkuAku.org/
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Jsdsi-users mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> 
> 


-- 
Sameer Ajmani
http://ajmani.net

[Jsdsi-devel] Re: Jsdsi team

From: Sean R. <sra...@ae...> - 2004-08-04 10:16:46

Luis Pedro wrote:

> Sean,
>  
> I've seen the new page and it looks great. Tell me something, on the 
> "Team" how can i change the "Organization" and "Time"?
>
>              -- Luís Pedro
>
>
> _____________________ 
>
Those are specified in project.xml

The timezone thingy is very odd. Based on Australian (Brisbane) time I 
think!!

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/

[Jsdsi-devel] Bug fix

From: Sean R. <sra...@ae...> - 2004-07-31 15:31:10

Guys,

Fixed a bug in Hash.hashCode() that was causing problems with 2 
Signature instances that equaled each other not to have the same hashCode().

Also done a maven site:deploy. As I have the final 1.0 of Maven the 
default stylesheet has changed, which means that the JSDSI site has 
different colours. Hope no one objects (in fact I think it looks better).

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/

Re: [Jsdsi-devel] Obj and clone

From: Sean R. <sra...@ae...> - 2004-07-10 18:17:37

ok. I just need to return a copy of Principal (PublicKey/PublicKeyHash) 
within the Hibernate framework. I can do the copy manually within my 
stuff for now - though maybe I could write a 'service class' within 
jsdsi.util that'll take an Obj and return a copy of it.

Sean

Sameer Ajmani wrote:

>Not unless there's a very good reason to do so.  Inheriting clone() is
>dangerous (returns a supertype where a subtype is expected), and so
>should be avoided.  If a duplication method is needed, we can do it on
>a per-class basis.
>
>Sameer
>
>On Fri, 09 Jul 2004 23:21:29 +0100, Sean Radford
><sra...@ae...> wrote:
>  
>
>>Hi,
>>
>>Just a thought... Should jsdsi.Obj be cloneable?
>>
>>Regards,
>>
>>Sean
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by Black Hat Briefings & Training.
>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>>digital self defense, top technical experts, no vendor pitches,
>>unmatched networking opportunities. Visit www.blackhat.com
>>_______________________________________________
>>Jsdsi-devel mailing list
>>Jsd...@li...
>>https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Jsdsi-devel mailing list
>Jsd...@li...
>https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>
>  
>

Re: [Jsdsi-devel] Obj and clone

From: Sameer A. <aj...@gm...> - 2004-07-09 22:53:53

Not unless there's a very good reason to do so.  Inheriting clone() is
dangerous (returns a supertype where a subtype is expected), and so
should be avoided.  If a duplication method is needed, we can do it on
a per-class basis.

Sameer

On Fri, 09 Jul 2004 23:21:29 +0100, Sean Radford
<sra...@ae...> wrote:
> Hi,
> 
> Just a thought... Should jsdsi.Obj be cloneable?
> 
> Regards,
> 
> Sean
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
>

[Jsdsi-devel] Obj and clone

From: Sean R. <sra...@ae...> - 2004-07-09 22:24:03

Hi,

Just a thought... Should jsdsi.Obj be cloneable?

Regards,

Sean

RE: [Jsdsi-devel] branch-algo

From: Sean R. <sra...@ae...> - 2004-07-08 13:34:08

On Thu, 2004-07-08 at 13:32, Luis Pedro wrote:
> Sean,
>=20
> I've already toke a very quick look. I've to see it better, but it look=
s
> very good, i haven't tested. For what i've seen, now there is no proble=
m
> using jdk or sdsi algorithms.
>=20
cool

> Today or tomorrow i will look it better.
excellent

>  Today afternoon i've a major
> reunion and i had not the time. I've to defend my changes...i'm using r=
mi
> and made webservices using rmi...but here we have to explain all, even =
if
> the person who demands that don't know a thing about developing......
>=20
Good luck

>              -- Lu=EDs Pedro
>=20
>=20
> _____________________
> yahoo: lpv_pt
>    msn: lp...@ne...
>=20
> =20
>=20
> =BB     -----Original Message-----
> =BB     From: jsd...@li...=20
> =BB     [mailto:jsd...@li...] On=20
> =BB     Behalf Of Sean Radford
> =BB     Sent: quinta-feira, 8 de Julho de 2004 13:02
> =BB     To: devel jsdsi
> =BB     Subject: [Jsdsi-devel] branch-algo
> =BB    =20
> =BB     Luis,
> =BB    =20
> =BB     You were in the process of looking at the algo branch,=20
> =BB     and just wondered
> =BB     if you managed to have a good look or not?
> =BB    =20
> =BB     Regards,
> =BB    =20
> =BB     Sean
> =BB    =20
> =BB     --=20
> =BB     Dr. Sean Radford, MBBS, MSc
> =BB     sra...@ae...
> =BB     http://www.aegeus-technology.com
> =BB    =20
> =BB    =20
> =BB    =20
> =BB     -------------------------------------------------------
> =BB     This SF.Net email sponsored by Black Hat Briefings & Training.
> =BB     Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> =BB     digital self defense, top technical experts, no vendor pitches,=
=20
> =BB     unmatched networking opportunities. Visit www.blackhat.com
> =BB     _______________________________________________
> =BB     Jsdsi-devel mailing list
> =BB     Jsd...@li...
> =BB     https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
--=20
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] branch-algo

From: Sean R. <sra...@ae...> - 2004-07-08 12:05:12

Luis,

You were in the process of looking at the algo branch, and just wondered
if you managed to have a good look or not?

Regards,

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] Re: Javadoc

From: Sean R. <sra...@ae...> - 2004-07-04 11:33:30

Yes, our maven build looks for @todo to generate its Task List:

http://jsdsi.sourceforge.net/task-list.html

Sean

On Sat, 2004-07-03 at 19:28, Luis Pedro wrote:
> Hi Sean,
> 
> I was wondering. Have u some javadoc taglets, like @todo
> 
> 	-- Luis Pedro
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] Re: Javadoc

From: Sean R. <sra...@ae...> - 2004-07-01 23:16:41

>From your CVS tree you can use Maven:

maven javadoc


This creates it under the directory 'target/docs/apidocs' if memory
serves me correctly.


Sean

On Thu, 2004-07-01 at 17:07, Luis Pedro wrote:
> Hi Sean,
> 
> What tool u use to create the javadoc documentation?
> 
> 	Thanks,
> 
> 		-- Luis Pedro
> 
> ----------------------------------------------------------------------------
> -
> PORTUGAL na final do euro 2004
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] someone else wants to help

From: Sameer A. <aj...@gm...> - 2004-06-28 15:11:53

JSDSI developers,

Yet another person is interested in contributing to the project (see
below).  But since we don't really need additional developers right
now, I'm not adding him to the project (yet).  He sounds like he's
mainly looking for experience with working on this kind of project. 
If you can think of a nice (isolated) sub-project for him to work on
and are willing to mentor him on it, let me know and I'll add him to
the project.

Sameer

--------------------------------
     am open to work on security related modules, and am not
completly clear about your vision for long time about the same
project.  Can u kindly explain for the same, if u have any
prepared documents (highlevel or lowlevel architecture) for the
project kindly mail me.

   Expecting your reply

Satish
hcs...@re...

[Jsdsi-devel] JSDSI CVS branch: branch-algo

From: Sean R. <sra...@ae...> - 2004-06-24 23:50:21

Guys,

I've got a cvs branch running called 'branch-algo' which implements
Digest and Signature algorythms using an Enum class approach to
circumvent the problems of just using String names.

All the existing functionality should work as per the HEAD and I would
be very interested for your views of the design and ideally feedback on
any problems on using it.

Regards,

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Logging framework

From: Sean R. <sra...@ae...> - 2004-06-10 14:32:40

On Thu, 2004-06-10 at 15:14, Sameer Ajmani wrote:
> Logging is always a good idea.  In JSDSI, it would be very helpful to have
> logging in the prover and verifier.
> 
> If most applications use log4j, why do you suggest apache commons-logging?
>  Are they compatible? (they're both Apache team products, right?)  Or do
> you mean we can just plug log4j into commons-logging, and other users can
> plug alternative logging frameworks into it?
That's exactly it. commons-logging is an abstraction layer for logging
that uses log4j, JDK logging, it's own simple logger, a dummy logger or
whatever framework you care to connect it to.

Sean

> 
> Sameer
> 
> > Here's a question that I've been meaning to ask.
> >
> > How do people feel about logging frameworks?
> >
> > I myself think logging is a good idea as it is a great tool to track
> > down problems in live systems. So I would like to ask how people feel to
> > adding the apache commons-logging to jsdsi. The reason to go for that
> > rather than straight for either log4j or java.util.logging is that it is
> > an abstraction to other logging frameworks so the target environment can
> > be using whatever it choses (or nothing).
> >
> > An example: most (all) J2EE application containers use log4j... If jsdsi
> > uses JDK logging then ALL the messages appear at the ERROR level or are
> > discarded completely!
> >
> > I think logging is becoming more and more needed in JSDSI, especially as
> > it will become more complicated with more functionality in the future.
> >
> > Regards,
> >
> > Sean
> >
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: GNOME Foundation
> > Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> > GNOME Users and Developers European Conference, 28-30th June in Norway
> > http://2004/guadec.org
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Logging framework

From: Sameer A. <aj...@cs...> - 2004-06-10 14:14:10

Logging is always a good idea.  In JSDSI, it would be very helpful to have
logging in the prover and verifier.

If most applications use log4j, why do you suggest apache commons-logging?
 Are they compatible? (they're both Apache team products, right?)  Or do
you mean we can just plug log4j into commons-logging, and other users can
plug alternative logging frameworks into it?

Sameer

> Here's a question that I've been meaning to ask.
>
> How do people feel about logging frameworks?
>
> I myself think logging is a good idea as it is a great tool to track
> down problems in live systems. So I would like to ask how people feel to
> adding the apache commons-logging to jsdsi. The reason to go for that
> rather than straight for either log4j or java.util.logging is that it is
> an abstraction to other logging frameworks so the target environment can
> be using whatever it choses (or nothing).
>
> An example: most (all) J2EE application containers use log4j... If jsdsi
> uses JDK logging then ALL the messages appear at the ERROR level or are
> discarded completely!
>
> I think logging is becoming more and more needed in JSDSI, especially as
> it will become more complicated with more functionality in the future.
>
> Regards,
>
> Sean
>
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

[Jsdsi-devel] Logging framework

From: Sean R. <sra...@ae...> - 2004-06-10 09:11:53

Here's a question that I've been meaning to ask.

How do people feel about logging frameworks?

I myself think logging is a good idea as it is a great tool to track
down problems in live systems. So I would like to ask how people feel to
adding the apache commons-logging to jsdsi. The reason to go for that
rather than straight for either log4j or java.util.logging is that it is
an abstraction to other logging frameworks so the target environment can
be using whatever it choses (or nothing).

An example: most (all) J2EE application containers use log4j... If jsdsi
uses JDK logging then ALL the messages appear at the ERROR level or are
discarded completely!

I think logging is becoming more and more needed in JSDSI, especially as
it will become more complicated with more functionality in the future.

Regards,

Sean


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

From: Sameer A. <aj...@cs...> - 2004-06-09 16:59:03

Feel free to send questions -- I like to at least read about what's going
on, even if I can't contribute right now :)

Sameer

> On Wed, 2004-06-09 at 17:04, Sameer Ajmani wrote:
>> I'm not familiar with cvs branches, but if this is a good solution for
>> you, go for it.  I won't have a chance to look at JSDSI for about two
>> months (dissertation crunch)!  However, if your algorithm change is
>> compatible with older versions (won't break existing code), then
>> there's probably no harm in checking it in.
>>
> It better not break old code or existing stored objects as I have apps
> running now with the current stuff.
>
> Will probably create a branch to be on the safe-side though.
>
>
> Good luck with the dissertation - I'll try not to bother you with
> questions.
>
> Sean
>
>> Sameer
>>
>> > Hi,
>> >
>> > Don't suppose any of you have had a chance to look my classes - I'm
>> going to need to cope with varying algos in the very very near
>> future so would like to take a crack at it.
>> >
>> > (If no one has had a chance, how do you all feel about me making a
>> cvs branch?)
>> >
>> > Sean
>> >
>> > On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
>> >> Been thinking and I believe that the Enum way of going is a good
>> idea and so converted the util classes to them.
>> >>
>> >> So in CVS there is my proposal of how to do things. Let me know
>> what you think.
>> >>
>> >> Sean
>> >>
>> >>
>> >> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
>> >> > I guess we could change Algorithms from using straight Strings
>> for
>> >> the constants to an Enum class style for type-safety.
>> >> >
>> >> > Something akin to:
>> >> >
>> >> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>> >> >
>> >> >
>> >> > Sean
>> >> >
>> >> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
>> >> > > Guys,
>> >> > >
>> >> > > I've committed to cvs 3 classes in jsdsi.util for handling of
>> >> algorythm names:
>> >> > >
>> >> > > Algorithms
>> >> > > DigestUtils
>> >> > > SignatureUtils
>> >> > >
>> >> > >
>> >> > >  - not implemented any of them yet as want input/comments
>> first.
>> >> > >
>> >> > > The idea being that in Algorithms there is a list of constants
>> >> which clients use to indicate what they desire, e.g. DIGEST_MD5,
>> KEY_RSA, etc. There are then utility methods to calculate the SPKI
>> or JDK versions of such (This includes the problematic
>> >> Signatures).
>> >> > >
>> >> > > I would suggest the following coding ethos is JSDSI:
>> >> > >
>> >> > > 1. jsdsi object constructors that need algorythm names use SPKI
>> >> format names (this is what they should use now as that is the
>> format dumped to Sexpression, and consequently read from a stream)
>> >> > >
>> >> > > Not so sure about Hash.. has anyone looked at an Sexpression
>> for
>> >> hash and know that if you supply MD5 it comes out (incorrectly) in
>> upper case in the Sexpression? I guess the current implementation
>> would cause a problem with SHA-1? (as in SPKI that should be
>> >> sha1).
>> >> > >
>> >> > > Which then begs the question: should Hash.getAlgorithm() return
>> >> the SPKI or JDK version (I guess JDK to be consistent with Key and
>> Signature)?
>> >> > >
>> >> > >
>> >> > >
>> >> > > 2. static create methods use the constants for easy client use.
>> >> > >
>> >> > > The question I have for this is about jsdsi.Signature. Should
>> the
>> >> create methods take a digest constant and from that calculate the
>> JDK Signature algorythm and corresponding SPKI algorythm using the
>> provided constant and by examining the given keypair?
>> >> > >
>> >> > >
>> >> > >
>> >> > > Thoughts? (in particular problems this approach would lead to
>> with
>> >> existing applications)
>> >> > >
>> >> > >
>> >> > > Sean
>> >> > >
>> >> > >
>> > --
>> > Dr. Sean Radford, MBBS, MSc
>> > sra...@ae...
>> > http://www.aegeus-technology.com
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > This SF.Net email is sponsored by: GNOME Foundation
>> > Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
>> GNOME Users and Developers European Conference, 28-30th June in
>> Norway http://2004/guadec.org
>> > _______________________________________________
>> > Jsdsi-devel mailing list
>> > Jsd...@li...
>> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>>
>>
>> http://ajmani.net
>>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com


http://ajmani.net

Re: [Jsdsi-devel] Algorythm names

From: Sean R. <sra...@ae...> - 2004-06-09 16:24:29

On Wed, 2004-06-09 at 17:04, Sameer Ajmani wrote:
> I'm not familiar with cvs branches, but if this is a good solution for
> you, go for it.  I won't have a chance to look at JSDSI for about two
> months (dissertation crunch)!  However, if your algorithm change is
> compatible with older versions (won't break existing code), then there's
> probably no harm in checking it in.
> 
It better not break old code or existing stored objects as I have apps
running now with the current stuff.

Will probably create a branch to be on the safe-side though.


Good luck with the dissertation - I'll try not to bother you with
questions.

Sean

> Sameer
> 
> > Hi,
> >
> > Don't suppose any of you have had a chance to look my classes - I'm
> > going to need to cope with varying algos in the very very near future so
> > would like to take a crack at it.
> >
> > (If no one has had a chance, how do you all feel about me making a cvs
> > branch?)
> >
> > Sean
> >
> > On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
> >> Been thinking and I believe that the Enum way of going is a good idea
> >> and so converted the util classes to them.
> >>
> >> So in CVS there is my proposal of how to do things. Let me know what
> >> you think.
> >>
> >> Sean
> >>
> >>
> >> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
> >> > I guess we could change Algorithms from using straight Strings for
> >> the constants to an Enum class style for type-safety.
> >> >
> >> > Something akin to:
> >> >
> >> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
> >> >
> >> >
> >> > Sean
> >> >
> >> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> >> > > Guys,
> >> > >
> >> > > I've committed to cvs 3 classes in jsdsi.util for handling of
> >> algorythm names:
> >> > >
> >> > > Algorithms
> >> > > DigestUtils
> >> > > SignatureUtils
> >> > >
> >> > >
> >> > >  - not implemented any of them yet as want input/comments first.
> >> > >
> >> > > The idea being that in Algorithms there is a list of constants
> >> which clients use to indicate what they desire, e.g. DIGEST_MD5,
> >> KEY_RSA, etc. There are then utility methods to calculate the SPKI
> >> or JDK versions of such (This includes the problematic
> >> Signatures).
> >> > >
> >> > > I would suggest the following coding ethos is JSDSI:
> >> > >
> >> > > 1. jsdsi object constructors that need algorythm names use SPKI
> >> format names (this is what they should use now as that is the
> >> format dumped to Sexpression, and consequently read from a stream)
> >> > >
> >> > > Not so sure about Hash.. has anyone looked at an Sexpression for
> >> hash and know that if you supply MD5 it comes out (incorrectly) in
> >> upper case in the Sexpression? I guess the current implementation
> >> would cause a problem with SHA-1? (as in SPKI that should be
> >> sha1).
> >> > >
> >> > > Which then begs the question: should Hash.getAlgorithm() return
> >> the SPKI or JDK version (I guess JDK to be consistent with Key and
> >> Signature)?
> >> > >
> >> > >
> >> > >
> >> > > 2. static create methods use the constants for easy client use.
> >> > >
> >> > > The question I have for this is about jsdsi.Signature. Should the
> >> create methods take a digest constant and from that calculate the
> >> JDK Signature algorythm and corresponding SPKI algorythm using the
> >> provided constant and by examining the given keypair?
> >> > >
> >> > >
> >> > >
> >> > > Thoughts? (in particular problems this approach would lead to with
> >> existing applications)
> >> > >
> >> > >
> >> > > Sean
> >> > >
> >> > >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: GNOME Foundation
> > Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> > GNOME Users and Developers European Conference, 28-30th June in Norway
> > http://2004/guadec.org
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] SerialVersionId

From: Sean R. <sra...@ae...> - 2004-06-09 16:20:34

Well as we are using SExpressions for the serialisation the class UID
actually has no real effect on whether a class is compatible as it is
purely up to the Sexp parser/unparser to cope and has no bearing on
whether the class method/field signatures have changed.

(P.S. I do have a maven script to generate a file listing all the
current UID's - currently it would be a hand-job to then edit the java
source files)

Sean

On Wed, 2004-06-09 at 17:03, Sameer Ajmani wrote:
> The problem with this is if the classes change in an incompatible way, the
> coder needs to remember to change the serialVersionUID or else there could
> be strange runtime failures.  The purpose of UIDs is to detect when these
> changes occur automatically (and throw an exception when incompatible
> deserialization happens), so I hesitate to change this.  Perhaps there's a
> way to pre-process the code for your purposes (using a script, e.g.) so
> that you can speed things up without changing the JSDSI mainline?
> 
> Sameer
> 
> > Any objections to me placing serialVersionUID's on the Serializable
> > classes to speed things up (and help class compatibility)?
> >
> > Sean
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: GNOME Foundation
> > Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> > GNOME Users and Developers European Conference, 28-30th June in Norway
> > http://2004/guadec.org
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

From: Sameer A. <aj...@cs...> - 2004-06-09 16:04:59

I'm not familiar with cvs branches, but if this is a good solution for
you, go for it.  I won't have a chance to look at JSDSI for about two
months (dissertation crunch)!  However, if your algorithm change is
compatible with older versions (won't break existing code), then there's
probably no harm in checking it in.

Sameer

> Hi,
>
> Don't suppose any of you have had a chance to look my classes - I'm
> going to need to cope with varying algos in the very very near future so
> would like to take a crack at it.
>
> (If no one has had a chance, how do you all feel about me making a cvs
> branch?)
>
> Sean
>
> On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
>> Been thinking and I believe that the Enum way of going is a good idea
>> and so converted the util classes to them.
>>
>> So in CVS there is my proposal of how to do things. Let me know what
>> you think.
>>
>> Sean
>>
>>
>> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
>> > I guess we could change Algorithms from using straight Strings for
>> the constants to an Enum class style for type-safety.
>> >
>> > Something akin to:
>> >
>> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>> >
>> >
>> > Sean
>> >
>> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
>> > > Guys,
>> > >
>> > > I've committed to cvs 3 classes in jsdsi.util for handling of
>> algorythm names:
>> > >
>> > > Algorithms
>> > > DigestUtils
>> > > SignatureUtils
>> > >
>> > >
>> > >  - not implemented any of them yet as want input/comments first.
>> > >
>> > > The idea being that in Algorithms there is a list of constants
>> which clients use to indicate what they desire, e.g. DIGEST_MD5,
>> KEY_RSA, etc. There are then utility methods to calculate the SPKI
>> or JDK versions of such (This includes the problematic
>> Signatures).
>> > >
>> > > I would suggest the following coding ethos is JSDSI:
>> > >
>> > > 1. jsdsi object constructors that need algorythm names use SPKI
>> format names (this is what they should use now as that is the
>> format dumped to Sexpression, and consequently read from a stream)
>> > >
>> > > Not so sure about Hash.. has anyone looked at an Sexpression for
>> hash and know that if you supply MD5 it comes out (incorrectly) in
>> upper case in the Sexpression? I guess the current implementation
>> would cause a problem with SHA-1? (as in SPKI that should be
>> sha1).
>> > >
>> > > Which then begs the question: should Hash.getAlgorithm() return
>> the SPKI or JDK version (I guess JDK to be consistent with Key and
>> Signature)?
>> > >
>> > >
>> > >
>> > > 2. static create methods use the constants for easy client use.
>> > >
>> > > The question I have for this is about jsdsi.Signature. Should the
>> create methods take a digest constant and from that calculate the
>> JDK Signature algorythm and corresponding SPKI algorythm using the
>> provided constant and by examining the given keypair?
>> > >
>> > >
>> > >
>> > > Thoughts? (in particular problems this approach would lead to with
>> existing applications)
>> > >
>> > >
>> > > Sean
>> > >
>> > >
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

Re: [Jsdsi-devel] SerialVersionId

From: Sameer A. <aj...@cs...> - 2004-06-09 16:03:13

The problem with this is if the classes change in an incompatible way, the
coder needs to remember to change the serialVersionUID or else there could
be strange runtime failures.  The purpose of UIDs is to detect when these
changes occur automatically (and throw an exception when incompatible
deserialization happens), so I hesitate to change this.  Perhaps there's a
way to pre-process the code for your purposes (using a script, e.g.) so
that you can speed things up without changing the JSDSI mainline?

Sameer

> Any objections to me placing serialVersionUID's on the Serializable
> classes to speed things up (and help class compatibility)?
>
> Sean
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

2 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 2 3 4 5 .. 9 > >> (Page 3 of 9)

2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (4)	Sep	Oct	Nov	Dec
2004	Jan	Feb (45)	Mar (60)	Apr (12)	May (18)	Jun (14)	Jul (8)	Aug (10)	Sep	Oct (12)	Nov (16)	Dec (15)
2005	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec