On Sun, 6 Sep 2015 10:11, dongsheng.s...@gmail.com said:
> In theory, you are right. But ALL Windows kernel object include HANDLE
> lower than 2^24.
I have seen kernel objects with a higher value. Not necessary HANDLE,
though.
> Then if these cast is safe for 64 bit Linux, then safe for Window
On Sun, 6 Sep 2015 16:29, joh...@vulcan.xs4all.nl said:
> Perhaps they accept larger files or can use more memory? I do remember
Should all be the same. I see no practical reason for using a 64 bit
binary. I even doubt that it will be faster because gpg does no
allocate large memory blocks.
On 2015-09-06 18:02, Peter Lebbing wrote:
> Is there any reason to provide 64-bits binaries, BTW? It's an unbiased
> question, I simply don't know. Does it provide any benefits?
Yes, when we running 64 bit Windows, use 64 bit binary is naturally requirement.
WoW64 is optional component for Window
> Is there any reason to provide 64-bits binaries, BTW? It's an unbiased
> question, I simply don't know. Does it provide any benefits?
Potentially. It allows the compiler to use x64 features such as W^X,
which relies on there being an NX bit in the page table entry. This
wasn't part of the x86
On 06-09-2015 12:02, Peter Lebbing wrote:
> Is there any reason to provide 64-bits binaries, BTW? It's an unbiased
> question, I simply don't know. Does it provide any benefits?
Perhaps they accept larger files or can use more memory? I do remember
once compiling the pgp 2.6.3ia sources with Visu
On 06/09/15 10:11, Dongsheng Song wrote:
> On 2015-09-05 17:40, Werner Koch wrote:
>> - The random number generator may not produce random output.
>
> Why not trust Windows CryptoAPI (CryptGenRandom) like libressl ?
May I suggest that you take down your compiled 64-bits versions and
issue a warn
On 2015-09-05 17:40, Werner Koch wrote:
> On Sat, 5 Sep 2015 04:23, dongsheng.s...@gmail.com said:
>
>> It's really works, you can check my building results:
> No, it can't work:
>
> - The random number generator may not produce random output.
Why not trust Windows CryptoAPI (CryptGenRandom) lik
On Sat, 5 Sep 2015 04:23, dongsheng.s...@gmail.com said:
> It's really works, you can check my building results:
No, it can't work:
- The random number generator may not produce random output.
- GnuPG casts pointers to integers which does not work on 64 bit
Windows where a pointer (and th
On Wed, Sep 2, 2015 at 11:53 PM, Werner Koch wrote:
> On Wed, 2 Sep 2015 11:17, dongsheng.s...@gmail.com said:
>
>> Yes, I build gnupg 2.1.7 for 32 bit and 64 bit Windows with the latest
>> libgcrypt and pinentry.
>
> Funny, 64 bit Windows is not supported by GnuPG.
>
It's really works, you can
On Wed, 2 Sep 2015 18:30, t...@riseup.net said:
> Sounds almost reasonable. But why then GnuPG shows Ed25519 keys as eg.
> 'ed25519/52275F7A'? When someone trying to generate 'Curve25519-signing
> key' they'll get ed25519 key. "Maybe I've done something wrong? I should
Well, given that you used
On Wed, 2 Sep 2015 11:17, dongsheng.s...@gmail.com said:
> Yes, I build gnupg 2.1.7 for 32 bit and 64 bit Windows with the latest
> libgcrypt and pinentry.
Funny, 64 bit Windows is not supported by GnuPG.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Werner Koch:
> That is actually on purpose. Both are based on the same curve and it
> seems easier to just call it Curve25519 than to explain why we use a
> different variant for signing. After all Curve25519 is a well known
> term.
Sounds almost reasonable. But why then GnuPG shows Ed25519 keys
On Wed, 2 Sep 2015 03:37, t...@riseup.net said:
> I'm also not able to generate keys in 2.1.7 on my Gentoo machine. It
> generates Ed25519 without errors (a typo: GnuPG says that it would use
> Curve25519 for signature not Ed25519). Because there is no option to
That is actually on purpose. Both
Hi,
On Monday, August 31, 2015 07:07:03 PM Andre Heinecke wrote:
> If I use the pinentry-basic included in the gnupg-w32 installer I get the
> "No pinentry" error.
> So it looks like pinentry-basic also has a Problem on Windows > 8.1
This was a problem in my test setup. I probably had gpg4win ins
On 2015-09-02 14:33, NIIBE Yutaka wrote:
> On 09/02/2015 10:37 AM, Ivan Markin wrote:
>> I'm also not able to generate keys in 2.1.7 on my Gentoo machine. It
>> generates Ed25519 without errors (a typo: GnuPG says that it would use
>> Curve25519 for signature not Ed25519). Because there is no optio
On 09/02/2015 10:37 AM, Ivan Markin wrote:
> I'm also not able to generate keys in 2.1.7 on my Gentoo machine. It
> generates Ed25519 without errors (a typo: GnuPG says that it would use
> Curve25519 for signature not Ed25519). Because there is no option to
> create Curve25519 at the beginning with
I'm also not able to generate keys in 2.1.7 on my Gentoo machine. It
generates Ed25519 without errors (a typo: GnuPG says that it would use
Curve25519 for signature not Ed25519). Because there is no option to
create Curve25519 at the beginning with Ed25519 one I'm trying to
`addkey` later. Error se
I'm also not able to generate keys in 2.1.7 on my Gentoo machine. It
generates Ed25519 without errors (a typo: GnuPG says that it would use
Curve25519 for signature not Ed25519). Because there is no option to
create Curve25519 at the beginning with Ed25519 one I'm trying to
`addkey` later. Error se
On Mon, 31 Aug 2015 21:01, aheine...@intevation.de said:
> I think you can't. I've already complained to Werner several times
> that I find the aspect that only "Developers" or the original reporter
> can add information to a bug report hurts bugs.g10code.com
This is done for a reason: In the pas
On 2015-08-31 at 21:01, Andre Heinecke wrote:
> 2010 I guess is slightly different as it has the "No Pinentry" Problem so
> I've
> left that out.
>
> Regards,
> Andre
>
It could be or at least part of it may be different.
I know that I also get the "gpg: error getting the KEK: Input/output
er
Hi,
On Monday, August 31, 2015 08:26:31 PM Juan Miguel Navarro Martínez wrote:
> I don't know how to reply to the issue (or maybe I just can't),
I think you can't. I've already complained to Werner several times that I find
the aspect that only "Developers" or the original reporter can add infor
I don't know how to reply to the issue (or maybe I just can't), I wanted
to say that issues 2083[1], 2010[2] and 1819[3] may be related or just
the same. They all have the "End of file" error.
[1]: https://bugs.gnupg.org/gnupg/issue2083
[2]: https://bugs.gnupg.org/gnupg/issue2010
[3]: https://bugs
On 2015-08-31 at 19:07, Andre Heinecke wrote:
> Hi,
>
> On Monday, August 31, 2015 01:53:48 PM Juan Miguel Navarro Martínez wrote:
>> I assume you are using a Windows 8 or higher. I already reported that on
>> another message in this same list. For some reason, making a passphrase
>> protected key
Hi,
On Monday, August 31, 2015 01:53:48 PM Juan Miguel Navarro Martínez wrote:
> I assume you are using a Windows 8 or higher. I already reported that on
> another message in this same list. For some reason, making a passphrase
> protected key makes GPG Agent crash.
I think this is a different bu
Hi,
On Monday, August 31, 2015 01:49:06 PM Zero0 wrote:
> I cleared the AppData and registry, installed
> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe to
> D:\Program Files (x86)\GnuPG, started the command prompt, typed "gpg
> --full-gen-key --expert" and get an EOF error after
I assume you are using a Windows 8 or higher. I already reported that on
another message in this same list. For some reason, making a passphrase
protected key makes GPG Agent crash.
On 2015-08-31 at 07:49, Zero0 wrote:
> I cleared the AppData and registry, installed
> https://gnupg.org/ftp/gcrypt
I cleared the AppData and registry, installed
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe to D:\Program
Files (x86)\GnuPG, started the command prompt, typed "gpg --full-gen-key
--expert" and get an EOF error after I entered the password.
gpg (GnuPG) 2.1.7; Copyright (C) 2015
27 matches
Mail list logo
