Hi!
Brad Tilley schrieb:
> Hope this isn't too inappropriate. It is OK to redistribute the GnuPG
> Windows binary installer?
IANAL, but given that GnuPG is GPLed, it should be perfectly OK.
However, you probably have to GPL your additions to the binary (i.e. the
customized scripts).
> We'd lik
?
Ultra Enterprise 4500, solaris 10, gcc 3.46, make 3.81
Everything builds ok until I get into the scd directory ...
Is there a way to disable the scd make? Is it necessary for gnpug to function?
-thank you,
Ray
<>
make
.
/usr/local/src/objcode/gnupg-2.0.7/scd
make[2]: En
Hi,
I just uploaded a release candidate for GnuPG 2.0.8:
ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.8rc1.tar.bz2
ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.8rc1.tar.bz2.sig
Note that the language files are not all updated and our translators may
want to check whether they find ti
Hi,
I just uploaded a second release candidate for GnuPG 1.4.8:
ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.8rc2.tar.bz2
ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.8rc2.tar.bz2.sig
If you have problems with 1.4.7, you may want to give it a try. Those
who reported build problems s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Werner Koch wrote the following on 12/14/07 8:35 AM:
> Hi,
>
> I just uploaded a second release candidate for GnuPG 1.4.8:
>
> ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.8rc2.tar.bz2
> ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.8rc2
On Fri, 14 Dec 2007 01:10, [EMAIL PROTECTED] said:
> gpg: O j: ATR returned by pcsc_status is too large
The PC/SC driver returns an ATR (Answer-To-Reset, the initial hello from
a smartcard) which is longer than the maximum of 32 bytes. The Beta of
Leopard had some problems with PC/SC:
ht
Remco Post wrote the following on 12/13/07 7:10 PM:
> Hi All,
>
> it seams that gpg and macos 10.5 are not on good terms for the smartcard:
>
> flops:~ remco$ gpg --card-status --no-use-agent
> gpg: detected reader `SCR335 USB Smart Card Reader 00 00'
> gpg: pcsc_status failed: insufficient buffe
> Dirmngr only supports binary CRLs. I have not seen anything about
> an ASCII armor requirement in the specs. You may use dirmngr-client
> to manualy load the CRL:
>
> dirmngr-client --load-crl --pem crl.asc
# dirmngr-client --load-crl --pem /dev/shm/RSA_Security_2048_v3.asc
dirmngr-client:
On Thu, 13 Dec 2007 23:14, [EMAIL PROTECTED] said:
> verification failes. Other CRLs are binary, this one starts with "-BEGIN
> X509 CRL-".
>
> Is this expected behavior or what can I do to fix it?
Yes, Dirmngr only supports binary CRLs. I have not seen anything about
an ASCII armor req
