Is there a plan to switch from libassuan 1 to libassuan 2, as gnupg just
did, for the signer browser plugin?
--
Ale
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Andreas Jellinghaus ha scritto:
> Please give it a final test.
>
> http://www.opensc-project.org/files/opensc/testing/opensc-0.11.11-rc1.tar.gz
Working here.
--
Ale
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-p
Andreas Jellinghaus ha scritto:
> here is a preview to 0.11.11, it contains a fix
> for compiling with openssl 0.9.7. please give it a try.
Tested, working.
--
Alessandro
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.ope
Andreas Jellinghaus ha scritto:
> true. here is a new patch on top of douglas patch.
> what do you think?
It compiles and seems correct, thanks.
Do you think to reroll the tarball or create a new release (or ...) ?
--
Alessandro
___
opensc-devel mailing
Douglas E. Engert ha scritto:
> Attached is a patch that compiles on Solaris 10 using the
> /usr/sfw/ version of OpenSSL-0.9.7 (which has security patches.)
>
> It tests the version of openssl and uses the old RSA_gererate_key
> if older the 0.9.8. Someone needs to try in on a system with 0.9.8.
Andreas Jellinghaus ha scritto:
> thanks for reporting, I was not aware of that. Can you post the error messages
> you get, if openssl 0.9.7 is used for compiling?
westcos files use the openssl 0.9.8 RSA_generate_key_ex() function. In
0.9.7 there is only RSA_generate_key().
> if we can make a sma
> Yes, this is what I mean: they *must not* be encoded, so that the
> shortest possible representation results that still allows to
> differentiate between positive and negative numbers.
Ok, we agree. Sorry if my first message seemed a bit rude.
> P.S. A couple of years ago I did an analysis of M
Andreas Steffen ha scritto:
> Additionally prepended 0x00 octets for positive and 0xFF octets for
> negative numbers, respectively are discarded.
If with "discarded" you mean that they will not appear in the encoded
form, yes. If you mean the decoder should ignore them, then no
octets. See the ITU-T X.690 standard.
--
Alessandro Premoli
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
b) shall not all be zero.
NOTE – These rules ensure that an integer value is always encoded in the
smallest possible number of octets.
The correct encodings of 128 and -128 are:
(128) 02:02:00:80
(-128) 02:01:80
Anything else is wrong.
--
Alessandro Prem
ure. The
problem is that attr->pValue is not guaranteed to be null terminated,
opensc should read attr->ulValueLen and do a copy of the label.
--
Alessandro Premoli
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://w
Ludovic Rousseau ha scritto:
> It is a bug in the installation of pcsc-lite. libpcsclite.so does use
> pthread but is not really links with it.
>
> This bug only occurs on *BSD systems.
That's not a bug, it's a feature. On FreeBSD libraries don't link with
thread libs, only the final binary has
I found the problem with my eAladdin eToken and latest OpenSC. It's
missing the CardOS 4.01 ATR (it was accidentally removed a few days ago
from card-cardos.c but not re-added together with 4.01a).
--
Alessandro
___
opensc-devel mailing list
opensc-dev
Andreas Jellinghaus wrote :
>> https://www.opensc-project.org/files/openct/testing/openct-0.6.12-pre3.tar.gz
That's fine.
>> https://www.opensc-project.org/files/opensc/testing/opensc-0.11.3-pre2.tar.gz
I have a regression with this one. I didn't investigate further yet, but
a simple 'ls' insid
Andreas Jellinghaus ha scritto:
> this change includes the recent improvements to the piv code.
> please give it a try.
Any chance to look at the following enhancement?
http://www.opensc-project.org/opensc/ticket/130
--
Alessandro
___
opensc-devel mail
Hi All,
as you perhaps remember, I was not confident about the rewrite of the
PKCS#11 header files. So, I asked the RSA's opinion and I'm now glad to
share their reply with you:
My apologies for the lengthy delay in responding to your message.
This would appear to be within the spirit of the
Alessandro Premoli ha scritto:
I started working on adding support to read/write data objects on crypto
token via pkcs#11. I think to finish in one or two days, I'll post patches
when I'm done.
Ticket #130, complete patch.
--
Alessandro
smime.p7s
Description: S/MIME Cryptographic
Hello,
I started working on adding support to read/write data objects on crypto
token via pkcs#11. I think to finish in one or two days, I'll post patches
when I'm done. Today I got writing file and update the DODF working,
tomorrow I'll continue with reading file and testing.
If you are wondering
Andreas Jellinghaus ha scritto:
It adds --disable-openct and --disable-pcsc-lite options.
Well, if it helps... commited to trunk, thanks!
Yes, it helps, thanks. It's always a good thing to deliberately choose
which libraries and packages link to.
--
Alessandro
smime.p7s
Description: S/MI
ructures.
Very easy.
--
Alessandro Premoli
smime.p7s
Description: S/MIME Cryptographic Signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
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 Sign
blem, possibly creating another one.
I'm sure OpenSC users would prefer to see code changes and improvements
rather than interface rewrites for GPL fanatism (ops, yes, I said it,
but it seems the thread took this direction).
--
Alessandro Premoli
smime.p7s
Des
r patch for libp11.
It seems completely useless to me. We should use the original and
official RSA headers.
--
Alessandro Premoli
smime.p7s
Description: S/MIME Cryptographic Signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
> OpenCT 0.6.10 doesn't compile on non-linux, so here is a fixed package:
>
> Please test and let me know if it works for you.
Yes, it works. Thanks.
--
Ale
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project
Andreas Jellinghaus ha scritto:
This new version only fixes a few minor bugs:
* implement usb reset (Andrey Jivsov)
Only for linux:
cc -Wall -O2 -fno-strict-aliasing -pipe -march=athlon-mp -D_THREAD_SAFE
-o .libs/ifdhandler ifdhandler.o -L/usr/local/lib ./.libs/libifd.a
/usr/home/alex/freeb
Nils Larsch wrote:
that's not surprising. old cardos cards couldn't sign and decrypt with
the same key
Do you mean that new cardos cards don't have this limit? From what
version? Is anyone aware of the reason of this limit?
and for these keys it was necessary to create signature
with the DE
Nils Larsch wrote:
If lock_login is set to false
setting cache_pins to true might help (not tested yet).
Yes, setting cache_pins works. I already tried it, but before the
locking fix, so it didn't seem to work at that time.
--
Alessandro
smime.p7s
Description: S/MIME Cryptographic Signatur
Nils Larsch wrote:
could you try a recent snapshot if you still get this behaviour ?
I tried today's opensc snapshot with debug patch from Andreas, and this
particular issue seems fixed. Setting 'lock_login = false' now works on
*single* access, i.e. I can run "echo Hello | pkcs11-tool -s --
Alessandro Premoli wrote:
Second scenario: PKCS#11 lib with lock_login = false
1) start thunderbird
2) read an encrypted message (it asks user pin, but fails to decrypt the
message, the PKCS#11 lib is unusable)
3) pkcs11-tool works correctly and displays all the info requested
Just an
Hello,
I've started playing with an Aladdin eToken PRO using latest releases of
openct and opensc on FreeBSD, but I'm encountering strange behaviours on
concurrent accesses. I'd like to understand how locking works in opensc
and if these are expected behaviours or real bugs. Single access works
30 matches
Mail list logo
