Well, I still get a "Missing object" error in libaacs, and I'm not sure how to
fix it. But the patch is in, so I think the bug can be closed.

It seems the problem is around the code here:
http://git.videolan.org/?p=libaacs.git;a=blob;f=src/libaacs/crypto.c;h=4db7641ec8e9af3cdf056562de39a39e3fa0c09b;hb=HEAD#l308

And the error I get when I try to scan a disc with aacs_info is as follows:
crypto.c:587: _aacs_verify: gcry_pk_verify failed. error was: Missing item in object
aacs.c:1502: invalid signature in cached hrl

If you have any hints, I'd be very grateful. Thanks!

Can we close this bug? (1.71 has been released)

libgcryp-1.7.0 t-lock and random test cases consistently crash on
SPARCv7 platform. On other platforms like x86/amd64/SPARCv9 the tests
succeed.

• 8< ---

PASS: t-mpi-point
PASS: curves
/bin/bash: line 5: 6557 Bus Error (core dumped)
GCRYPT_IN_REGRESSION_TEST=1 ${dir}$tst
FAIL: t-lock
PASS: prime

[...]

PASS: fips186-dsa
PASS: aeswrap
PASS: pkcs1v2
random: running './random --in-recursion --early-rng-check' failed
FAIL: random
PASS: dsa-rfc6979

256 of 1026 tests done
512 of 1026 tests done

• 8< ---

This will be useful for GnuPG itself. For example, currently in
gnupg/agent/command-ssh.c, we have a function ssh_receive_key which compose a
private key from 'ssh-add'. With this API, it will be cleaned up.

Shoul all be done for 1.7.0.

Given that a released version of libgpg-error does now exist, the problem should
be solved even for further versions taken from the repo.

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.

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

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.

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

Fwiw we're tracking this downstream as "dev-libs/libgcrypt-1.7.0: impossible
constraints on 'asm' operand" - https://bugs.gentoo.org/show_bug.cgi?id=580270

Here is the gist of the info:

i686-pc-linux-gnu
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. \

-I../src -I../src -I/usr/local/include -g -O2 \
-fvisibility=hidden -Wall -MT rijndael-aesni.lo \
-MD -MP -MF .deps/rijndael-aesni.Tpo -c rijndael-aesni.c \
-fPIC -DPIC -o .libsrijndael-aesni.o

rijndael-aesni.c: In function '_gcry_aes_aesni_ctr_enc':
rijndael-aesni.c:817:3: error: can't find a register in class \

'GENERAL_REGS' while reloading 'asm'

rijndael-aesni.c:1117:3: error: 'asm' operand has impossible constraints
rijndael-aesni.c:817:3: error: 'asm' operand has impossible constraints

I've attached the config.log file.

There's an issue somewhere: I built & installed libgpg-error 1.22 beta exactly
the same way as I did with 1.21. I'm not surprised by your answer: you guys have
already dismissed another perfectly valid issue report.

Something went wrong wile you installed libgpg-error. The linker picks up
another version of the library. If you need help, please ask on gnupg-devel.
Glad, that it now works for you.

pushed to the 1.7 branch.

Thanks for the info and the patch.
I have pushed commit 4545372 to master and it will eventually go into 1.7.1.

Hi Werner,

FreeBSD 9.x uses gcc version 4.2.1 20070831 patched [FreeBSD]

Thanks for the patch.
Which compiler version are you using?

Please provide more information. A kernel version is not sufficient. What
distro are you using, which compiler, etc. Sending the file config.log or a
transscript of the configure run would be helpful.

D365: 816_patch-cipher_crc-intel-pclmul.c

The following patch solves the problem.

System is Linux 3.2.0-23-generic.

If I understand correctly, we cannot compile latest libgcrypt because:

• the installed libgpg-error is a beta release
• it has been installed in /usr instead of /usr/local

That's unusual.
So I rebuilt libgcrypt with libgpg-error stable 1.21 installed in /usr, and it
passed.

It is true that I have built & installed libgpg-error from git master into
/usr:
./configure --enable-shared=yes \

			--enable-maintainer-mode \
			--prefix=/usr --sysconfdir=/etc --localstatedir=/var

But what do you mean by "properly install the library"?

Your system is misconfigured. You are using the gpg-error.h header
file from an unreleased version of libgpg-error but you are linking to
an older library.

  checking for gpg-error-config... /usr/bin/gpg-error-config
  checking for GPG Error - version >= 1.13... yes (1.22-beta14)

It seems you installed a libgpg-error version from git master
(.1.22-beta14) into the system directories instead of using
/usr/local. And you forgot to properly install the library.

Configured with:
./configure --enable-shared=yes \

			--enable-maintainer-mode \
			--prefix=/usr --sysconfdir=/etc --localstatedir=/var

In sexp.c we use suitable_encoding to decide on how to print the value: Either
as token, as an escaped string or as a hex-string. This is only done when using
FMT_ADVANCED. We could come up with some heuristics on how to print in base64
instead of hex (i.e. |YWJj| instead of #616263#) but that has the drawback that
the output would not be readable by older versions of libgcrypt.

Hwoever, what can be done is to make do_vsexp_sscan work with base64 encoding -
as of now such a value is simply ignored.

Can you please enter the command "where" in dbx after the fault?

No updates in 8 months, thus closing.

Thus clang is wrong here because it prints an "error" and not something like a
"performance hint". I close this bug.

Current code is perfectly fine as crc-intel-pclmul.c is i386/amd64-only source
file and that target architecture can handle unaligned loads.

The code in question is only for i386 and given that no SSE instructions are
used I wonder why you consider this a bug. The code might be faster if we would
access the short properly aligned but the question is whether this is worth an
extra copy operation.

jussi: What do you say?

Not easy yet, need more time to dig.

ping - will check tonight.

Meanwhile I also commited the Fedora patch.

aixtools: Had you a chance to test it?

Great! Thank you, Werner.

We now require a 64 bit integer type for >= 1.7 (commit 897ccd2)