Page MenuHome GnuPG
Feed Advanced Search

Sep 11 2015

werner added a project to T2098: gpg not built with large secure memory buffer. Ignoring --enable-large-rsa: Won't Fix.
Sep 11 2015, 9:11 AM · Won't Fix, gnupg, Feature Request

Sep 8 2015

werner closed T1969: gpg-agent stops working after OSX Upgrade to Yosemite as Resolved.
Sep 8 2015, 3:00 PM · patch, Bug Report, gpgagent, gnupg, gnupg (gpg20), Won't Fix, MacOS
werner added a project to T2090: broken link "Roundup docs": Won't Fix.
Sep 8 2015, 9:25 AM · Won't Fix, Bug Report, gpgweb

Sep 7 2015

werner added a comment to T1682: whirlpool amd64 assembly.

No DCO received, no review, won't apply. Sorry.

Sep 7 2015, 6:32 PM · Won't Fix, libgcrypt, Feature Request
werner added a project to T1682: whirlpool amd64 assembly: Won't Fix.
Sep 7 2015, 6:32 PM · Won't Fix, libgcrypt, Feature Request
werner added a project to T1741: comparison between signed and unsigned integer: Won't Fix.
Sep 7 2015, 6:29 PM · Won't Fix, libgcrypt
werner added a project to T2037: please add pkg-config file for libgcrypt: Won't Fix.
Sep 7 2015, 6:19 PM · Won't Fix, libgcrypt, Feature Request

Aug 13 2015

werner added a comment to T1211: gpg-agent should disable ptrace.

c) Run gpg-agent under gdb
d) Run a modified gpg-agent (rm ~/S.gpg-agent; my-gpg-agent --daemon)
e) Hook into the tty and use pinentry-curses
f) scp ~/.gnupg/private-keys-v1.d/* mybox: and sniff the passphrase.

Aug 13 2015, 6:36 PM · Won't Fix, Feature Request, gnupg, Not A Bug, gpgagent

Aug 12 2015

dkg reopened T1211: gpg-agent should disable ptrace as "Open".
Aug 12 2015, 3:53 PM · Won't Fix, Feature Request, gnupg, Not A Bug, gpgagent
dkg added a comment to T1211: gpg-agent should disable ptrace.

so far, the proposed mechanisms for getting at gpg-agent's memory from a peer
process running as the same user are:

a) ptrace (e.g. via /usr/bin/gcore or /usr/bin/strace)
b) /proc/$PID/mem, which is owned by the user and mode 0600

DarkStarSword's patch effectively closes (a) (by rejecting ptrace connections)
and appears on my GNU/Linux system to close (b) as well: /proc/$PID/mem is
root-owned when the patch is applied instead of being user-owned.

Are there other channels for per-process memory access that we should be
thinking about?

I agree with Werner and Neal that the UNIX model is probably insufficient to
close all the holes easily, but i also don't think that's a good reason to avoid
closing those holes we can close.

If there are other ways that another process by the same user can get at the
RAM, please point them out and i'll look into ways to address them too.

In the meantime, i'll also look into ways to facilitate running the process as a
separate user account entirely.

Aug 12 2015, 3:53 PM · Won't Fix, Feature Request, gnupg, Not A Bug, gpgagent
werner closed T1211: gpg-agent should disable ptrace as Resolved.
Aug 12 2015, 10:09 AM · Won't Fix, Feature Request, gnupg, Not A Bug, gpgagent
werner added a project to T1211: gpg-agent should disable ptrace: Won't Fix.
Aug 12 2015, 10:09 AM · Won't Fix, Feature Request, gnupg, Not A Bug, gpgagent

Jul 21 2015

werner added a comment to T2017: consider using $XDG_RUNTIME_DIR for gpg-agent socket communication.

1.4 won't handle such a redirection because it does not use libassuan.

2.0 should follow such a redirection but the 2.0 agent is not able to setup a
socket in this way. If there is a real need it can be backported.

Jul 21 2015, 3:48 PM · Won't Fix, gnupg, Feature Request

Jul 1 2015

dkg added a comment to T2017: consider using $XDG_RUNTIME_DIR for gpg-agent socket communication.

So the implication here is that users who want to use XDG_RUNTIME_DIR can do:

echo '%Assuan%' > ~/.gnupg/S.gpg-agent
echo '${XDG_RUNTIME_DIR}/S.gpg-agent' >> ~/.gnupg/S.gpg-agent

and it will Just Work for those with an NFS homedir?

Even on non-NFS volumes, this has the nice property that gpg-agent's
"check-own-socket" feature should be able to close down the gpg-agent process
when it's no longer needed by an active session.

What would the failure conditions be if that variable isn't actually set,
though? I guess it would be the same as specifying /S.gpg-agent, which should
result in permission denied, which means a failed gpg-agent. Is that right?

Will 1.4.x or 2.0.x respect such a redirection if they find it in the socket
they're trying to talk to, or is this a 2.1.x-only feature?

Jul 1 2015, 8:35 AM · Won't Fix, gnupg, Feature Request

Jun 23 2015

werner added a comment to T2017: consider using $XDG_RUNTIME_DIR for gpg-agent socket communication.

Thr redirect feature has not yet been documented. You can create a regular file
with the name of the socket file using this format

   %Assuan%
   socket=NAME

   where NAME is the actual socket to use.  No white spaces are
   allowed, both lines must be terminated by a single LF, extra lines
   are not allowed.  Environment variables are interpreted in NAME if
   given in "${VAR} notation; no escape characters are defined, if
   "${" shall be used verbatim, you need to use an environment
   variable with that content.

   The use of an absolute NAME is strongly suggested.  The length of
   the file is limited to 511 bytes which is more than sufficient for
   that common value of 107 for sun_path.
Jun 23 2015, 11:40 AM · Won't Fix, gnupg, Feature Request

Jun 22 2015

rdieter added a comment to T2017: consider using $XDG_RUNTIME_DIR for gpg-agent socket communication.

and to be clear, I'm not suggesting not using ~/.gnupg at all anymore. I'm only
saying that using that as a default location for gpg-agent socket is bad for some
use-cases (like nfs $HOME)

Jun 22 2015, 4:15 PM · Won't Fix, gnupg, Feature Request
rdieter reopened T2017: consider using $XDG_RUNTIME_DIR for gpg-agent socket communication as "Open".
Jun 22 2015, 4:05 PM · Won't Fix, gnupg, Feature Request
rdieter added a comment to T2017: consider using $XDG_RUNTIME_DIR for gpg-agent socket communication.

what is this "redirect feature" you mention? how would that help a user logging
into multiple computers using the same (nfs) $HOME ?

Jun 22 2015, 4:05 PM · Won't Fix, gnupg, Feature Request
werner added a project to T2017: consider using $XDG_RUNTIME_DIR for gpg-agent socket communication: Won't Fix.
Jun 22 2015, 11:06 AM · Won't Fix, gnupg, Feature Request

May 22 2015

werner removed Version on T1991: pinentry-w32 needs to adjust button sizes.
May 22 2015, 3:01 PM · pinentry, Won't Fix, Feature Request, Not A Bug
werner renamed T1991: pinentry-w32 needs to adjust button sizes from Password insecure warning dialog has buttons too small for text to pinentry-w32 needs to adjust button sizes.
May 22 2015, 3:01 PM · pinentry, Won't Fix, Feature Request, Not A Bug
werner added a comment to T1991: pinentry-w32 needs to adjust button sizes.

Oh well, resizing the buttons to a new fixed size would be a job in the source
of 10 minutes or so. However, this makes an very ugly Pinentry for every day's
use (i.e. entering a passphrase for an existing key). So, sorry, I won't take
that patch.

With native Windows code I mean native Windows code for GUIs instead of relying
on MFC or whatever is the latest GUI framework MS uses. This is similar to xlib
programm vs. GTK+ programming

Anyway, thanks for looking into this. I will retitle the bug to keep it open.
Maybe eventually someone starts to hack on it.

May 22 2015, 3:01 PM · pinentry, Won't Fix, Feature Request, Not A Bug
werner added projects to T1991: pinentry-w32 needs to adjust button sizes: Feature Request, pinentry.
May 22 2015, 3:01 PM · pinentry, Won't Fix, Feature Request, Not A Bug
werner removed projects from T1991: pinentry-w32 needs to adjust button sizes: Bug Report, gpg4win.
May 22 2015, 3:01 PM · pinentry, Won't Fix, Feature Request, Not A Bug
Animedude5555 added a comment to T1991: pinentry-w32 needs to adjust button sizes.

May 22 2015, 11:29 AM · pinentry, Won't Fix, Feature Request, Not A Bug
Animedude5555 added a comment to T1991: pinentry-w32 needs to adjust button sizes.

May 22 2015, 11:29 AM · pinentry, Won't Fix, Feature Request, Not A Bug
Animedude5555 added a comment to T1991: pinentry-w32 needs to adjust button sizes.

Well, here's my fix. Using this neat little program I downloaded called
Resource Hacker, I edited the buttons on the dialog box so that they would
be big enough to display the messages needed. Realizing that pinentry.exe
and pinentry-w32.exe were identical files (checking them in a hex editor
with file comparison function showed them to be exactly the same), I just
copied my edited version of pinentry.exe and renamed the copy as
pinentry-w32.exe. I have put both of them in a zip file called
pinentry.zip, and have attached this zip file to this email. Feel free to
distribute this on the official GPG4Win website. Note that the file name of
the attachment is "piz" not "zip", so before you extract its contents (for
use, or posting on your website) you will need to rename it from "piz" back
to "zip". I had to rename it from "zip" to "piz" because otherwise Gmail's
mail server scans inside the zip file and then for blocks it because it
detects exe files (and exe files are a format that can potentially harbor
malware). Even though this has no malware (as you can see by scanning it
with a virus scanner), Google's mail server takes extra precautions by
refusing to allow sending of executable files or even archive files that
contain executable files.

May 22 2015, 11:29 AM · pinentry, Won't Fix, Feature Request, Not A Bug
Animedude5555 added a comment to T1991: pinentry-w32 needs to adjust button sizes.

May 22 2015, 11:04 AM · pinentry, Won't Fix, Feature Request, Not A Bug
Animedude5555 reopened T1991: pinentry-w32 needs to adjust button sizes as "Open".
May 22 2015, 11:04 AM · pinentry, Won't Fix, Feature Request, Not A Bug
Animedude5555 added a comment to T1991: pinentry-w32 needs to adjust button sizes.

As far as I know, GPG4Win is a compiling/linking of GPG to be Windows
compatible, which means that the code was already altered to work with
Windows. Therefore native Windows code is already in use in the GPG4Win
variant of GPG. Therefore it should work correctly in every respect in
Windows (including correctly sized buttons).

May 22 2015, 11:04 AM · pinentry, Won't Fix, Feature Request, Not A Bug
werner closed T1991: pinentry-w32 needs to adjust button sizes as Resolved.
May 22 2015, 9:48 AM · pinentry, Won't Fix, Feature Request, Not A Bug
werner added a project to T1991: pinentry-w32 needs to adjust button sizes: Won't Fix.
May 22 2015, 9:48 AM · pinentry, Won't Fix, Feature Request, Not A Bug

May 11 2015

werner removed a project from T1046: --quiet --passphrase ... outputs passphrase message: Stalled.
May 11 2015, 8:51 PM · Won't Fix, Ubuntu, gnupg, Feature Request
werner closed T1046: --quiet --passphrase ... outputs passphrase message as Resolved.
May 11 2015, 8:51 PM · Won't Fix, Ubuntu, gnupg, Feature Request
werner added projects to T1606: gpg --sign-key doesn't worth with --yes, --no-tty, or --batch: gnupg (gpg14), gnupg (gpg20), Won't Fix.
May 11 2015, 8:43 PM · Won't Fix, gnupg (gpg20), gnupg (gpg14), gnupg
werner added projects to T1485: deluid deleting all exact copies from secret key: gnupg (gpg14), Won't Fix.
May 11 2015, 8:33 PM · Won't Fix, gnupg (gpg14), gnupg, Bug Report
werner added a project to T1742: gpg --list-secret-keys may not show all UIDs when a UID has been revoked: Won't Fix.
May 11 2015, 8:28 PM · Won't Fix, Bug Report, gnupg

May 7 2015

gniibe added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

In 1.6.3, libgcrypt now work with automake >= 1.14.

See the commit: c123e313e90a6ffb14c9be3ddaab3ad44a44f2b6

May 7 2015, 4:04 AM · libgcrypt, Gentoo, Won't Fix, Bug Report
gniibe added a project to T1607: libgcrypt parallel tests automake>=1.13 issue: libgcrypt.
May 7 2015, 4:04 AM · libgcrypt, Gentoo, Won't Fix, Bug Report
gniibe closed T1607: libgcrypt parallel tests automake>=1.13 issue as Resolved.
May 7 2015, 4:04 AM · libgcrypt, Gentoo, Won't Fix, Bug Report

May 6 2015

werner added a project to T1969: gpg-agent stops working after OSX Upgrade to Yosemite: Won't Fix.
May 6 2015, 9:37 AM · patch, Bug Report, gpgagent, gnupg, gnupg (gpg20), Won't Fix, MacOS

Apr 4 2015

werner closed T1749: Use of atexit() problematical for dynamically loaded libraries -- libgpg-error as Resolved.
Apr 4 2015, 11:19 AM · Won't Fix, Bug Report, gpgrt
werner added a project to T1749: Use of atexit() problematical for dynamically loaded libraries -- libgpg-error: Won't Fix.
Apr 4 2015, 11:19 AM · Won't Fix, Bug Report, gpgrt

Mar 10 2015

werner added a project to T1901: seed.c: the right operand of '^' is a garbage value: Won't Fix.
Mar 10 2015, 9:59 AM · Won't Fix, libgcrypt

Feb 11 2015

werner added a project to T1833: Add support for JSON output: Won't Fix.
Feb 11 2015, 12:00 PM · Won't Fix, gnupg, Feature Request

Jan 28 2015

werner removed a project from T1821: cannot specify secret key to decrypt msg with multiple recipients: Bug Report.
Jan 28 2015, 11:23 AM · Won't Fix, Feature Request, gnupg
werner added projects to T1821: cannot specify secret key to decrypt msg with multiple recipients: Feature Request, Won't Fix.
Jan 28 2015, 11:23 AM · Won't Fix, Feature Request, gnupg

Jan 27 2015

werner added a comment to T1817: Changing expiration on subkeys breaks subkeys.

I just verified that it is not a problem in 2.1.

I am not sure whether it makes sense to fix it in 1.4 given that it is easier to
change it with 2.1, export and import it then to 1.4. I feel it is better to
use my time to fix some missing export options in 2.1

Jan 27 2015, 9:08 AM · Won't Fix, gnupg (gpg20), gnupg (gpg14), Bug Report, gnupg

Jan 19 2015

werner added a project to T1817: Changing expiration on subkeys breaks subkeys: Won't Fix.
Jan 19 2015, 4:55 PM · Won't Fix, gnupg (gpg20), gnupg (gpg14), Bug Report, gnupg
werner added a comment to T1817: Changing expiration on subkeys breaks subkeys.

It is known that the secret keyrings easily gets out of sync. Thus do not rely
on that information. Always use the public key ring for such info.

We won't fix that in < 2.1

Jan 19 2015, 4:55 PM · Won't Fix, gnupg (gpg20), gnupg (gpg14), Bug Report, gnupg

Jan 10 2015

werner added a comment to T1809: add option for SHA256 and SHA512 fingerprint.

MD5 is not used bu OpenPGP. It is allowed for backward compatibility but even
that has been dropped for GnuPG 2.1.

The use of SHA-1 fingerprints is hardwired into OpenPGP and to change this a
complete new key format needs to be specified. In any case the fingerprints
are not a problem right now.

Using Base64 fingerprints are actually a bad idea because they are to hard to
compare for a human.

Jan 10 2015, 6:20 PM · gnupg, Feature Request, Won't Fix

Jan 9 2015

kolAflash added a comment to T1809: add option for SHA256 and SHA512 fingerprint.

P.S.
SHA512 probably would be the right thing. If someone's too lazy to compare such
a long fingerprint, he can still choose just to compare just one half of it.

Jan 9 2015, 2:44 PM · gnupg, Feature Request, Won't Fix
kolAflash added a comment to T1809: add option for SHA256 and SHA512 fingerprint.

Sure, a standard for that would be great.

MD5 is pretty much broken for security purposes and I would wonder, if that's
not also true in the context of OpenPGP.

You're probably much closer to the people responsible for the OpenPGP standard.
Are there any efforts to introduce SHA512-BASE64 fingerprints? (or at least SHA256)

Jan 9 2015, 2:38 PM · gnupg, Feature Request, Won't Fix
werner added projects to T1809: add option for SHA256 and SHA512 fingerprint: Won't Fix, gnupg.
Jan 9 2015, 1:00 PM · gnupg, Feature Request, Won't Fix

Jan 5 2015

werner added a project to T1704: SCO OpenServer build fix: Won't Fix.
Jan 5 2015, 7:13 PM · Won't Fix, Bug Report, libgcrypt
werner closed T1704: SCO OpenServer build fix as Resolved.
Jan 5 2015, 7:13 PM · Won't Fix, Bug Report, libgcrypt
werner added a project to T1706: Resource leak in file "cipher/pubkey.c" in function "gcry_pk_encrypt" at line 2876 and "gcry_pk_genkey" at line 3623: Won't Fix.
Jan 5 2015, 7:05 PM · Won't Fix, Bug Report, libgcrypt

Dec 16 2014

werner added a comment to T1790: Keep signed files executable.

OpenPGP does not specify this. It is actually not easy to add another format
becuase that opens the path for all kind of attacks. Like with ELF comment
section you can do the same for any other data format. No, there is no ELF
parser in gpg and there won't be one for any other language.

Please take this to the gnupg-users ML or to the OpenPGP WG. Thanks.

Dec 16 2014, 3:40 PM · Won't Fix, Feature Request
werner added a project to T1790: Keep signed files executable: Won't Fix.
Dec 16 2014, 3:40 PM · Won't Fix, Feature Request

Oct 3 2014

werner closed T1460: allow larger key creation (8192 bits) as Resolved.
Oct 3 2014, 6:15 PM · Feature Request, Won't Fix

Sep 26 2014

werner closed T1723: more precise wording in option lists as Resolved.
Sep 26 2014, 2:18 PM · Won't Fix, gnupg, Feature Request
werner closed T1722: advertise the ? option in CLI as Resolved.
Sep 26 2014, 2:16 PM · Won't Fix, gnupg, Feature Request
infinity0 added a comment to T1722: advertise the ? option in CLI.

FYI, just adding a "Type ? for help." after "Invalid selection." would improve
the situation massively.

Sep 26 2014, 2:01 PM · Won't Fix, gnupg, Feature Request
infinity0 added a comment to T1722: advertise the ? option in CLI.

Really, which prompts are those?

$ sh
$ ?
sh: 1: ?: not found
$
127

$ ed
?
?
1

$ bash
$ ?
bash: ?: command not found
127

$ zsh
% ?
zsh: no matches found: ?
%
1

$ man man
?
Pattern not found (press RETURN)

$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
?
(standard_in) 1: illegal character: ?

$ gdb
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) ?
Undefined command: "". Try "help".
(gdb) quit

Fuck, even vi tells me "type :help<Enter> or <F1> for on-line help"

$ python
Python 2.7.8 (default, Sep 9 2014, 22:08:43)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

?

File "<stdin>", line 1
  ?
  ^

SyntaxError: invalid syntax

$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ: ?

<interactive>:2:1: parse error on input `?'
λ:
Leaving GHCi.

Sep 26 2014, 2:01 PM · Won't Fix, gnupg, Feature Request
werner closed T1728: document parameters to GET_LINE et. al. as Resolved.
Sep 26 2014, 12:56 PM · Bug Report, Won't Fix, gnupg
werner added a comment to T1728: document parameters to GET_LINE et. al..

If you order such a docuemntation I'll be glad to add it. Contact me at my
company address.

Sep 26 2014, 12:56 PM · Bug Report, Won't Fix, gnupg
infinity0 reopened T1723: more precise wording in option lists as "Open".
Sep 26 2014, 1:12 AM · Won't Fix, gnupg, Feature Request
infinity0 added a comment to T1723: more precise wording in option lists.

You responded to my previous suggestions, and this is my next iteration, with me
trying to take into account your comments.

I find that making related options visually related, helps the user to better
intuitively understand what they do. The current options don't do this.

You also had a comment along the lines of "sign is not accurate because there's
also certify and authenticate", but a few current options also have this flaw. I
think it's OK, but it's better to do this consistently.

Sep 26 2014, 1:12 AM · Won't Fix, gnupg, Feature Request
infinity0 added a comment to T1728: document parameters to GET_LINE et. al..

If "a complete documentation is not possible", then it is not fit for purpose as
an API to be scripted, and you should stop advertising that functionality in public.

If you do not have time to do this documentation, the correct response is to say
"I do not have time to do this", but leave the bug open, because it is something
to be resolved in the future.

An exposed public interface that you expressly suggested me to use in a script,
is *supposed* to have documentation associated with it. That is basic standard
software engineering. You don't see standard library authors respond with "just
try out the function to see what happens", when someone points out missing
documentation.

Sep 26 2014, 12:30 AM · Bug Report, Won't Fix, gnupg
infinity0 added a project to T1728: document parameters to GET_LINE et. al.: Bug Report.
Sep 26 2014, 12:30 AM · Bug Report, Won't Fix, gnupg
infinity0 removed a project from T1728: document parameters to GET_LINE et. al.: Feature Request.
Sep 26 2014, 12:30 AM · Bug Report, Won't Fix, gnupg
infinity0 reopened T1728: document parameters to GET_LINE et. al. as "Open".
Sep 26 2014, 12:30 AM · Bug Report, Won't Fix, gnupg

Sep 25 2014

werner added a comment to T1723: more precise wording in option lists.

Nope. We discussed this already at the ML.

Sep 25 2014, 8:36 PM · Won't Fix, gnupg, Feature Request
werner added a project to T1723: more precise wording in option lists: Won't Fix.
Sep 25 2014, 8:36 PM · Won't Fix, gnupg, Feature Request
werner added a project to T1722: advertise the ? option in CLI: Won't Fix.
Sep 25 2014, 8:35 PM · Won't Fix, gnupg, Feature Request
werner added a comment to T1728: document parameters to GET_LINE et. al..

That is exactly the idea. Walk it through manually and you see what you need to
type. Adding docs bearks the risk that the docs is not in sync with the code
and thus we would need to run tests to make sure this is the case. The order of
the prompts depends on so many factors that a complete documentation si not
possible.

Sep 25 2014, 8:33 PM · Bug Report, Won't Fix, gnupg
werner added a project to T1728: document parameters to GET_LINE et. al.: Won't Fix.
Sep 25 2014, 8:33 PM · Bug Report, Won't Fix, gnupg

Aug 6 2014

werner closed T1679: Update outdated default preferences as Resolved.
Aug 6 2014, 3:37 PM · patch, gnupg, gnupg (gpg21), Feature Request, Won't Fix, OpenPGP
werner added a comment to T1679: Update outdated default preferences.

There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.

Aug 6 2014, 3:37 PM · patch, gnupg, gnupg (gpg21), Feature Request, Won't Fix, OpenPGP
coruus reopened T1679: Update outdated default preferences as "Open".
Aug 6 2014, 2:28 PM · patch, gnupg, gnupg (gpg21), Feature Request, Won't Fix, OpenPGP
coruus added a comment to T1679: Update outdated default preferences.

Thank you for the prompt response.

I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?

Aug 6 2014, 2:28 PM · patch, gnupg, gnupg (gpg21), Feature Request, Won't Fix, OpenPGP
werner added a project to T1679: Update outdated default preferences: Won't Fix.
Aug 6 2014, 10:39 AM · patch, gnupg, gnupg (gpg21), Feature Request, Won't Fix, OpenPGP

Jun 24 2014

werner added a project to T1547: gnupg >= 2.0.21 won't build on OSX 10.8.5 with XCode5: Won't Fix.
Jun 24 2014, 1:38 PM · Won't Fix, Bug Report, gnupg
werner closed T1547: gnupg >= 2.0.21 won't build on OSX 10.8.5 with XCode5 as Resolved.
Jun 24 2014, 1:38 PM · Won't Fix, Bug Report, gnupg

Jun 23 2014

werner closed T1233: private main and subkeys spread over several keyrings as Resolved.
Jun 23 2014, 10:46 AM · Won't Fix, Bug Report, gnupg

May 15 2014

werner added a project to T1641: Add native support for PK 8192: Won't Fix.
May 15 2014, 5:41 PM · gnupg, Feature Request, Won't Fix
werner removed projects from T1641: Add native support for PK 8192: patch, In Progress.
May 15 2014, 5:41 PM · gnupg, Feature Request, Won't Fix
werner closed T1641: Add native support for PK 8192 as Resolved.
May 15 2014, 5:41 PM · gnupg, Feature Request, Won't Fix
werner added a comment to T1641: Add native support for PK 8192.

Won't happen. Please read the FAQ. IF you need to discuss this, please do that
at gnupg-users@

May 15 2014, 5:41 PM · gnupg, Feature Request, Won't Fix

Jan 29 2014

werner added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

A user shall not use automake to build libgrypt.

I am very well aware of all the problems with newer automake versions. I try to
eventually mitigate the problems and the extra rules we have in some projects
might be helpful but a proper solution for automake would be to reverse the
default tests method to serial-tests. There are only a few projects with lots
of regression tests which benefit from the new default - those could easily
switch on parallel-tests. But I have seen no signs that they will revert it.

Eventually we need to add our own test driver - IIRC, recent automakes allow to
enable a custom test driver while still having build support by automake.

Jan 29 2014, 4:25 PM · libgcrypt, Gentoo, Won't Fix, Bug Report
alonbl added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

the tarball is OK, however, we must patch the autoconf[1], so we also use the
automake installed at user site which may be newer than 1.13.

it seems that this expression has no effect to 1.13 and damage the 1.14...

bench-slope.log: benchmark.log
hashtest-256g.log: bench-slope.log

you can close this issue, but know that it does exist in newer versions of
automake. if there is no real need for the above statements then removing them
resolves the issue.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

Jan 29 2014, 3:18 PM · libgcrypt, Gentoo, Won't Fix, Bug Report
werner added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

I am confused:

Do you say that you have problems to build the tarball release? In that case I
can replicate the problem. FWIW, the 1.6.1 release has been build with automake
1.11 and I am pretty sure that this was also the case for 1.6.0.
From the top Makefile.in:

Makefile.in generated by automake 1.11.6 from Makefile.am.

So, why do you need autoreconf to fix a problem with parallel tests? automake
1.11 does not generate such test rules.

Jan 29 2014, 3:09 PM · libgcrypt, Gentoo, Won't Fix, Bug Report
alonbl reopened T1607: libgcrypt parallel tests automake>=1.13 issue as "Open".
Jan 29 2014, 10:19 AM · libgcrypt, Gentoo, Won't Fix, Bug Report
alonbl added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

That was added because we have it in master.

Have 'it'? I see it in the tarball of 1.6.

Again: If you do not use the tarball release do not expect that pacthes will

be included. You should never do autoreconf.

We do use the tarball release, and we must patch it to resolve issues you do not
handle as I presented in previous comment.

Jan 29 2014, 10:19 AM · libgcrypt, Gentoo, Won't Fix, Bug Report
werner added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

That was added because we have it in master.

Again: If you do not use the tarball release do not expect that pacthes will be
included. You should never do autoreconf.

Jan 29 2014, 8:26 AM · libgcrypt, Gentoo, Won't Fix, Bug Report
werner closed T1607: libgcrypt parallel tests automake>=1.13 issue as Resolved.
Jan 29 2014, 8:26 AM · libgcrypt, Gentoo, Won't Fix, Bug Report

Jan 28 2014

alonbl reopened T1607: libgcrypt parallel tests automake>=1.13 issue as "Open".
Jan 28 2014, 11:15 PM · libgcrypt, Gentoo, Won't Fix, Bug Report
alonbl added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

We patch your sources mainly because[1], I will be happy to stop autoreconf your
packages, but cannot do this until this and other issues are resolved.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

OK, someone already tried to solve it at your side:

tests/Makefile.am

  1. Force sequential run of some tests. bench-slope.log: benchmark.log hashtest-256g.log: bench-slope.log

However, from automake manual:

In order to guarantee an ordering between tests even with make -jN, dependencies
between the corresponding .log files may be specified through usual make
dependencies. For example, the following snippet lets the test named
foo-execute.test depend upon completion of the test foo-compile.test:

TESTS = foo-compile.test foo-execute.test
foo-execute.log: foo-compile.log

Please note that this ordering ignores the results of required tests, thus the
test foo-execute.test is run even if the test foo-compile.test failed or was
skipped beforehand. Further, please note that specifying such dependencies
currently works only for tests that end in one of the suffixes listed in
TEST_EXTENSIONS.

Removing the above makes all works in parallel without specific order, which is
nice... unsure why the above was added when there is no real dependency, and
prior to automake-1.13 there was no parallel anyway.

Jan 28 2014, 11:15 PM · libgcrypt, Gentoo, Won't Fix, Bug Report
werner added a comment to T1607: libgcrypt parallel tests automake>=1.13 issue.

Because that automake version is not supported. automake is a maintainer tool
and not a build dependency. If Gentoo has its own policy they are on their own

  • it is free software. The tarball release does not have this problem. Or am I

wrong? GIT is developer only and definitely not a release.

Jan 28 2014, 3:28 PM · libgcrypt, Gentoo, Won't Fix, Bug Report
werner closed T1607: libgcrypt parallel tests automake>=1.13 issue as Resolved.
Jan 28 2014, 3:28 PM · libgcrypt, Gentoo, Won't Fix, Bug Report