Hi,
I put it in.
Thanks,
Marcus
2006-12-17 Marcus Brinkmann <[EMAIL PROTECTED]>
* src/pkcs11.h [__WIN32]: Changed to [_WIN32 ||
CRYPTOKI_FORCE_WIN32] at the end.
Submitted by Alon Bar-Lev.
At Fri, 15 Dec 2006 15:15:05 +0200,
Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
>
Hello Marcus,
One more minor modification.
Index: include/pkcs11-helper-1.0/pkcs11.h
===
--- include/pkcs11-helper-1.0/pkcs11.h (revision 36)
+++ include/pkcs11-helper-1.0/pkcs11.h (working copy)
@@ -1321,7 +1321,7 @@
/* Syste
On 12/11/06, Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
The translation rules between the two interfaces are very simple, and
documented in the header file. So I don't think that's a big issue in
practice.
Sure...
It like learing that on Windows integer is DWORD, and pointer is PBYTE.
It is e
At Fri, 8 Dec 2006 20:20:20 +0200,
Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
>
> On Saturday 25 November 2006 01:35, Andreas Jellinghaus wrote:
> > BSD had for a long time this clause in its license:
> > 3. All advertising materials mentioning features or use of this
> > software must display the fo
At Fri, 8 Dec 2006 20:42:38 +0200,
Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
>
> On Friday 08 December 2006 20:28, Alon Bar-Lev wrote:
> > On Friday 08 December 2006 20:20, Alon Bar-Lev wrote:
> > > Hi!
> > >
> > > I've modified pkcs11-helper to use the new free pkcs11.h header.
> > > I was surprise
At Fri, 8 Dec 2006 20:28:42 +0200,
Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
>
> On Friday 08 December 2006 20:20, Alon Bar-Lev wrote:
> > Hi!
> >
> > I've modified pkcs11-helper to use the new free pkcs11.h header.
> > I was surprised that it went relatively OK, good work! :)
> >
> > Some modificat
On 12/9/06, Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
Well, two reasons: We like the GNU coding standard, and I toyed with
the idea to just change the API so that we could make our own code
consistent. But I haven't gotten around to do that yet (that's
because I wrote the code against the orig
Alon Bar-Lev wrote:
Hi!
I've modified pkcs11-helper to use the new free pkcs11.h header.
I was surprised that it went relatively OK, good work! :)
thanks!
Some modifications:
I think those are ok. Marcus?
Compiles fine with opensc and libp11 so I commited the latest pkcs11.h
from pkcs11-he
On Friday 08 December 2006 20:28, Alon Bar-Lev wrote:
> On Friday 08 December 2006 20:20, Alon Bar-Lev wrote:
> > Hi!
> >
> > I've modified pkcs11-helper to use the new free pkcs11.h header.
> > I was surprised that it went relatively OK, good work! :)
> >
> > Some modifications:
>
> One more:
One
On Friday 08 December 2006 20:20, Alon Bar-Lev wrote:
> Hi!
>
> I've modified pkcs11-helper to use the new free pkcs11.h header.
> I was surprised that it went relatively OK, good work! :)
>
> Some modifications:
One more:
6. Cast CKR_VENDOR_DEFINED to ck_rv_t so compiler will not
complain about s
On Saturday 25 November 2006 01:35, Andreas Jellinghaus wrote:
> BSD had for a long time this clause in its license:
> 3. All advertising materials mentioning features or use of this
> software must display the following acknowledgement:
> This product includes software developed by the Unive
On Fri, Dec 01, 2006 at 11:16:26PM +0100, Andreas Jellinghaus wrote:
> Peter Stuge wrote:
> >On Thu, Nov 30, 2006 at 10:28:14PM +0100, Andreas Jellinghaus wrote:
> >>the typedefs are not conditional or anything, so there is no
> >>difference if we uee "unsigned char" directly in that function
> >
>
Peter Stuge wrote:
On Thu, Nov 30, 2006 at 10:28:14PM +0100, Andreas Jellinghaus wrote:
the typedefs are not conditional or anything, so there is no
difference if we uee "unsigned char" directly in that function
Until it has to be changed in many places instead of one because
unsigned char isn
On Thu, Nov 30, 2006 at 10:28:14PM +0100, Andreas Jellinghaus wrote:
> the typedefs are not conditional or anything, so there is no
> difference if we uee "unsigned char" directly in that function
Until it has to be changed in many places instead of one because
unsigned char isn't 8 bit anymore. M
Peter Stuge wrote:
You said "might as well skip the extra typedef" and I thought that if
the spec explicitly says 8 bits and not 1 byte then there is a
(admittedly very small) point in having the abstraction.
ah, that was only a comment in the header file.
what the standard does is
typedef unsi
On Thu, Nov 30, 2006 at 08:47:41PM +0100, Andreas Jellinghaus wrote:
> Peter Stuge wrote:
> >If the spec says bits and not bytes
>
> hu? sorry, I'm confused, could you please quote the spec
> and where our header file is different?
I'm not claiming a discrepancy, I'm debating the usefulness of an
Peter Stuge wrote:
If the spec says bits and not bytes
hu? sorry, I'm confused, could you please quote the spec
and where our header file is different?
Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.op
On Thu, 30 Nov 2006 09:54, [EMAIL PROTECTED] said:
> not sure, but I guess the scute pkcs#11 module will make the whole
> gnupg key store available to some application, but this is only
> speculation.
That is the idea. As of now it only supports the authentication key
but we are working on more
On Thu, Nov 30, 2006 at 10:08:23AM +0100, Andreas Jellinghaus wrote:
> also there are no #ifdef or anything, so on every plattform and
> compiler the values are assigned like that, so I see no reason
> to add or keep any indirection. do you agree?
If the spec says bits and not bytes we could add t
Ludovic Rousseau wrote:
For example the type of tokenPresent is changed from CK_BBOOL to
unsigned char.
the original pkcs11t.h has:
/* an unsigned 8-bit value */
typedef unsigned char CK_BYTE;
and
/* a BYTE-sized Boolean flag */
typedef CK_BYTE CK_BBOOL;
so this is not a change.
Martin Paljak wrote:
This should be asked from from scute people actually, but why the
openpgp card support in opensc was/is not enough to have a openpgp card
only pkcs11 module ... ?
take a look at gnupg. as far as I know the whole architecture is
different. as far as I know: with openpgp ca
On 30.11.2006, at 1:38, Andreas Jellinghaus wrote:
already done. commited to scute already, and unless anyone stops me
real
This should be asked from from scute people actually, but why the
openpgp card support in opensc was/is not enough to have a openpgp
card only pkcs11 module ... ?
Alessandro Premoli wrote:
Perfect. Then we could only extract all the functions and data types
from the specs, create an header file that is *identical* to the
original one (perhaps with mis-ordered lines) but *without* the ugly
license and we are all ok. You are saying so, we are copying small
Andreas Jellinghaus ha scritto:
so I can print the document (unchanged, so complient to this license),
and give it to someone else. that person receives a book from me,
nothing else. no contract or anything binding that person to me or
rsa labs. no obligation from rsa labs to me to not give anyon
On 29.11.2006, at 1:22, Andreas Jellinghaus wrote:
also I think werner is also very active with these topics, read and
heard a lot about it. but still we are no lawyers and might be
completely wrong, even if I think the chances for this are small.
Why not contact RSA labs directly (or as
Andreas Jellinghaus wrote:
> true. I'm not a lawyer. on the other hand I have been following
> discussions ..., so I hope I'm totally clueless...
I hope you are rather not so clueless ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
begin:vcard
fn:Eddy Nigg
n:Ni
Ludovic Rousseau wrote:
"License to COPY this document is granted provided that it is
identified as "RSA Security Inc. Public-Key Cryptography Standards
(PKCS)" in all material mentioning or
referencing this document. "
so I can print the document (unchanged, so complient to this license),
and
Ludovic Rousseau wrote:
You have the legal right to _run_ such a combination. The GPL has no
limitation on how you _execute_ the GPL software. You can mix a GPL
code and a proprietary code and use it. What you can't (legally) do is
_distribute_ such a mix.
I thought there was something like tha
Alessandro,
sure, the header file we wrote is a derived work of the pkcs#11 standard
documentation. but that is a book, and what we do is quote certain parts
we need. a book is not a software, there is no license on it, only
copyright. and copyright allows us to quote parts within certain
limit
Martin Paljak wrote:
So if I had an application, 100% GPL and it implemented a 'celan'
pkcs#11 interface that loaded pkcs11-spy (LGPL?) what in turn loads a
StrangeToken$$$ pkcs11 module, that would not be good ?
all code in an application at compile time and runtime must be under GPL
compati
Martin Paljak wrote:
On 28.11.2006, at 0:06, Andreas Jellinghaus wrote:
from a legal point of view I would like opensc being compatible with
the GPL. the rsa header files are not under their current license.
I hope you meant L-GPL.
no,GPL. opensc is and stays under LGPL. but if we have an
On 27/11/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
Alessandro Premoli wrote:
> The new PKCS#11 header *is* a derivative work of the original RSA
> interface.
you can't put a license on a printed book - the law is quite clear
on that. so if someone reads the book "pkcs#11 (the complete s
On 28/11/06, Martin Paljak <[EMAIL PROTECTED]> wrote:
On 28.11.2006, at 10:56, Werner Koch wrote:
> On Tue, 28 Nov 2006 09:47, [EMAIL PROTECTED] said:
>
>> I hope you meant L-GPL.
>
> An GPLed application can't use an LGPLed library if that library in
> turn uses GPL-incomatible code. Everythi
On Tue, 28 Nov 2006 10:14, [EMAIL PROTECTED] said:
> Ok, the RSA headers are not GPLed, and then? Who cares? We are not
> going to extend or modify them, we are implementing the official RSA
> PKCS#11 standard after all!
The headers from RSA come with a license that is not compatible to the
GPL:
On 28.11.2006, at 10:56, Werner Koch wrote:
On Tue, 28 Nov 2006 09:47, [EMAIL PROTECTED] said:
I hope you meant L-GPL.
An GPLed application can't use an LGPLed library if that library in
turn uses GPL-incomatible code. Everything else would open a
So if I had an application, 100% GPL and i
Werner Koch ha scritto:
I hope you meant L-GPL.
An GPLed application can't use an LGPLed library if that library in
turn uses GPL-incomatible code.
These discussions remind me how wonderful is the BSD license.
--
Alessandro Premoli
smime.p7s
Description: S/MIME Cryptographic Signature
Werner Koch ha scritto:
The new PKCS#11 header *is* a derivative work of the original RSA
interface. If you think implementing RSA PKCS#11 in OpenSC makes it a
No, it is not a derivative work.
You missed the first point of my email and are all focusing on the
second one. Implementing an inte
On Tue, 28 Nov 2006 09:47, [EMAIL PROTECTED] said:
> I hope you meant L-GPL.
An GPLed application can't use an LGPLed library if that library in
turn uses GPL-incomatible code. Everything else would open a
loophole: Take non-GPL-compatible code, write an LGPLed wrapper and
use that wrapper from
On 28.11.2006, at 0:06, Andreas Jellinghaus wrote:
from a legal point of view I would like opensc being compatible
with the GPL. the rsa header files are not under their current
license.
I hope you meant L-GPL.
--
Martin Paljak / [EMAIL PROTECTED]
martin.paljak.pri.ee / ideelabor.ee
+372
Ludovic Rousseau wrote:
I am not sure it is a good idea to change the arguments types.
that is not intentional, any difference is a bug and needs
to be fixed.
Should'nt we stick to the API as defined in the standard?
yes. but replacing the header files with something GPL compatible
would be
Martin Paljak wrote:
from practical point of view i agree with the original RSA header standpoint.
from a legal point of view I would like opensc being compatible with the
GPL. the rsa header files are not under their current license.
Regards, Andreas
Alessandro Premoli wrote:
The new PKCS#11 header *is* a derivative work of the original RSA
interface.
you can't put a license on a printed book - the law is quite clear
on that. so if someone reads the book "pkcs#11 (the complete standard,
not the header files)", and notes down the definitions
On Mon, 27 Nov 2006 15:00, [EMAIL PROTECTED] said:
> The new PKCS#11 header *is* a derivative work of the original RSA
> interface. If you think implementing RSA PKCS#11 in OpenSC makes it a
No, it is not a derivative work. It is an implementation of the
interface defined in the pkcs#11 specs.
On 27.11.2006, at 16:00, Alessandro Premoli wrote:
It seems completely useless to me. We should use the original and
official RSA headers.
I don't know if the reasoning you gave is legally correct, but from
practical point of view i agree with the original RSA header standpoint.
--
Marti
Alessandro Premoli wrote:
> The new PKCS#11 header *is* a derivative work of the original RSA
> interface. If you think implementing RSA PKCS#11 in OpenSC makes it a
> derivative work and so subjected to RSA's license, then implementing a
> derivative interface doesn't change anything, because of t
Andreas Jellinghaus ha scritto:
End of August I tried to address the issue on the cryptoki mailing lists
and asked for a license change, but the result was none. However
communicating with other open source projects they understand the
problem and would like to see it solved too.
The problem
Hello,
On 25/11/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
Please have a look at let me know what you think about it. Also if you
spot any difference, typo or problem with the new header file, please
let me know.
I am not sure it is a good idea to change the arguments types.
-/* C_Get
47 matches
Mail list logo
