work in progress for review.

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

work in progress for review.

Andreas Jellinghaus-2
Hi,

I uploaded all changes I did today to
        http://www.opensc.org/files/wip/

tar.gz files as well as diff files.

engine_pkcs11:
 * build wiki documentation on "make dist"
 * change code to work with libp11 changes (below)

libp11:
 * build wiki documentation on "make dist"
 * examples/auth.c: expect libary name as command line parameter
 * remove slots and nslots from private context structure
 * enumerate_slots: allways allocate and return slots
 * find_token: require slots and nslots to be passed as parameters.
 * init_token: do not update slots/tokens (FIXME!)
 * make destroy_slot and destroy_all_slots functions public.

openct:
 * build wiki and api documentation on "make dist"
 * move api documentation to doc/api/ directory
 * make doxygen.conf.in written by configure.
 * require libltdl to be installed in a standard place.
   (user needs to set LIBS / CFLAGS is necessary)

opensc:
 * build wiki and old html documentation on "make dist"
 * HUGE configure changes. use pkg-config for openct, openssl,
   pcsc. drop "common dir" support. don't probe for docbook etc.
 * use libassuan.m4 for probing assuan library.
 * require libltdl to be installed in a standard place.
   (user needs to set LIBS / CFLAGS is necessary)
 * move code from scdl to ltdl, obsolete ltdl.
 * don't build libp11 or engine_*

pam_p11:
 * build wiki and old html documentation on "make dist"
 * port to changes libp11 api.

pam_pkcs11:
  * ignore. no changes, don't want to interfere with ludovic and
    jonsy. the patch is big because "make maintainer-clean" does
    not remove the generated files with pam_pkcs11. ignore.


please review those patches. I would like to commit them soon.

also I would like to implement doxygen for all projects the
way it is done with openct, even if we don't have documentation
right now, so at least the infrastructure is in place.

comments are very welcome.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Roumen Petrov-2
Why users should use CFLAGS and LIBS ?

Standard is CPPFLAGS and LDFLAGS !
=====================================================
..../configure --help
.....
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
CPP C preprocessor
=====================================================

Why opensc project don't follow standards ?



Andreas Jellinghaus wrote:

>Hi,
>
>I uploaded all changes I did today to
> http://www.opensc.org/files/wip/
>
>tar.gz files as well as diff files.
>
>engine_pkcs11:
> * build wiki documentation on "make dist"
> * change code to work with libp11 changes (below)
>
>libp11:
> * build wiki documentation on "make dist"
> * examples/auth.c: expect libary name as command line parameter
> * remove slots and nslots from private context structure
> * enumerate_slots: allways allocate and return slots
> * find_token: require slots and nslots to be passed as parameters.
> * init_token: do not update slots/tokens (FIXME!)
> * make destroy_slot and destroy_all_slots functions public.
>
>openct:
> * build wiki and api documentation on "make dist"
> * move api documentation to doc/api/ directory
> * make doxygen.conf.in written by configure.
> * require libltdl to be installed in a standard place.
>   (user needs to set LIBS / CFLAGS is necessary)
>
>opensc:
> * build wiki and old html documentation on "make dist"
> * HUGE configure changes. use pkg-config for openct, openssl,
>   pcsc. drop "common dir" support. don't probe for docbook etc.
> * use libassuan.m4 for probing assuan library.
> * require libltdl to be installed in a standard place.
>   (user needs to set LIBS / CFLAGS is necessary)
> * move code from scdl to ltdl, obsolete ltdl.
> * don't build libp11 or engine_*
>
>pam_p11:
> * build wiki and old html documentation on "make dist"
> * port to changes libp11 api.
>
>pam_pkcs11:
>  * ignore. no changes, don't want to interfere with ludovic and
>    jonsy. the patch is big because "make maintainer-clean" does
>    not remove the generated files with pam_pkcs11. ignore.
>
>
>please review those patches. I would like to commit them soon.
>
>also I would like to implement doxygen for all projects the
>way it is done with openct, even if we don't have documentation
>right now, so at least the infrastructure is in place.
>
>comments are very welcome.
>
>Regards, Andreas
>_______________________________________________
>opensc-devel mailing list
>[hidden email]
>http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>
>  
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Andreas Jellinghaus-2
On Wednesday 31 August 2005 23:09, Roumen Petrov wrote:
> Why opensc project don't follow standards ?

less /usr/bin/*-config /usr/lib/pkgconfig/*
tells me you live in a different world than I do.
those changes improve opensc and friends and make
it follow the standard about everyone seems to use.

none of your postings so far mentioned anything the
real world I percive cares about. bad luck for you.

Good night.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Ludovic Rousseau
In reply to this post by Andreas Jellinghaus-2
On 31/08/05, Andreas Jellinghaus <[hidden email]> wrote:
> please review those patches. I would like to commit them soon.

Please do commit. We can clean up a bit the code later.

> also I would like to implement doxygen for all projects the
> way it is done with openct, even if we don't have documentation
> right now, so at least the infrastructure is in place.

For OpenCT the doxygen documentation is in the source code C file.
Maybe it would be a better place in the header file?
The rational is that it would be easy to access the API documentation
using "less /usr/include/libp11.h". No need of a web browser. It will
not be more complex or difficult to have the doxygen doc in .h rather
than in .c and it has a beneficial effect.

Of course the documentation would still be available as web pages
online and in /usr/share/doc/libp11/ or similar.

Do you think it is a good idea?

Bye,

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Laurent Pinchart
> For OpenCT the doxygen documentation is in the source code C file.
> Maybe it would be a better place in the header file?
> The rational is that it would be easy to access the API documentation
> using "less /usr/include/libp11.h". No need of a web browser. It will
> not be more complex or difficult to have the doxygen doc in .h rather
> than in .c and it has a beneficial effect.

From the Doxygen doc (http://www.stack.nl/~dimitri/doxygen/docblocks.html):

"This way the documentation can be placed in the source file instead of the
header file. This keeps the header file compact, and allows the implementer
of the members more direct access to the documentation."

We have two convincing rationales here, now we must choose one of them :-)

Laurent Pinchart

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Andreas Jellinghaus-2
In reply to this post by Andreas Jellinghaus-2
On Thursday 01 September 2005 07:45, Martin Paljak wrote:
> On 8/31/05, Andreas Jellinghaus <[hidden email]> wrote:
> Nice job. The only question what i still have after such huge clean
> and splitups:
>
> >  * use libassuan.m4 for probing assuan library.
> Can we somehow get rid of the signer in core opensc too? This is the
> only stone that doesn't let the libopensc thing become a 'slim'
> library..

maybe? :)
lets get it first stable and working again with all those changes.

what does everyone else think about splitting off the signer?

configure wise it is the only user of libassuan and options like
the plugin dir, pin entry. it uses X11. and I have still no clue
how to actualy use and test it. but it uses libopensc directly,
not pkcs11.

> >  * move code from scdl to ltdl, obsolete ltdl.
> scdl then ;)

oops, yes.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Ludovic Rousseau
In reply to this post by Laurent Pinchart
On 01/09/05, Laurent Pinchart <[hidden email]> wrote:

> > For OpenCT the doxygen documentation is in the source code C file.
> > Maybe it would be a better place in the header file?
> > The rational is that it would be easy to access the API documentation
> > using "less /usr/include/libp11.h". No need of a web browser. It will
> > not be more complex or difficult to have the doxygen doc in .h rather
> > than in .c and it has a beneficial effect.
>
> From the Doxygen doc (http://www.stack.nl/~dimitri/doxygen/docblocks.html):
>
> "This way the documentation can be placed in the source file instead of the
> header file. This keeps the header file compact, and allows the implementer
> of the members more direct access to the documentation."
>
> We have two convincing rationales here, now we must choose one of them :-)

OpenSC has (some) Doxygen code in opensc.h [1].
So I win! yes! :-)

[1] http://www.opensc.org/opensc/file/trunk/src/libopensc/opensc.h

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Andreas Jellinghaus-2
In reply to this post by Ludovic Rousseau
On Thursday 01 September 2005 09:39, Ludovic Rousseau wrote:
> On 31/08/05, Andreas Jellinghaus <[hidden email]> wrote:
> > please review those patches. I would like to commit them soon.
>
> Please do commit. We can clean up a bit the code later.

ok, thanks.

> For OpenCT the doxygen documentation is in the source code C file.
> Maybe it would be a better place in the header file?

good idea.

> Of course the documentation would still be available as web pages
on my todo list, once it is in svn and the nightly snapshot generate
the files.

> online and in /usr/share/doc/libp11/ or similar.
we leave that job to the distributions.

> Do you think it is a good idea?

yes.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Laurent Pinchart
In reply to this post by Ludovic Rousseau
> > From the Doxygen doc

> > (http://www.stack.nl/~dimitri/doxygen/docblocks.html):
> >
> > "This way the documentation can be placed in the source file instead of
> > the header file. This keeps the header file compact, and allows the
> > implementer of the members more direct access to the documentation."
> >
> > We have two convincing rationales here, now we must choose one of them
> > :-)
>
> OpenSC has (some) Doxygen code in opensc.h [1].
> So I win! yes! :-)
>
> [1] http://www.opensc.org/opensc/file/trunk/src/libopensc/opensc.h
I suppose the impact is minor, but don't larger header files make compilation
slower ? I'm personally in favor of placing documentation in the source files
(like Qt does), but if everyone else agrees to put it in the headers, fine
with me.

Laurent Pinchart

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Ludovic Rousseau
On 01/09/05, Laurent Pinchart <[hidden email]> wrote:
> I suppose the impact is minor, but don't larger header files make compilation
> slower ?

Do you have performances numbers?

In theory it should have a performance impact. If you are really
concern by the performances of cpp/gcc/etc. when reading source code
files you should also remove any comments and indentation.

Or you can use tcc [1] that is really faster than gcc. The code
generated by tcc may not be as good as the one generated by gcc but
when you are in the edit/compile/run/debug cycle it may be valuable to
gain some seconds/minutes.

Bye,

[1] http://fabrice.bellard.free.fr/tcc/

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Andreas Jellinghaus-2
In reply to this post by Ludovic Rousseau
> > We have two convincing rationales here, now we must choose one of them :-)
>
> OpenSC has (some) Doxygen code in opensc.h [1].
> So I win! yes! :-)

what we need is a tool that regenerates the header files
from the source code. that way we could write code and
documentation in the source, and the tool would extract
all function definitions marked as export into the
header file including documentation.

I don't think there is such a tool, so back to square #1 :)

I think having documentation and code side by side has merrits
too, so I'm undecided. whoever writes the documentation gets
to choose?

Andreas
p.s. sure a very plain attempt to get everyone
to write documentation :)
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Andreas Jellinghaus-2
In reply to this post by Ludovic Rousseau
if your gcc is to slow you can use precompiled headers, see
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

I suggest:
we will not care about the additional size due to comments
in the header files. that slows down a normal computer only
microseconds, so compiling is still fast enough, and the
additional benefit from a well documented header file
is worth a lot more.

also many project spend up to 30% of the total time and
cpu time in autoconf/make/libtool/configure. if you want
to optimize total time for a compile, I would look over
there.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Roumen Petrov-2
In reply to this post by Andreas Jellinghaus-2
Andreas you wrote:
 > (user needs to set LIBS / CFLAGS is necessary)

Againg ./configure --help is very clear about variables:
1.) LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
2.) CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>

And again: Why users should use variables like CFLAGS/LIBS in opensc ONLY to set -I/-L flags instead to use will known standard ?


Andreas Jellinghaus wrote:

> On Wednesday 31 August 2005 23:09, Roumen Petrov wrote:
>
>>Why opensc project don't follow standards ?
>
>
> less /usr/bin/*-config /usr/lib/pkgconfig/*
> tells me you live in a different world than I do.
> those changes improve opensc and friends and make
> it follow the standard about everyone seems to use.
>
> none of your postings so far mentioned anything the
> real world I percive cares about.  bad luck for you.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Andreas Jellinghaus-2
if you had run any of those libfoo-config scripts with
"--libs" you would know what they do and not write
something that is so obviously wrong.

sure, pkg-config is not a clean system, as it does not
have two flags (LIBS and LDFLAGS) but only one that
combined both. go fix it upstream, go fix all users
of pkg-config and after that happened your are very
welcome to post patches here.

so far I don't care about that small glitch, have never
seen a real world case where it matters and I have
spend far too much time on your rambling. I have work
to do, please either grow up and be helpful or go
and play elsewhere.

Thank you.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Roumen Petrov-2
Andreas Jellinghaus wrote:

>if you had run any of those libfoo-config scripts with
>"--libs" you would know what they do and not write
>something that is so obviously wrong.
>
>sure, pkg-config is not a clean system, as it does not
>have two flags (LIBS and LDFLAGS) but only one that
>combined both.
>
> go fix it upstream, go fix all users
>of pkg-config and after that happened your are very
>welcome to post patches here.
>
>so far I don't care about that small glitch, have never
>seen a real world case where it matters and I have
>spend far too much time on your rambling. I have work
>to do, please either grow up and be helpful or go
>and play elsewhere.
>
>Thank you.
>
>Andreas
>
:) childs ...


Autoconf info pages are very clear about 'Preset Output Variables'.
When user use LDFLAGS to set -L flags this work fine in all cases and in
all scripts created by autoconf.
Dealing with variable LIBS is tricky.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Tarasov Viktor
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus wrote:

>Hi,
>
>I uploaded all changes I did today to
> http://www.opensc.org/files/wip/
>
>tar.gz files as well as diff files.
>
>engine_pkcs11:
> * build wiki documentation on "make dist"
> * change code to work with libp11 changes (below)
>
>libp11:
> * build wiki documentation on "make dist"
> * examples/auth.c: expect libary name as command line parameter
> * remove slots and nslots from private context structure
> * enumerate_slots: allways allocate and return slots
> * find_token: require slots and nslots to be passed as parameters.
> * init_token: do not update slots/tokens (FIXME!)
> * make destroy_slot and destroy_all_slots functions public.
>
>openct:
> * build wiki and api documentation on "make dist"
> * move api documentation to doc/api/ directory
> * make doxygen.conf.in written by configure.
> * require libltdl to be installed in a standard place.
>   (user needs to set LIBS / CFLAGS is necessary)
>
>opensc:
> * build wiki and old html documentation on "make dist"
> * HUGE configure changes. use pkg-config for openct, openssl,
>   pcsc. drop "common dir" support. don't probe for docbook etc.
> * use libassuan.m4 for probing assuan library.
> * require libltdl to be installed in a standard place.
>   (user needs to set LIBS / CFLAGS is necessary)
> * move code from scdl to ltdl, obsolete ltdl.
> * don't build libp11 or engine_*
>
>pam_p11:
> * build wiki and old html documentation on "make dist"
> * port to changes libp11 api.
>
>pam_pkcs11:
>  * ignore. no changes, don't want to interfere with ludovic and
>    jonsy. the patch is big because "make maintainer-clean" does
>    not remove the generated files with pam_pkcs11. ignore.
>
>
>please review those patches. I would like to commit them soon.
>
>also I would like to implement doxygen for all projects the
>way it is done with openct, even if we don't have documentation
>right now, so at least the infrastructure is in place.
>
>comments are very welcome.
>  
>
Hi,

Now, the pkcs15init's rule for the object ID generation is different
from the Mozilla's one.
Mozilla (and others) use SHA1 of the modulus as ID for PrKey, PubKey,
and Cert objects.
Pkcs15init use (AFAIS) linear schema, one byte ID, starting from '45',
with the possibility of reusing.

So, my humble question is:
in the nearest future, do you envisage to change pkcs15init ID
generation rule,
or, at least, to supply the card specific side with possibility to
choose object ID (card specific 'select_id')?

IMHO, there are several advantages of this step:
1. No need to create public key object, when generating private key.
2. More then one key can be generated and certificate imported with Mozilla.
3. Natural correspondance between PrKey, PubKey, and Cert objects. (For
exemple, right now,
I have a problem with deleting of public key, when importing with
Mozilla the corresponding certificate.)

Best regards,
Viktor.

>Regards, Andreas
>_______________________________________________
>opensc-devel mailing list
>[hidden email]
>http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>
>
>  
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: work in progress for review.

Nils Larsch
Tarasov Viktor wrote:
...
> Now, the pkcs15init's rule for the object ID generation is different
> from the Mozilla's one.

Mozilla doesn't create pkcs15 ids it creates pkcs11 CKA_IDs (and there
are afaik no rules or recommendation for pkcs15 ids)

> Mozilla (and others) use SHA1 of the modulus as ID for PrKey, PubKey,
> and Cert objects.

well for CKA_IDs it's recommended (however it's not a must) to use
the subject key identifier from the x509 certificate, if present, as
id value (of course how the subject key identifier is calculated is
not really standardized, there's only a recommendation (see rfc 3280)).

> Pkcs15init use (AFAIS) linear schema, one byte ID, starting from '45',
> with the possibility of reusing.

this is of course simpler and more useful if you use command line
options

>
> So, my humble question is:
> in the nearest future, do you envisage to change pkcs15init ID
> generation rule,

perhaps as an optional feature, btw: for on-card generated keys this
somewhat difficult as you don't know the hash before creating the key.

> or, at least, to supply the card specific side with possibility to
> choose object ID (card specific 'select_id')?

certainly not something card specific as this is not card specific

>
> IMHO, there are several advantages of this step:
> 1. No need to create public key object, when generating private key.

why ?

> 2. More then one key can be generated and certificate imported with Mozilla.
> 3. Natural correspondance between PrKey, PubKey, and Cert objects. (For

this depends on the definition of 'natural'. Normally the the exact
value of the id shouldn't matter (as long as the values are the same).

> exemple, right now,
> I have a problem with deleting of public key, when importing with
> Mozilla the corresponding certificate.)

a bug in mozilla ?

Nils

PS: Some time ago I wanted to raise this question as well, but I
     forgot it.

PPS: wrong thread
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel