Oh... If you wish to have LOCAL smartcard login, GINA is the right solution.
But I fail to see how it extend security... :)
Example... you require smartcard to access the computer, I turn it off
and boot from CDROM and access your files.
Or... you require smartcard to access the computer, I turn i
Am Dienstag 09 Februar 2010 10:43:04 schrieb Alon Bar-Lev:
> No need to change gina, simple configuration will do if the CSP is
> written properly.
but the default GINA still requires (for smart card authentication)
that the machine is part of an active directory domain, and that
the domain admini
2010/2/9 François Leblanc :
>>I have some fixups to the build.
>
> Great Thank you.
>
>>Can you please send me a usable cardmod.h so I can compile this stuff?
>
> I will send you in private way.
>
>>Also, can we put the .inf and .reg anywhere else but bin?
>
> The .reg is not to stay (just for exam
No need to change gina, simple configuration will do if the CSP is
written properly.
On Tue, Feb 9, 2010 at 9:15 AM, Peter Stuge wrote:
> François Leblanc wrote:
>> For login is still a bit more difficult since you need a domain
>> controller Configured for login with certificats
>
> Or something
I use mingw-w64 which has winscard.h available.
Much better maintained and support both win32 and win64.
On Tue, Feb 9, 2010 at 10:50 AM, Kalev Lember wrote:
> On 02/09/2010 09:04 AM, François Leblanc wrote:
>> Concerning your fixup, I remember you that mingw32 seems not to have
>> "winscard.h" i
On 02/09/2010 09:04 AM, François Leblanc wrote:
> Concerning your fixup, I remember you that mingw32 seems not to have
> "winscard.h" it's why I've make a complex cardmod.h detection since
> if you don't have winscard.h you use internal-winscard.h
I think the _right_ way in long term would be to c
François Leblanc wrote:
> For login is still a bit more difficult since you need a domain
> controller Configured for login with certificats
Or something like pGina.
//Peter
pgpIS4yXlqXQg.pgp
Description: PGP signature
___
opensc-devel mailing list
o
>I have some fixups to the build.
Great Thank you.
>Can you please send me a usable cardmod.h so I can compile this stuff?
I will send you in private way.
>Also, can we put the .inf and .reg anywhere else but bin?
The .reg is not to stay (just for example until we made it by a tool)
The .inf
On Sat, Feb 6, 2010 at 12:38 PM, Andreas Jellinghaus
wrote:
> Am Samstag 06 Februar 2010 10:34:03 schrieb Alon Bar-Lev:
>> The inf file management is very hard to maintain and produce something
>> sane. It great for drivers but not software.
>> I prefer we do all what needed in the install batch
Am Samstag 06 Februar 2010 10:34:03 schrieb Alon Bar-Lev:
> The inf file management is very hard to maintain and produce something
> sane. It great for drivers but not software.
> I prefer we do all what needed in the install batch file until someone
> come forward
> and maintain msi based package
On Sat, Feb 6, 2010 at 9:50 AM, Andreas Jellinghaus
wrote:
> Am Freitag 05 Februar 2010 19:51:00 schrieb Alon Bar-Lev:
>> Also, can we put the .inf and .reg anywhere else but bin?
>
> doesn't windows "install" the files if you double-click an inf file
> (or right-click / install)? it needs to fin
Am Freitag 05 Februar 2010 19:51:00 schrieb Alon Bar-Lev:
> Also, can we put the .inf and .reg anywhere else but bin?
doesn't windows "install" the files if you double-click an inf file
(or right-click / install)? it needs to find the files?
Ok, currently the "CopyFiles" sections are empty, but we
Committed some stuff build system related, I hope I did not damage your build.
One more question... Why don't you use the logging of opensc and
implemented your own?
2010/2/5 Alon Bar-Lev :
> 2010/2/5 François Leblanc :
>>
>> Hi,
>>
>> Minidriver added.
>
> I have some fixups to the build.
> Can
2010/2/5 François Leblanc :
>
> Hi,
>
> Minidriver added.
I have some fixups to the build.
Can you please send me a usable cardmod.h so I can compile this stuff?
Also, can we put the .inf and .reg anywhere else but bin?
Regarding the 32bit and 64bit card modules, we do not compile both
64bit and
>note: I removed the "Makefile.in".
>All those files generated by automake, autoconf and libtool
>are not submitted to svn, as they change, depending on the
>version of these tools used by each developer, and we are
>not interested in having these changes in the svn.
Ok.
>> Unfortunatly I can su
Am Freitag 05 Februar 2010 14:18:39 schrieb François Leblanc:
> Hi,
>
> Minidriver added.
good!
note: I removed the "Makefile.in".
All those files generated by automake, autoconf and libtool
are not submitted to svn, as they change, depending on the
version of these tools used by each developer,
Hi,
Minidriver added.
> - Move libopensc/opensccm.c to cardmod/cardmod.c -> build
> opensc-cardmod.dll
>leave it as is, and commit the code you posted.
>
>the code can be changed later, when there is an agreement how it can
>be changed.
Unfortunatly I can successfully use env to transmit SCA
>> Ok, to be more clear I suggest "opensc-cardmod.dll"...
>
>good idea.
Thank you.
>> Yes dlls must be in Path, the Path can be update at install process.
>
>I know you can set the path for users. but can you also set the
>path for system processes (e.g. the login window)?
Oups sorry, of cour
Am Donnerstag 04 Februar 2010 08:38:31 schrieb François Leblanc:
> Ok, to be more clear I suggest "opensc-cardmod.dll"...
good idea.
> Yes dlls must be in Path, the Path can be update at install process.
I know you can set the path for users. but can you also set the
path for system processes (e
On Feb 4, 2010, at 09:38 , François Leblanc wrote:
> So I plan to:
>
> - Move libopensc/opensccm.c to cardmod/cardmod.c -> build opensc-cardmod.dll
Perfect.
> - Update code to transmit SCARDHANDLE and SCARDCONTEXT by "env" to
> reader-pcsc.c
I'm not saying that the environment variable approach i
Hello,
>ok. hmm, but if we create an extra dll for the card module, the
>original name "opensccm" might be better. move the file
>to "cardmod/opensccm.c" and create "opensccm.dll"?
>is that ok for you.
Ok, to be more clear I suggest "opensc-cardmod.dll"...
>> dll-s are OK if they have a purpo
Am Mittwoch 03 Februar 2010 21:18:51 schrieb Peter Stuge:
> Are you sure that the file is not one of the files in the SDK which
> are in fact freely re-distributable? There is a list of files in the
> SDK which can be re-distributed.
The header file is in Includes/. The list of files you may distr
Andreas Jellinghaus wrote:
> > The header can not be included in the package for
> > licensing reasons?
>
> yes, microsoft doesn't license it for distribution. that is stupid,
> but well... it should be part of the plattform SDK too,
Are you sure that the file is not one of the files in the SDK
Am Mittwoch 03 Februar 2010 16:37:31 schrieb Martin Paljak:
> > so the only variable I see is the placement of opensccm.c
> > (and the name for it - "cardmod.c" is ok for you?).
>
> Yes.
>
> > in my opinion a single source file could be placed in a seperate
> > directory. and we can either create
On Feb 3, 2010, at 14:28 , Andreas Jellinghaus wrote:
>> Consolidating platform components to the opensc svn is good, mungling it
>> down the existing source structure not necessarily so good.
>
> the diffstat is:
> configure.ac | 31
> etc/opensc.conf.in|
>Sure, I know the case with windows and BaseCSP and why the driver rocks, if
finalized and why it is good and important.
>
>But the way it is included and integrated with the rest of OpenSC should be
discussed. I don't like the idea of putting it >"on the same level" with
libopensc and I don't lik
>> > as far as I know both are too much involved in opensc internals to port
>> > them to pkcs#11 api.
>>
>> You have the correct understanding.
>
>ok, thanks.
I Will try to think about it.
>> The question here is how the "feature" (pre-opened card handles) is
>> implemented inside libopensc. T
Am Mittwoch 03 Februar 2010 12:50:42 schrieb Martin Paljak:
[putting card module in opensc source / tar.gz]
> I'm not sure it would be the best and only option.
so lets discuss alternatives.
> It is not about different versioning or anything similar, it is about
> packaging and source code organ
On Feb 3, 2010, at 13:50 , François Leblanc wrote:
> Moreover keep in mind more use of opensc is done more usefull and longtime
> the project will exist,
>
> So to give the possibility for all windows application using cryptographics
> to use opensc is interesting...
Sure, I know the case with w
>-Message d'origine-
>De : Andreas Jellinghaus [mailto:a...@dungeon.inka.de]
>Envoyé : mercredi 3 février 2010 12:26
>À : Martin Paljak
>Cc : François Leblanc; opensc-devel@lists.opensc-project.org
>Objet : Re: [opensc-devel] Add card minidriver base on trunk.
(
On Feb 3, 2010, at 13:25 , Andreas Jellinghaus wrote:
> Am Mittwoch 03 Februar 2010 11:50:38 schrieb Martin Paljak:
>> Things to think about:
>>
>> - Will it be part of OpenSC (a cross-platform smart card library) or a
>> platform specific plugin? - If yes, do we package it with
>> opensc-x.x.x.ta
Am Mittwoch 03 Februar 2010 11:50:38 schrieb Martin Paljak:
> Things to think about:
>
> - Will it be part of OpenSC (a cross-platform smart card library) or a
> platform specific plugin? - If yes, do we package it with
> opensc-x.x.x.tar.gz?
it would be fine with me to do that.
> - If we incl
On Feb 3, 2010, at 12:02 , Andreas Jellinghaus wrote:
> Am Mittwoch 03 Februar 2010 10:37:37 schrieb François Leblanc:
>>> if you used some sample minicard driver template,
>>> we would need to mention that and have a look at
>>> its license. but the cng sdk contains nothing
>>> like that. if you u
Am Mittwoch 03 Februar 2010 10:37:37 schrieb François Leblanc:
> >if you used some sample minicard driver template,
> >we would need to mention that and have a look at
> >its license. but the cng sdk contains nothing
> >like that. if you used no template file, then
> >there is absolutely no problem
Am Mittwoch 03 Februar 2010 09:33:11 schrieb François Leblanc:
> There are a lot of stuff to do to improve this module (documentation, key
> Managing, writing card and so on) this why I need some help but I can't be
> helped if nobody can't access the code so It's why I wish to put this base.
> Mo
Andreas Jellinghaus wrote:
> Before you can download the CNG SDG you need a live.com/passport
> account, and sell your soul to microsoft or something like that.
It requires looking around a bit, but it is possible to create a
passport account using any email address.
//Peter
Before you can download the CNG SDG you need a live.com/passport
account, and sell your soul to microsoft or something like that.
Mickey Mouse seems to have done that.
inside the SDK there is only cardmod.h, but no example code
for writing a cardmod or anything like that. So I guess
François wro
>Please send us the licence.rtf so we can check it is LGPL compatible.
>
>Thanks
Ok, join licence.rtf and other.
François
License.tar.bz2
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
opensc-devel mailing list
o
Le 3 février 2010 09:33, François Leblanc
a écrit :
>>* I guess opensccm.c uses some template from microsoft?
>> please document in the file header to give credit where due.
>> Using a template of a published API for your own code is fine
>> I guess - no copyright/license issue here. Unless of
>a few comments from my side:
>* please change all debug strings to english :)
Of course it will be the case at end..
>* "opensccm" is a big cryptik, what about "cardmodule" or so?
> (if it is in the opensc source code, we know it relates to opensc,
> so no need to put "opensc" in the name)
Ye
a few comments from my side:
* please change all debug strings to english :)
* "opensccm" is a big cryptik, what about "cardmodule" or so?
(if it is in the opensc source code, we know it relates to opensc,
so no need to put "opensc" in the name)
* I guess opensccm.c uses some template from micr
41 matches
Mail list logo
