Adding libp11 (or its equivalent) to OpenSSL

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

Re: Adding libp11 (or its equivalent) to OpenSSL

Nikos Mavrogiannopoulos-2
On Fri, 2016-02-26 at 16:20 +0100, Michal Trojnara wrote:

> > I'm also tempted to suggest that we should make it capable of
> > using p11-kit for the basic module loading and initialisation.
> > Since p11-kit is "sufficiently ubiquitous" on the platforms where
> > this is relevant, my approach would probably be to *start* by
> > depending on p11-kit, and if anyone objects they can do so in 'diff
> > -up' form. Starting with a full implementation of RFC7512 URI
> > parsing...
>
> I'm not sure what you mean by "depending on p11-kit".  I agree p11
> -kit
> simplifies configuration on some popular desktop platforms.  My point
> is OpenSSL is not exclusively used on desktop platforms.  Shall we
> really require p11-kit?  Wouldn't it limit the portability of
> OpenSSL?

p11-kit is not about desktop. I don't even think it provides any
desktop integration. It is about configuration of pkcs11 modules in a
system and coordination of the usage of PKCS #11. For example one
application could use smart cards even if it is linked with all of
openssl, nss or gnutls (and that's a very common scenario in complex
applications).

>  Shall we also merge p11-kit into OpenSSL?

p11-kit is used by gnutls as well. Integration to openssl would defeat
its purpose of coordination between modules.

regards,
Nikos



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

David Woodhouse
In reply to this post by Nikos Mavrogiannopoulos-2

> On Fri, 2016-02-26 at 22:36 +0200, Michael Jackson wrote:
>
>> [...]
>> After the heartbleed fiasco, RH has been switching as much as
>> possible to use NSS and stopped linking against OpenSSL. NSS is
>> probably far more portable than OpenSSL, and would probably be a
>> better target for integration.
>
> I do not believe you are a Red Hat spokesperson, and as far as I know
> none of these are true.

Red Hat *did* switch a bunch of stuff to NSS in the past but IIRC that was
FIPS-related. These days we ought to be doing the opposite -- there are
open bugs for things like curl for "does not accept PKCS#11 URI"
(#1219544) which could be solved just by building against GnuTLS. Could be
made to work with OpenSSL too but requires jumping through extra
libp11/engine hoops because OpenSSL doesn't have that support built in ...
which brings us nicely back on topic :)

NSS at this point is *nit* a better target for integration. Not before
https://bugzilla.mozilla.org/show_bug.cgi?id=1161219 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1162897 are fixed.

--
dwmw2


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

David Woodhouse
In reply to this post by Nikos Mavrogiannopoulos-2
On Sat, 2016-02-27 at 10:46 +0100, Nikos Mavrogiannopoulos wrote:
>
> p11-kit is not about desktop. I don't even think it provides any
> desktop integration. It is about configuration of pkcs11 modules in a
> system and coordination of the usage of PKCS #11. For example one
> application could use smart cards even if it is linked with all of
> openssl, nss or gnutls (and that's a very common scenario in complex
> applications).

However, those benefits are achieved just by going via p11-kit-proxy.so
as the default PKCS#11 provider — that's how I already did it for
engine_pkcs11, after all.

So perhaps we are better off keeping it simple. Just have our own URI
parsing (we can *lift* p11-kit's, we have a basic implementation in the
engine already that I put there, *and* Jaroslav has offered a version
(thanks).

Am I missing something else that a direct dependency on libp11-kit
would give us?


--
dwmw2



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

Nikos Mavrogiannopoulos-2
On Sat, 2016-02-27 at 15:55 +0000, David Woodhouse wrote:

> On Sat, 2016-02-27 at 10:46 +0100, Nikos Mavrogiannopoulos wrote:
> >
> > p11-kit is not about desktop. I don't even think it provides any
> > desktop integration. It is about configuration of pkcs11 modules in
> > a
> > system and coordination of the usage of PKCS #11. For example one
> > application could use smart cards even if it is linked with all of
> > openssl, nss or gnutls (and that's a very common scenario in
> > complex
> > applications).
>
> However, those benefits are achieved just by going via p11-kit
> -proxy.so
> as the default PKCS#11 provider — that's how I already did it for
> engine_pkcs11, after all.

The p11-kit proxy requires function call rewritting something that
cannot work in environments where code generation is prohibited (e.g.,
apache under selinux in RHEL is like that).

Said that, for simplicity p11-kit uses code generation for few other
cases which don't relate to the proxy, but these can be fixed; the
proxy cannot unfortunately be without any code generation.

regards,
Nikos


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

David Woodhouse
In reply to this post by Alon Bar-Lev
On Fri, 2016-02-26 at 19:12 +0200, Alon Bar-Lev wrote:
>
> What you seek is actually NSS.
> This won't happen, ever.
> Even if it will happen, libp11 is not the right implementation of
> doing that.

Yeah, we don't want NSS. NSS has its own problems :)

When I say we want to make PKCS#11 a first-class citizen in OpenSSL, I
don't mean we want to rearchitect OpenSSL to be completely based around
PKCS#11, as NSS is. I only mean that we want the PKCS#11 functionality
(like that of libp11 or indeed pkcs11-helper) to be a *part* of
OpenSSL's APIs. So that anyone using OpenSSL could reasonably be
*expected* to support certificates/keys from PKCS#11 whenever they
support using them from a file.

> I have experience in working with openssl codebase and it won't be
> extended to support such specific implementation.
> There was the opencryptoki project, that was the closest one of doing
> that without adding any code to openssl.

The point here *is* to add code to OpenSSL. That's why we have OpenSSL
developers on Cc, who are interested in making this happen.

Your ideas on what the OpenSSL API should look like would be very much
welcomed. You're absolutely right that it shouldn't turn into NSS, and
I have already been talking to Rich about the keystore. Any more
insight, either in advance or as I proceed with trying to put something
together, would be very much appreciated; thanks!

Just as importantly, please could you agree to the use of your code in
libp11 under a 3-clause BSD licence? Whether or not the final OpenSSL
1.2 API actually looks like libp11 or not, I'm fairly sure there *will*
be a lot of opportunity for code re-use, and the permission to
relicense it would be very much appreciated.

Thanks.

--
dwmw2


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

Alon Bar-Lev
On 29 February 2016 at 10:25, David Woodhouse <[hidden email]> wrote:

>
> On Fri, 2016-02-26 at 19:12 +0200, Alon Bar-Lev wrote:
> >
> > What you seek is actually NSS.
> > This won't happen, ever.
> > Even if it will happen, libp11 is not the right implementation of
> > doing that.
>
> Yeah, we don't want NSS. NSS has its own problems :)
>
> When I say we want to make PKCS#11 a first-class citizen in OpenSSL, I
> don't mean we want to rearchitect OpenSSL to be completely based around
> PKCS#11, as NSS is. I only mean that we want the PKCS#11 functionality
> (like that of libp11 or indeed pkcs11-helper) to be a *part* of
> OpenSSL's APIs. So that anyone using OpenSSL could reasonably be
> *expected* to support certificates/keys from PKCS#11 whenever they
> support using them from a file.

I believe it will be a mistake to introduce PKCS#11 into OpenSSL.
The engine should be extended up to a point in which someone can
implement and engine that can leverage any crypto interface,
CryptoAPI, PKCS#11 or whatever.

There is much work to be done at OpenSSL level, for example a
certificate/key/crl store, hierarchy awareness (a set of keys are
stored on a device, a set of devices can be accessed via same engine
instance), dynamic content to enable removal and re-introduce keyset
without destroying context, events for key/device
availability/removal.

One of the major challenges is to delegate CPU time to the engine for
house keeping and idle tasks. Another challenge is to resolve
threading issues. An asynchronous engine interface will resolve most
of the issues.

> > I have experience in working with openssl codebase and it won't be
> > extended to support such specific implementation.
> > There was the opencryptoki project, that was the closest one of doing
> > that without adding any code to openssl.
>
> The point here *is* to add code to OpenSSL. That's why we have OpenSSL
> developers on Cc, who are interested in making this happen.
>
> Your ideas on what the OpenSSL API should look like would be very much
> welcomed. You're absolutely right that it shouldn't turn into NSS, and
> I have already been talking to Rich about the keystore. Any more
> insight, either in advance or as I proceed with trying to put something
> together, would be very much appreciated; thanks!
>
> Just as importantly, please could you agree to the use of your code in
> libp11 under a 3-clause BSD licence? Whether or not the final OpenSSL
> 1.2 API actually looks like libp11 or not, I'm fairly sure there *will*
> be a lot of opportunity for code re-use, and the permission to
> relicense it would be very much appreciated.

Fine by me, but again, libp11 is not the quality nor mindset of what
OpenSSL should merge.

Regards,
Alon

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

David Woodhouse
On Mon, 2016-02-29 at 23:05 +0200, Alon Bar-Lev wrote:
> I believe it will be a mistake to introduce PKCS#11 into OpenSSL.
> The engine should be extended up to a point in which someone can
> implement and engine that can leverage any crypto interface,
> CryptoAPI, PKCS#11 or whatever.

You mean the engine API, rather than specifically engine_pkcs11, yes?

That does seem like a reasonable approach. The STORE that Rich has been
working on does sound like it would facilitate this.

The thing is, I absolutely DO NOT CARE how we do it. I'm more than
happy to listen to your thoughts on how it should be done.

My primary aim is just when applications use OpenSSL, it shall be
expected that *wherever* they could use a filename to specify a
certificate or key, it should Just Work™ if the user provides a PKCS#11
URI instead (in the config file, on the command line, or wherever).

Further than that, I really don't care about much at all :)

> There is much work to be done at OpenSSL level, for example a
> certificate/key/crl store, hierarchy awareness (a set of keys are
> stored on a device, a set of devices can be accessed via same engine
> instance), dynamic content to enable removal and re-introduce keyset
> without destroying context, events for key/device
> availability/removal.

Those sound useful, although I wouldn't class all of them as imperative
for my own purposes. I'd certainly want to ensure that whatever design
we end up with *can* support those. Even if some of them are left as an
exercise for later implementation.

> > Just as importantly, please could you agree to the use of your code
> > in libp11 under a 3-clause BSD licence? 

> Fine by me,

Thank you.

> but again, libp11 is not the quality nor mindset of what
> OpenSSL should merge.

It provides a lot of the basic PKCS#11 functionality for loading
modules and invoking them. I suspect we can use a lot of it even if we
*then* stop and take a closer look at how it should be seamlessly
*integrated* into the OpenSSL API set.

I see it as a two-phase project in that sense. And I get the impression
most of your commentary is about the second phase.

--
dwmw2


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

Andreas Jellinghaus-4
In reply to this post by David Woodhouse
Sorry for the late response. Responding once more to give a public statement. Comments inline below, I suppose your email reader can trim the quoted section, thus not spending time on that myself.

2016-02-26 15:19 GMT+01:00 David Woodhouse <[hidden email]>:
It would be really useful if OpenSSL *included* support for PKCS#11 as
a first class citizen.

This would mean that it could be natively incorporated into higher
level APIs such as SSL_CTX_use_certificate() and friends. Basically any
API that can take a filename to reference a certificate, should also be
able take a RFC7512 PKCS#11 URI.

This would also allow us to use a coherent trust database from PKCS#11,
which solves the problem of which *purposes* we trust each CA for,
unlike the existing flat-file solutions.

And applications would no longer need to jump through additional hoops
and have additional dependencies to get PKCS#11 support; we could make
it largely Just Work™, like it does for example with GnuTLS.



The code in libp11 is basically written to be OpenSSL code. If you
dropped it into the crypto/pkcs11 directory of OpenSSL precisely as it
stands, it wouldn't look out of place.

I propose — as the starting point of a plan which will surely be
modified by the time we conclude this thread — that we do so.

The biggest barrier to this, of course, is the licence. For reasons
which are lost in the mists of time, libp11 is licensed under the
LGPLv2, and is not compatible with the OpenSSL licence.

Therefore, I propose that we relicense the libp11 project under a
standard 3-clause BSD licence.

I did a bit of a sanity check offline, and I contacted Olaf Kirch as
well as the top contributors responsible¹ for 8611 of the 8984 lines of
.[ch] files in the repository. All of whom so far have agreed to allow
their contributions to be re-used under a BSD licence.

That gives me reasonable confidence that we can all agree, and that if
there *are* some people we can't find, or who don't agree, we can
reimplement the corresponding lines of code without too much of a
problem.

If you have ever contributed to libp11 (or the engine, although I
wasn't going there yet), I would be very grateful for an explicit
response to the question: "May I re-use your code under the 3-clause
BSD licence as seen at https://opensource.org/licenses/BSD-3-Clause?"

Yes, all code from me for libp11 may be re-used under the BSD-3 clause.
Same applies to engine_pkcs11 or pam_p11 (the two users of libp11 that I'm aware off), in case that is helpful.

Please note that I created libp11 mostly by splitting engine_pkcs11/opensc code into
a new project, so that I can use it for a pam module I was adding. At least that is how I remember it.
Thus most code under my name might come from Olaf Kirch instead, but he has given the same approval
already for all I know.

(There is a separate question, if we get that far, which is "shall we
*change* the licence of the libp11 project to 3-clause BSD?".
Personally I'd say yes to that too.)

If anyone wants to maintain libp11 and wants to change the license: all ok from my side.
 
So next we come to the technical approach, and I'd really appreciate
feedback here.

Do we *want* to drop the libp11 API directly into OpenSSL? That might
be ideal from the point of view of existing applications as they
migrate from OpenSSL <=1.1 + libp11, to OpenSSL 1.2.

Or perhaps we want to take this opportunity to change the API? Perhaps
libp11 would continue to exist alongside OpenSSL 1.2 for compatibility
with those existing apps?

(That question is specifically aimed as the OpenSSL folks on Cc as well
as the libp11 list.)

I don't know current users or use cases who/how libp11 is being used. 
For me it is important there is a nice story at the end: this is how you can use
smart cards. The work I did a few years ago included opensc, openct, pam_p11,
engine_pkcs11, libp11 and openssl. If there is an updated story with other components,
fine with me as well. The result counts for me, the details on how to get there: not that much.

In theory it would be fine if people still could use a smart card or usb crypto token for
both SSL connections, ssh connections and console login. In practice maybe noone is
interested in maintaining that, and then it is ok if some progress on one side kills
unmaintained code elsewhere. If there is sufficient interest, the code is easy enough to understand and adapt I think.

For a start, I definitely think we should at least add functions for
obtaining an EVP_PKEY or an X509 cert from a PKCS#11 URI alone —
similar to the pkcs11_load_key() and pkcs11_load_cert() functions in
the engine code.

I'm also tempted to suggest that we should make it capable of using
p11-kit for the basic module loading and initialisation. Since p11-kit
is "sufficiently ubiquitous" on the platforms where this is relevant,
my approach would probably be to *start* by depending on p11-kit, and
if anyone objects they can do so in 'diff -up' form. Starting with a
full implementation of RFC7512 URI parsing...

I haven't kept up with that RFC or p11-kit, thus can't comment on what is the best way
here. As this is open source: do what you think is right :)

Thanks for taking on this project! I'm glad to see someone improves the support
for smart card / hardware based authentication into our daily live.

Andreas

Once we have a consensus on what the resulting API would look like, 
my idea would be to create a sequence of submissions to OpenSSL (not
for 1.1 but to be merged to OpenSSL HEAD after that), which slowly add
the required functionality step by step (probably leaving out the
deprecated functions).

Each commit would then be easily reviewable for merging into OpenSSL.
And where it's lifted from existing libp11 code, I could properly check
the provenance of each line of code as I go, to make sure I do have
permission to relicense it.

That's about as far as my plan goes, really. The point here is to
solicit feedback and work out how best to proceed...

Please note there are two members of the OpenSSL team in Cc. Please
make sure you "reply to all" and don't drop them.

--
dwmw2


¹ According to 'git blame', which I appreciate is a blunt tool and doesn't
  even credit Olaf with any lines of code. But as a sanity check for "should
  I give up on this idea and just write something from scratch?" it's OK.
  Specifically:

$ for a in `find . -name \*.[ch]` ; do git blame $a; done | sed 's/........ (\(.*\)[[:space:]]*20..-..-.. ..:..:.. .*/\1/' | sed s/[[:space:]]*$// | sort | uniq -c  | sort -rn
   4559 Michał Trojnara
   2813 Andreas Jellinghaus
    749 Doug Engert
    454 Nikos Mavrogiannopoulos
    163 Ludovic Rousseau
     59 Mikhail Denisenko
     45 Alon Bar-Lev
     44 Stephane Adenot
     39 Nils Larsch
     32 Michal Trojnara
      9 Martin Paljak
      6 Anton Fedorov
      4 David Woodhouse
      3 Christian Heimes
      2 Mike Gerow
      2 Jean-Pierre Szikora
      1 LE TOUX Vincent

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

David Woodhouse
On Tue, 2016-03-01 at 16:12 +0100, Andreas Jellinghaus wrote:

> Yes, all code from me for libp11 may be re-used under the BSD-3 clause.
> Same applies to engine_pkcs11 or pam_p11 (the two users of libp11
> that I'm aware off), in case that is helpful.

Thank you.

> Please note that I created libp11 mostly by splitting
> engine_pkcs11/opensc code into a new project, so that I can use it
> for a pam module I was adding. At least that is how I remember it.
> Thus most code under my name might come from Olaf Kirch instead, but
> he has given the same approval already for all I know.

Actually, the interesting part starts before that. You moved the code
out from OpenSC to separate engine_pkcs11 and libp11 repositories in
August/September 2005.

But they all appeared, in a big lump, in OpenSC in May 2003:
https://github.com/OpenSC/OpenSC/commit/496232d9b

Where did they come from before that? 

There are commits earlier in the OpenSC history which strongly imply
that the engine code was already there — Olaf's commit f169b5c891
tweaks some autoconf code and is titled "only build sslengine if
OpenSSL supports it". But according to the git history there *is* no
code at that point; only the autoconf test...

--
dwmw2


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

Andreas Jellinghaus-4

2016-03-01 17:43 GMT+01:00 David Woodhouse <[hidden email]>
Actually, the interesting part starts before that. You moved the code
out from OpenSC to separate engine_pkcs11 and libp11 repositories in
August/September 2005.

But they all appeared, in a big lump, in OpenSC in May 2003:
https://github.com/OpenSC/OpenSC/commit/496232d9b

Where did they come from before that? 

src/sslengines has the source code from Olaf and Kevin Stefanik.

Many files are already using the BSD-2 or OpenSSL license.

Also maybe someone has a backup of the old SVN server? my backup disk died some year ago,
after the project was moved already to github and the server was retired :(

Regards, Andreas

There are commits earlier in the OpenSC history which strongly imply
that the engine code was already there — Olaf's commit f169b5c891
tweaks some autoconf code and is titled "only build sslengine if
OpenSSL supports it". But according to the git history there *is* no
code at that point; only the autoconf test...

--
dwmw2



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

Andreas Jellinghaus-4
In reply to this post by David Woodhouse
found it, commit b2455b097f8bd9b0a075df3820ce21c6bf33357a in engine_pkcs11 has the same content as opensc in commit bae2b51e01e16c126613289dd68e75545d3dd333 at least for these files:

aj@seiryu:~/opensc-git/src/sslengines$ md5sum ~/xx/xx/engine_pkcs11/src/*
f16abeabca8f30197b94f5cbbed56132  /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.c
e693a2a09ee07964722d71f1afbf1882  /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.def
9936c4fc0357e7c24ddc12abe66fcd06  /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.h
e4d4f039411f964636b11973d5617ffc  /home/aj/xx/xx/engine_pkcs11/src/hw_opensc.c
8f7565d60db0ad6246c50b3282676bbf  /home/aj/xx/xx/engine_pkcs11/src/hw_pkcs11.c
f4911e7a7cd3b44a4251ca8529f685bc  /home/aj/xx/xx/engine_pkcs11/src/Makefile.am
003221d31d444bb8cd3ca09b7a305158  /home/aj/xx/xx/engine_pkcs11/src/Makefile.mak
aj@seiryu:~/opensc-git/src/sslengines$ md5sum *
1a29991197312afe0b8d055e5912ce2f  engine_opensc.c
e4219829d19f13cc6c59f7a49d1d830c  engine_opensc.h
f16abeabca8f30197b94f5cbbed56132  engine_pkcs11.c
e693a2a09ee07964722d71f1afbf1882  engine_pkcs11.def
9936c4fc0357e7c24ddc12abe66fcd06  engine_pkcs11.h
e4d4f039411f964636b11973d5617ffc  hw_opensc.c
8f7565d60db0ad6246c50b3282676bbf  hw_pkcs11.c
cae21328df67ce552a790779bf3e4015  Makefile.am
003221d31d444bb8cd3ca09b7a305158  Makefile.mak
0afa2a574a5f83c7fa52cfe35fbd9098  test_engine.sh

thus the code can be tracked back to opensc that way. Also the code at that age is already BSD-2 or OpenSSL licensed.

engine_pkcs11.def is trivial and I guess you have no need to reuse old Makefiles. Thus you should be all good?

Regards, Andreas

2016-03-01 17:43 GMT+01:00 David Woodhouse <[hidden email]>:
On Tue, 2016-03-01 at 16:12 +0100, Andreas Jellinghaus wrote:

> Yes, all code from me for libp11 may be re-used under the BSD-3 clause.
> Same applies to engine_pkcs11 or pam_p11 (the two users of libp11
> that I'm aware off), in case that is helpful.

Thank you.

> Please note that I created libp11 mostly by splitting
> engine_pkcs11/opensc code into a new project, so that I can use it
> for a pam module I was adding. At least that is how I remember it.
> Thus most code under my name might come from Olaf Kirch instead, but
> he has given the same approval already for all I know.

Actually, the interesting part starts before that. You moved the code
out from OpenSC to separate engine_pkcs11 and libp11 repositories in
August/September 2005.

But they all appeared, in a big lump, in OpenSC in May 2003:
https://github.com/OpenSC/OpenSC/commit/496232d9b

Where did they come from before that? 

There are commits earlier in the OpenSC history which strongly imply
that the engine code was already there — Olaf's commit f169b5c891
tweaks some autoconf code and is titled "only build sslengine if
OpenSSL supports it". But according to the git history there *is* no
code at that point; only the autoconf test...

--
dwmw2



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding libp11 (or its equivalent) to OpenSSL

David Woodhouse
On Tue, 2016-03-01 at 21:39 +0100, Andreas Jellinghaus wrote:
>
> thus the code can be tracked back to opensc that way. Also the code
> at that age is already BSD-2 or OpenSSL licensed.

The latter is the point I'd missed; thanks. I was worried about the
provenance of the code when it *arrived* in OpenSC. But if it was
already suitably licensed at that point, we don't need to care.

The same appears to be true for the libp11 repository — you changed the
licence when you moved the files to the new repository, so all we need
to track is changes which were contributed *since* then, which is
great.

Thanks again.

--
dwmw2


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
12