Re: [opensc-devel] Changes to opensc-project(.org) (Re: opensc-commit spam)
2010/3/24 Martin Paljak : > I'd like to change the main page of opensc-project.org with what can > be seen on http://www.opensc-project.org/opensc in near future, what > do you think? I like this idea. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Windows installer
I try to avoid wine as much as I can. Anyway, I have no feeling for the windows binaries... I do not use the output anyway :) I just provide them because after I rewrote the opensc build system, there was no reason to maintain parallel build system for windows only, and the windows build was unmaintained anyway. So free to do whatever you think best. I can continue building binaries whenever version gets out using current build project, but if it is not necessary we can drop it in favor of something else. Alon. 2010/3/24 Martin Paljak : > On Mar 24, 2010, at 16:04 , François Leblanc wrote: >>> The download link for i386 installer is included in the wiki page together >>> with some comments and questions. Unlike NSIS >InnoSetup is a win32 >>> application but I have successfully used it from wine. >> It's the main reason why we choice NSIS, I think using wine to build >> installer a bit complicated. > > I suspect that the main reason is the possibility to automate the build > process on a linux host platform. The same can be done with wine and > InnoSetup (somethng along the lines of "wine innosetup.exe opensc.iss") > > As said, the technology of the installer can be left open and/or there can > multiple installers (as long as they all do the same thing). > > What should be reviewed is what the installer does, why it does something and > how the user experience works for real end-users. > > Compared to the nsis installer the inno version does currently these things > differently: > - writes a wrong path to ConfigFile setting (see below) > - does not execute opensc-install.bat (see below) > - does not add the tools folder to %PATH%. > + generates a proper uninstaller > + uses OpenSC as the name and has more extra information > + has a skeleton README phase. > > One of the goals has been to allow OpenSC to work for 80% of people (or > hopefully more, of course) without any changes to any configuration file. > That mission was completed for *nix when the default profile directory is > coded in as a #define. > Obviously we can't make this the same way on Windows, people have as many > strange windows setups as there are different linux distros... So maybe > "opensc home" could be fetched from registry and located by the rest of the > code. > > The same way installing a config file pointer into HKLM might not be done. > Maybe only do it for a custom install if the user requests it. > > > > > -- > Martin Paljak > http://martin.paljak.pri.ee > +3725156495 > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changes to opensc-project(.org) (Re: opensc-commit spam)
Hello again, A few weeks have passed so here's a re-cap of the information exchanged this far: 2010/3/9 Martin Paljak : > Here are some plans that should make opensc-project.org more attractive to > both users and developers and also ease the administration burden. Lets > collect feedback for a week: please let me know which you feel would be > useful or what would absolutely resist. > > - Consolidate opensc-user and opensc-devel to maximize chances of response > and reduce confusion. Many questions that appear on opensc-user should either > have a FAQ entry (read below about faq) or are actually issues that will > require developer attention. Having a single opensc-devel would bring the > list of relevant mailing lists down to two (opensc-devel and muscle, many > people cross-post to both lists even now) Implementation tactics could be > directing people to opensc-devel only and asking existing subscribers > re-subscribe or do it automatically with an informational e-mail to > subscribers. Looking at subscriber lists reveals that about 1/3 of > subscribers on both lists follow the other list as well already. Some people like it, some think that the audience of the lists is different. I don't have any strong feelings about it, eventually it should be also asked on opensc-user, what the subscribers there feel (as the idea would be to consolidate user list into devel, not vice versa). I still think that it could do good, but let it stay as it is for now. > - Have a clear path of communication: faq -> mailing list -> trac tickets. > With a single mailing list there is no question where to post and with a > single trac instance there is no question where to file bugs. Hopefully this > will re-animate trac tickets as a functioning issue tracking platform that > would benefit all parties. The "correct way of interaction" has been documented on https://www.opensc-project.org/opensc/wiki/GetStarted what should be the place where people look first (when they have no previous experience with OpenSC). The FAQ on the main page is still outdated but a skeleton for a new one is is online https://www.opensc-project.org/opensc/wiki/FrequentlyAskedQuestions The rest of the old FAQ (what really was more like a tutorial) must be merged with relevant developer or overview wiki pages (the information has been copied to relevant pages already) > > - Consolidate trac instances into a) a single OpenSC trac, moving all wiki > content and closing other trac-s b) closing all ticket sections in favor of > opensc trac but keep the wiki pages (and SVN browser) in read only mode. > Reason for this: Information is scattered between several trac-s, which all > require administration and housekeeping and is confusing to users as well. > None of the smaller trac-s have been actively used for ticket tracking or > have any other changes for months. This could be approached on a case-by-case > basis as well. No change in SVN repos. This was generally an accepted OK change, as information seems to be scattered and unorganized in the wikis. As a surprise a first ticket was posted to pkcs11-helper trac, asking for compilation help. Such requests should go to the mailing list instead, so maybe extending the "leave your e-mail" notice above new ticket entry could also include "and post to a mailing list if not sure" as well. I created a "namespace" for all wiki content of sub-projects (tagged as "project" in Trac) and copied the small content over. One exception is OpenCT, as it does not deal with PKCS#11, like the rest of projects. The copied wiki pages still need work and updating, but it should be done the OpenSC wiki, not the sub-wikis. I would turn the rest of the wikis read-only and add a to the rest of wiki templates a bold "this wiki has been moved to a new location: http://..."; and "please post new tickets to http:///"; Everything will remain the same for the foreseeable future with timelines and svn browsers and svn addresses. > - Remove outdated static html content on opensc-project.org and replace > with/forward to the wiki. The fact that trac has been not used lately is due > to the registration being closed for a long period because of spam. Open > access to wiki and documentation (with a review for spam and such, of course) > will hopefully improve it. Fighting for spam is easy (or at least simpler) > now that necessary plugins are installed, but I installed them only to opensc > trac. This has been completed, all content has been moved to wiki. The generic cleanup done in the wiki (I already deleted some pages that were totally empty or 100% useless or outdated oneliners with dead links) and the current status of it is here: http://www.opensc-project.org/opensc/wiki/ProjectCleanup I've tagged most pages that need work with some (almost random) classification, either to signal that the page is old or should be improved or should be merged with some other page. > Most importantly
Re: [opensc-devel] OpenSC Windows installer
On Mar 24, 2010, at 16:04 , François Leblanc wrote: >> The download link for i386 installer is included in the wiki page together >> with some comments and questions. Unlike NSIS >InnoSetup is a win32 >> application but I have successfully used it from wine. > It's the main reason why we choice NSIS, I think using wine to build > installer a bit complicated. I suspect that the main reason is the possibility to automate the build process on a linux host platform. The same can be done with wine and InnoSetup (somethng along the lines of "wine innosetup.exe opensc.iss") As said, the technology of the installer can be left open and/or there can multiple installers (as long as they all do the same thing). What should be reviewed is what the installer does, why it does something and how the user experience works for real end-users. Compared to the nsis installer the inno version does currently these things differently: - writes a wrong path to ConfigFile setting (see below) - does not execute opensc-install.bat (see below) - does not add the tools folder to %PATH%. + generates a proper uninstaller + uses OpenSC as the name and has more extra information + has a skeleton README phase. One of the goals has been to allow OpenSC to work for 80% of people (or hopefully more, of course) without any changes to any configuration file. That mission was completed for *nix when the default profile directory is coded in as a #define. Obviously we can't make this the same way on Windows, people have as many strange windows setups as there are different linux distros... So maybe "opensc home" could be fetched from registry and located by the rest of the code. The same way installing a config file pointer into HKLM might not be done. Maybe only do it for a custom install if the user requests it. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Windows installer
>The download link for i386 installer is included in the wiki page together >with some comments and questions. Unlike NSIS >InnoSetup is a win32 >application but I have successfully used it from wine. It's the main reason why we choice NSIS, I think using wine to build installer a bit complicated. Regards, François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC Windows installer
Hello, build svn recently grew a NSIS installer script. As an alternative, here's a try with the InnoSetup utility, slightly customized from an installer version for OpenSC that has been used for several years in Estonia. It provides IMHO (at least now) a smoother and more familiar experience than the nsis version and the installer description is easier to read for those who don't know the internals of NSIS. Eventually the tasks that the end-user installation does should be documented so that the actual method of delivering files (.exe created with nsis or innosetup or installshield or maybe even an .msi) can be changed without affecting the functioning of the software. I believe it is important to have an end-user package named OpenSC. The download link for i386 installer is included in the wiki page together with some comments and questions. Unlike NSIS InnoSetup is a win32 application but I have successfully used it from wine. If you use Windows, give it a try. If you have thoughts on what the installer should do or what that specific instance does wrong, please either describe it on the the wiki page or post here. The .iss file used to create the installer is attached to the the wiki page. Eventually the file should be generated (to substitute version numbers etc) with configure and merged with the build system, which output it uses for the binary files. Request for comments. Eventually we'd need input from the folks on opensc-user as they should be the target audience for the installer. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changes to opensc-project.org certificate.
On Mar 22, 2010, at 23:22 , Martin Paljak wrote: > Hello, > > If your browser or SVN client is configured to warn you if the certificate of > the server has changed, don't be alarmed if you see tomorrow a new > certificate with the following fingerprints: > > SHA1: 17 BE 7F 71 EB 84 2D 91 B1 A4 36 D5 63 44 08 F7 4D 5F B5 1A > MD5: AF B0 2C BC 41 82 C0 DD A9 D8 BE 8D CE 7A B4 97 This change has been implemented. Hopefully potential new contributors will not be scared away by big red warning pages shown by some modern browsers. Also, the registration link of OpenSC trac is secured, so that the initial registration password would not be sent over the wire in clear. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] LGPL issues with dnielectronico.es and cartaodocidadao.pt
2010/3/23 Martin Paljak : > Hello, > > If no-one has any objections or improvements to the message, I'd like to send > the following e-mails to the official contact addresses of the two sites: > > > Dear Sir or Madam, > > My name is Martin Paljak and I'm writing on behalf of OpenSC project[1]. > > It has come to our attention that your organization is publicly > distributing[2] software that apparently contains code[3] from OpenSC > project, which is licensed under LGPL v2.1 of the License or (at your option) > any later version. The full text of the license is available online[4]. > > According to the LGPL license you need to provide the source code for the > modified work if requested. As we have not been able to locate the source > code from the website where you distribute the binaries, please provide us > with the source code in digital form. > > For your convenience this e-mail is digitally signed with my Estonian ID-card. > > Feel free to either e-mail OpenSC project directly via > opensc-de...@opensc-project.org mailing list[5] or contact me personally with > further questions. > > [1] http://www.opensc-project.org/opensc > [2] > http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/index.html > [3] http://www.opensc-project.org/opensc/ticket/205 > [4] http://www.gnu.org/licenses/lgpl-2.1.html > [5] http://www.opensc-project.org/opensc/wiki/MailingLists > > > All the best, > > -- > Martin Paljak > mar...@paljak.pri.ee / http://martin.paljak.pri.ee/ > GSM:+3725156495 > > > For Portugal the links would be: > > [1] http://www.opensc-project.org/opensc > [2] > http://www.cartaodocidadao.pt/index.php?option=com_content&task=view&id=102&Itemid=44&lang=pt > [3] http://www.opensc-project.org/opensc/ticket/204 > [4] http://www.gnu.org/licenses/lgpl-2.1.html > [5] http://www.opensc-project.org/opensc/wiki/MailingLists > > > Recipients would be: > For DNI: > - Dirección General de Policía y de la Guardia Civil > (from linux packages) > - s...@dnielectronico.es (from the web page) > - f...@fsfeurope.org (http://www.fsfe.org/projects/ftf/ftf.en.html) > - opensc-devel > > For PT eID: > - a...@ama.pt (apparently responsible for the procurement) > - cartaodecida...@dgrn.mj.pt (from the web page) > - f...@fsfeurope.org (http://www.fsfe.org/projects/ftf/ftf.en.html) > - opensc-devel This is OK for me. Maybe suggesting to email to opensc-de...@opensc-project.org is not a good idea if posting to the list is restricted to members of the list. Keep a eye on the rejected mails since some of them may be very important. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [RFC] starcos 3 driver
>> (It may burn your house, or your card, or you reader)
>> =>you have been warned :)
> Nice to know.
>
>
>> I don't know what is needed for a possible inclusion in opensc,
>> but in the future this may be an option, if anyone is interested
>> in this.
>> (At this point, it's only a snapshot of my development tree.)
> I think the first requirement would be to have a possibility to expose
> something (a > key or a PIN) via PKCS#11 or pkcs15-tool --dump.
Yes. this works. (I meant with "reading support" that -D works)
>
> If the card is available from a public source in quantities <=10 (a web shop)
> so that > anyone interested could buy it, there should be no restrictions
> other than readable > and functioning code.
I'm unsure about that. I got my card, which has a a pkcs15 struct on it
and a card which is now empty again :-) (for testing the write support.)
But a bit of googleing did not show a web shop where I can buy it.
(But this does not mean, that you cannot buy the cards, I simply havent
found a shop)
>
> Otherwise, for a closed or restricted card, decent documentation on the card
> is
> required and a responsible maintainer contact for the drvier
The documentation is available, as stated in the FAQ:
http://www.opensc-project.org/faq.html (under the starcos section)
(This should be no problem.)
>> If you have a comment ("RFC") what is missing, should be improved
>> etc... please post a reply.
> Some small comments-questions:
> - you seem to have diffed it against 0.11 not trunk.
> sc_ctx_suppress_errors_* is
> long gone for good.
I tried to diff against trunk, but noticed that the debugging macros changed,
so for now I use the stable release.(Is it really necessary to add ~20chars
in every debug call?)
> - please use the style guide http://www.opensc-project.org/opensc
Yes. I will do that.
> - don't use printf in libopensc/*
No problem. Currently its only a development version anyway.
> - is the card very different from the older starcos 2.3 driver?
Initially I started with the 2.3 driver, because I thought, its maybe changing
the ATR, fixing some smaller thing etc.., doing after that
some backporting with if/else constructs and then it works.
(Then I noticed that it wont be so easy.)
I hadn't any knowledge of smartcards and experimented much
with the original 2.3 code, thus there is not much left from it.
In other words, I started with the idea of a patch against 2.3, then I was
forced to do some refactoring, then some more.
Thus, I would say, they differ(in the context that the 2.3 driver needs
a refactoring.)
>If it would be small and simple, maybe a single starcos driver could do, with
>if-s for >different versions. (have not compared the files yet, just asking)
I had to rework the fci,fcp and in in combination with that the
select_file call, which then needed different cache handling.
Then I worked on the sec_env and because this seemed not to work at
all I experimented a lot with it, which means code rewrite etc...
Although, many apdu calls are still the same, like in the 2.3 driver.
> - do you have a manual for the card?
Yes.(But I cannot share it.)
> If there is a manual that defines different bits to set, maybe re-create the
> >constants by using bitwise operators instead of having a table of opaque
> constants >(sc_algo2apdu table)
This whole set_security_env is still a mystary, and it would be nice
to have more information in the code where the bits from opensc
go into the apdu call. But I have not found another solution yet
(and I doubt that there is anything possible), like getting the bits
from opensc and then altering matching bits for the apdu.
>> I know, that writing support is missing in the driver, but
>> up to now I haven't figured out how opensc and the pkcs15-init
>> mechanism works...(I think I already locked up one card with
>> writing, so you should definitely not try this)
> True, this is a bit complicated. I hope we can have a small howto for new
> card >drivers one day. I don't know the full story with PKCS#15
> initialization either, I >guess Viktor might be the best source for this
> information.
Up to now, I cannot even come up with a question, because I dont know
what to ask :-).
But I think I will figure out something.
regards,
Martin
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
