compatibility [u]

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

compatibility [u]

Andreas Jellinghaus-2
Hi,

starting with the next release, should we retain compatibility with
_old_ software, or remove some cruft code? I'm thinking about these
options:
 - require openssl
 - only support openssl >= 0.9.7 (i.e. engine included)
 - only support openssl >= 0.9.7d (i.e. libcrypto fixed,
   remove the ugly work around with linking libcrypto staticaly)
 - require pkg-config to find openct, openssl, pcsc-lite
   (all of them provide *.pc files, and that would makes the
    long and horrible autoconf code quite simple)
 - drop pam_opensc (if pam_pkcs11 works fine as replacement)
   (that way we also drop sia and ldap code which is only used by pam)
 - drop engine_opensc (engine_pkcs11 is superior in every way?)
 - merge scrandom into libopensc
 - replace scdl with libltdl3 (same idea by libtool folks:
   universal dl() functions for all plattforms)
 - I vagualy read something about "argp" which is like getopt, but a
   bit better? I'm not sure what an upgrade will improve, but maybe
   that would be nice?

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: compatibility [u]

Martin Paljak
On 6/28/05, Andreas Jellinghaus [c] <[hidden email]> wrote:
>  - require openssl
It would not hurt to drop the developer viewpoint and take the users
viewpoint for a while:
Do we want to be ultra-cross-patform-compatible and compile on 10
different platforms and a wide variety of libraries&versions and to be
'somewhat usable under certain conditions' or should opensc be
_usable_ on most common platforms. I mean usable as able to provide
fully functional downloadable (binary) packages for users instead of
thinking about 'ease of development'. User experience/importance as it
seems to be for .ee is: Windows, OS X, Linux-unix-bsd-xyz. Windows
users don't care how the outcome is built as long as it works; 'normal
people' don't compile opensc on windows. OS X users usually are very
happy if they can install binary packages and they don't care how it
was built (or if it uses openssl or a private copy of openssl) as long
as it works for them; some users want to compile it as on 'normal
unix' but those who do should be smart enough to install all
dependancies or explain why they don't like the installer.
Linux-bsd-solaris-xxx users either download some kind of binary
packages (RPM, DEB etc), some are heavy compilers anyway (bsd, gentoo
etc); many people want to compile opensc themselves. Out of these
users most people use some kind of linux (most common) or bsd (not so
common) distro that either includes opensc in 'normal packages' or is
generally recent enough that recent trunk snapsht works well. As
opensc is mainly client platform targeted  the popularity % of the
client platform should guide the development efforts.


>  - only support openssl >= 0.9.7 (i.e. engine included)
>  - only support openssl >= 0.9.7d (i.e. libcrypto fixed,
>    remove the ugly work around with linking libcrypto staticaly)
I'd say 'yes'
>  - require pkg-config to find openct, openssl, pcsc-lite
>    (all of them provide *.pc files, and that would makes the
>     long and horrible autoconf code quite simple)
GoodThing. Windows doesn't care, most linux distros include
pkg-config, osx users would usually prefer a simple installer instead
and develpers/packagers should be capable of installing it themselves.
Other unix flavours - usually users are smart enough to figure out the
needed dependancies or they install binary packages too.

>  - drop pam_opensc (if pam_pkcs11 works fine as replacement)
>    (that way we also drop sia and ldap code which is only used by pam)
Also scam, that is currently a separate library but goes to the same
jar as sia and scldap.
It would not hurt to lift all other extras to a separate package
altogether. pam or netscape (signer) has nothing to do with core
libopensc/pkcs11 iplementation.
>  - drop engine_opensc (engine_pkcs11 is superior in every way?)
It can live for a while with a 'deprecated' sign..
>  - merge scrandom into libopensc
reasonable and done in my tree.
>  - replace scdl with libltdl3 (same idea by libtool folks:
>    universal dl() functions for all plattforms)
I tend to say 'yes' to every kind of re-use.
>  - I vagualy read something about "argp" which is like getopt, but a
>    bit better? I'm not sure what an upgrade will improve, but maybe
>    that would be nice?


--
Martin Paljak
[hidden email]
http://martin.paljak.pri.ee/
+372.5156495 - phone
_______________________________________________
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: compatibility [u]

Nils Larsch
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus [c] wrote:
> Hi,
>
> starting with the next release, should we retain compatibility with
> _old_ software, or remove some cruft code? I'm thinking about these
> options:
>  - require openssl
>  - only support openssl >= 0.9.7 (i.e. engine included)

no objections ;-)

>  - only support openssl >= 0.9.7d (i.e. libcrypto fixed,
>    remove the ugly work around with linking libcrypto staticaly)

this might be problematic; which distros actually have a
openssl >= 0.9.7d installed ?

>  - require pkg-config to find openct, openssl, pcsc-lite
>    (all of them provide *.pc files, and that would makes the
>     long and horrible autoconf code quite simple)

the may all provide *.pc files but which distros actually have
them all properly installed ? Or do we expect that the developer
must build/install every library on which opensc depends himself ?
Btw: on my (rather old) Susi 9.0 box I couldn't find a pcsc-lite
.pc file.

>  - drop pam_opensc (if pam_pkcs11 works fine as replacement)
>    (that way we also drop sia and ldap code which is only used by pam)

agree

>  - drop engine_opensc (engine_pkcs11 is superior in every way?)

I doubt the part in the parentheses but I agree that the current
engine_opensc code is really good and I won't miss it

>  - merge scrandom into libopensc

ok, for what do you we actually use scrandom ?

>  - replace scdl with libltdl3 (same idea by libtool folks:
>    universal dl() functions for all plattforms)
                                   ^^^ really ?

might be a good idea

>  - I vagualy read something about "argp" which is like getopt, but a
>    bit better? I'm not sure what an upgrade will improve, but maybe
>    that would be nice?

unless there isn't a reason to do so I wouldn't waste any time
with this

Nils
_______________________________________________
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: compatibility [u]

Andreas Jellinghaus-2
Hi,

one new issue: GPL apps and the openssl license trouble.

As long as opensc can be compiled with and without openssl support,
there shouldn't be much trouble. but if openssl is always compiled
with openssl support, then all apps using it need to be fine with
the openssl adv. conditions it in its license.

not that I'm aware of any gpl'ed app (not already using openssl)
having plans to use us. but keeping this door open might be nice.  

for openssl versions: I will check the distributions and see
who uses what. with that data the discussion should be easier.

> >  - require pkg-config to find openct, openssl, pcsc-lite
> >    (all of them provide *.pc files, and that would makes the
> >     long and horrible autoconf code quite simple)
>
> the may all provide *.pc files but which distros actually have
> them all properly installed ? Or do we expect that the developer
> must build/install every library on which opensc depends himself ?
> Btw: on my (rather old) Susi 9.0 box I couldn't find a pcsc-lite
> .pc file.

pcsc-lite added it quite late, as far as I know.

> >  - merge scrandom into libopensc
>
> ok, for what do you we actually use scrandom ?

pkcs11 function C_GenerateRandom.
scam/pam for get_random/sign/verify authentication.
pkcs15-etoken.c generate key can be passed some random data
(but the code doesn't use it right now).

> >  - replace scdl with libltdl3 (same idea by libtool folks:
> >    universal dl() functions for all plattforms)
>
>                                    ^^^ really ?

no. no idea how many plattforms they support.
but I expect the gnu libtool people have experience with
_lots_ of *ix plattforms, and we don't. so if anyone wants
to port us to some strang plattform, it might help using libltdl.

but: I need to investigate win32. maybe in that case we are better
off keeping our code, as libtool isn't ported to native win32.

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: compatibility [u]

Nils Larsch
Andreas Jellinghaus [c] wrote:

> Hi,
>
> one new issue: GPL apps and the openssl license trouble.
>
> As long as opensc can be compiled with and without openssl support,
> there shouldn't be much trouble. but if openssl is always compiled
> with openssl support, then all apps using it need to be fine with
> the openssl adv. conditions it in its license.
>
> not that I'm aware of any gpl'ed app (not already using openssl)
> having plans to use us. but keeping this door open might be nice.

hmm, I think: most (if not all) people will use opensc
through pkcs11 alike dyn. module api and if GPL app requires
GPL compatible pkcs11 libs etc. it wouldn't be really useful
(as hsm vendors might be willing to provide a Linux etc. pkcs11
lib but almost certainly not under GPL compatible license
(selling software + support is yet another source of income)).

...
>>> - merge scrandom into libopensc
>>
>>ok, for what do you we actually use scrandom ?
>
>
> pkcs11 function C_GenerateRandom.

hmm, this raises another question: do we want a pkcs11 library
(with which we want to "speak" a hardtoken token) return
"software" generated random numbers ? I would naively expect
that a hardware pkcs11 lib either returns hardware generated
random data or no random data at all (in the latter case I could
ask /dev/random etc. myself).

> scam/pam for get_random/sign/verify authentication.

the part you want to remove :)

> pkcs15-etoken.c generate key can be passed some random data
> (but the code doesn't use it right now).

yep, interesting point. This raises yet another question: is it
really secure to generate private keys without supplying a random
value: if it's not the current implementation has a major flaw
(and the card as well IMHO) if it's secure to create a key without
supplying a random seed why bother with this at all ?

Nils
_______________________________________________
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: compatibility [u]

Ludovic Rousseau
On 29/06/05, Nils Larsch <[hidden email]> wrote:
> Andreas Jellinghaus [c] wrote:
> > pkcs15-etoken.c generate key can be passed some random data
> > (but the code doesn't use it right now).
>
> yep, interesting point. This raises yet another question: is it
> really secure to generate private keys without supplying a random
> value: if it's not the current implementation has a major flaw
> (and the card as well IMHO) if it's secure to create a key without
> supplying a random seed why bother with this at all ?

If the card needs to be given a random value to generate a key pair it
is not (much) safer than generating the key pair on the PC and loading
the private in the card.

On board key generation is a real security service only if the private
key can't be obtained by any way (logical or physical attacks).

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: compatibility [u]

Ludovic Rousseau
In reply to this post by Nils Larsch
On 29/06/05, Nils Larsch <[hidden email]> wrote:
> Andreas Jellinghaus [c] wrote:
> >  - only support openssl >= 0.9.7d (i.e. libcrypto fixed,
> >    remove the ugly work around with linking libcrypto staticaly)
>
> this might be problematic; which distros actually have a
> openssl >= 0.9.7d installed ?

Debian stable (aka Sarge aka 3.1) has 0.9.7e.
Don't know for the other systems :-)

> >  - require pkg-config to find openct, openssl, pcsc-lite
> >    (all of them provide *.pc files, and that would makes the
> >     long and horrible autoconf code quite simple)
>
> the may all provide *.pc files but which distros actually have
> them all properly installed ? Or do we expect that the developer
> must build/install every library on which opensc depends himself ?

One possibility for the developper is to use CFLAGS=... LIBS=...
./configure to include the correct paths to his libs. I propose that
solution for my CCID driver if ifdhandler.h can't be found.

> Btw: on my (rather old) Susi 9.0 box I couldn't find a pcsc-lite
> .pc file.

I installed a SuSE 9.2 and it was using pcsc-lite 1.1.2 (IIRC).
SuSE 9.3 is now using 1.2.9 (beta6 ?) [1]

Regards,

[1] http://www.novell.com/products/linuxpackages/professional/pcsc-lite.html

--
 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: compatibility [u]

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Wednesday 29 June 2005 10:23, Nils Larsch wrote:
> hmm, I think: most (if not all) people will use opensc
> through pkcs11 alike dyn. module api and if GPL app requires
> GPL compatible pkcs11 libs

GPL is only enfored with distribution.
if a GPL app uses pkcs11 api, and there are two implementations,
one GPL'ed and one not, and the user chooses to combine the
wrong ones - well, that happends only at run time on the users
machine so nobody knows. he might have difficulties getting
support for such an unwanted combination, but that is the only
trouble he will have.

I'm a big favor of gpl, but I know that anyone can implement
a standardized api, and I don' kare much, if people mismix components
at runtime.

> >>> - merge scrandom into libopensc
> >>
> >>ok, for what do you we actually use scrandom ?
> >
> > pkcs11 function C_GenerateRandom.
>
> hmm, this raises another question: do we want a pkcs11 library
> (with which we want to "speak" a hardtoken token) return
> "software" generated random numbers ? I would naively expect
> that a hardware pkcs11 lib either returns hardware generated
> random data or no random data at all (in the latter case I could
> ask /dev/random etc. myself).

true. but a TODO item, not a show stopper. we can keep it the
way we currently do this, and change it someday later.
maybe some app expects a pkcs11 engine to return random bytes
always, so maybe we don't want to return nothing. we could have
a config file option, whether we should fall back to /dev/urandom
or to returning nothing?

create a ticket so we don't forget this?

> > scam/pam for get_random/sign/verify authentication.
>
> the part you want to remove :)

yes, only mentioned it for completenes.

> > pkcs15-etoken.c generate key can be passed some random data
> > (but the code doesn't use it right now).
>
> yep, interesting point. This raises yet another question: is it
> really secure to generate private keys without supplying a random
> value: if it's not the current implementation has a major flaw
> (and the card as well IMHO) if it's secure to create a key without
> supplying a random seed why bother with this at all ?

true, I too wondered what this is all about. if the card isn't truly
random, I might as well not use a smart card at all, or at least not
for those parts that require random data (key generation, partialy
secure messaging and some forms of authentication).

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: compatibility [u]

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Wednesday 29 June 2005 00:59, Nils Larsch wrote:
> this might be problematic; which distros actually have a
> openssl >= 0.9.7d installed ?

debian stable: 0.9.7e-3

fedora 1,2,3: 0.9.7a
fedora 4: 0.9.7f
redhat enterprise 3: 0.9.7a
redhat enterprise 4: 0.9.7a

gentoo: 0.9.7g

mandrake cvs: 0.9.7g
mandriva 10.2: 0.9.7e
mandriva 10.1: 0.9.7d
mandriva 10.0: 0.9.7c

suse enterprise linux 9: 0.9.7d
suse 9.3: 0.9.7e
suse 9.2: 0.9.7d
suse 9.1: 0.9.7d
suse 9.0: 0.9.7b        (2003?)

rock linux: 0.9.7g

freebsd 5.4: 0.9.7e
freebsd 5.3: 0.9.7d
freebsd 4.9: 0.9.7b

mac os X 10.4.1: OpenSSL 0.9.7b 10 Apr 2003

netbsd: 0.9.7f

everyone has 0.9.7 except debian woody, so we can
require 0.9.7 without any issue, I think.

I don't care about suse 9.0, as suse is already
at 9.3 (or 9.4)? mac os X doesn't have static libs
anyway, so it is not affected by the sslengine problem
(or our work aroung wouldn't work anyway).

so the only question is: shall we keep the workaround
for openssl <= 0.9.7c? redhat enterprise and fedora
core 1-3 would need them, everyone else is fine.
(ok mandriva 10.0 - which is quite old, too -
would also need it.)

> >  - require pkg-config to find openct, openssl, pcsc-lite
> >    (all of them provide *.pc files, and that would makes the
> >     long and horrible autoconf code quite simple)
>
> the may all provide *.pc files but which distros actually have
> them all properly installed ?

"make install" installs them, so I doubt any distribution will
not have those files.

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: compatibility [u]

Nils Larsch
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus [c] wrote:
...
> true. but a TODO item, not a show stopper. we can keep it the
> way we currently do this, and change it someday later.
> maybe some app expects a pkcs11 engine to return random bytes
> always, so maybe we don't want to return nothing. we could have
> a config file option, whether we should fall back to /dev/urandom
> or to returning nothing?

if a hsm doesn't provide a certain service why should the
library to access this hsm provide that service. This might
actually be a security problem as we give the library user
a false sense of security.

>
> create a ticket so we don't forget this?

ok, will do so tomorrow

...

>>>pkcs15-etoken.c generate key can be passed some random data
>>>(but the code doesn't use it right now).
>>
>>yep, interesting point. This raises yet another question: is it
>>really secure to generate private keys without supplying a random
>>value: if it's not the current implementation has a major flaw
>>(and the card as well IMHO) if it's secure to create a key without
>>supplying a random seed why bother with this at all ?
>
>
> true, I too wondered what this is all about. if the card isn't truly
> random,

it's certainly not truly random (but that shouldn't be a real
problem here as the card can't output that such much random
data anyway)

> I might as well not use a smart card at all, or at least not
> for those parts that require random data (key generation, partialy
> secure messaging and some forms of authentication).

I will ask someone who knows more about cardos cards what this
option is good for

Nils
_______________________________________________
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: compatibility [u]

Roumen Petrov-2
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus [c] wrote:
> Hi,
>
> starting with the next release, should we retain compatibility with
> _old_ software, or remove some cruft code? I'm thinking about these
> options:
>  [SNIP]
>  - require pkg-config to find openct, openssl, pcsc-lite
>    (all of them provide *.pc files, and that would makes the
>     long and horrible autoconf code quite simple)

pkg-config is not portable and might it is not good solution.

Let see openssl.pc:
=================================================
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

......
Libs: -L${libdir} -lssl -lcrypto  -ldl
Cflags: -I${includedir}
=================================================
Most common use is "pkg-config --libs <PACKAGE>".
With command like above opensc will link with all three libs instead of only one - crypto :-\ .
Of cource pkg-config can return only -L/-R part.
Pkg-config mix compiler and preprocesor flags, mix library search path with libraries.
I'm not sure that pkg-config will simplify configure script.


I can write suitable macro files that can detect external libs/programs.
With proposed solution configure.{ac|in} will contain as example AC_OPENCT or AM_OPENCT.
I guess that macro files will be quite similar.


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


--
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/


_______________________________________________
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: compatibility [u]

Andreas Jellinghaus-2
Hi Roumen,

ah, I didn't remember it only has a single *.pc file.
sure, it would be better to have a libssl.pc and a libcrypto.pc.
I filed a bug report :)

however, why is pkg-config not portable?
it should work fine on all *ix systems (i.e.
everywhere except for windows, and we have special
makefiles for windows anyway).

> With command like above opensc will link with all three libs instead of
> only one - crypto :-\ .

well libcrypto requires libdl, so we can ignore that part.
and libssl links with libcrypto, so in that case it is fine, too.

the only bothering part is that -lssl might be unnecessary, if only
libcrypto is needed. not good, but not very bad either.

> Pkg-config mix compiler and preprocesor flags, mix library search path with
> libraries.

at least on linux I never saw a big problem with that.
will it cause trouble on other architectures?
can libtool fix that, or do we need to deal with it ourself?

> I'm not sure that pkg-config will simplify configure script.

well, it will reduce the code to 5 simple lines, unless you find
some issue that is broken.

I'm proposing pkg-config because I have spend far too much time with
broken configure scripts. its not use if everyone writes there own
one, so a library should provide some help. a macro would be ok.
but why should every library write their own macro, if there is
one that works for everyone? at least this is the hope I have with
pkg-config, and some simple tests look very promising. also it is
nice if everyone uses the same way, so using some library is easy
and doesn't require any new learning to write the autoconf detection
routing / use the provided macro.

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: compatibility [u]

Ville Skyttä
In reply to this post by Roumen Petrov-2
On Thu, 2005-06-30 at 01:09 +0300, Roumen Petrov wrote:

> Libs: -L${libdir} -lssl -lcrypto  -ldl
> Cflags: -I${includedir}
> =================================================
> Most common use is "pkg-config --libs <PACKAGE>".
> With command like above opensc will link with all three libs instead
> of only one - crypto :-\ .

I guess using the --as-needed option of the linker (where available)
would be an easy way to avoid that.

_______________________________________________
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: compatibility [u]

Roumen Petrov-2
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus [c] wrote:
> Hi Roumen,
>
> ah, I didn't remember it only has a single *.pc file.
> sure, it would be better to have a libssl.pc and a libcrypto.pc.
> I filed a bug report :)
good - [openssl.org #1143] pkg-config files for each lib.

Yes that is first problem. Name pkg-config is confusing.
 From man page:
- "pkg-config - Return metainformation about installed libraries"
- "...pkg-config retrieves information about packages from special metadata files...."
Library and package definitely are not equal - a project should create pc file for every installed library.


>
> however, why is pkg-config not portable?
> it should work fine on all *ix systems (i.e.
> everywhere except for windows, and we have special
> makefiles for windows anyway).
>
My information was old.


>>[SNIP]
>>Pkg-config mix compiler and preprocesor flags, mix library search path with
>>libraries.
>
>
> at least on linux I never saw a big problem with that.
> will it cause trouble on other architectures?
Problem is note related to architectures.
Some projects asign result from `pkg-config --cflags` to CFLAGS instead to CPPFLAGS in configure script.
Configure script will find header file when CPPFLAGS contain -I flag.


> can libtool fix that, or do we need to deal with it ourself?
I cannot remember platform with number of -L flags limit (solaris ?).
Libtool should remove duplicate -L flags and should put correct -R flag when necessary.


>
>
>>I'm not sure that pkg-config will simplify configure script.
>
>
> well, it will reduce the code to 5 simple lines, unless you find
> some issue that is broken.
Note that pkg-config require libraries to be installed.
'New library test case problem' :
When I like to test a program against new version of a library,
without to install it pkg-config cannot help. Usualy on system
library and headers are already installed and cannot be replaced.


> I'm proposing pkg-config because I have spend far too much time with
> broken configure scripts.
Many developers found that writing of autoconf script is too difficult.


 > its not use if everyone writes there own
> one, so a library should provide some help. a macro would be ok.
Some project provide m4 macro file instaled in `aclocal --print-ac-dir` with AM_PATH_XXXX.


> but why should every library write their own macro, if there is
> one that works for everyone?
:-\


> at least this is the hope I have with
> pkg-config, and some simple tests look very promising.
Since some projects (as example xft, fontconfig, xml2 ...) create and install
XXX-config shell scripts pkg-config is good replacement and generalization.
But pkg-config cannot replace aclocal/autoconf macros.
May be with pkg-config we can get CPPFLAGS and LDFLAGS in two lines, but rest of
script should check existence of headers/library, specific functions,
structure members, do some extra test and this part is important.

As example lets see file libxml.m4 - it contain lines that found xml-config
and call it to get flags and version. Other examle is alsa.m4 - it contain
lines that check version. All those lines can be replaces with pkg-config
calls but note 'New library test case problem'.


> also it is
> nice if everyone uses the same way, so using some library is easy
> and doesn't require any new learning to write the autoconf detection
> routing / use the provided macro.
>


Regards,
Rumen
_______________________________________________
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: compatibility [u]

Nils Larsch
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus [c] wrote:
...

>>>pkcs15-etoken.c generate key can be passed some random data
>>>(but the code doesn't use it right now).
>>
>>yep, interesting point. This raises yet another question: is it
>>really secure to generate private keys without supplying a random
>>value: if it's not the current implementation has a major flaw
>>(and the card as well IMHO) if it's secure to create a key without
>>supplying a random seed why bother with this at all ?
>
>
> true, I too wondered what this is all about. if the card isn't truly
> random, I might as well not use a smart card at all, or at least not
> for those parts that require random data (key generation, partialy
> secure messaging and some forms of authentication).

the cardos GIVE RANDOM command used in the etoken code is *not*
for key pair generation but for secure messaging. I've removed
the corresponding code in card-etoken.c etc. (one reason less
for scrandom in libopensc ....)

Nils
_______________________________________________
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: compatibility [u]

Andreas Jellinghaus-2
In reply to this post by Roumen Petrov-2
On Friday 01 July 2005 00:06, Roumen Petrov wrote:

> >>[SNIP]
> >>Pkg-config mix compiler and preprocesor flags, mix library search path
> >> with libraries.
> >
> > at least on linux I never saw a big problem with that.
> > will it cause trouble on other architectures?
>
> Problem is note related to architectures.
> Some projects asign result from `pkg-config --cflags` to CFLAGS instead to
> CPPFLAGS in configure script. Configure script will find header file when
> CPPFLAGS contain -I flag.

ok, so we can fix this by using pkg-config properly, so no issue here.

also if we are using pkg-config people are not supposed to play with
LIBS and CPPFLAGS environment variables to find libs/header files,
but to modify the PKG_CONFIG_PATH.

> Note that pkg-config require libraries to be installed.
> 'New library test case problem' :
> When I like to test a program against new version of a library,
> without to install it pkg-config cannot help. Usualy on system
> library and headers are already installed and cannot be replaced.

no problem here. configure and install it to /opt/testing/thatlib-version/
and set PKG_CONFIG_PATH to include that directory first.

but in general: once a software uses several libraries, there is no way
at all that you can have one of those libraries installed in two different
version on your system. sorry, but the unix link and include system has
limitsx, and you hit them in this case. the scenario is quite easy:
you have liba in /usr and /opt/something and want to use the second location.
you have libb in /usr. if the configure script probes for libb first, it
will generate a -I/usr/include and -L/usr/lib in most cases. thus, even
if you have -I/opt/something/unclude and -L/opt/something/lib in your
FLAGS, liba will be used from /usr/.

the best way to deal with these limits, is to have the development files
for only one version of a library in a given root. i.e. if you want
to compile with a different software combination, build a chroot
with exactly that combo. works fine over here.

> Some project provide m4 macro file instaled in `aclocal --print-ac-dir`
> with AM_PATH_XXXX.

but how are those scripts any better than the generic pkg-config system?
and if they are not, it is a special case for no good reason.

> Since some projects (as example xft, fontconfig, xml2 ...) create and
> install XXX-config shell scripts pkg-config is good replacement and
> generalization. But pkg-config cannot replace aclocal/autoconf macros.

yes, pkg-config is the libname-config system moved to a generic system.
pkg-config has a aclocal/autoconf macro shipped with it, and it can
be used, if no special features are needed.

> May be with pkg-config we can get CPPFLAGS and LDFLAGS in two lines, but
> rest of script should check existence of headers/library, specific
> functions, structure members, do some extra test and this part is
> important.

"make install" needs to succeed completely. if anyone has a system where
that was run only partialy or someone messed with the result, there is
no way to completely check the integrity. I think it is better to check
only if a library is there, and a simple link test that reflects the use
in opensc. further test should go into the testing code of that library,
and not into the configure code if applications using it.


Ok, how should we proceed? I think it might be best to simply
do those changes to configure.ac and then seek real world experience,
whether we need special code, or whether the generic pkg.m4 code works
fine for us.

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: compatibility [u]

Roumen Petrov-2
> [SNIP]
>
> Ok, how should we proceed? I think it might be best to simply
> do those changes to configure.ac and then seek real world experience,
> whether we need special code, or whether the generic pkg.m4 code works
> fine for us.
>

writen from scratch:
May be an existing macro can be used - AC_LIB_LINKFLAGS([XXXX])
(Note I'm not sure about name).
It should be defined in liblink.m4 (?).
This macro will add option --with-libXXXX-prefix to configure
script and will set some variables (may be LIBXXXX INCXXXX ?).

I will try to find it and to propose a patch - may be first for libopenct.

_______________________________________________
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: compatibility [u]

Stef Hoeben
In reply to this post by Nils Larsch
Hi,

> hmm, this raises another question: do we want a pkcs11 library
> (with which we want to "speak" a hardtoken token) return
> "software" generated random numbers ? I would naively expect
> that a hardware pkcs11 lib either returns hardware generated
> random data or no random data at all (in the latter case I could
> ask /dev/random etc. myself).

The way our pkcs11 works: if random data is requested, we ask 20
bytes randomness from the card. If the card can't give this, an
error is returned.
And then these 20 bytes are used to seed a software random generator
(from openssl in this case) to produce random bytes.

Of course, it's also possible to ask all random bytes from the card,
but if the pkcs11 app would asks 10000 random bytes...

Cheers,
Stef

_______________________________________________
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: compatibility [u]

Nils Larsch
Stef Hoeben wrote:
...
> The way our pkcs11 works: if random data is requested, we ask 20
> bytes randomness from the card. If the card can't give this, an
> error is returned.
> And then these 20 bytes are used to seed a software random generator
> (from openssl in this case) to produce random bytes.

btw: why 20 bytes ? And about the sc_random call in this function:
why is it really necessary ? The openssl random number generator should
, when it is initialized, query the typical system sources for
random data (afaik the same does scrandom).

>
> Of course, it's also possible to ask all random bytes from the card,
> but if the pkcs11 app would asks 10000 random bytes...

being pedantic that's what I would naively expect a pkcs11 lib
should do (of course this would be terrible slow but a pkcs11
library should not patronize the user). This is just my personal
opinion (and I would like to hear more opinions).

note1: the smartcard command used to get the random data from the
card is called GET CHALLENGE and it's intended use is to provide
random data for secure messaging. I don't think it was intended
to use this command to provide application with random data ...

note2: if we keep the current behaviour it should be clearly
documented (where ?).

Nils
_______________________________________________
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: compatibility [u]

Stef Hoeben
Nils Larsch wrote:

> Stef Hoeben wrote:
> ...
>
>> The way our pkcs11 works: if random data is requested, we ask 20
>> bytes randomness from the card. If the card can't give this, an
>> error is returned.
>> And then these 20 bytes are used to seed a software random generator
>> (from openssl in this case) to produce random bytes.
>
>
> btw: why 20 bytes ?

Guess it's enough (to seed an pseudo-random generator) and not too much

> And about the sc_random call in this function:
> why is it really necessary ? The openssl random number generator should
> , when it is initialized, query the typical system sources for
> random data (afaik the same does scrandom).

Hm, if openssl gathers enough randomness from itself on all platforms
then the call to the smart card indeed wouldn't be needed. (OTOH, openssl
allows to add an extra random seed, but that's probably for the paranoid?)

>>
>> Of course, it's also possible to ask all random bytes from the card,
>> but if the pkcs11 app would asks 10000 random bytes...
>
>
> being pedantic that's what I would naively expect a pkcs11 lib
> should do (of course this would be terrible slow but a pkcs11
> library should not patronize the user). This is just my personal
> opinion (and I would like to hear more opinions).

Guess a pseudo-random stream derived from 20 random bytes is
almost as good as 10000 random bytes (using a good algo of course).
IMHO a user want random bytes quickly... In the other case, she would
have to get a separate pseudo-random generator if she wants much
random data because our pkcs11 lib will be too slow..

Cheers,
Stef

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