Ah nevermind. I think myself that this is nobug and current behavior is correct.
There is a mechanism for the redundant setup that we want to have already and we
need to use it instead of doing something undefined.

D364: 829_0001-Dirmngr-Treat-multiple-crlDPs-as-redundancies.patch

Ah, the world of S/MIME related RFCs,.. Fun.

From RFC 5280 4.2.1.13. CRL Distribution Points:
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.

So the short Answer is. Intevation's certificate is bad. If we want to mark that
our Certificate Revocation lists are Redundant then we should have used a list
in the crlDP and not multiple crlDPs. This GnuPG would handle correctly.

Before I noticed beforementioned bit I've tried to fix it in GnuPG. And I think
it might be an improval as the same section also says:

If the DistributionPoint omits the reasons field, the CRL MUST
include revocation information for all reasons. This profile
RECOMMENDS against segmenting CRLs by reason code. When a conforming
CA includes a cRLDistributionPoints extension in a certificate, it
MUST include at least one DistributionPoint that points to a CRL that
covers the certificate for all reasons.

So If we have one such list we don't have to fetch all crlDP's and error out if
one can't be obtained.

I've attached a patch for that but I can fully understand If you don't think
this should be applied as the current behavior is mature and conforms to the RFC
already. In that case you can resolve this as "nobug".

Cofactor is defined by the curve. I guess that the cofactor of the curve in
libaacs is 1. Although my patch includes the code which gets cofactor from key
parameters, the ECDSA computation itself doesn't use cofactor actually.

Well, I haven't expected there is a user who uses (flags param), because it was
mostly for our development. There must be more bugs around that...

I encountered this bug when I tried to use libgcrypt-HEAD with libaacs.
libaacs uses ECDSA, and when it calls gcry_pk_verify(), I get GPG_ERR_NO_OBJ
because the sexp was constructed without the h parameter.

Good catch.
Fixed in c7430aa752232aa690c5d8f16575a345442ad8d7.

Thanks for the clarification. I'll ignore it in QGpgME then, too.

And after grepping for KEYEXPIRED in doc I have now found the DETAILS
documentation of which I was unaware until now. :-)

This is documented behaviour; see below. GPA ignores this status line.

• KEYEXPIRED <expire-timestamp> The key has expired. expire-timestamp is the expiration time in seconds since Epoch. This status line is not very useful because it will also be emitted for expired subkeys even if this subkey is not used. To check whether a key used to sign a message has expired, the EXPKEYSIG status line is to be used. Note, that the TIMESTAMP may either be a number of seconds since Epoch or an ISO 8601 string which can be detected by the presence of the letter 'T'.

Not a bug. "iff" is used math as an abbreviation for "if and only if ..."

Thanks. Fixed in working directory; will show up soon.

In case you want to submit more typo fixes, please collect some of them and put
them into one report.

1.3.4 has been released.

1.3.4 has been released

I just released 1.3.4 and thus closing this bug and 2342 and 2343. Thanks again
for you help.

In data martedì 3 maggio 2016 15:13:04 CEST, hai scritto:

Werner Koch <wk@gnupg.org> added the comment:

From my dash man page:

echo [-n] args...
          Print the arguments on the standard output, separated by spaces.

Unless the -n option is present, a new

line is output following the arguments.

The version is 0.5.7 and the debian docs say.

Do whatever you prefer. I'm sorry that I bothered you with what is, after all, a
local problem. I'll try to push a workaround for this in Gentoo.

Thanks for your patience.

I tend to add a test for printf but given that we will soon replace the entire
test suite I doubt that this will be the best use of my time.

Right after I wrote my last reply I noticed that Gentoo patches dash to
"neuter" its echo builtin so that it recognizes neither options nor escape
sequences. So this is Gentoo (and derivatives) specific.

See (if you care) the discussions that led to this behaviour:
http://bugs.gentoo.org/337329
http://bugs.gentoo.org/527848

From my dash man page:

  echo [-n] args...
            Print the arguments on the standard output, separated by spaces.
            Unless the -n option is present, a new
            line is output following the arguments.

The version is 0.5.7 and the debian docs say.

This package was debianized by Mark W. Eichin eichin@kitten.gen.ma.us on
Mon, 24 Feb 1997 16:00:16 -0500.

This package was re-ported from NetBSD and debianized by
Herbert Xu herbert@debian.org on Thu, 19 Jun 1997 19:29:16 +1000.

This package was adopted by Gerrit Pape <pape@smarden.org> on
Fri, 28 May 2004 18:38:18 +0000.

It was downloaded from http://gondor.apana.org.au/~herbert/dash/files/

The problem with printf is that it is not availabale on older Unices.

AFAIK dash does not support "echo -n". From "man dash":
echo args...

            Print the arguments on the standard output, separated by spaces.

            No arguments or backslash sequences are supported as they are not

portable. They will be printed out exactly as

            passed in.

            You can replace `echo -n ...` with the portable `printf %s ...`

construct.

I use dash myself and I have no problems. dash supports echo -n and
he test is supposed to detect this. However, in your case neither \c
nor -n is supported and thus the LF is appended. I don't known for
sure why this is done; the ChangeLog entry for this is

  Wed Aug  4 10:34:18 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>

• defs.inc (echo_n): New and used instead of /bin/echo "\c"

Probably we never hit that case. The test for echo as used by
configure is too complex to use here. Anyway, something is wrong with
your dash version: It does not neither grok -n nor \c.

Fixed with commit 3f74c2c. Thanks.

The use in cert-basic is correct because get_oid_desc accepst a NULL pointer.
However, some libc versions bail out on a NULL for "%s"; I fixed that too.

Fixed with commit 6be61da.

The old fix for the problem from April 2015 had an off-by-one in the
bad encoding handling. Now using simpler code.

Fixed with commit a7eed17 . Thanks.

I also checked all other places to ensure that the tag length returned from
_ksba_ber_parse_tl is within the bounds.

I've made the following script to isolate the issue:
#!/bin/sh
echo_n_init=no
echo_n () {

if test "$echo_n_init" = "no"; then
  if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
    if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn >/dev/null; then
      echo_n_n=
      echo_n_c='

'

    else
      echo_n_n='-n'
      echo_n_c=
    fi
  else
    echo_n_n=
    echo_n_c='\c'
  fi
  echo_n_init=yes
fi
echo $echo_n_n "${1}$echo_n_c"

}

echo_n "abcdefghijklmnopqrstuvwxyz" | gpg2 --with-colons --print-mds

If I run it with "bash -x" I get:
+ echo_n_init=no
+ echo_n abcdefghijklmnopqrstuvwxyz
+ test no = no
+ echo 'testing\c'
+ echo 1,2,3
+ gpg2 --with-colons --print-mds
+ grep c
+ echo -n testing
+ sed s/-n/xn/
+ echo 1,2,3
+ grep xn
+ echo_n_n=-n
+ echo_n_c=
+ echo_n_init=yes
+ echo -n abcdefghijklmnopqrstuvwxyz
:1:C3FCD3D76192E4007DFB496CCA67E13B:
:2:32D10C7B8CF96570CA04CE37F2A19D84240D3A89:
:3:F71C27109C692C1B56BBDCEB5B9D2865B3708DBC:
:11:45A5F72C39C5CFF2522EB3429799E49E5F44B356EF926BCF390DCCC2:
:8:71C480DF93D6AE2F1EFAD1447C66C9525E316218CF51FC8D9ED832F2DAF18B73:
:9:FEB67349DF3DB6F5924815D6C3DC133F091809213731FE5C7B5F4999E463479FF2877F5F2936FA63BB43784B12F3EBB4:
:10:4DBFF86CC2CA1BAE1E16468A05CB9881C97F1753BCE3619034898FAA1AABE429955A1BF8EC483D7421FE3C1646613A59ED5441F
B0F321389F77F48A879C7B1F1:

which is correct. If I run it with "dash -x" I get:
+ echo_n_init=no
+ echo_n abcdefghijklmnopqrstuvwxyz
+ test no =+ no
gpg2 --with-colons --print-mds
+ grep c
+ echo testing\c
+ echo 1,2,3
+ echo -n testing
+ echo 1,2,3
+ sed s/-n/xn/
+ grep xn
+ echo_n_n=
+ echo_n_c=

+ echo_n_init=yes
+ echo abcdefghijklmnopqrstuvwxyz

:1:AD5DEB9B35AB55595BC8312CF1EE134F:
:2:7FDFFACEC05073FD23135CF94868A0076ABF3953:
:3:13F4E18DD89D9611E224C7A73E25C6A42BFF090F:
:11:DBB9A410F16C536637D928B37682A522E3A473864EF6915715DE81B3:
:8:DC6BEFD7DC150815AC9DA4477A059849BC60CE64B052F7D73F33239ADB80F292:
:9:5EAB880F1B7A7E5E888A745B650D705DF7DD1960728BE123088C897B5BCFD37042BE1EFD172CFC0B09E1705EB190A8F4:
:10:6B779E094FB3286174E9E7D08C3D65D6755AC29ACDBEDE2B48E35EA1E9F040E089F62ED8C1378AF2D999F4562334BB071D7493A
FEA19E62C00678F59AA624126:

which is, obviously, not correct.

Please explain the version number you entered and from where you downloaded GPA

Sorry, I might be wrong about in previous comment. I am not sure if pshareds=1
opens up some vulnerability hole.

pshared=1 will not work on AIX for FORKED processes. It works only for threads.

Thank you.
I think that it's better to use sem_init with pshared=1.
I'm sending my proposal patch to gnupg-devel.

Another problem has been fixed in 6677d8b.
I intentionally set up more hubs from computer to the device to cause an error.
When an error occurred, scdaemon continued to report "Card error", even after I
inserted the device directly to the computer.
Now, it returns "No such device" for severe errors, and scdaemon can recover
from such errors.

The file oid_oob_big.crt would cause the function ksba_oid_to_str() to be called with a “length” argument of

3100166514561975041. This is what execution in tis-interpreter (in which allocations always succeed) shows:

…
48

83

A5

this is not going to end well: length=3100166514561975041

src/oid.c:105:[kernel] warning: out of bounds read. assert \valid_read(buf_0+n);

                  stack: _ksba_oid_to_str :: src/cert.c:1462 <-
                         _ksba_cert_get_ext_key_usages :: src/visibility.c:259 <-
                         ksba_cert_get_ext_key_usages :: tests/cert-basic.c:265 <-
                         list_extensions :: tests/cert-basic.c:545 <-
                         one_file :: tests/cert-basic.c:592 <-
                         main

“Fortunately”, for the file oid_oob_big.crt, execution of the program tests/cert-basic differs in that a memory
allocation fails:

$ ./tests/cert-basic ../../libksba-1.3.3/oid_oob_big.crt
Certificate in `../../libksba-1.3.3/oid_oob_big.crt':

serial....: (#04#)
issuer....: `1.2.840.113549.1.9.1=#696E73656375726540746573742E696E736563757265,CN=For Tests

Only,O=InsecureTestCertificate,C=de'

       aka: `<insecure@test.insecure>'
subject...: `1.2.840.113549.1.9.1=#696E73656375726540746573742E696E736563757265,CN=Insecure Server

Cert,O=InsecureTestCertificate,C=de'

       aka: `<insecure@test.insecure>'
notBefore.: 2001-08-17 08:46:24
notAfter..: 2006-08-16 08:46:24
hash algo.: 1.2.840.113549.1.1.4

Extn: 2.5.29.15 at 474 with length 4
Extn: 2.5.29.37 at 487 with length 12
Extn: 2.5.29.14 at 508 with length 22
Extn: 2.5.29.35 at 541 with length 145
Extn: 2.5.29.17 at 695 with length 26
Extn: 2.5.29.18 at 730 with length 26
Extn: 2.16.840.1.113730.1.1 at 771 with length 4
Extn: 2.16.840.1.113730.1.13 at 790 with length 47
SubjectKeyIdentifier: (#0234E2C906F6E0B44253BE04C0CBA7823A6DB509#)
AuthorityKeyIdentifier: 1.2.840.113549.1.9.1=#696E73656375726540746573742E696E736563757265,CN=For Tests
Only,O=InsecureTestCertificate,C=de

       serial: (#00#)
keyIdentifier: (#BF53438278D09EC380E51B67CA0500DFB94883A5#)

KeyUsage: digitalSignature keyEncipherment keyAgreement
cert-basic.c:271: ksba_cert_ext_key_usages failed: Cannot allocate memory
CertificatePolicies: none

Regardless, between themselves, the two files oid_oob_big.crt and oid_oob_small.crt shows that an attacker seems to have
many possibilities for crafting a malicious certificate that crashes in ksba_oid_to_str() called from
ksba_cert_get_ext_key_usages().

D366: 825_fix-in-gpgmepp.patch

Note to self.

The problem is that editinteractor in edit_interactor_callback_impl checks
status_to_error before the GpgSignKeyEditInteractor::nextState implementation
has the chance to ignore that status with needsNoResponse.

A fix in GpgMEpp could be to ignore the error if the state machine was not
started. E.g. we have not yet send any command.

Attached patch fixes the problem. But I'm not sure that this does not cause
regressions e.g. when trying to add a uid to an expired key or trying to
actually sign expired uid's. :-/

The particular problem of T2306 (aheinecke on Apr 25 2016, 06:53 PM / Roundup) has been fixed in cb4fee8.

I think that it was not always reproducible because it depends on timing (only
when it detected an error at bulk_in, the problem happened). I'm not sure if
the difference of old/new libusb mattered for this problem.

Those libraries are not GnuPG specific.

Thank You. I noticed later that, indeed, at the first instance,
there's a problem with the library, but I corrected that issue
with the other try, the one that is described at

https://bugs.gnupg.org/gnupg/file821/2016_04_gnupg_v_2_1_11_build_log.txt

---citation--start----
gcc -DHAVE_CONFIG_H -I. -I.. -I../common -
DLOCALEDIR=\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/gnup
g/share/locale\" -
DGNUPG_BINDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/
gnupg/bin\"" -
DGNUPG_LIBEXECDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016
_04/gnupg/lib\"" -
DGNUPG_LIBDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/
gnupg/lib64/gnupg\"" -
DGNUPG_DATADIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04
/gnupg/share/gnupg\"" -
DGNUPG_SYSCONFDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016
_04/gnupg/etc/gnupg\"" -
DGNUPG_LOCALSTATEDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2
016_04/gnupg/var\"" -
I/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/libgcrypt/includ
e -
I/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/libksba/include
-Wall -Wno-pointer-sign -Wpointer-arith -mtune=native -ftree-vectorize -MT
libkeybox_a-keybox-util.o -MD -MP -MF .deps/libkeybox_a-keybox-util.Tpo -c -o
libkeybox_a-keybox-util.o test -f 'keybox-util.c' || echo './'keybox-util.c
In file included from keybox-defs.h:42:0,

from keybox-util.c:29:

../common/stringhelp.h: In function ‘make_filename’:
../common/stringhelp.h:55:52: error: expected declaration specifiers before â
€˜GPGRT_ATTR_SENTINEL’
char *make_filename( const char *first_part, ... ) GPGRT_ATTR_SENTINEL(0);

^

---citation--end------

Besides, given the small size of the GnuPG, shouldn't the
few GnuPG specific libraries just be subfolders of the
GnuPG project? If not in the repository, then at least
at the release tar-ball? It would avoid the
"library wrongly installed" part.

A beta version is not a released version. For example SO numbers may be
different. BTW 1.22 has been released.

libksba has not been installed properly.

For help on building libgcrypt, please ask on gcrypt-devel ML.

Your report is too sparse to help you. When writing to the ML you should
specify the used OS, any special configuration you have, and a detailed
description of what you did.

libgpg-error 1.22 is out with fix. Please test.

libgpg-error 1.2.2 is out. Please test with it.

I can make "a" problem (not sure if it is "the" problem) reproducible with the
following command (as root):

AUTHFILE="/sys/bus/usb/devices/4-1.2/authorized" ; echo 0 > "$AUTHFILE" ; sleep
1 ; echo 1 > "$AUTHFILE"

This was based on:
http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line/61165#61165

where 4-1.2 is the id of my reader. The error message in scdaemon log is
slightly different but the behavior is the same. It's in an error state until I
kill it.

Just as a note, this bug is for the "MIME Aware" interface with event driven
sign / encrypt.

The downstream issue does not persist in gcc 4.9.3 but triggers for 4.8.5