Re: [opensc-devel] Moving master forward

2012-01-07 Thread Jean-Michel Pouré - GOOZE 
Le jeudi 08 décembre 2011 à 21:32 +0200, Martin Paljak a écrit :
 * Github.com pull requests are automagically sent to Gerrit (polled
 every 5 minutes). This is a convenience method to get pull requests to
 a
 central location [1] [2], direct pushing to Gerrit's refs/for/staging
 should be preferred. 

Dear all,

I would like to understand more deeply. In the previous organization,
SVN would be the central place to receive all changes. This allowed
everyone to test development.

In the new GIT organization, does OpenSC staging branch receive
automatically all pull requests which are then built and tested by the
community?

The reason is that I would like to:
* test ePass2003_1 branch with latests Viktors branch.
* build installers for Windows and Mac OS X.

Kind regards,
Jean-Michel Pouré
-- 
  Jean-Michel Pouré - Gooze - http://www.gooze.eu


smime.p7s
Description: S/MIME cryptographic signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-23 Thread Viktor Tarasov 
Hello Martin,

spectacular advancement.


Le 08/12/2011 20:32, Martin Paljak a écrit :
 * Jenkins (build master) has been moved to opensc-project.org.
 opensc-project.org will move soonish (probably during the Christmas
 time) to a new bare metal home. This allows to run the builders close
 together on a decent machine. I'm thus consolidating all bits and pieces
 that are needed for running the site onto a single filesystem image for
 easy syncing before the IP address change. The new URL for Jenkins is:

   https://www.opensc-project.org:

For the Jenkins users, it would be nice to have possibility to change per-user 
Jenkins settings;
at least in the limits of build options and the (github ?) branch to pull 
source from.


 * Github.com pull requests are automagically sent to Gerrit (polled
 every 5 minutes). This is a convenience method to get pull requests to a
 central location [1] [2], direct pushing to Gerrit's refs/for/staging
 should be preferred.

I've tried to push directly my local 'OpenSC::staging' merged with SM branch,
but seems, do not have permission.

OpenSC.gerrit$ git push ssh://vik...@www.opensc-project.org:8882/OpenSC.git 
HEAD:refs/for/staging
Counting objects: 189, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (36/36), done.
Writing objects: 100% (132/132), 28.39 KiB, done.
Total 132 (delta 108), reused 118 (delta 96)
remote: Resolving deltas:   4% (5/108)
To ssh://vik...@www.opensc-project.org:8882/OpenSC.git
  ! [remote rejected] HEAD - refs/for/staging (you are not allowed to upload 
merges)
error: failed to push some refs to 
'ssh://vik...@www.opensc-project.org:8882/OpenSC.git'


 I fed Viktor's secure-messaging branch in whole to Gerrit (and thus also
 Jenkins for building),

Thanks,
now this branch is in more or less completed state.
So, if I do not permitted to do it, could you, please, fetch and push it to 
Gerrit yourself?
I will continue testing it with different cards and build options.


 and the reason why development must be separated
 from change proposals to master is obvious:

 https://www.opensc-project.org:/job/Gerrit_tarball_test/buildTimeTrend

 (or the unverified changes in Gerrit
 https://www.opensc-project.org:8881/#q,status:open,n,0019920500cf)

 Red parts of the graphic are commits that result in a stage where the
 tree does not build on Linux. Windows and OS X might probably be even
 more different (I'm working on getting Gerrit changes to be built and
 verified by default on Windows and OS X as well). While merging the tree
 in whole would result in a buildable state, it is not meaningful to have
 intermediate commits which are not meaningful enough or even put the
 tree in unstable state.

Until recently the SM branch was an experimental one,
and in that status, from my point of view, was permitted to be not be always 
'green' .
Well, I will try to use 'git rebase' more actively, when pushing out from the 
local repository.


Thank you for this nice work,
Viktor.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-16 Thread Viktor Tarasov 
Le 15/12/2011 19:22, Douglas E. Engert a écrit :

 On 12/15/2011 1:56 AM, Alon Bar-Lev wrote:
 On Thu, Dec 15, 2011 at 9:43 AM, Martin Paljakmar...@martinpaljak.net   
 wrote:
 On 15/12/11 01:43, Alon Bar-Lev wrote:
 Oh... I was so excited I missed some important issue.
 When submitting a patchset it should be tested for build as atomic unit.
 Currently the system tries to compile each changeset by it-self.
 Many times this will not work, as patchset is divided into logical
 sections suited for review not for build.
 I'd prefer the opposite, given your exact sample:
 It would be best if not a single commit would break the build, on any
 platform.

 It is probably a bit harder for some structural changes, but most
 probably possible.

 As said, I'm working on figuring out how to make the Gerrit changes
 autobuilds happen on all platforms (Windows included) as at the moment
 it is a simple Linux tarball build (the Gerrit configuration seems to be
 tied to master)

 Splitting patches would make sense if it really was a huge change per
 se, but it is not.

 Use git rebase --interactive to merge all these into a single commit
 with a descriptive commit message before publishing (melding in all
 those single line messages would also help)

 The goal is to separate development (small things patched together until
 it works) from releasing (meaningful changes with enough documentation)

 Fixing Windows build after a change that broke it is meaningful to me
 as a developer but useless for normal people. Removing libltdl
 dependency is understandable to a wider audience.

 Martin
 Here we completely disagree.
 The whole point of sending changes to review is to allow humans to go
 over code without actually building or testing and get valid feedback.
 Doing so on large changesets is something that is almost impossible.
 Well, maybe. But it also allows one to fetch, build *and* test.
 For example, by testing Viktor's SM patch, I found problems using
 cards that did not use SM.

SM branch just recently passed phase of active development,
it was not yet rigorously tested with the many card.
Any verbose feedback would be greatly appreciated.


 It is much easer to guide reviewer at the process of changes by
 splitting the change into logical pieces.
 Think of it as the story of the change presented by the developers to
 the audience without verbal synchronous meeting.
 It is not that each line of code should be split, but the main building 
 blocks.

 Alon.
 ___
 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] Moving master forward

2011-12-16 Thread Viktor Tarasov 
Le 15/12/2011 18:29, Douglas E. Engert a écrit :


 On 12/15/2011 4:47 AM, Viktor Tarasov wrote:
 Le 15/12/2011 09:21, Viktor Tarasov a écrit :
 Hello Douglas,


 Le 14/12/2011 23:11, Douglas E. Engert a écrit :

 On 12/14/2011 2:14 PM, Douglas E. Engert wrote:

 I am able to use the:
 https://www.opensc-project.org/codereview/
 and login with the Google account from work.
 Then find the changes from 12/8, which include Viktor's SM code that has 
 my ECDH
 code included:

 git clone -b staging 
 https://myuse...@www.opensc-project.org/codereview/p/OpenSC some_dir
 and
 git fetch https://myuse...@www.opensc-project.org/codereview/p/OpenSC 
 refs/changes/10/210/1

 Am testing it right now. There are some issues with the sc_app_info being 
 null.
 Hope to have a patch later today.

 Attached is a patch to Viktor's code as found on Gerrit I258bde6a. I added 
 a review
 to this but being new to Gerrit, I was not sure how to add the patch, of 
 if Viktor
 should add it, or if this is the right change to start with.

 I needed this patch to allow the PIV card with RSA to work with this code 
 base.
 it would not work with PKCS#11 as the framework-bind was not being called.
 After fixing that, there were a number of places where a NULL appl_info
 would cause a segfault. There may be other places too.

 I expect other cards that do not have an application to also fail.

 I started with this base because it has my ECDH code included, that I 
 still need to test.


 Ok, thanks.
 I will look, test and apply it into SM branch.

 https://github.com/viktorTarasov/OpenSC/commit/4352d9aed483010762c575b8bf09ae3023cb1b72
 https://github.com/viktorTarasov/OpenSC/commit/4a6e0d779578d009ebac7d3246a9a3a8e37eab14

 By the way, IMHO, the PIN flags of the PIV PKCS#15 emulated card should be 
 reconsidered.
 I would suggest to:
 - add 'INITIALIZED' flag;
 - remove 'LOCAL' (look ISO 7816-15 8.9.2 Password attributes). As for me, 
 every PIN without path has to be the 'global' one.

 The newer cards may have a Discovery Object that can specify
 if the Global PIN and/or the PIV card application PIN can be used,
 and which one the card holder prefers. NIST 800-73-3 Part 1 Section 3.2.6.

 The default if no Discovery object is found is LOCAL.
 What I should do is turn off the LOCAL bit, if the Discovery object says
 the Global PIN can be used. I already change the label, in pkcs15-piv.c
 if the Discovery object says use the Global PIN.

 I will add the INITIALIZED flag.

 NIST has looked at PIV vs PKCS15/ISO 7816-15 cards in 2006, but
 has not done anything about it:

 http://csrc.nist.gov/publications/nistir/ir7284/nistir-7284.pdf


Ok, essential in 'INITIALIZED' flag.

With 'LOCAL' flags as you like.
Just one note,
currently in restricted opensc-pkcs11 configuration (one slot for 'UserPIN') 
the 'UserPIN' is selected by pkcs11's 'pkcs15' framework following the rules:
- first 'global' PIN;
- if no 'global' PINs found -- first 'local' PIN.

These rules could not satisfy all card configurations, and so, are opened for 
suggestions.



 Kind regards,
 Viktor.



___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-15 Thread Viktor Tarasov 
Le 15/12/2011 09:21, Viktor Tarasov a écrit :
 Hello Douglas,


 Le 14/12/2011 23:11, Douglas E. Engert a écrit :

 On 12/14/2011 2:14 PM, Douglas E. Engert wrote:

 I am able to use the:
 https://www.opensc-project.org/codereview/
 and login with the Google account from work.
 Then find the changes from 12/8, which include Viktor's SM code that has my 
 ECDH
 code included:

git clone -b staging 
 https://myuse...@www.opensc-project.org/codereview/p/OpenSC some_dir
 and
git fetch https://myuse...@www.opensc-project.org/codereview/p/OpenSC 
 refs/changes/10/210/1

 Am testing it right now. There are some issues with the sc_app_info being 
 null.
 Hope to have a patch later today.

 Attached is a patch to Viktor's code as found on Gerrit I258bde6a. I added a 
 review
 to this but being new to Gerrit, I was not sure how to add the patch, of if 
 Viktor
 should add it, or if this is the right change to start with.

 I needed this patch to allow the PIV card with RSA to work with this code 
 base.
 it would not work with PKCS#11 as the framework-bind was not being called.
 After fixing that, there were a number of places where a NULL appl_info
 would cause a segfault. There may be other places too.

 I expect other cards that do not have an application to also fail.

 I started with this base because it has my ECDH code included, that I still 
 need to test.


 Ok, thanks.
 I will look, test and apply it into SM branch.

https://github.com/viktorTarasov/OpenSC/commit/4352d9aed483010762c575b8bf09ae3023cb1b72
https://github.com/viktorTarasov/OpenSC/commit/4a6e0d779578d009ebac7d3246a9a3a8e37eab14

By the way, IMHO, the PIN flags of the PIV PKCS#15 emulated card should be 
reconsidered.
I would suggest to:
- add 'INITIALIZED' flag;
- remove 'LOCAL' (look ISO 7816-15 8.9.2 Password attributes). As for me, 
every PIN without path has to be the 'global' one.

Kind regards,
Viktor.


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-15 Thread Douglas E. Engert 


On 12/15/2011 1:56 AM, Alon Bar-Lev wrote:
 On Thu, Dec 15, 2011 at 9:43 AM, Martin Paljakmar...@martinpaljak.net  
 wrote:
 On 15/12/11 01:43, Alon Bar-Lev wrote:
 Oh... I was so excited I missed some important issue.
 When submitting a patchset it should be tested for build as atomic unit.
 Currently the system tries to compile each changeset by it-self.
 Many times this will not work, as patchset is divided into logical
 sections suited for review not for build.

 I'd prefer the opposite, given your exact sample:
 It would be best if not a single commit would break the build, on any
 platform.

 It is probably a bit harder for some structural changes, but most
 probably possible.

 As said, I'm working on figuring out how to make the Gerrit changes
 autobuilds happen on all platforms (Windows included) as at the moment
 it is a simple Linux tarball build (the Gerrit configuration seems to be
 tied to master)

 Splitting patches would make sense if it really was a huge change per
 se, but it is not.

 Use git rebase --interactive to merge all these into a single commit
 with a descriptive commit message before publishing (melding in all
 those single line messages would also help)

 The goal is to separate development (small things patched together until
 it works) from releasing (meaningful changes with enough documentation)

 Fixing Windows build after a change that broke it is meaningful to me
 as a developer but useless for normal people. Removing libltdl
 dependency is understandable to a wider audience.

 Martin

 Here we completely disagree.
 The whole point of sending changes to review is to allow humans to go
 over code without actually building or testing and get valid feedback.
 Doing so on large changesets is something that is almost impossible.

Well, maybe. But it also allows one to fetch, build *and* test.
For example, by testing Viktor's SM patch, I found problems using
cards that did not use SM.

 It is much easer to guide reviewer at the process of changes by
 splitting the change into logical pieces.
 Think of it as the story of the change presented by the developers to
 the audience without verbal synchronous meeting.
 It is not that each line of code should be split, but the main building 
 blocks.

 Alon.
 ___
 opensc-devel mailing list
 opensc-devel@lists.opensc-project.org
 http://www.opensc-project.org/mailman/listinfo/opensc-devel



-- 

  Douglas E. Engert  deeng...@anl.gov
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Douglas E. Engert 


On 12/14/2011 8:13 AM, Martin Paljak wrote:
 Hello,

 On 09/12/11 22:14, Ludovic Rousseau wrote:
 2011/12/9 Alon Bar-Levalon.bar...@gmail.com:
 Can you set up standard ports so it passes firewalls?
 First choice: http / https
 Second choice: git/ssh

 Same question but to pass web proxies. git and ssh ports are not even
 available in some places.

 Reasonable reasons ;)


 Is it possible to use:
 https://jenkins.opensc-project.org/ instead of
 https://www.opensc-project.org:/

 https://www.opensc-project.org/autobuild/


 https://gerrit.opensc-project.org/ instead of
 https://www.opensc-project.org:8881/

 https://www.opensc-project.org/codereview/


 There is a single IP at the moment, nor are there proper
 (read:auto-green) certificates, nor my belief in SNI. Thus this kind of
 masking.

 It is possible to access Gerrit Git interface through HTTP (instructions
 pending) for pushing changes, also to check out code.

 Changing the URL of the Gerrit site resulted in invalid Google
 authentication tokens (which are bound to a URL) so after a login, new
 assignments to privileges must be made. I enabled an option to allow
 upgrading Google accounts based on e-mails, but it did not work for
 me. Maybe it works for you.

 Git-over-SSH should still be preferred and I guess is available as well,
 if not in a corporate environment, then at least elsewhere.

So are you saying, I should get my network people to open ports
8881 and  for me? (I can do that, but since others have the
same problem, I was waiting to see if there was some other
solution.)

Thanks.


 Martin
 ___
 opensc-devel mailing list
 opensc-devel@lists.opensc-project.org
 http://www.opensc-project.org/mailman/listinfo/opensc-devel



-- 

  Douglas E. Engert  deeng...@anl.gov
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Peter Stuge 
Martin Paljak wrote:
 It is possible to access Gerrit Git interface through HTTP (instructions
 pending) for pushing changes, also to check out code.

Feel free to reuse stuff from http://www.coreboot.org/Git


//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Peter Stuge 
Douglas E. Engert wrote:
  Is it possible to use:
  https://jenkins.opensc-project.org/ instead of
  https://www.opensc-project.org:/
 
  https://www.opensc-project.org/autobuild/
 
 
  https://gerrit.opensc-project.org/ instead of
  https://www.opensc-project.org:8881/
 
  https://www.opensc-project.org/codereview/

..

 So are you saying, I should get my network people to open ports
 8881 and  for me?

No, you can use these URLs:

https://www.opensc-project.org/autobuild/
https://www.opensc-project.org/codereview/

To access Jenkins and Gerrit respectively.


//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Alon Bar-Lev 
On Wed, Dec 14, 2011 at 4:49 PM, Peter Stuge pe...@stuge.se wrote:

 Douglas E. Engert wrote:
   Is it possible to use:
   https://jenkins.opensc-project.org/ instead of
   https://www.opensc-project.org:/
  
   https://www.opensc-project.org/autobuild/
  
  
   https://gerrit.opensc-project.org/ instead of
   https://www.opensc-project.org:8881/
  
   https://www.opensc-project.org/codereview/

 ..

  So are you saying, I should get my network people to open ports
  8881 and  for me?

 No, you can use these URLs:

 https://www.opensc-project.org/autobuild/
 https://www.opensc-project.org/codereview/

 To access Jenkins and Gerrit respectively.

This is great

I succeed in login to gerrit using google account.
How do I login to jenkins?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Alon Bar-Lev 
On Wed, Dec 14, 2011 at 5:13 PM, Alon Bar-Lev alon.bar...@gmail.com wrote:
 No, you can use these URLs:

 https://www.opensc-project.org/autobuild/
 https://www.opensc-project.org/codereview/

 To access Jenkins and Gerrit respectively.

 This is great

 I succeed in login to gerrit using google account.
 How do I login to jenkins?

First experience for me in Gerrit... I cannot reach port 8881 nothing
response there...
And the http://www.opensc-project/codereview/p/OpenSC.git is also not working.

Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Martin Paljak 
On 12/14/11 5:42 , Alon Bar-Lev wrote:
 On Wed, Dec 14, 2011 at 5:13 PM, Alon Bar-Lev alon.bar...@gmail.com wrote:
 No, you can use these URLs:

 https://www.opensc-project.org/autobuild/
 https://www.opensc-project.org/codereview/

 To access Jenkins and Gerrit respectively.

 This is great

 I succeed in login to gerrit using google account.
 How do I login to jenkins?
 
 First experience for me in Gerrit... I cannot reach port 8881 nothing
 response there...
 And the http://www.opensc-project/codereview/p/OpenSC.git is also not working.


Why such URL, have I made a mistake somewhere and you get this link from
somewhere ?

The URL for accessing Git through Gerrit over https would be:

https://www.opensc-project.org/codereview/gitweb?p=OpenSC.git;a=summary

If you have logged on in /codereview, it would also give the SSH remote
addresses, for what you can get the password from

https://www.opensc-project.org/codereview/#settings,http-password



-- 
@MartinPaljak
+3725156495
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Martin Paljak 
On 12/14/11 5:13 , Alon Bar-Lev wrote:
 This is great
 
 I succeed in login to gerrit using google account.
 How do I login to jenkins?
Actually there is no similar SSO readily available for Jenkins, nor
should it be necessary. Jenkins should work semi-automatically by
building the branches/trees/changes it has to, like pre-building Gerrit
changes or any other trees.

The setup is manual, any repository is polled every X minutes, and
builds created and uploaded as needed. Jenkins must be publicly
available to see the status (green/red button) and any output (Gerrit
can nicely cross-reference builds and Jenkins build results)

Given that I have remotely recovered access to an otherwise
disconnected linux host running the Windows VM-s (SSH tunneling) through
a custom job on the Windows guest I'd prefer to keep the
configurations under close inspection. If you have


Martin
-- 
@MartinPaljak
+3725156495
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Martin Paljak 
On 12/14/11 4:40 , Douglas E. Engert wrote:
 
 So are you saying, I should get my network people to open ports
 8881 and  for me? (I can do that, but since others have the
 same problem, I was waiting to see if there was some other
 solution.)

No. Everything should be doable over http(s) but having git port open
would probably be useful every now and then nevertheless.

Beware, that the actual IP of opensc-project.org shall change around
Christmas/NewYear.

Martin


-- 
@MartinPaljak
+3725156495
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Douglas E. Engert 


On 12/14/2011 12:51 PM, Martin Paljak wrote:
 On 12/14/11 4:40 , Douglas E. Engert wrote:

 So are you saying, I should get my network people to open ports
 8881 and  for me? (I can do that, but since others have the
 same problem, I was waiting to see if there was some other
 solution.)

 No. Everything should be doable over http(s) but having git port open
 would probably be useful every now and then nevertheless.

 Beware, that the actual IP of opensc-project.org shall change around
 Christmas/NewYear.

 Martin


It looks like the URLs are working, so don't have problems with the local 
firewall!

I am able to use the:
https://www.opensc-project.org/codereview/
and login with the Google account from work.
Then find the changes from 12/8, which include Viktor's SM code that has my ECDH
code included:

  git clone -b staging 
https://myuse...@www.opensc-project.org/codereview/p/OpenSC some_dir
and
  git fetch https://myuse...@www.opensc-project.org/codereview/p/OpenSC 
refs/changes/10/210/1

Am testing it right now. There are some issues with the sc_app_info being null.
Hope to have a patch later today.



-- 

  Douglas E. Engert  deeng...@anl.gov
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Douglas E. Engert 



On 12/14/2011 2:14 PM, Douglas E. Engert wrote:



I am able to use the:
https://www.opensc-project.org/codereview/
and login with the Google account from work.
Then find the changes from 12/8, which include Viktor's SM code that has my ECDH
code included:

   git clone -b staging 
https://myuse...@www.opensc-project.org/codereview/p/OpenSC some_dir
and
   git fetch https://myuse...@www.opensc-project.org/codereview/p/OpenSC 
refs/changes/10/210/1

Am testing it right now. There are some issues with the sc_app_info being null.
Hope to have a patch later today.


Attached is a patch to Viktor's code as found on Gerrit I258bde6a. I added a 
review
to this but being new to Gerrit, I was not sure how to add the patch, of if 
Viktor
should add it, or if this is the right change to start with.

I needed this patch to allow the PIV card with RSA to work with this code base.
it would not work with PKCS#11 as the framework-bind was not being called.
After fixing that, there were a number of places where a NULL appl_info
would cause a segfault. There may be other places too.

I expect other cards that do not have an application to also fail.

I started with this base because it has my ECDH code included, that I still 
need to test.







--

 Douglas E. Engert  deeng...@anl.gov
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444
From 6013b7e6d375c13bcbfa074c05758fe46c259122 Mon Sep 17 00:00:00 2001
From: Doug Engert deeng...@anl.gov
Date: Wed, 14 Dec 2011 15:20:17 -0600
Subject: [PATCH] sc_appl_info may be NULL for cards without applications Add
 additional checks for sc_app_info being NULL as some cards
 do not have an application, or only one application. In
 slot.c frameworks[i]-bind was not being called for these
 cards.

---
 src/libopensc/pkcs15.c|5 -
 src/pkcs11/framework-pkcs15.c |2 +-
 src/pkcs11/slot.c |9 -
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/libopensc/pkcs15.c b/src/libopensc/pkcs15.c
index 643fbd6..33ff71a 100644
--- a/src/libopensc/pkcs15.c
+++ b/src/libopensc/pkcs15.c
@@ -862,7 +862,10 @@ struct sc_app_info * sc_find_app(struct sc_card *card, struct sc_aid *aid)
 
 static struct sc_app_info *sc_dup_app_info(const struct sc_app_info *info)
 {
-	struct sc_app_info *out = calloc(1, sizeof(struct sc_app_info));
+	struct sc_app_info *out = NULL; 
+
+	if (info) 
+	out = calloc(1, sizeof(struct sc_app_info));
 
 	if (!out)
 		return NULL;
diff --git a/src/pkcs11/framework-pkcs15.c b/src/pkcs11/framework-pkcs15.c
index a2a6c08..d1b6342 100644
--- a/src/pkcs11/framework-pkcs15.c
+++ b/src/pkcs11/framework-pkcs15.c
@@ -281,7 +281,7 @@ pkcs15_init_token_info(struct sc_pkcs15_card *p15card, CK_TOKEN_INFO_PTR pToken)
 	strcpy_bp(pToken-manufacturerID, p15card-tokeninfo-manufacturer_id, 32);
 
 	p11_conf_block = sc_get_conf_block(p15card-card-ctx, pkcs11, NULL, 1);
-	if (p11_conf_block)   {
+	if (p11_conf_block  p15card-file_app)   {
 		scconf_block **blocks = NULL;
 		char str_path[SC_MAX_AID_STRING_SIZE];
 
diff --git a/src/pkcs11/slot.c b/src/pkcs11/slot.c
index 08f15ca..eccae3c 100644
--- a/src/pkcs11/slot.c
+++ b/src/pkcs11/slot.c
@@ -285,7 +285,14 @@ CK_RV card_detect(sc_reader_t *reader)
 
 		/* Initialize framework */
 		sc_log(context, %s: Detected framework %d. Creating tokens., reader-name, i);
-		if (app_generic)   {
+/* DEE Looks like a bug. Many cards may not have apps, and
+ * get_generic_application may return NULL
+ * bind and create_tokens tests for NULL,
+ * But other locations may not. 
+ * in this case frameworks[i]-bind is never called.
+ * Will try and see if NULL works...
+ */
+		if (1 /*app_generic*/)   {
 			rv = frameworks[i]-bind(p11card, app_generic);
 			sc_log(context, %s: generic bind result %i, reader-name, rv);
 			if (rv != CKR_OK)
-- 
1.7.5.4

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Alon Bar-Lev 
On Wed, Dec 14, 2011 at 8:41 PM, Martin Paljak mar...@martinpaljak.net wrote:
 On 12/14/11 5:13 , Alon Bar-Lev wrote:
 This is great

 I succeed in login to gerrit using google account.
 How do I login to jenkins?
 Actually there is no similar SSO readily available for Jenkins, nor
 should it be necessary. Jenkins should work semi-automatically by
 building the branches/trees/changes it has to, like pre-building Gerrit
 changes or any other trees.

 The setup is manual, any repository is polled every X minutes, and
 builds created and uploaded as needed. Jenkins must be publicly
 available to see the status (green/red button) and any output (Gerrit
 can nicely cross-reference builds and Jenkins build results)

 Given that I have remotely recovered access to an otherwise
 disconnected linux host running the Windows VM-s (SSH tunneling) through
 a custom job on the Windows guest I'd prefer to keep the
 configurations under close inspection. If you have


This is just great!
I could not believe it!
I posted pull request, automatically transfered to gerrit, and to
jenkins to build, while result is reported back!!!
Great work!
And I thought I need to push to gerrit and handle the cycle...
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Alon Bar-Lev 
On Thu, Dec 15, 2011 at 1:41 AM, Alon Bar-Lev alon.bar...@gmail.com wrote:
 On Wed, Dec 14, 2011 at 8:41 PM, Martin Paljak mar...@martinpaljak.net 
 wrote:
 On 12/14/11 5:13 , Alon Bar-Lev wrote:
 This is great

 I succeed in login to gerrit using google account.
 How do I login to jenkins?
 Actually there is no similar SSO readily available for Jenkins, nor
 should it be necessary. Jenkins should work semi-automatically by
 building the branches/trees/changes it has to, like pre-building Gerrit
 changes or any other trees.

 The setup is manual, any repository is polled every X minutes, and
 builds created and uploaded as needed. Jenkins must be publicly
 available to see the status (green/red button) and any output (Gerrit
 can nicely cross-reference builds and Jenkins build results)

 Given that I have remotely recovered access to an otherwise
 disconnected linux host running the Windows VM-s (SSH tunneling) through
 a custom job on the Windows guest I'd prefer to keep the
 configurations under close inspection. If you have


 This is just great!
 I could not believe it!
 I posted pull request, automatically transfered to gerrit, and to
 jenkins to build, while result is reported back!!!
 Great work!
 And I thought I need to push to gerrit and handle the cycle...

Oh... I was so excited I missed some important issue.
When submitting a patchset it should be tested for build as atomic unit.
Currently the system tries to compile each changeset by it-self.
Many times this will not work, as patchset is divided into logical
sections suited for review not for build.

Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Martin Paljak 
On 15/12/11 01:43, Alon Bar-Lev wrote:
 Oh... I was so excited I missed some important issue.
 When submitting a patchset it should be tested for build as atomic unit.
 Currently the system tries to compile each changeset by it-self.
 Many times this will not work, as patchset is divided into logical
 sections suited for review not for build.

I'd prefer the opposite, given your exact sample:
It would be best if not a single commit would break the build, on any
platform.

It is probably a bit harder for some structural changes, but most
probably possible.

As said, I'm working on figuring out how to make the Gerrit changes
autobuilds happen on all platforms (Windows included) as at the moment
it is a simple Linux tarball build (the Gerrit configuration seems to be
tied to master)

Splitting patches would make sense if it really was a huge change per
se, but it is not.

Use git rebase --interactive to merge all these into a single commit
with a descriptive commit message before publishing (melding in all
those single line messages would also help)

The goal is to separate development (small things patched together until
it works) from releasing (meaningful changes with enough documentation)

Fixing Windows build after a change that broke it is meaningful to me
as a developer but useless for normal people. Removing libltdl
dependency is understandable to a wider audience.

Martin
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-14 Thread Alon Bar-Lev 
On Thu, Dec 15, 2011 at 9:43 AM, Martin Paljak mar...@martinpaljak.net wrote:
 On 15/12/11 01:43, Alon Bar-Lev wrote:
 Oh... I was so excited I missed some important issue.
 When submitting a patchset it should be tested for build as atomic unit.
 Currently the system tries to compile each changeset by it-self.
 Many times this will not work, as patchset is divided into logical
 sections suited for review not for build.

 I'd prefer the opposite, given your exact sample:
 It would be best if not a single commit would break the build, on any
 platform.

 It is probably a bit harder for some structural changes, but most
 probably possible.

 As said, I'm working on figuring out how to make the Gerrit changes
 autobuilds happen on all platforms (Windows included) as at the moment
 it is a simple Linux tarball build (the Gerrit configuration seems to be
 tied to master)

 Splitting patches would make sense if it really was a huge change per
 se, but it is not.

 Use git rebase --interactive to merge all these into a single commit
 with a descriptive commit message before publishing (melding in all
 those single line messages would also help)

 The goal is to separate development (small things patched together until
 it works) from releasing (meaningful changes with enough documentation)

 Fixing Windows build after a change that broke it is meaningful to me
 as a developer but useless for normal people. Removing libltdl
 dependency is understandable to a wider audience.

 Martin

Here we completely disagree.
The whole point of sending changes to review is to allow humans to go
over code without actually building or testing and get valid feedback.
Doing so on large changesets is something that is almost impossible.
It is much easer to guide reviewer at the process of changes by
splitting the change into logical pieces.
Think of it as the story of the change presented by the developers to
the audience without verbal synchronous meeting.
It is not that each line of code should be split, but the main building blocks.

Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-10 Thread Alon Bar-Lev 
On Sat, Dec 10, 2011 at 10:39 AM, Peter Stuge pe...@stuge.se wrote:
 Ludovic Rousseau wrote:
  Can you set up standard ports so it passes firewalls?
  First choice: http / https

 Same question but to pass web proxies. git and ssh ports are not
 even available in some places.

 Note that Gerrit supports also HTTP push and pull, and http: is no
 longer significantly more inefficient than git:. (Since git 1.6.7
 IIRC.

 I guess the services run in virtual machines, and that there is not
 an abundance of public IP addresses. This would make it neccessary to
 proxy all HTTP requests, which would suck because in the
 corresponding virtual machines it would be difficult to distinguish
 different connected clients. This matters not at all for using the
 services, but it does matter some for administration. :\

Never had this problem, you can always pass an header with the originating IP.

Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Moving master forward.

2011-12-09 Thread Martin Paljak 
Hello,

Here is an overview of updates to opensc-project.org plumbing and Git.

* Jenkins (build master) has been moved to opensc-project.org.
opensc-project.org will move soonish (probably during the Christmas
time) to a new bare metal home. This allows to run the builders close
together on a decent machine. I'm thus consolidating all bits and pieces
that are needed for running the site onto a single filesystem image for
easy syncing before the IP address change. The new URL for Jenkins is:

 https://www.opensc-project.org:/

* Gerrit code review has been set up to manage the construction of the
staging branch. All patches sent to Gerrit get automatically built and
verified by Jenkins (currently on Linux only, unfortunately). Commits
that don't build shall get Verified = - 1 automatically and should not
be processed further. Gerrit uses OpenID for authentication (google.com
has one, as do many other websites) thus no new passwords needed. Gerrit
is accessible on:

 https://www.opensc-project.org:8881/

Go and log in/register, the existing list shall be included in the
submitters group.

* Github.com pull requests are automagically sent to Gerrit (polled
every 5 minutes). This is a convenience method to get pull requests to a
central location [1] [2], direct pushing to Gerrit's refs/for/staging
should be preferred.

* Because of Gerrit, the majority of Git plumbing is kept on
opensc-project.org site. Github integration script makes sure that
master and staging branches are available on github.com/OpenSC/OpenSC
while picking up pull requests from Github. Github is thus acting more
or less like off-site backup of source code.

* Signing of OpenSC source releases
I'm planning to sign the next release of OpenSC with GnuPG. OpenPGP v2.0
cards or the GPF CryptoStick token (supported by OpenSC to some extent)
are currently the best RSA hardware readily available, supporting up
to 4096bit keys. After some tweaking it is possible to use it with
Thunderbird/PKCS#11 but co-operation (and initialization with OpenSC)
requires some further work.

* Removing password logins from opensc-project.org ?
By relying on OpenID and SSH keys, opensc-project.org would be a much
safer place as there are no secrets to guard on the site (except for
internal passwords for databases etc) and it is also easier on users, as
there are less things to remember.


== Moving master forward, AKA how to create staging ==

Preparing the next master, please keep in mind:
 - the idea is to keep development separate from releasing, so to say.
 - to have meaningful changes with enough review and documentation go
into the master release history.
 - git rebase --interactive can do miracles on development trees
 - commit messages are supposed to be meaningful. There is some ideas
and links on DevelopmentPolicy wiki page.
 - have topic branches. Seriously. Many.

I fed Viktor's secure-messaging branch in whole to Gerrit (and thus also
Jenkins for building), and the reason why development must be separated
from change proposals to master is obvious:

https://www.opensc-project.org:/job/Gerrit_tarball_test/buildTimeTrend

(or the unverified changes in Gerrit
https://www.opensc-project.org:8881/#q,status:open,n,0019920500cf)

Red parts of the graphic are commits that result in a stage where the
tree does not build on Linux. Windows and OS X might probably be even
more different (I'm working on getting Gerrit changes to be built and
verified by default on Windows and OS X as well). While merging the tree
in whole would result in a buildable state, it is not meaningful to have
intermediate commits which are not meaningful enough or even put the
tree in unstable state.

git rebase --interactive / git commit --amend is the preferred method of
fixing such issues. The NightlyBuilds machinery (meaning a tree per
developer) is supposed to help by providing access to all released
platforms to all developers in a convenient way in terms of
building/packaging changes for testing. But the branch to be built is
not even supposed to be be the main development branch.

What I suggest:

Have:
master (master branch, from opensc-project.org, ff-only updates to this)
staging (staging branch, from opensc-project.org, used to send patches
to Gerrit and to rebase against staging on opensc-project.org. Used to
build pre-releases)
nightly (fed to Jenkins for building. reset/rebased/deleted as needed by
a person. Constructed by merging topic branches as needed for
distributing changes and testing building against the infrastructure)
topic-a (to help separate a logical change and to help communicate it to
others)
topic-b (ditto)
topic-c (ditto)


More tomorrow.


[1] http://zbowling.github.com/blog/2011/11/25/github/
[2] http://v3.sk/~lkundrak/blog/entries/github-ribbons.html
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-09 Thread Peter Stuge 
Martin Paljak wrote:
 Here is an overview of updates to opensc-project.org plumbing and Git.

Amazing effort Martin. Thank you so much for getting this done!


 Gerrit uses OpenID for authentication (google.com has one, as do
 many other websites) thus no new passwords needed.

In case anyone needs an OpenID please send me an email with your
name, your prefered username and md5(yourdesiredpassword) and I will
make one for you.

You will then need to add two elements into head on any web page
that you control, and the URL for that web page will be your OpenID,
which some other sites will show as your username.


//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Moving master forward

2011-12-09 Thread Alon Bar-Lev 
Can you set up standard ports so it passes firewalls?
First choice: http / https
Second choice: git/ssh

On Thu, Dec 8, 2011 at 9:32 PM, Martin Paljak mar...@martinpaljak.net wrote:
 Hello,

 Here is an overview of updates to opensc-project.org plumbing and Git.

 * Jenkins (build master) has been moved to opensc-project.org.
 opensc-project.org will move soonish (probably during the Christmas
 time) to a new bare metal home. This allows to run the builders close
 together on a decent machine. I'm thus consolidating all bits and pieces
 that are needed for running the site onto a single filesystem image for
 easy syncing before the IP address change. The new URL for Jenkins is:

  https://www.opensc-project.org:/

 * Gerrit code review has been set up to manage the construction of the
 staging branch. All patches sent to Gerrit get automatically built and
 verified by Jenkins (currently on Linux only, unfortunately). Commits
 that don't build shall get Verified = - 1 automatically and should not
 be processed further. Gerrit uses OpenID for authentication (google.com
 has one, as do many other websites) thus no new passwords needed. Gerrit
 is accessible on:

  https://www.opensc-project.org:8881/

 Go and log in/register, the existing list shall be included in the
 submitters group.

 * Github.com pull requests are automagically sent to Gerrit (polled
 every 5 minutes). This is a convenience method to get pull requests to a
 central location [1] [2], direct pushing to Gerrit's refs/for/staging
 should be preferred.

 * Because of Gerrit, the majority of Git plumbing is kept on
 opensc-project.org site. Github integration script makes sure that
 master and staging branches are available on github.com/OpenSC/OpenSC
 while picking up pull requests from Github. Github is thus acting more
 or less like off-site backup of source code.

 * Signing of OpenSC source releases
 I'm planning to sign the next release of OpenSC with GnuPG. OpenPGP v2.0
 cards or the GPF CryptoStick token (supported by OpenSC to some extent)
 are currently the best RSA hardware readily available, supporting up
 to 4096bit keys. After some tweaking it is possible to use it with
 Thunderbird/PKCS#11 but co-operation (and initialization with OpenSC)
 requires some further work.

 * Removing password logins from opensc-project.org ?
 By relying on OpenID and SSH keys, opensc-project.org would be a much
 safer place as there are no secrets to guard on the site (except for
 internal passwords for databases etc) and it is also easier on users, as
 there are less things to remember.


 == Moving master forward, AKA how to create staging ==

 Preparing the next master, please keep in mind:
  - the idea is to keep development separate from releasing, so to say.
  - to have meaningful changes with enough review and documentation go
 into the master release history.
  - git rebase --interactive can do miracles on development trees
  - commit messages are supposed to be meaningful. There is some ideas
 and links on DevelopmentPolicy wiki page.
  - have topic branches. Seriously. Many.

 I fed Viktor's secure-messaging branch in whole to Gerrit (and thus also
 Jenkins for building), and the reason why development must be separated
 from change proposals to master is obvious:

 https://www.opensc-project.org:/job/Gerrit_tarball_test/buildTimeTrend

 (or the unverified changes in Gerrit
 https://www.opensc-project.org:8881/#q,status:open,n,0019920500cf)

 Red parts of the graphic are commits that result in a stage where the
 tree does not build on Linux. Windows and OS X might probably be even
 more different (I'm working on getting Gerrit changes to be built and
 verified by default on Windows and OS X as well). While merging the tree
 in whole would result in a buildable state, it is not meaningful to have
 intermediate commits which are not meaningful enough or even put the
 tree in unstable state.

 git rebase --interactive / git commit --amend is the preferred method of
 fixing such issues. The NightlyBuilds machinery (meaning a tree per
 developer) is supposed to help by providing access to all released
 platforms to all developers in a convenient way in terms of
 building/packaging changes for testing. But the branch to be built is
 not even supposed to be be the main development branch.

 What I suggest:

 Have:
 master (master branch, from opensc-project.org, ff-only updates to this)
 staging (staging branch, from opensc-project.org, used to send patches
 to Gerrit and to rebase against staging on opensc-project.org. Used to
 build pre-releases)
 nightly (fed to Jenkins for building. reset/rebased/deleted as needed by
 a person. Constructed by merging topic branches as needed for
 distributing changes and testing building against the infrastructure)
 topic-a (to help separate a logical change and to help communicate it to
 others)
 topic-b (ditto)
 topic-c (ditto)


 More tomorrow.


 [1]