OpenSC write access to main trunk, discussion

[Jean-Michel Pouré - GOOZE]

Dear all,

I just got in contact with Stef Walter, who is integrating libp11-glue
into Gnome and Gnome keyring.

He outlines that libp11-glue needs this patch:
PKCS#11 module shouldn't fail if mlock doesn't work
http://www.opensc-project.org/opensc/ticket/389

This patch and other waiting patches raise the question of OpenSC
guidance and the need to have more commiters to OpenSC main GIT.

Martin, would you agree to add Viktor as a major OpenSC GIT member with
power to apply patches to main GIT trunk? I don't want to be paranoid,
but we need a more flexible approach rather than just Martin and Ludovic
applying and reviewing patches.

We discussed that at FOSDEM in a small audience, but I would like to
discuss that issue in public and have your own opinion. Who would like
OpenSC GITHUB to be REALLY in control of the community? Martin and
Ludovic, could you agree to open your group to other members of the
community?

Community, please advice and discuss this issue.

Kind regards,
Jean-Michel

[Douglas E. Engert]

Post by Jean-Michel Pouré - GOOZE
Dear all,
I just got in contact with Stef Walter, who is integrating libp11-glue
into Gnome and Gnome keyring.
PKCS#11 module shouldn't fail if mlock doesn't work
http://www.opensc-project.org/opensc/ticket/389
This patch and other waiting patches raise the question of OpenSC
guidance and the need to have more commiters to OpenSC main GIT.
Martin, would you agree to add Viktor as a major OpenSC GIT member with
power to apply patches to main GIT trunk? I don't want to be paranoid,
but we need a more flexible approach rather than just Martin and Ludovic
applying and reviewing patches.
We discussed that at FOSDEM in a small audience, but I would like to
discuss that issue in public and have your own opinion. Who would like
OpenSC GITHUB to be REALLY in control of the community? Martin and
Ludovic, could you agree to open your group to other members of the
community?

The question is not so much who is on the commiter list, but do commits
get made when needed, and who decides a commit is ready and should be made.

There are minor fixes, like 389 that is 4 months old with an additional
fix 2 months ago, and looks like it needs to be made, as well as major
changes such as the SM, ePass2003, and the ECDH modifications.

Personally, I am quite interested in getting the ECDH in to the next
release with or without the SM code and am willing to rebase the
modifications as needed. I believe the ECDH has been ready for months.

Viktor pulled the ECDH modifications into his SM on October 4, 2011 and
he also pulled in the ePass2003 on January 29.

The way forward is not necessarily more commiters, but a plan
for the next release and some action.

So can we consider adding ePass2003, SM, and ECDH to the next release
as these are already being tested together.

If giving Viktor commit authority would speed up the inclusion of both small
and larger modifications, it would be OK with me. If we can get these
included without giving him commit authority, that would be OK
with me too. But we need action.

Post by Jean-Michel Pouré - GOOZE
Community, please advice and discuss this issue.
Kind regards,
Jean-Michel
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Alon Bar-Lev]

Hello,

Post by Douglas E. Engert
The way forward is not necessarily more commiters, but a plan
for the next release and some action.

Well, once there was maintainer for each subject, so if maintainer of
(in this case) ePass2003 decides to put a specific implementation it
should be OK.

If another one is working on SM and it effects only specific drivers, why not?

For example, I don't think I need to beg to include the removal of the
libltdl dependency should be trivial even if I got this only 99%.

This project loses its flexibility, this is not an advantage.

You can decide which feature goes to which milestone, and cooperate
with people within different branches.

Alon.

[Peter Stuge]

Post by Alon Bar-Lev
This project loses its flexibility, this is not an advantage.

I disagree. I find that Git allows all the flexibility developers
could ask for.

The cry for more committers is misguided. With Git, anyone and
everyone is a committer. If commits exist but are not being included
in the main repository then it is most likely because they need more
work. The effort required to include a perfect patch is next to zero.

The question is if a project will insist on perfect patches (e.g.
Linux) or if anyone should be allowed to commit anything to the main
repo. Inkscape apparently did the latter, and it resulted in a
massive janitorial workload to clean up the horrible mess that had
been created. No fun.

Consider also that addition of commits without review will quite
likely introduce bugs which would have been discovered by peers. I
think this fact alone is reason enough for OpenSC to not include a
single line which hasn't been reviewed rather thoroughly. The review
process could even be formalized and made into a strict requirement
before writes to the main repo are possible.

I understand that Gooze and others have strong interest in inclusion
of changes into OpenSC. The only way to make that happen is what
Douglas described; put in the work, and create perfect patches.

Write access to some repository is not the issue. The whole world
already has Git write access. If someone needs help with publishing a
repository then feel free to let me know.

If you have prepared a patch which you think is perfect but noone is
responding then give it a thorough review yourself, and try again.
Also try discussing the change, explaining it in an email can be a
great way to produce a better commit message, which is very important
for anyone who is doing review.

Note that review does not mean to browse through the change and say
"looks ok", but it means to understand the effects of every changed
line. This can require a lot of context and/or research.

You can help by that commit be included by doing review. You doing
review is infinitely more important than you having write access to
some repository.


//Peter

[Jean-Michel Pouré - GOOZE]

Post by Peter Stuge
The cry for more committers is misguided. With Git, anyone and
everyone is a committer. If commits exist but are not being included
in the main repository then it is most likely because they need more
work. The effort required to include a perfect patch is next to zero.

The question here is flexibility:

* OpenSC used to have a very flexible approach. OpenSC is NOT kernel.org
with thousands of developers and no need for hierarchy.

* Setting-up a compilation farm is no reason for closing write access to
historical developers of OpenSC.

* Discussions are the base of Free Software. Once discussions have
occurred, there should be several people with write access. You have to
trust people. No need to lock write access to the main GIT.

From my point of view, OpenSC is becoming a semi-private project with
two people in charge: Ludovic and Martin. Personally, I don't want
OpenSC to be organized the same way as libccid.

We demand more freedom and transparency or this can only lead to endless
flamewars.

Keep in mind that before doing business, I have been a politician
fighting during 4 years for more freedom. Now I am retired, but if need
be, we will create a charity for OpenSC and organize a duly elected
board. I am not talking about a fork, which will never happen, but about
elections.

Kind regards,

[Peter Stuge]

Post by Jean-Michel Pouré - GOOZE

With Git, anyone and everyone is a committer.

What flexibility is needed? My point is that everyone can easily
create perfect patches, and given perfect patches which have been
peer reviewed there is no need for flexibility as in lots of people
with write access to the main repository. Even just one person can
easily handle that effort, like Linus shows in the much larger
kernel project.

Post by Jean-Michel Pouré - GOOZE
* OpenSC used to have a very flexible approach. OpenSC is NOT
kernel.org with thousands of developers and no need for hierarchy.

OpenSC is smaller, but I do not agree that there is no need for any
kind of hierarchy. Now, please understand that this is not about
power hierarchy as in politics, but it is about technical experience
with the code and with the problem domain.

I am personally familiar with the smart card domain but I haven't
spent much time with the OpenSC codebase and therefore I absolutely
do not want some patch I create to be included without being reviewed
first.

The review is criticial. Especially in a codebase like OpenSC, to
which I might indeed delegate my legal authority, I want the review
to be merciless.

Don't make the mistake of believing that only people with write
access can do review. It is quite the opposite. I have been trying
to make this point many times before, but it seems difficult for many
to grasp that all peer review is helpful and important for the
codebase, regardless of who is doing it. Everyone who cares about a
software can and should help with review.

A side effect of doing review is of course that knowledge about the
codebase increases in the community. After having done some amount of
review, people might even get write access, because they have
demonstrated that they can be trusted. This is demonstrated by
finding difficult-to-spot problems in others' patches. It is not
demonstrated by quickly giving every patch a thumbs-up.

Some say that it feels pointless to do review for someone who does
not have write access. I disagree with this, and I think this is a
very dangerous, almost complacent, attitude. If you do not believe
that your review is worth anything to those with write access, why
should you yourself have write access? This becomes a negative spiral
where in the end a project has no resources to do review, simply
because people do not have enough self-esteem to believe that the
review they can contribute matters. I don't know what the answer is.
I've tried time and time again to convince people that doing review
is helpful and important and a significant contribution to any
project, but it often doesn't really stick.

Post by Jean-Michel Pouré - GOOZE
* Setting-up a compilation farm is no reason for closing write access
to historical developers of OpenSC.

I agree, but I don't think one has anything to do with the other,
even if they happened at the same time. I guess that anyone who had
write access to the repository earlier can get it again if they just
send a public ssh key and their prefered username.

Post by Jean-Michel Pouré - GOOZE
* Discussions are the base of Free Software. Once discussions have
occurred, there should be several people with write access. You
have to trust people. No need to lock write access to the main GIT.

I disagree about having to trust people out of the blue. Generally,
people write really shitty software, and the poor way that a lot of
open source software works is all the proof we need.

I love open source, not neccessarily because it is technically
superior, but because it allows *me* to fix things which are broken.

I believe that open source is as good as it is primarily thanks to
the practise of peer review.

The purpose of more write access as far as I can see is to have
faster, ie. less well reviewed and thus less well understood, changes
in the main repo. I do not agree at all with that goal.

Post by Jean-Michel Pouré - GOOZE
From my point of view, OpenSC is becoming a semi-private project
with two people in charge: Ludovic and Martin. Personally, I don't
want OpenSC to be organized the same way as libccid.

I find both Martin and Ludovic to be quite reasonable people. I've
never had any problem discussing any issue with them, actually quite
the opposite.

If there are perfect patches (well reviewed, well understood) then I
am convinced that they would race each other to add those patches
into the repository.

I have no experience from libccid development, but I'm happy with it
as a user, so Ludovic must be doing something right.

Post by Jean-Michel Pouré - GOOZE
We demand more freedom and transparency or this can only lead to
endless flamewars.

Let's focus on a concrete problem. Have you created a patch which has
been peer reviewed and is well understood, but has been rejected by
Martin and Ludovic? If yes, let's try to find a solution. If no, you
can't really demand more freedom and transparency, because you
haven't exercised the freedom to create perfect patches yet.

I did review the epass2003 commits when their availability was
announced, and I've looked at the entersafe github account
again just now. Here is some feedback:

There are three branches; ePass2003_1, epass2003 and ep2k3. These
names are non-descript.

Commit 902e637c is quite long with over 2k lines added for the card
driver. That seems much to me. It's infeasible for me as careful
programmer but OpenSC internals newbie to review this code. My gut
feeling is that much of the code could be factored out.

The commits are not very well described in the commit messages.

The commits include unrelated changes.

The commits include whitespace changes mixed with actual code
changes.

The following commit undoes some of the unrelated changes in the
previous one.

This is what was immediately obvious to me just by looking at one and
a half commits in one of the branches. The things I point out above
are all things which do not belong in a perfect patch, and do not
beling in the OpenSC codebase that I want to use.

All these things, and probably more!, must be obvious to any other
programmer who has looked at the commits. I do not believe that I
have some special vision and only I can see these things.

It seems to me that the commits have been created without
self-review, which is of course the very first thing to do before
proposing any change for inclusion.

Post by Jean-Michel Pouré - GOOZE
Keep in mind that before doing business, I have been a politician
fighting during 4 years for more freedom.

I did not know - that is quite commendable! Thank you for working on
making the world a better place!

Keep in mind that open source is not a democracy.

Post by Jean-Michel Pouré - GOOZE
Now I am retired, but if need be, we will create a charity for
OpenSC and organize a duly elected board. I am not talking about
a fork, which will never happen, but about elections.

But elections do not increase code quality. I think software quality
is more important than flat democracy. The meritocracy that is open
source *is* a hierarchy. I don't think this is bad.


//Peter

[Jean-Michel Pouré - GOOZE]

Dear Peter,

Thank you for your time. In organization theory, there is no perfect
solution. There are several ways to achieve success.

Let us take two examples to see how OpenSC can be improved:

1) The ePass2003 code was reviewed by Viktor and included in his branch.
You probably did not know, did not compile, did not test and therefore
Viktor's work is ignored.

He needs and deserves write access to OpenSC main GIT to speed up
development. The reasons is that we need more new features, more beta
testers.

2) Take the example of Alon developments around PKCS#11. A lot of them
were ignored by OpenSSH. The reason is that when a small number of
people have a grasp on a project, strange things sometimes happen. I
would not like this to happen with OpenSC. Locking a project to a small
number of developers is not good.

IMHO, the way OpenSC used to be organized one year ago was superior,
because there was a central repository with all new features. More beta
features, more testers, larger market and superior quality.

This is no longer the case and each developers works in his corner. The
only collaborative work is what you call "peer review".

So my opinion would be to allow each developer to commit changes to the
main GITHUB staging (developing) branch after discussion. Like it used
to be the case using SVN. And make sure OpenSC is not only owned by one
or two people. This cannot ever happen, we don't agree with this
privatization.

The organization should be like:
* 4/5 committers
* 10/20 code contributors and developers
* 100 beta testers

Kind regards,
Jean-Michel

[Nikos Mavrogiannopoulos]

Let us take two examples to see how OpenSC can be improved: 1) The
ePass2003 code was reviewed by Viktor and included in his branch. You
probably did not know, did not compile, did not test and therefore
Viktor's work is ignored. He needs and deserves write access to
OpenSC main GIT to speed up development. The reasons is that we need
more new features, more beta testers.

[disclaimer I'm not experienced with opensc internals and comment might
be wrong]
This sounds pretty similar to the situation in hardware drivers which
often evolve faster than the linux kernel's pace. It might be better to
have a module approach for such development so that cutting edge drivers
can be used with opensc without recompilation or waiting for a new
opensc release. I don't know though, whether the size of the
projectjustifies something like that.

2) Take the example of Alon developments around PKCS#11. A lot of
them were ignored by OpenSSH. The reason is that when a small number
of people have a grasp on a project, strange things sometimes happen.
I would not like this to happen with OpenSC. Locking a project to a
small number of developers is not good.

In cases it might be good. We rejected Alon's PKCS #11 patches on gnutls
as well. You can say it was the wrong decision or so, but in the end of
day the few developers responsible for the project will have to maintain
it. If it is code they cannot maintain, or does not agree with the
longer term plans of the project maybe the feature should be postponed.

regards,
Nikos

[Viktor Tarasov]

Post by Douglas E. Engert

Post by Jean-Michel Pouré - GOOZE
Dear all,
I just got in contact with Stef Walter, who is integrating libp11-glue
into Gnome and Gnome keyring.
PKCS#11 module shouldn't fail if mlock doesn't work
http://www.opensc-project.org/opensc/ticket/389
This patch and other waiting patches raise the question of OpenSC
guidance and the need to have more commiters to OpenSC main GIT.
Martin, would you agree to add Viktor as a major OpenSC GIT member with
power to apply patches to main GIT trunk? I don't want to be paranoid,
but we need a more flexible approach rather than just Martin and Ludovic
applying and reviewing patches.
We discussed that at FOSDEM in a small audience, but I would like to
discuss that issue in public and have your own opinion. Who would like
OpenSC GITHUB to be REALLY in control of the community? Martin and
Ludovic, could you agree to open your group to other members of the
community?

The question is not so much who is on the commiter list, but do commits
get made when needed, and who decides a commit is ready and should be made.
There are minor fixes, like 389 that is 4 months old with an additional
fix 2 months ago, and looks like it needs to be made, as well as major
changes such as the SM, ePass2003, and the ECDH modifications.
Personally, I am quite interested in getting the ECDH in to the next
release with or without the SM code and am willing to rebase the
modifications as needed. I believe the ECDH has been ready for months.
Viktor pulled the ECDH modifications into his SM on October 4, 2011 and
he also pulled in the ePass2003 on January 29.
The way forward is not necessarily more commiters, but a plan
for the next release and some action.

As I understand the current policy, the patch acceptance policy is resumed in:
- fixes for crying bugs go to 'master';
- little fixes, evident limited patch goes to 'staged';
- more consequent proposals pass to Gerrit and here waits for approval to be applied to 'staged'.

Current problem is that the process is stagnated on the Gerrit level.
For some obscure reasons Martin do not participates in Gerrit review/acceptance procedures, as well as Ludovic.
Nobody else have sufficient authority to do it.

Martin has pushed to Gerrit part of SM branch. What are the intentions for the rests?
What about next release? What should be included into?
How can be tested the compatibility of different proposals?

Personally I do not look for additional rights,
as Douglas, I'm interested in some action and ready to help to move the things forward.
And so, would like to have this possibility.


Also Jenkins is dead for some time already.
What shall we do?
Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ?

Post by Douglas E. Engert
So can we consider adding ePass2003, SM, and ECDH to the next release
as these are already being tested together.
If giving Viktor commit authority would speed up the inclusion of both small
and larger modifications, it would be OK with me. If we can get these
included without giving him commit authority, that would be OK
with me too. But we need action.

Post by Jean-Michel Pouré - GOOZE
Community, please advice and discuss this issue.
Kind regards,
Jean-Michel
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Ludovic Rousseau]

Post by Viktor Tarasov

Post by Douglas E. Engert

Post by Jean-Michel Pouré - GOOZE
Dear all,
I just got in contact with Stef Walter, who is integrating libp11-glue
into Gnome and Gnome keyring.
PKCS#11 module shouldn't fail if mlock doesn't work
http://www.opensc-project.org/opensc/ticket/389
This patch and other waiting patches raise the question of OpenSC
guidance and the need to have more commiters to OpenSC main GIT.
Martin, would you agree to add Viktor as a major OpenSC GIT member with
power to apply patches to main GIT trunk? I don't want to be paranoid,
but we need a more flexible approach rather than just Martin and Ludovic
applying and reviewing patches.
We discussed that at FOSDEM in a small audience, but I would like to
discuss that issue in public and have your own opinion. Who would like
OpenSC GITHUB to be REALLY in control of the community? Martin and
Ludovic, could you agree to open your group to other members of the
community?

The question is not so much who is on the commiter list, but do commits
get made when needed, and who decides a commit is ready and should be made.
There are minor fixes, like 389 that is 4 months old with an additional
fix 2 months ago, and looks like it needs to be made, as well as major
changes such as the SM, ePass2003, and the ECDH modifications.
Personally, I am quite interested in getting the ECDH in to the next
release with or without the SM code and am willing to rebase the
modifications as needed.  I believe the ECDH has been ready for months.
Viktor pulled the ECDH modifications into his SM on October 4, 2011 and
he also pulled in the ePass2003 on January 29.
The way forward is not necessarily more commiters, but a plan
for the next release and some action.

- fixes for crying bugs go to 'master';
- little fixes, evident limited patch goes to 'staged';
- more consequent proposals pass to Gerrit and here waits for approval to be applied to 'staged'.
Current problem is that the process is stagnated on the Gerrit level.
For some obscure reasons Martin do not participates in Gerrit review/acceptance procedures, as well as Ludovic.
Nobody else have sufficient authority to do it.

I don't know why only Martin and myself are integrators on Gerrit.

I reviewed some patches but don't know what to do next. It looks like
the patches are not moved to github/staging. Maybe a configuration
problem?
Note: this is my first use of Gerrit.

Post by Viktor Tarasov
Martin has pushed to Gerrit part of SM branch. What are the intentions for the rests?
What about next release? What should be included into?
How can be tested the compatibility of different proposals?
Personally I do not look for additional rights,
as Douglas, I'm interested in some action and ready to help to move the things forward.
And so, would like to have this possibility.
Also Jenkins is dead for some time already.

Exact. I did not noticed.

Post by Viktor Tarasov
What shall we do?
Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ?

Martin, what do you plan to do?

Regards,

[Jean-Michel Pouré - GOOZE]

Dear all,

Post by Viktor Tarasov
As I understand the current policy, the patch acceptance policy is
- fixes for crying bugs go to 'master';
- little fixes, evident limited patch goes to 'staged';
- more consequent proposals pass to Gerrit and here waits for approval
to be applied to 'staged'.

This seems relevant and superior to the previous SVN process.

Post by Viktor Tarasov
Current problem is that the process is stagnated on the Gerrit level.
For some obscure reasons Martin do not participates in Gerrit
review/acceptance procedures, as well as Ludovic.
Nobody else have sufficient authority to do it.

From Gerrit webpage: "Gerrit simplifies Git based project maintainership
by permitting any authorized user to submit changes to the master Git
repository, rather than requiring all approved changes to be merged in
by hand by the project maintainer."

YES, this is what is needed.

[Peter Stuge]

Post by Jean-Michel Pouré - GOOZE
1) The ePass2003 code was reviewed by Viktor and included in his branch.
You probably did not know, did not compile, did not test and therefore
Viktor's work is ignored.

This is appropriate in my opinion, because I do not think that the
commits are ready for inclusion in the main OpenSC repository,
regardless of the fact that Viktor has included them in his.

Post by Jean-Michel Pouré - GOOZE
He needs and deserves write access to OpenSC main GIT to speed up
development.

I disagree, if he considers the epass2003 commits I looked at to be
of acceptable quality.

Post by Jean-Michel Pouré - GOOZE
The reasons is that we need more new features, more beta testers.

You disregard the topic of code quality, which I think that is
unacceptable in particular for a security related project.

Post by Jean-Michel Pouré - GOOZE
2) Take the example of Alon developments around PKCS#11. A lot of them
were ignored by OpenSSH. The reason is that when a small number of
people have a grasp on a project, strange things sometimes happen.

What? The reason is that, as you may know, OpenSSH is developed in
the OpenBSD project, and their plans for PKCS#11 did not align with
Alon's plans for OpenSSH PKCS#11 outside OpenBSD.

Post by Jean-Michel Pouré - GOOZE
Locking a project to a small number of developers is not good.

There is no locking. Please get that idea out of your mind. Everyone
can create commits. But as I have tried to give several examples of,
obviously not every commit should automatically be included in the
main repository - which is in principle what you advocate.

Post by Jean-Michel Pouré - GOOZE
IMHO, the way OpenSC used to be organized one year ago was superior,
because there was a central repository with all new features. More beta
features, more testers, larger market and superior quality.

More code = more bugs.

Post by Jean-Michel Pouré - GOOZE
This is no longer the case and each developers works in his corner.

If that is the case, it is so because the active developers do not
communicate with each other. As you've mentioned, communicating is
important. Committing to the main repository is never the start of
communication, it is what concludes communication.

Post by Jean-Michel Pouré - GOOZE
The only collaborative work is what you call "peer review".

I'm not sure how much review actually happens.

Post by Jean-Michel Pouré - GOOZE
So my opinion would be to allow each developer to commit changes to the
main GITHUB staging (developing) branch after discussion. Like it used
to be the case using SVN.

Replace branch with repository and I see no problem. But sharing a
sandbox is significantly less convenient than each developer having
their own repository/ies, while also exchanging commits with each
other. It is perfectly fine for each developer to have one or even
more repositories. Please understand that this is the nature of git,
and actually the nature of development work. One person has focus on
one thing at a time, in their corner. After they finish, it is of
course important to do show and tell, get review comments, rework the
code, and repeat until consensus.

Post by Jean-Michel Pouré - GOOZE
And make sure OpenSC is not only owned by one or two people. This
cannot ever happen, we don't agree with this privatization.

Who are "we" ? I don't care if OpenSC has just one committer, as
long as code quality is a high, if not the highest, priority.

Post by Jean-Michel Pouré - GOOZE
* 4/5 committers
* 10/20 code contributors and developers
* 100 beta testers

The problem with this organizational diagram is that neither you nor
anyone else can magically generate competent developers with lots of
spare time. People contribute what they can when they can. You can of
course hire developers, but if your recruitment process is strict, so
as to find only really competent developers, you will discover
quickly that they are quite rare.


//Peter

[Viktor Tarasov]

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
* OpenSC used to have a very flexible approach. OpenSC is NOT
kernel.org with thousands of developers and no need for hierarchy.

OpenSC is smaller, but I do not agree that there is no need for any
kind of hierarchy. Now, please understand that this is not about
power hierarchy as in politics, but it is about technical experience
with the code and with the problem domain.
I am personally familiar with the smart card domain but I haven't
spent much time with the OpenSC codebase and therefore I absolutely
do not want some patch I create to be included without being reviewed
first.
The review is criticial. Especially in a codebase like OpenSC, to
which I might indeed delegate my legal authority, I want the review
to be merciless.

Nobody doubts that review in critical.
But what shall we do now, how can we 'move forward',
if the review/acceptance process is stopped at the Gerrit level
and the only person that is capable and has authority to do something is absent for a long time already ?

...

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
* Setting-up a compilation farm is no reason for closing write access
to historical developers of OpenSC.

I agree, but I don't think one has anything to do with the other,
even if they happened at the same time. I guess that anyone who had
write access to the repository earlier can get it again if they just
send a public ssh key and their prefered username.

I agree, compilation farm is extremely useful.
But it has to be adapted/configured in accordance with the available human and other resources.
There has to be no definitive obstacle for 'moving forward', otherwise this 'compilation farm' stuff loose it's sense of being.

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
We demand more freedom and transparency or this can only lead to
endless flamewars.

Let's focus on a concrete problem. Have you created a patch which has
been peer reviewed and is well understood, but has been rejected by
Martin and Ludovic? If yes, let's try to find a solution. If no, you
can't really demand more freedom and transparency, because you
haven't exercised the freedom to create perfect patches yet.
I did review the epass2003 commits when their availability was
announced, and I've looked at the entersafe github account
There are three branches; ePass2003_1, epass2003 and ep2k3. These
names are non-descript.
Commit 902e637c is quite long with over 2k lines added for the card
driver. That seems much to me. It's infeasible for me as careful
programmer but OpenSC internals newbie to review this code. My gut
feeling is that much of the code could be factored out.
The commits are not very well described in the commit messages.
The commits include unrelated changes.
The commits include whitespace changes mixed with actual code
changes.
The following commit undoes some of the unrelated changes in the
previous one.
This is what was immediately obvious to me just by looking at one and
a half commits in one of the branches. The things I point out above
are all things which do not belong in a perfect patch, and do not
beling in the OpenSC codebase that I want to use.
All these things, and probably more!, must be obvious to any other
programmer who has looked at the commits. I do not believe that I
have some special vision and only I can see these things.
It seems to me that the commits have been created without
self-review, which is of course the very first thing to do before
proposing any change for inclusion.

Probably you have a reason -- 'whitespace', 'commit messages', 'undoes unrelated changes', ...
But from my point of view:
- commit history do not needs to be perfect for the new driver, before it's commited into one of the official branches;
- personally, I'm ready to correct myself the limited number of the coding style ot other issues when merging newbie commits,
but to not make the 'ping-pong' last for ages;
- historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' .
(It's the module approach, that Nikos Mavrogiannopoulos talking about in his mail in this thread.)
Certainly, the 'newbies' have to be 'educated' in the 'right' direction, but the process could not be so rigorous
and finally to not block the 'moving forward'.


...

Post by Peter Stuge
//Peter

Kind regards,
Viktor.

[Peter Stuge]

Post by Viktor Tarasov
Nobody doubts that review in critical.
But what shall we do now, how can we 'move forward',
if the review/acceptance process is stopped at the Gerrit level
and the only person that is capable and has authority to do
something is absent for a long time already ?

I suggest to iterate over proposed patches until they are perfect.

That way, those who can submit commits in Gerrit (this is the Gerrit
term for including a commit into the main repository) will need to
spend close to zero time on doing so. Their job becomes so easy that
it is a no-op. Then it also gets done quickly and frequently. This
must be the goal.

Post by Viktor Tarasov
Probably you have a reason -- 'whitespace', 'commit messages',
'undoes unrelated changes', ...
- commit history do not needs to be perfect for the new driver,
before it's commited into one of the official branches;

Work in progress will always exist. Beta testing of work in progress
is good and important, and Git makes this extremely easy. Anyone in
the world can publish their work in progress.

Proposing a commit for inclusion in the main repo is something quite
different. Whenever something is pushed to Gerrit it must indeed be
perfect, or it is just some lazy or sloppy developer wasting the time
of others. I think we are all busy and want to avoid wasted time.

Post by Viktor Tarasov
- personally, I'm ready to correct myself the limited number of the
coding style ot other issues when merging newbie commits, but to
not make the 'ping-pong' last for ages;

This is a trade-off. It's fine to do this once or twice for a new
developer. It's however quite hopeless when the developer whose work
you review consistently makes the same mistakes that you have
corrected and possibly even pointed out several times before. It is a
waste of time for humans to do such work. Static analysis of commits,
e.g. using checkpatch.pl from Linux possibly with som modifications,
can and must be automated. Gerrit is the perfect place to do it.

Post by Viktor Tarasov
- historically, afais, driver authors where relatively free in
coding style, implementation particularities, etc. in the part
that concerns it's 'own space' .

I find this problematic since it leads to low reusability. Even just
visual style differences are not really helpful. A uniform codebase
is more coherent and easier to deal with for everyone involved. The
coding style rules do not have to be very many, but having project
wide rules is a good thing.

Post by Viktor Tarasov
Certainly, the 'newbies' have to be 'educated' in the 'right'
direction, but the process could not be so rigorous and finally to
not block the 'moving forward'.

Until newbies can demonstrate that they have learned the right things
they are by definition not moving forward.


//Peter

[Anders Rundgren]

IMO the core problem with OpenSC is a that all cards seem to require
a tweak, profile or similar. For government IDs which are driven
by politics rather than reason there is no problem to solve; the
governments simply have to pay the price for demanding "uniqueness".

For non-government tokens like the excellent Feitian Epass2003
I would consider another approach: Updating the firmware to
emulate PIV so that we can put the middleware aside once and
for all. That is, HW vendors should qualify their products
against middleware rather than running never-ending projects
that only creates frustration and exuberant costs.

Anders

[Peter Stuge]

Post by Anders Rundgren
For non-government tokens like the excellent Feitian Epass2003
I would consider another approach: Updating the firmware to
emulate PIV so that we can put the middleware aside once and
for all.

I agree completely that all the legacy involved in tokens and cards
is horrendous waste of engineering resources, time and life.

I'm excited about the gnuk project, it's a nice platform to play with
the PKCS#11 over USB idea, which I refuse to give up on before having
attempted to implement it and failed. :)


//Peter

[Jean-Michel Pouré - GOOZE]

Post by Peter Stuge
Until newbies can demonstrate that they have learned the right things
they are by definition not moving forward.

Come-on, we are not in a class-room or in an administration.

We all agree that Gerrit is the solution. So let's make it work and open
accounts for recognized developers to make sure simple patches are
committed.

If this is not done within a reasonable time frame, I will create a
Charity under French law open to everyone and we will have elections.

Kind regards,

[Viktor Tarasov]

Post by Peter Stuge

Post by Viktor Tarasov
Nobody doubts that review in critical.
But what shall we do now, how can we 'move forward',
if the review/acceptance process is stopped at the Gerrit level
and the only person that is capable and has authority to do
something is absent for a long time already ?

I suggest to iterate over proposed patches until they are perfect.

Iterate with who? There is nobody on the other side of the wire.
For months the only person that is capable to do/answer something is absent.

Post by Peter Stuge
That way, those who can submit commits in Gerrit (this is the Gerrit
term for including a commit into the main repository) will need to
spend close to zero time on doing so. Their job becomes so easy that
it is a no-op. Then it also gets done quickly and frequently. This
must be the goal.

I'm completely agree with you, and admire the beauty of your abstract considerations,
but what have we do here & now, in our current situation -- Jenkins is dead, Gerrit is in mute coma.


...

Post by Peter Stuge

Post by Viktor Tarasov
- personally, I'm ready to correct myself the limited number of the
coding style ot other issues when merging newbie commits, but to
not make the 'ping-pong' last for ages;

This is a trade-off. It's fine to do this once or twice for a new
developer. It's however quite hopeless when the developer whose work
you review consistently makes the same mistakes that you have
corrected and possibly even pointed out several times before. It is a
waste of time for humans to do such work.

Believe me, I have other interesting things to do.
But for months I'm looking the way to help to 'move OpenSC forward' and but had no answers -- there is no activity on the other side.
Decision to pull the ECDH, the ePass2003 into SM branch is my isolated desperate attempt to 'move forward'.

Post by Peter Stuge
Static analysis of commits,
e.g. using checkpatch.pl from Linux possibly with som modifications,
can and must be automated. Gerrit is the perfect place to do it.

Please, come back to earth -- Gerrit is not actually functional.

Post by Peter Stuge

Post by Viktor Tarasov
- historically, afais, driver authors where relatively free in
coding style, implementation particularities, etc. in the part
that concerns it's 'own space' .

I find this problematic since it leads to low reusability. Even just
visual style differences are not really helpful. A uniform codebase
is more coherent and easier to deal with for everyone involved. The
coding style rules do not have to be very many, but having project
wide rules is a good thing.

Completely on you side. But that's the current state of art.
To change something we need more resources.

Post by Peter Stuge

Post by Viktor Tarasov
Certainly, the 'newbies' have to be 'educated' in the 'right'
direction, but the process could not be so rigorous and finally to
not block the 'moving forward'.

Until newbies can demonstrate that they have learned the right things
they are by definition not moving forward.

...

Post by Peter Stuge
//Peter

Kind regards,
Viktor.

[Viktor Tarasov]

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
1) The ePass2003 code was reviewed by Viktor and included in his branch.
You probably did not know, did not compile, did not test and therefore
Viktor's work is ignored.

This is appropriate in my opinion, because I do not think that the
commits are ready for inclusion in the main OpenSC repository,
regardless of the fact that Viktor has included them in his.

Post by Jean-Michel Pouré - GOOZE
He needs and deserves write access to OpenSC main GIT to speed up
development.

I disagree, if he considers the epass2003 commits I looked at to be
of acceptable quality.

The ePass2003 commit has been re-factored before creating the SM+ePass2003 branch,
to make it compatible with the general SM framework and to correct some of the coding style issues.
https://github.com/viktorTarasov/OpenSC/commits/include-ePass2003

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
The reasons is that we need more new features, more beta testers.

You disregard the topic of code quality, which I think that is
unacceptable in particular for a security related project.

Just to remind,
the overwhelming part of the ePass2003 commit is concentrated in it's own new module (card driver) .

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
Locking a project to a small number of developers is not good.

There is no locking. Please get that idea out of your mind. Everyone
can create commits. But as I have tried to give several examples of,
obviously not every commit should automatically be included in the
main repository - which is in principle what you advocate.

Post by Jean-Michel Pouré - GOOZE
IMHO, the way OpenSC used to be organized one year ago was superior,
because there was a central repository with all new features. More beta
features, more testers, larger market and superior quality.

More code = more bugs.

Post by Jean-Michel Pouré - GOOZE
This is no longer the case and each developers works in his corner.

If that is the case, it is so because the active developers do not
communicate with each other. As you've mentioned, communicating is
important. Committing to the main repository is never the start of
communication, it is what concludes communication.

Post by Jean-Michel Pouré - GOOZE
The only collaborative work is what you call "peer review".

I'm not sure how much review actually happens.

Post by Jean-Michel Pouré - GOOZE
So my opinion would be to allow each developer to commit changes to the
main GITHUB staging (developing) branch after discussion. Like it used
to be the case using SVN.

Replace branch with repository and I see no problem. But sharing a
sandbox is significantly less convenient than each developer having
their own repository/ies, while also exchanging commits with each
other. It is perfectly fine for each developer to have one or even
more repositories. Please understand that this is the nature of git,
and actually the nature of development work. One person has focus on
one thing at a time, in their corner. After they finish, it is of
course important to do show and tell, get review comments, rework the
code, and repeat until consensus.

Post by Jean-Michel Pouré - GOOZE
And make sure OpenSC is not only owned by one or two people. This
cannot ever happen, we don't agree with this privatization.

Who are "we" ? I don't care if OpenSC has just one committer, as
long as code quality is a high, if not the highest, priority.

Post by Jean-Michel Pouré - GOOZE
* 4/5 committers
* 10/20 code contributors and developers
* 100 beta testers

The problem with this organizational diagram is that neither you nor
anyone else can magically generate competent developers with lots of
spare time. People contribute what they can when they can. You can of
course hire developers, but if your recruitment process is strict, so
as to find only really competent developers, you will discover
quickly that they are quite rare.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Peter Stuge]

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge
Until newbies can demonstrate that they have learned the right things
they are by definition not moving forward.

Come-on, we are not in a class-room or in an administration.

We are also not in a democracy. We are in a security related open
source project.

Post by Jean-Michel Pouré - GOOZE
We all agree that Gerrit is the solution. So let's make it work and
open accounts for recognized developers to make sure simple patches
are committed.

Everyone can register an account, which then allows to push commits
into Gerrit, and to comment on and perform +1/-1 review of other
commits. An OpenID is neccessary. If someone does not have an OpenID
and would like me to provide one, feel free to send me your prefered
username, md5(yourpassword) and your full name and email address, and
I will create an identity for you on my OpenID provider. You then add
two <meta> tags to any web page that you control, and the URL of that
web page is your OpenID identifier.

Note that many sites such as SourceForge, Google, Yahoo, etc. already
have OpenID providers, so if you have an account there you can look
around to find your OpenID identifier, which you then use to register
with Gerrit.

Post by Jean-Michel Pouré - GOOZE
If this is not done within a reasonable time frame, I will create a
Charity under French law open to everyone and we will have elections.

Create as many charities as you like, I don't think it will make any
difference. Working on code is unrelated to holding elections.

I suggest that those who want to contribute to OpenSC start flooding
Gerrit with perfect patches that are so obviously perfect and that
are approved by so many contributors that they require nearly zero
attention from Martin and Ludovic, and thus can be submitted (again,
the Gerrit term for including in the main repo) very quickly.

The only alternative to that is IMO for those who want to do
development with a different goal and/or a different method than
Martin and Ludovic to create a fork. Actually this is already what
happens when using Git. Every repository is already a fork.

Forking isn't neccessarily bad, but keep in mind that you will have
to work very hard to be able to replace the de-facto standard. It
will be significantly easier to focus on working with the existing
project, on the terms of the existing project.

Whenever a fork is created, it is important to decide right at the
start what the purpose will be. If the purpose is to get changes back
into the original codebase then it is obviously critical to follow
the procedures and practises of that codebase, otherwise the effort
will be wasted, since the forked codebase is unmergeable. Maybe
someone wants to spend time fixing it up. This is very painful, and a
complete waste of time. The alternative is to go full steam ahead and
decide to never look back. Only with this attitude does it really
make sense to fork. You already indicated that you don't really want
to fork, so I guess your choice is made.

This is all politics. Let's disregard the politics. That leaves code.


It is impossible to argue against a perfect patch.


//Peter

[Jean-Michel Pouré - GOOZE]

Post by Peter Stuge
We are also not in a democracy. We are in a security related open
source project.

Don't get me wrong. This is an organization issue. I am not talking
about forking OpenSC, this would be stupid. The website, teams and tools
should remain. But we need a simplier and more effective approach.

Remember that under European law, all contributors hold a copyright on
OpenSC code. The leader is not the copyright holder. When nothing
happens in a project, we have the right to change leadership.

Holding elections will allow to decide how to organize the project.

IMHO, a reasonable timeframe to fix organization issues should be around
one month. We are today 19th February 2012. If within a month all these
issues are not fixed, I will incorporate a Charity with other OpenSC
members and call for elections of a board.

Kind regards,

[Peter Stuge]

Post by Viktor Tarasov

Post by Peter Stuge

Post by Viktor Tarasov
Nobody doubts that review in critical.
But what shall we do now, how can we 'move forward',
if the review/acceptance process is stopped at the Gerrit level
and the only person that is capable and has authority to do
something is absent for a long time already ?

I suggest to iterate over proposed patches until they are perfect.

Iterate with who? There is nobody on the other side of the wire.
For months the only person that is capable to do/answer something
is absent.

Martin is not the only person who you can talk to about code. Try
asking the mailing list, and if that fails it is always possible to
do self-review and iterate locally.

Post by Viktor Tarasov

Post by Peter Stuge
That way, those who can submit commits in Gerrit (this is the Gerrit
term for including a commit into the main repository) will need to
spend close to zero time on doing so. Their job becomes so easy that
it is a no-op. Then it also gets done quickly and frequently. This
must be the goal.

I'm completely agree with you, and admire the beauty of your abstract
considerations, but what have we do here & now, in our current
situation -- Jenkins is dead, Gerrit is in mute coma.

Jenkins may have a problem, but Gerrit looks like it is functioning
fine, at least now. It is trying to merge commits which have been
pushed, reviewed and submitted for merge, but where the commits have
been pushed with dependencies, and where the dependencies have not
yet been reviewed and submitted for merge.

Here is where perfect patches make all the difference. The dependency
looks wrong, and if there was no dependency, the commit would already
have been included in the repository.

Granted, Gerrit was introduced recently and will take a little
getting used to, for people to learn the ins and outs. But in the
end it is an incredibly helpful tool.

Post by Viktor Tarasov
Believe me, I have other interesting things to do.

Yes, I believe you. :)

Post by Viktor Tarasov
But for months I'm looking the way to help to 'move OpenSC forward'
and but had no answers -- there is no activity on the other side.

I think everyone is on the same side.

Post by Viktor Tarasov
Decision to pull the ECDH, the ePass2003 into SM branch is my
isolated desperate attempt to 'move forward'.

:) Well, maybe nothing desperate is neccessary. Ludovic can submit
commits in Gerrit to the main repository, so work on making the
commits in Gerrit trivial for him to submit. I believe he will do it
quickly.

One very nice thing about Gerrit is that anyone can push an improved
version of anyone else's work. In order to not make a mess, it is
important to preserve the Change-Id inside the commit message, but
everything else can change, both the rest of the commit message and
the contents and the history of the commit.

So for example:

https://www.opensc-project.org/codereview/#change,7

has status Submitted, Merge Pending

Ludovic has approved and submitted this change. Gerrit tries to
include it, but a dependency is missing.

Change 7 has one dependency:

https://www.opensc-project.org/codereview/#change,6

which has been verified by Jenkins, but not reviewed and submitted by
Ludovic. This change has no further dependencies.

There are two ways to move forward on change 7:

1. Ludovic can review and submit change 6 for merge, which will then
also make change 7 get included in the repository.

2. Anyone with a Gerrit account can fetch the commit in change 7
according to the download instructions, and cherry-pick it onto a
new branch of the main repository, and then push that branch to
Gerrit. This will make the change no longer have a dependency.

Dependencies are created when a branch with several commits is pushed
to Gerrit. Gerrit prefers that any branch being pushed is strictly
for logically related commits. Gerrit prefers very many different
branches, rather than only few. Fortunately, branches are fast and
easy with git!

After someone has done 2. above Ludovic will have to review and
submit the updated change 7 for merge. So it seems more efficient to
convince Ludovic to review and submit change 6, and then change 7
will automatically go in right after it.

Repeat for all open and later added :) changes.

Post by Viktor Tarasov

Post by Peter Stuge
Static analysis of commits,
e.g. using checkpatch.pl from Linux possibly with som modifications,
can and must be automated. Gerrit is the perfect place to do it.

Please, come back to earth -- Gerrit is not actually functional.

It looks good to me? https://www.opensc-project.org/codereview/

I've just registered and signed in. It works for Ludovic as well, and
I'm sure he will submit commits as long as they need no further work.
I don't really see a problem.

Post by Viktor Tarasov

Post by Peter Stuge

Post by Viktor Tarasov
- historically, afais, driver authors where relatively free in
coding style, implementation particularities, etc. in the part
that concerns it's 'own space' .

I find this problematic since it leads to low reusability. Even just
visual style differences are not really helpful. A uniform codebase
is more coherent and easier to deal with for everyone involved. The
coding style rules do not have to be very many, but having project
wide rules is a good thing.

Completely on you side. But that's the current state of art.
To change something we need more resources.

Yes of course. And perhaps it is not highest priority to work on
style cleanup. On the other hand, doing that might be a way for
everyone to contribute very simple changes and get comfortable with
the tools, and trivial things like how to create nice looking commit
messages and so on, the technicalities.

Remember to install the Gerrit commit-hook locally in all clones of
the repository, so that a Change-Id is generated locally when you
commit. Avoid pushing anything to Gerrit which doesn't have a
Change-Id, in order to reduce issues you may have if and when you
start reworking either a patch you yourself created, or a patch from
someone else.

If no commit-hook is installed locally, Gerrit will generate a
Change-Id on push. If two different versions of the same commit are
pushed, Gerrit will generate two distinct Change-Id, and thus they
will appear to be different changes, when in fact they are only
different versions of one and the same change. Running the
commit-hook locally avoids this problem, because the Change-Id is
only generated the first time that the commit is created. The
commit-hook will not replace an existing Change-Id.


//Peter

[Jean-Michel Pouré - GOOZE]

Post by Peter Stuge
Jenkins may have a problem, but Gerrit looks like it is functioning
fine, at least now. It is trying to merge commits which have been
pushed, reviewed and submitted for merge, but where the commits have
been pushed with dependencies, and where the dependencies have not
yet been reviewed and submitted for merge.

I created an account on Gerrit and looked at this URL:
https://www.opensc-project.org/codereview/#q,status:open,n,z

Some issues are marked 18 February 2012 with "Jenkins" user.
So it seems we have GITHUB, Jenkins and Gerrit ...

All this seems complicated.

Please advise:
1) How to push a patch from GITHUB to OpenSC staging directory. In two
or three sentences.
2) Explain who is responsible of reviewing and you are going to extend
the review team.

Post by Peter Stuge

Post by Anders Rundgren
For non-government tokens like the excellent Feitian Epass2003
I would consider another approach: Updating the firmware to
emulate PIV so that we can put the middleware aside once and
for all.

I agree completely that all the legacy involved in tokens and cards
is horrendous waste of engineering resources, time and life.

What??? Are suggesting that we should upgrade the ePass2003 firmware?
This is ridiculous.

If you don't have time and resources, open the review team to the
historical OpenSC developers, like Viktor and others.

Kind regards,

[Peter Stuge]

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge
We are also not in a democracy. We are in a security related open
source project.

Don't get me wrong. This is an organization issue. I am not talking
about forking OpenSC, this would be stupid.

Not neccessarily - if there is critical mass I think it is the only
reasonable course.

Post by Jean-Michel Pouré - GOOZE
The website, teams and tools should remain. But we need a simplier
and more effective approach.

The tools (git and Gerrit) are as simple and effective as they can
be. They are truly state of the art. That's the tools part.

As for workflow, that will only be simple and effective when there is
agreement on what is desired in the codebase.

I consider it prudent to focus on quality, in particular for security
related projects.

That means that changes are not included on a whim or just because
they are proposed. It means that development will be much slower than
would be the case with a focus other than quality, e.g. a focus on
rapid introduction of new features.

Post by Jean-Michel Pouré - GOOZE
Remember that under European law, all contributors hold a copyright
on OpenSC code. The leader is not the copyright holder. When
nothing happens in a project, we have the right to change
leadership.

Everyone has copyright, but actually that is not the key; the license
already guarantees freedom for the code.

"Leadership" is not related to the copyright, and since the codebase
has a free license, actually "change leadership" is nothing other
than starting a new project.

Post by Jean-Michel Pouré - GOOZE
Holding elections will allow to decide how to organize the project.

No, not really. Holding elections may allow to decide how to organize
a different project using the same codebase from the same copyright
holders under the same or a compatible license. A fork.

Post by Jean-Michel Pouré - GOOZE
IMHO, a reasonable timeframe to fix organization issues should be
around one month. We are today 19th February 2012. If within a
month all these issues are not fixed, I will incorporate a Charity
with other OpenSC members and call for elections of a board.

I don't think you should wait. If you can find enough people to
participate in the fork then as I said I think you should do it with
determination; if there is hesitation then the fork is doomed to fail
already before it has begun.

I for one will stay at opensc-project.org and hope that it will never
hold elections. What little I might be able to contribute I'd prefer
to contribute to code.

It's strange that democracy and bureacracy are proposed to move a
software project forward, and that perfect commits isn't seen as a
perhaps more effective path.


//Peter

[Peter Stuge]

Post by Jean-Michel Pouré - GOOZE
https://www.opensc-project.org/codereview/#q,status:open,n,z
Some issues are marked 18 February 2012 with "Jenkins" user.
So it seems we have GITHUB, Jenkins and Gerrit ...
All this seems complicated.

It's not so bad. I'll try to explain!

GitHub stores the project output. This is where the current
repository is published for the world to use, test, and base work on.

Gerrit receives input. All proposed commits arrive here. It looks
like there may be two ways for commits to arrive:

1. A developer creates an account and does git push directly to Gerrit

2. A developer signals the OpenSC repository on GitHub that they want
to propose some change. Maybe this is done with a GitHub pull request.

Note: I am not sure about this 2. I'm guessing based on the "GitHub"
owner seen for many of the proposed changes. The Owner column on

https://www.opensc-project.org/codereview/#q,status:open,n,z

is the name of the person who uploaded the commit into Gerrit.


Whenever Gerrit receives a change, it asks Jenkins to verify that the
change at least does not break the build, but Jenkins can also do
some further testing, such as checking the formatting and whatever
technical checks are desired for proposed changes.

Only Jenkins can set the Verified flag for commits in Gerrit, and
nothing can go out to GitHub from Gerrit without Jenkins approving.

Post by Jean-Michel Pouré - GOOZE
1) How to push a patch from GITHUB to OpenSC staging directory.
In two or three sentences.

I would do:

One-time setup:
a. Create Gerrit account and add username and public SSH key
b. git clone from github which has the patch
c. cd into cloned dir
d. Install commit-msg hook
scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/
e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git
f. git config remote.gerrit.push HEAD:refs/for/master

For each patch:
1. Make the current branch equal to OpenSC GitHub + the patch (git rebase)
2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD
3. git push gerrit

In case multiple commits belong together in the same logical change
or that they depend on each other, then the current branch should
have all these commits following the last commit of OpenSC GitHub.

Post by Jean-Michel Pouré - GOOZE
2) Explain who is responsible of reviewing and you are going to
extend the review team.

Everyone is responsible for reviewing. All registered users can
review all proposed changes, comment on each changed line, comment on
the change as a whole, and give a score of +1, 0 or -1.

Martin and Ludovic can in addition "submit" changes, ie. move them
from Gerrit to the OpenSC GitHub. Obviously the job for Martin and
Ludovic becomes much much easier if there are many others who have
already given +1 score for a change.

I am also just a user in Gerrit, like you and others, so I can't
extend permissions for anyone, but I don't think doing that is very
important. Focus on the code and everything else will fall into
place.

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge

Post by Anders Rundgren
For non-government tokens like the excellent Feitian Epass2003
I would consider another approach: Updating the firmware to
emulate PIV so that we can put the middleware aside once and
for all.

I agree completely that all the legacy involved in tokens and cards
is horrendous waste of engineering resources, time and life.

What??? Are suggesting that we should upgrade the ePass2003 firmware?
This is ridiculous.

Converging on a single implementation would perhaps not be such a bad
idea, but I would personally prefer something without any legacy, ie.
not even CCID.

Post by Jean-Michel Pouré - GOOZE
If you don't have time and resources, open the review team to the
historical OpenSC developers, like Viktor and others.

The whole world can do review. The more people that help with this,
the less effort it is for Martin and Ludovic. The more people who
help with review, the more people will be able to join Martin and
Ludovic in submitting changes from Gerrit to the OpenSC GitHub.

As I already wrote, I think that everyone who could commit before
Gerrit was set up just need to mention their Gerrit username to
Martin in order to also be able to submit changes from Gerrit to
OpenSC GitHub.


//Peter

[Peter Stuge]

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
1) How to push a patch from GITHUB to OpenSC staging directory.
In two or three sentences.

a. Create Gerrit account and add username and public SSH key
b. git clone from github which has the patch
c. cd into cloned dir
d. Install commit-msg hook
scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/
e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git
f. git config remote.gerrit.push HEAD:refs/for/master
1. Make the current branch equal to OpenSC GitHub + the patch (git rebase)
2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD
3. git push gerrit
In case multiple commits belong together in the same logical change
or that they depend on each other, then the current branch should
have all these commits following the last commit of OpenSC GitHub.

This is my prefered way. I just found confirmation of my guess that a
pull request sent to OpenSC GitHub will also arrive into Gerrit. So
if already using GitHub then that is probably the easiest way.


//Peter

[Anders Rundgren]

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge

Post by Anders Rundgren
For non-government tokens like the excellent Feitian Epass2003
I would consider another approach: Updating the firmware to
emulate PIV so that we can put the middleware aside once and
for all.

I agree completely that all the legacy involved in tokens and cards
is horrendous waste of engineering resources, time and life.

What??? Are suggesting that we should upgrade the ePass2003 firmware?
This is ridiculous.

Dear Jean-Michel,

It depends what your interest is. My clients which include banks
and government agencies are only interested in *using* tokens with
as little "fuzz" as possible. In spite of my role as a consultant
I think they are right.

You didn't hear my presentation at FOSDEM 2012 but it was about
creating a token with a standard API so that you would as a customer
be able to just plug it in. This is though a much more ambitious
project than reflashing ePass2003 to emulate PIV.

Why PIV? Due to Europe's limited success creating an interoperable
card standard, it seems that NIST's PIV would be good choice. Since
some 98% of our client platforms nowadays are defined by only three
giant US corporations, US standards will always be better supported.

Cheers,
Anders

[Peter Stuge]

Post by Anders Rundgren
You didn't hear my presentation at FOSDEM 2012 but it was about
creating a token with a standard API so that you would as a
customer be able to just plug it in.

This is an advantage of USB P11. In Windows 8 and later there doesn't
even have to be a driver installed, since WinUSB comes with the
operating system already and can be loaded automatically if the
device follows some Microsoft-invented USB extensions. Only one
PKCS#11 DLL is neccessary, and nothing more.

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

In principle I do not argue strongly against PIV, I generally agree
with your observations.

But it would be nice to try to do even better. :)


//Peter

[Anders Rundgren]

Post by Peter Stuge

Post by Anders Rundgren
You didn't hear my presentation at FOSDEM 2012 but it was about
creating a token with a standard API so that you would as a
customer be able to just plug it in.

This is an advantage of USB P11. In Windows 8 and later there doesn't
even have to be a driver installed, since WinUSB comes with the
operating system already and can be loaded automatically if the
device follows some Microsoft-invented USB extensions. Only one
PKCS#11 DLL is neccessary, and nothing more.

I don't know what USB P11 is, can you send me a pointer?

Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The total confusion on the *NIX side regarding crypto subsystem
haven't been particularly beneficial for PKCS #11 either.

Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.

The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world. I have stretched this notion
to include connected tokens as well with a hope reaching the critical
mass needed for establishing a de-facto standard.

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

Post by Peter Stuge
In principle I do not argue strongly against PIV, I generally agree
with your observations.
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Anders

Post by Peter Stuge
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Peter Stuge]

Post by Anders Rundgren
I don't know what USB P11 is, can you send me a pointer?

It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.


//Peter

[Douglas E. Engert]

[Ludovic, Please see below.]

Post by Peter Stuge

Post by Peter Stuge

Post by Jean-Michel Pouré - GOOZE
1) How to push a patch from GITHUB to OpenSC staging directory.
In two or three sentences.

a. Create Gerrit account and add username and public SSH key
b. git clone from github which has the patch
c. cd into cloned dir
d. Install commit-msg hook
scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/
e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git
f. git config remote.gerrit.push HEAD:refs/for/master
1. Make the current branch equal to OpenSC GitHub + the patch (git rebase)
2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD
3. git push gerrit
In case multiple commits belong together in the same logical change
or that they depend on each other, then the current branch should
have all these commits following the last commit of OpenSC GitHub.

This is my prefered way. I just found confirmation of my guess that a
pull request sent to OpenSC GitHub will also arrive into Gerrit. So
if already using GitHub then that is probably the easiest way.

I am new to Gerrit too, but it looks like if 2 code reviews give a +1,
the code will be advanced.

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

I can use my Google OpenID to Sign In, and today did a code review
on: Change I51630a84: Cleanup PKCS15 PIV Card PIN flags

This is a change I submitted in December, and Victor gave it a +1
So today I gave it a +1, (As I am the only PIV developer I figure I can
review my own code) "Looks good to me, but someone else must approve"
But this does not look like it is the same as "Looks good to me, approved"

https://www.opensc-project.org/codereview/#admin,group,7
says Ludovic and Martin are the two members of the Integrators group.

I might assume Ludovic and Martin are in the Administrator group,
but I can not see that.

https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy
says:
"Git write access is granted to those who GetInvolved with OpenSC
development and ..."
This would imply that there is no intent to keep write access controlled,
but it might be controlled today based on the Gerrit access control.

Ludovic,
Can you verify if you are in the Gerrit Administrator's group?
and are any of the other people listed on the "GetInvolved" page
listed as integrators, or admins?

Post by Peter Stuge
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Peter Stuge]

Post by Douglas E. Engert
I am new to Gerrit too,

All right! I'm by no means an expert, but I have been using it in
several projects for a while, where I also helped with issues during
the migration, so please feel free to ask any questions.

Post by Douglas E. Engert
but it looks like if 2 code reviews give a +1, the code will be
advanced.
See: https://www.opensc-project.org/codereview/

Need Code Review +2 means that one "+2" review is neccessary. 2x +1
is not equivalent.

Post by Douglas E. Engert
I can use my Google OpenID to Sign In, and today did a code review
on: Change I51630a84: Cleanup PKCS15 PIV Card PIN flags

Thanks! Although since it is your patch it is perhaps a bit
redundant, since you have likely reviewed your patch locally
before sending it anyway.

Post by Douglas E. Engert
This is a change I submitted in December, and Victor gave it a +1
So today I gave it a +1, (As I am the only PIV developer I figure I
can review my own code)

I expect every developer to review their own code locally, already
before pushing to Gerrit. The fact that you're the PIV expert is
inconvenient to formalize a set of rules for, so it's something
integrators will simply have to keep in the back of their head, as
they look at individual changes.

Post by Douglas E. Engert
"Looks good to me, but someone else must approve"
But this does not look like it is the same as "Looks good to me, approved"

Indeed, the latter is a "+2" code review.

Post by Douglas E. Engert
https://www.opensc-project.org/codereview/#admin,group,7
says Ludovic and Martin are the two members of the Integrators group.

Right, this means that they are able to "submit" or integrate changes
from Gerrit into the OpenSC repository on GitHub, by selecting

+2 Looks good to me, approved

during review, and clicking the "Publish and Submit" button, which is
available in the web interface.

Ludovic: Keep in mind that selecting +2 and clicking "Publish
Comments" is *not* sufficient to integrate that change.

Gerrit is a young tool still. :)

I personally strongly prefer the SSH interface. If I was an
integrator, I could have included your change with the command:

ssh -p 8882 www.opensc-project.org gerrit review 51630a844e8e95e7108cb1966c5f3e21b93a463b --code-review +2 -s

The hash after the review command is the patch set commit hash.
Combination of Change-Id and patch set number should also work, i.e.

ssh -p 8882 www.opensc-project.org gerrit review I51630a84,1 --code-review +2 -s

although I haven't had success with this anywhere yet. (May be due to
old an buggy versions of Gerrit!)

Post by Douglas E. Engert
https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy
"Git write access is granted to those who GetInvolved with OpenSC
development and ..."
This would imply that there is no intent to keep write access controlled,
but it might be controlled today based on the Gerrit access control.

Gerrit behaves just like a Git repository, and for those more
comfortable with GitHub it's also possible to fork OpenSC there and
work from that. "Git write access" is almost nonsensical because Git
allows everyone to write everywhere.

Post by Douglas E. Engert
Ludovic,
Can you verify if you are in the Gerrit Administrator's group?
and are any of the other people listed on the "GetInvolved" page
listed as integrators, or admins?

Integrators is only Martin and Ludovic, hence those are the ones who
can currently include Gerrit changes into OpenSC on GitHub.

Now for the third time, I'm sure that everyone who used to have
repository write access will also quickly be added to the Integrator
group if they mention their account name or ID and someone in the
Administrators group is around. If only Martin is admin, then I guess
there's a bit of a wait state, but that's not really such a big deal,
because it doesn't block further work in any way.


//Peter

[Anders Rundgren]

Post by Peter Stuge

Post by Anders Rundgren
I don't know what USB P11 is, can you send me a pointer?

It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Maybe you would like to have an STM32F215-based token?
160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES
It may happen this year.

Anders

Post by Peter Stuge

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Douglas E. Engert]

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
I don't know what USB P11 is, can you send me a pointer?

It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Maybe you would like to have an STM32F215-based token?
160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES
It may happen this year.
Anders

I have not tried this, but check out this token too:

http://www.goldkey.com/usb-smart-card-with-piv.html

Built-in PIV Support
Basic functionality and support for PIV cards and tokens already
exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions.

It does not say what what the Linux support is, but I bet it is OpenSC.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Jean-Michel Pouré - GOOZE]

Dear Peter,

Post by Peter Stuge
It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Feitian offers two ranges of products: CCID (ePass2003 and other
products) and HID over USB (ePass2001 and other products).

At Gooze, we have HID over USB products in stock (around 100 unused
tokens) but we did not released them as they were incompatible with
OpenSC.

Under Windows, it seems that HID over USB range of products can be used
without drivers, just over USB. Under Linux, a small proprietary USB
framework is needed. If this is what you mean, you may be interested in
testing these HID products. Just write me a private email and I can send
you one of these tokens.

IMHO, CCID is superior as it is really plug-and-play under all systems.
Of course, CCID is needed, but it could be installed under all systems
by default. The last versions of libccid with udev really rocks. Pure
plug-and-play never exists, you always need an underlying library.
libccid is that library.

I agree PIN provisioning is really an issue. But if you think of
Android, there could be an application available from Android store to
do this job.

What we need is:
* Cheap hardware available worldwide, with onlines sales.
* A common framework under all systems, this is OpenSC.
* Compatibility with all systems, including Linux, Mac, Windows and
Android.
* A growing user base.
* A growing developer base.

A common strategy is to be able to answer "Yes" to all questions and
needs. With OpenSC, you can say YES to "Windows", "Mac", "Linux" and
soon "Android". You can say YES and ship tokens to most countries.
Remember crypto is a restricted market and you need authorizations to be
able to ship.

From my point of view, I would be more in favor of an Android phone
acting as a CCID device overs some secure wireless link over OpenSC.
GOOZE will soon release crypto chips for Android and this will become
one of our target project. We have the demo chips in stock. As usual, we
will offer free crypto chips for Android to hackers requesting it.

The only reason why Apple removed smartcard support is that (in my
opinion) it may be working secretly on a new iPhone replacing smartcards
and offering secure payment.

The target for new OpenSC developments should be smart phones. We may
discuss that in a few weeks after governance issues in OpenSC are
improved. All we need is to move forward.

Kind regards,

[Peter Stuge]

Post by Anders Rundgren

Post by Peter Stuge
It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Maybe you would like to have an STM32F215-based token?
160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES
It may happen this year.

That's nice, although I'm not crazy about stm32. I tend toward
NXP LPC. But so far, the closest to what I want and which is
available is Gnuk: http://www.fsij.org/gnuk/ ..which also uses
stm32. The development situation for stm32 in particular for USB
is not amazing it seems. I haven't looked very deep in the
datasheets yet.

Gnuk implements CCID and so on in order to be interoperable with
software stacks (in particular GnuPG) *today* but like you I'm
focusing less on the right now and more on the right way for the
future. :)

The nice part about Gnuk is that it has all the primitives in place,
even if it is only a slow software implementation, so I would really
only have to focus on the protocol/API, which actually is exactly
what I want. :)


//Peter

[Peter Stuge]

Post by Douglas E. Engert
http://www.goldkey.com/usb-smart-card-with-piv.html
Built-in PIV Support
Basic functionality and support for PIV cards and tokens already
exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions.
It does not say what what the Linux support is, but I bet it is OpenSC.

I like the mechanical design very much, but not really the other
aspects of the product; closed, they favor key escrow, and talk about
their "Master Token" products raises some question marks which I
believe will never be answered by the company.


//Peter

[Jean-Michel Pouré - GOOZE]

Post by Peter Stuge
Integrators is only Martin and Ludovic, hence those are the ones who
can currently include Gerrit changes into OpenSC on GitHub.
Now for the third time, I'm sure that everyone who used to have
repository write access will also quickly be added to the Integrator
group if they mention their account name or ID and someone in the
Administrators group is around. If only Martin is admin, then I guess
there's a bit of a wait state, but that's not really such a big deal,
because it doesn't block further work in any way.

This is where I don't quite agree.

The notion of trust is more interesting than the notion of code purity.
If you trust a small group of 5/6 main developers to have discussions
before writing +2, this is fairly enough.

I am worried that some people might ALWAYS argue that a code is not
pure-enough and this leads to endless flame wars. Free software is a
collaborative process where we improve the code base, just like in
ISO-9001 (release software, describe bug, fix bug, improve). This is a
circular process.

Collaborative commits means more bugs. But also more beta-testers, more
beta testers and more users and in the end a better project. This is
life.

Let me take an image: if you ask you wife to have surgery for a perfect
body before marriage, you won't go very far.

On the converse, I am in favor of a collaborative approach based on
trust.

Kind regards,

[Peter Stuge]

Hi!

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge
It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Feitian offers two ranges of products: CCID (ePass2003 and other
products) and HID over USB (ePass2001 and other products).

Don't get me started on HID. :) The libusb FAQ

http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass

tries to give an overview of the considerations for using HID.

Executive summary is that it's a bad idea if you want to run on
anything but Windows, and even there it may not be a very good idea
because you have to re-implement some features which USB otherwise
offers your protocol design for free.

Post by Jean-Michel Pouré - GOOZE
At Gooze, we have HID over USB products in stock (around 100 unused
tokens) but we did not released them as they were incompatible with
OpenSC.
Under Windows, it seems that HID over USB range of products can be
used without drivers, just over USB.

Do you know how it is used by CryptoAPI and/or PKCS#11 applications?

Post by Jean-Michel Pouré - GOOZE
Under Linux, a small proprietary USB framework is needed.

Proprietary? You know that I think that's the wrong approach. :)
The FAQ page mentions HIDAPI which can be used to communicate with
HID class devices in some cases, but if portability is a concern, it
should be clear from the FAQ page that using HID is not the best
choice anyway.

Post by Jean-Michel Pouré - GOOZE
If this is what you mean,

Sorry, no, it's not. What I have in mind is to implement the actual
PKCS#11 API directly over USB, as far as that is possible. Again,
issues have been pointed out with doing this, but I still think it's
worth a shot.

Post by Jean-Michel Pouré - GOOZE
IMHO, CCID is superior as it is really plug-and-play under all
systems.

So much software is running which is completely unneccessary. I agree
that CCID has sufficient usability, but it is by far not the best
that can be done.

Post by Jean-Michel Pouré - GOOZE
Pure plug-and-play never exists,

It does, actually. At least in Windows and Linux pure plug-and-play
would be possible with my USB P11 idea, but I believe also in other
systems.

As always with PKCS#11 it would be neccessary to point applications
to the correct PKCS#11-provider file (.dll or .so) but still I find
the idea worth exploring.

Post by Jean-Michel Pouré - GOOZE
* Cheap hardware available worldwide, with onlines sales.

Yes, and the logistics of this can be tricky, but as you know with
some volume it can indeed be done. And if the solution is good enough
I think the volume will come.

Post by Jean-Michel Pouré - GOOZE
* A common framework under all systems, this is OpenSC.

I'd be much happier without any framework at all actually.

Post by Jean-Michel Pouré - GOOZE
* Compatibility with all systems, including Linux, Mac, Windows and
Android.

Yes, the portability is important. iOS would also be nice, but well
that may be pushing one's luck. :p

Post by Jean-Michel Pouré - GOOZE
From my point of view, I would be more in favor of an Android phone
acting as a CCID device overs some secure wireless link over OpenSC.

As you probably know, anything wireless is a quite significant attack
vector. No "secure" transactions there please. But with a cable
maybe. However, Android devices so far do not have a strong history
of local IO either coming in or going out. :\ This can change along
with market demands of course, but it raises the barrier for
development.

Post by Jean-Michel Pouré - GOOZE
GOOZE will soon release crypto chips for Android

What kind of chips? How do they connect?

Post by Jean-Michel Pouré - GOOZE
The only reason why Apple removed smartcard support is that (in my
opinion) it may be working secretly on a new iPhone replacing
smartcards and offering secure payment.

Yes, I think this is a common belief, and I don't think it's wrong.

Post by Jean-Michel Pouré - GOOZE
The target for new OpenSC developments should be smart phones.

Much of OpenSC doesn't really apply in smartphones, but I agree that
smartphones may be very relevant security devices.


//Peter

[Jean-Michel Pouré - GOOZE]

Dear Peter,

Post by Peter Stuge
http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass

I wron't discuss as I don't know if improving HID for GNU/Linux is
really time consuming.

Post by Peter Stuge
Do you know how it is used by CryptoAPI and/or PKCS#11 applications?

CSP and PKCS#11.

Just contact me privately and I can ship you a free HID token for
testing. As you are the "wizard" of libusb, you may be able to judge and
maybe find a solution to communicate with the tokens. I have your
address in Berlin, is this still the same?

Kind regards,

[Peter Stuge]

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge
http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass

I wron't discuss as I don't know if improving HID for GNU/Linux is
really time consuming.

Hopefully you read the page anyway to find out about the
considerations for HID. It may still be relevant even if the
HID token is a little older.

The HIDAPI library created by Alan Ott is as easy to use as it gets
for HID class devices with Linux.

The Linux kernel since a long time offers an API which can be used
without any drivers and also without libusb, but the API has limited
capabilities, and depending on the device they may not be sufficient.

Then it will be neccessary to use libusb instead, and udev must be
configured to allow the user to disable the kernel HID class driver.

I believe HIDAPI now supports not only using libusb but also the
kernel API.

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge
Do you know how it is used by CryptoAPI and/or PKCS#11 applications?

CSP and PKCS#11.

OK! Yes, then the idea is similar to mine, except I do not like to
use HID in order to reduce portability issues. HID has advantages
for Windows but is more complicated everywhere else. (It can even
be impossible on Mac OS X. Apple changed the policy for replacing
the kernel HID driver in 10.6.)

Post by Jean-Michel Pouré - GOOZE
Just contact me privately and I can ship you a free HID token for
testing. As you are the "wizard" of libusb, you may be able to judge
and maybe find a solution to communicate with the tokens.

No need for token, but thanks for the offer! :) The code that already
supports the device is instead what I would look at. Is it available
online?


//Peter

[Jean-Michel Pouré - GOOZE]

Post by Peter Stuge
No need for token, but thanks for the offer! :) The code that already
supports the device is instead what I would look at. Is it available
online?

Sorry, it is not publicly available.

I am confused about this discussion, because at first you ask us to
flash the ePass2003 with another firmware, then we tell you that Feitian
HID tokens are already available and you are not interested because ...
kernel driver is not perfect under Linux.

At GOOZE, we stick to CCID.
Good luck with your project.

I hope that we will be able to collaborate more on OpenSC main branch
without being too picky on solutions.

Kind regards,

[Peter Stuge]

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge
No need for token, but thanks for the offer! :) The code that already
supports the device is instead what I would look at. Is it available
online?

Sorry, it is not publicly available.

You mentioned that one component is the small proprietary HID code
for Linux and that part is of course not available, but it seemed
like the other parts might be? Or did I misunderstand?

Can you say more about the software on Linux for that token?

Post by Jean-Michel Pouré - GOOZE
I am confused about this discussion, because at first you ask us to
flash the ePass2003 with another firmware,

Oh, no that was Anders' suggestion. Maybe that's the confusion.

I agree with him that as far as existing card/token standards go, PIV
is indeed likely to be well and widely supported, but I don't have
any opinion on changing the ePass2003 firmware.

Post by Jean-Michel Pouré - GOOZE
then we tell you that Feitian HID tokens are already available and
you are not interested because ... kernel driver is not perfect
under Linux.

I'm not interested in having yet another token laying around. :)
But I am however interested in the protocol! And I would look at the
Linux software situation for that HID token and I would maybe also be
able to find improvements. I just don't need the token to do that.

Post by Jean-Michel Pouré - GOOZE
At GOOZE, we stick to CCID.

I think this is smart, especially if the Feitian HID token is an
older product and no new HID token is planned.

Post by Jean-Michel Pouré - GOOZE
Good luck with your project.

Thanks! The idea was always only about a protocol optimized for
security, usability and portability, and it still needs r&d, so
please don't get the impression that I am trying to make someone
else use it before I have shown that it works.

Post by Jean-Michel Pouré - GOOZE
I hope that we will be able to collaborate more on OpenSC main
branch without being too picky on solutions.

Don't worry, as you know I'm not a significant contributor.


//Peter

[Peter Stuge]

Post by Peter Stuge
You mentioned that one component is the small proprietary HID code
for Linux and that part is of course not available, but it seemed
like the other parts might be? Or did I misunderstand?

I think I did. I read your email again to check.

Post by Peter Stuge
Can you say more about the software on Linux for that token?

From your email it seems that the software for Linux may be
completely proprietary. In that case it is of course difficult for
me to make any suggestions. Is there any protocol documentation?


//Peter

[Anders Rundgren]

On 2012-02-20 23:23, Jean-Michel Pouré - GOOZE wrote:
<snip>

Post by Jean-Michel Pouré - GOOZE
IMHO, CCID is superior as it is really plug-and-play under all systems.
Of course, CCID is needed, but it could be installed under all systems
by default. The last versions of libccid with udev really rocks. Pure
plug-and-play never exists, you always need an underlying library.
libccid is that library.

Jean-Michel,

I'm not following you here. CCID (as I understand it) only defines
an USB communication protocol/class, not how for example how to do
an RSA signature. When I look into my W7 installation I note that
when I attach my ePass2003 token to it, there is a driver from
"EnterSafe". That doesn't look particularly universal to me.

In addition, in order to do something useful with the token I had to
install a specific ePass2003 management program. It worked great BTW!

Don't get me wrong but from a *customer perspective* it would
have been much better if all this software was a part of a platform's
"smart card support". My guess is that the smart card industry can't
do that which is one of the motivations behind my SKS/KeyGen2 project.

Upgrading ePass2003 to PIV is an intermediary step. I believe the
management part unfortunately is largely undefined in PIV but maybe
somebody else know better? Douglas?

<snip>

Cheers,
Anders

[Ludovic Rousseau]

Post by Jean-Michel Pouré - GOOZE
Ludovic,
 Can you verify if you are in the Gerrit Administrator's group?
and are any of the other people listed on the "GetInvolved" page
listed as integrators, or admins?

I only see 2 groups in the admin section:
- Integrators: Martin and myself
- Release Managers: Martin only

It looks like I can add new member(s) to the Integrators group.

Bye,

[Ludovic Rousseau]

Post by Peter Stuge

Post by Douglas E. Engert
I am new to Gerrit too,

All right! I'm by no means an expert, but I have been using it in
several projects for a while, where I also helped with issues during
the migration, so please feel free to ask any questions.

Post by Douglas E. Engert
but it looks like if 2 code reviews give a +1, the code will be
advanced.
See: https://www.opensc-project.org/codereview/

Need Code Review +2 means that one "+2" review is neccessary. 2x +1
is not equivalent.

OK.
Using +2 (instead of +1) now shows some progress.

Example with https://www.opensc-project.org/codereview/#change,44
If I click on "Submit Patch Set 1" I now get the error:
"Submit Failed
Project policy requires all submissions to be a fast-forward.

Please rebase the change locally and upload again for review."

What should I do now?

It looks like gerrit worked for another patch:
https://www.opensc-project.org/codereview/#change,2
The status is "Submitted, Merge Pending"
Do I have to do something?
Who will do the merge?

Thanks

[Douglas E. Engert]

Post by Ludovic Rousseau

Post by Peter Stuge

Post by Douglas E. Engert
I am new to Gerrit too,

All right! I'm by no means an expert, but I have been using it in
several projects for a while, where I also helped with issues during
the migration, so please feel free to ask any questions.

Post by Douglas E. Engert
but it looks like if 2 code reviews give a +1, the code will be
advanced.
See: https://www.opensc-project.org/codereview/

Need Code Review +2 means that one "+2" review is neccessary. 2x +1
is not equivalent.

OK.
Using +2 (instead of +1) now shows some progress.
Example with https://www.opensc-project.org/codereview/#change,44
"Submit Failed
Project policy requires all submissions to be a fast-forward.
Please rebase the change locally and upload again for review."
What should I do now?

I think I have to rebase the code, and do another pull request?

Post by Ludovic Rousseau
https://www.opensc-project.org/codereview/#change,2
The status is "Submitted, Merge Pending"
Do I have to do something?
Who will do the merge?
Thanks

[Anders Rundgren]

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
I don't know what USB P11 is, can you send me a pointer?

It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Maybe you would like to have an STM32F215-based token?
160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES
It may happen this year.
Anders

http://www.goldkey.com/usb-smart-card-with-piv.html
Built-in PIV Support
Basic functionality and support for PIV cards and tokens already
exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions.
It does not say what what the Linux support is, but I bet it is OpenSC.

Douglas,
I believe you have misunderstood my intentions. The idea with my
project is not finding a suitable PIV token but creating a new standard
for cryptographic modules. However, I may have to hijack some of PIV
stack in order to not get swamped by contra-productive middleware
development.

My FOSDEM 2012 presentation:
http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf

Anders

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Douglas E. Engert]

Post by Anders Rundgren
<snip>

Post by Jean-Michel Pouré - GOOZE
IMHO, CCID is superior as it is really plug-and-play under all systems.
Of course, CCID is needed, but it could be installed under all systems
by default. The last versions of libccid with udev really rocks. Pure
plug-and-play never exists, you always need an underlying library.
libccid is that library.

Jean-Michel,
I'm not following you here. CCID (as I understand it) only defines
an USB communication protocol/class, not how for example how to do
an RSA signature. When I look into my W7 installation I note that
when I attach my ePass2003 token to it, there is a driver from
"EnterSafe". That doesn't look particularly universal to me.
In addition, in order to do something useful with the token I had to
install a specific ePass2003 management program. It worked great BTW!
Don't get me wrong but from a *customer perspective* it would
have been much better if all this software was a part of a platform's
"smart card support". My guess is that the smart card industry can't
do that which is one of the motivations behind my SKS/KeyGen2 project.
Upgrading ePass2003 to PIV is an intermediary step. I believe the
management part unfortunately is largely undefined in PIV but maybe
somebody else know better? Douglas?

That is correct. As I understand it, the intent was to let the card
vendors define this for theirs cards and allow them to market card
management systems, giving them some competitive advantage for
their cards. At least the end user card interface would be the same.
But 800-73 does define "put data" and "generate key", which allows
for some testing. It does not define a load key or any finalize
commands which would be needed by a production card management system.

Post by Anders Rundgren
<snip>
Cheers,
Anders
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Douglas E. Engert]

Post by Viktor Tarasov

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
I don't know what USB P11 is, can you send me a pointer?

It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Maybe you would like to have an STM32F215-based token?
160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES
It may happen this year.
Anders

http://www.goldkey.com/usb-smart-card-with-piv.html
Built-in PIV Support
Basic functionality and support for PIV cards and tokens already
exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions.
It does not say what what the Linux support is, but I bet it is OpenSC.

Douglas,
I believe you have misunderstood my intentions. The idea with my
project is not finding a suitable PIV token but creating a new standard
for cryptographic modules. However, I may have to hijack some of PIV
stack in order to not get swamped by contra-productive middleware
development.

OK. Note the PIV standards really define an application, and it could
be extended or an additional application on the card could be used
to do what you propose.

Post by Viktor Tarasov
http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf

The current PIV ECDH operations only return the ECDH keying material,
and do not save it on the token. This is what the ECDH mods I want to get
into OpenSC are all about. The mods return the raw keying material as a
PKCS#11 symmetric key Session Object to the caller who could then use
this with software based ECDH Key Agreement.

Pushing the ECDH Key Agreement to the token for use by the token
looks very interesting.

Post by Viktor Tarasov
Anders

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Anders Rundgren]

Post by Douglas E. Engert

Post by Viktor Tarasov

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
I don't know what USB P11 is, can you send me a pointer?

It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Maybe you would like to have an STM32F215-based token?
160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES
It may happen this year.
Anders

http://www.goldkey.com/usb-smart-card-with-piv.html
Built-in PIV Support
Basic functionality and support for PIV cards and tokens already
exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions.
It does not say what what the Linux support is, but I bet it is OpenSC.

Douglas,
I believe you have misunderstood my intentions. The idea with my
project is not finding a suitable PIV token but creating a new standard
for cryptographic modules. However, I may have to hijack some of PIV
stack in order to not get swamped by contra-productive middleware
development.

OK. Note the PIV standards really define an application, and it could
be extended or an additional application on the card could be used
to do what you propose.

That's correct and may very well be what I end-up with :-)

Post by Douglas E. Engert

Post by Viktor Tarasov
http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf

The current PIV ECDH operations only return the ECDH keying material,
and do not save it on the token. This is what the ECDH mods I want to get
into OpenSC are all about. The mods return the raw keying material as a
PKCS#11 symmetric key Session Object to the caller who could then use
this with software based ECDH Key Agreement.
Pushing the ECDH Key Agreement to the token for use by the token
looks very interesting.

I'm not sure I understand what you are trying to do here. The PIV
specification doesn't (AFAIK...) allow you to store the result of an
operation on the card. I could imagine that "super-operations" like

HMACSHA256 (ID-to-ECDH-priv-key-on-token,
Other-party's-ECDH pubkey,
KDF-Algorithm,
KDF-Data,
"Argument Data")

could be interesting but that looks like a new token method to me.

Anders

Post by Douglas E. Engert

Post by Viktor Tarasov
Anders

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Douglas E. Engert]

Post by Anders Rundgren

Post by Douglas E. Engert

Post by Viktor Tarasov

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
I don't know what USB P11 is, can you send me a pointer?

It's my old idea of implementing PKCS#11 directly over USB. Issues
have been pointed out, and they would have to be solved of course.

Maybe you would like to have an STM32F215-based token?
160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES
It may happen this year.
Anders

http://www.goldkey.com/usb-smart-card-with-piv.html
Built-in PIV Support
Basic functionality and support for PIV cards and tokens already
exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions.
It does not say what what the Linux support is, but I bet it is OpenSC.

Douglas,
I believe you have misunderstood my intentions. The idea with my
project is not finding a suitable PIV token but creating a new standard
for cryptographic modules. However, I may have to hijack some of PIV
stack in order to not get swamped by contra-productive middleware
development.

OK. Note the PIV standards really define an application, and it could
be extended or an additional application on the card could be used
to do what you propose.

That's correct and may very well be what I end-up with :-)

Post by Douglas E. Engert

Post by Viktor Tarasov
http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf

The current PIV ECDH operations only return the ECDH keying material,
and do not save it on the token. This is what the ECDH mods I want to get
into OpenSC are all about. The mods return the raw keying material as a
PKCS#11 symmetric key Session Object to the caller who could then use
this with software based ECDH Key Agreement.

The above allows for example Thunderbird to use ECDH for encrypted email,
with most if the work done in software, as the derived key is not stored
on the token.

Post by Anders Rundgren

Post by Douglas E. Engert
Pushing the ECDH Key Agreement to the token for use by the token
looks very interesting.

I meant based on your slides it looks like that is what you would like
to do as a new operation.

Post by Anders Rundgren
I'm not sure I understand what you are trying to do here. The PIV
specification doesn't (AFAIK...) allow you to store the result of an
operation on the card.

Correct.

Post by Anders Rundgren
I could imagine that "super-operations" like
HMACSHA256 (ID-to-ECDH-priv-key-on-token,
Other-party's-ECDH pubkey,
KDF-Algorithm,
KDF-Data,
"Argument Data")
could be interesting but that looks like a new token method to me.

Based on you slides, this sounds like a version of NIST 800-56A
Section 6.1.1.2. with all the operations done on the token,
and the key (Z) stored on the token for use by other operations.

Post by Anders Rundgren
Anders

Post by Douglas E. Engert

Post by Viktor Tarasov
Anders

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Anders Rundgren]

On 2012-02-21 18:16, Douglas E. Engert wrote:
<snip>

Post by Douglas E. Engert

Post by Anders Rundgren

Post by Douglas E. Engert
Pushing the ECDH Key Agreement to the token for use by the token
looks very interesting.

I meant based on your slides it looks like that is what you would like
to do as a new operation.

Post by Anders Rundgren
I'm not sure I understand what you are trying to do here. The PIV
specification doesn't (AFAIK...) allow you to store the result of an
operation on the card.

Correct.

Post by Anders Rundgren
I could imagine that "super-operations" like
HMACSHA256 (ID-to-ECDH-priv-key-on-token,
Other-party's-ECDH pubkey,
KDF-Algorithm,
KDF-Data,
"Argument Data")
could be interesting but that looks like a new token method to me.

Based on you slides, this sounds like a version of NIST 800-56A
Section 6.1.1.2. with all the operations done on the token,
and the key (Z) stored on the token for use by other operations.

You are right. My scheme does indeed store a ECDH Z-result in the token.
However, this is a token management/provisioning key, rather than a
"user key". For user-keys I currently have no ambitions beyond what
PIV supports.

I have "played" with the idea of creating a "secure stack-machine" for
performing arbitrary cryptographic operations on result-data but I couldn't
figure out how this would work without introducing vulnerabilities. :-(

Anders

Post by Douglas E. Engert

Post by Anders Rundgren
Anders

Post by Douglas E. Engert

Post by Anders Rundgren
Anders

Post by Jean-Michel Pouré - GOOZE

Post by Peter Stuge

Post by Anders Rundgren
Although PKCS #11 is good it is not particularly popular on Windows.
It is essentially only Mozilla who insists on not supporting the
native Windows crypto system. SUN/Oracle have managed to do 3(!)
major Java releases (5,6,7) without PKCS #11 support for Win-64.
They have though added support for Crypto-API.

The same USB device could support Crypto-API primitives too.

Post by Anders Rundgren
Regarding my token-project it has no direct ties to PKCS #11; it is
closer to the NXP GP-chip which is powering Google's Wallet.
The reason for this is that PKCS #11 doesn't have a interface
supporting secure remote provisioning, something which absolutely
necessary in the mobile phone world.

Provisioning is indeed outside PKCS#11 and could be done in some
other, also convenient, way. USB is really easy to use.

Post by Anders Rundgren
I have stretched this notion to include connected tokens as well
with a hope reaching the critical mass needed for establishing a
de-facto standard.

I fear that you are ahead of your time. :\ Adam Dunkels implemented
the internet of things many years ago, but I don't even have IPv6.
Things are changing, but still slowly.

Post by Anders Rundgren

Post by Peter Stuge

Post by Anders Rundgren
it seems that NIST's PIV would be good choice

It would be a much better candidate if there was not such a thick
layer of components involved which serve little to no purpose.

If you talk about the actual card standard I have no idea what
you are referring to. It looks quite simple to me. If you OTOH
refer to the OpenSC implementation, this is something that PIV
isn't responsible for.

Actually neither, I refer to the entire stack of software required
for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI.

Post by Anders Rundgren
Anyway, I know that the PIV vendors verify their cards against
Microsoft's driver and that is IMO the way to go.

If there's a superior alternative Microsoft may well catch up at some
point. They did with USB.

Post by Anders Rundgren

Post by Peter Stuge
But it would be nice to try to do even better. :)

That is what my project is all about but that is hardly an
alternative for Feitian at this stage.

Also agree. I'm also not suggesting Feitian to pick up on my idea. If
they do that's perfectly fine and totally awesome, but I'm keeping
the idea alive only because *I* think it is good and would like to
try it out.
//Peter
_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
http://www.opensc-project.org/mailman/listinfo/opensc-devel