[GPGME] python t-quick-key-manipulation.py fails

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
Hi,

All tests are passing except this one:
---
Traceback (most recent call last):
  File "./t-quick-key-manipulation.py", line 112, in <module>
    assert len(keys) == 1
AssertionError
---

Happens for both python2.7 and python3.4.

Any clue?
len(keys) == 0

Thanks!
Alon

---

$ gpg --version
gpg (GnuPG) 2.1.18
libgcrypt 1.7.6
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://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.

Home: /home/alonbl/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Justus Winter
Alon Bar-Lev <[hidden email]> writes:

> Hi,
>
> All tests are passing except this one:
> ---
> Traceback (most recent call last):
>   File "./t-quick-key-manipulation.py", line 112, in <module>
>     assert len(keys) == 1
> AssertionError
> ---
>
> Happens for both python2.7 and python3.4.
>
> Any clue?
> len(keys) == 0
Does your GnuPG support the TOFU trust model?  A way to check this is:

gpg --trust-model=tofu --list-config

This part of the test should probably be skipped if TOFU is not
supported, but I don't know how to check that from GPGME.  I'll have a
look at the qt test for TOFU for inspiration.

Justus

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
On 11 April 2017 at 11:21, Justus Winter <[hidden email]> wrote:

> Alon Bar-Lev <[hidden email]> writes:
>
>> Hi,
>>
>> All tests are passing except this one:
>> ---
>> Traceback (most recent call last):
>>   File "./t-quick-key-manipulation.py", line 112, in <module>
>>     assert len(keys) == 1
>> AssertionError
>> ---
>>
>> Happens for both python2.7 and python3.4.
>>
>> Any clue?
>> len(keys) == 0
>
> Does your GnuPG support the TOFU trust model?  A way to check this is:
>
> gpg --trust-model=tofu --list-config
>
> This part of the test should probably be skipped if TOFU is not
> supported, but I don't know how to check that from GPGME.  I'll have a
> look at the qt test for TOFU for inspiration.

Here:

$ gpg --trust-model=tofu --list-config
gpg: unknown trust model 'tofu'

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Andre Heinecke
In reply to this post by Justus Winter
Hi,

On Tuesday 11 April 2017 10:21:54 Justus Winter wrote:
> This part of the test should probably be skipped if TOFU is not
> supported, but I don't know how to check that from GPGME.  I'll have a
> look at the qt test for TOFU for inspiration.

I don't know a proper way either. The Qt test just bails out if even a simple
keylisting fails in the environment that has trust-model tofu+pgp. But I don't
consider this a big problem for Applications / users of GPGME because it's
basically the users fault if he has a GnuPG without tofu support (probably
self compiled) and then activates this trust model.

I even considered keeping the test failing in that case to show "Ok you have a
setup where some things just don't work." but as GPGME should support all
GnuPG versions I disabled it to avoid problems in such a case.



Regards,
Andre

--
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
On 11 April 2017 at 12:24, Andre Heinecke <[hidden email]> wrote:

>
> Hi,
>
> On Tuesday 11 April 2017 10:21:54 Justus Winter wrote:
> > This part of the test should probably be skipped if TOFU is not
> > supported, but I don't know how to check that from GPGME.  I'll have a
> > look at the qt test for TOFU for inspiration.
>
> I don't know a proper way either. The Qt test just bails out if even a simple
> keylisting fails in the environment that has trust-model tofu+pgp. But I don't
> consider this a big problem for Applications / users of GPGME because it's
> basically the users fault if he has a GnuPG without tofu support (probably
> self compiled) and then activates this trust model.
>
> I even considered keeping the test failing in that case to show "Ok you have a
> setup where some things just don't work." but as GPGME should support all
> GnuPG versions I disabled it to avoid problems in such a case.

How can it be user fault if gnupg formally supports --disable-tofu?
Tests should succeeded or skipped based on enabled features of gnupg.
In Gentoo we are trying to support package configuration to allow
choice of what features to enable, gnupg is included.
Please skip tests and not fail if a valid supported feature is disabled.

Thanks,
Alon

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Andre Heinecke
Hi,

On Tuesday 11 April 2017 12:29:51 Alon Bar-Lev wrote:
> How can it be user fault if gnupg formally supports --disable-tofu?
> Tests should succeeded or skipped based on enabled features of gnupg.
> In Gentoo we are trying to support package configuration to allow
> choice of what features to enable, gnupg is included.
> Please skip tests and not fail if a valid supported feature is disabled.

Well you can configure all kinds of stuff in GnuPG or worse, just install some
parts of it (like gpg but no gpg-agent) to create broken setups. So I'm kind
of wondering if GPGME's testsuite is not supposed to fail in cases where the
GnuPG system is missing features. If you decide to live with that breakage /
missing features then you just have to accept that the tests will fail. But
the information that the features are missing is conveyed at build time
instead of users facing Problems at runtime.

For this specific point, disabled tofu, I agree that it truly should be
optional but I'm starting to rethink / question if our approach to make the
tests work against any GnuPG version is the right one or if it would be better
for GPGME's test suite to fail and complain if something will not work with
this GnuPG version. It's more about the problems we had regarding 2.0.x
support for the test suite so maybe that should be a different thread.

E.g. Kleopatra has a selftest to check some basic GnuPG functionality on
startup and if that fails it tells the user what's wrong and why it can't work
with that and bails out. Instead of trying to handle every special
installation that might be conceivable.


Regards,
Andre


--
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
On 11 April 2017 at 13:21, Andre Heinecke <[hidden email]> wrote:

> Hi,
>
> On Tuesday 11 April 2017 12:29:51 Alon Bar-Lev wrote:
>> How can it be user fault if gnupg formally supports --disable-tofu?
>> Tests should succeeded or skipped based on enabled features of gnupg.
>> In Gentoo we are trying to support package configuration to allow
>> choice of what features to enable, gnupg is included.
>> Please skip tests and not fail if a valid supported feature is disabled.
>
> Well you can configure all kinds of stuff in GnuPG or worse, just install some
> parts of it (like gpg but no gpg-agent) to create broken setups. So I'm kind
> of wondering if GPGME's testsuite is not supposed to fail in cases where the
> GnuPG system is missing features. If you decide to live with that breakage /
> missing features then you just have to accept that the tests will fail. But
> the information that the features are missing is conveyed at build time
> instead of users facing Problems at runtime.
>
> For this specific point, disabled tofu, I agree that it truly should be
> optional but I'm starting to rethink / question if our approach to make the
> tests work against any GnuPG version is the right one or if it would be better
> for GPGME's test suite to fail and complain if something will not work with
> this GnuPG version. It's more about the problems we had regarding 2.0.x
> support for the test suite so maybe that should be a different thread.
>
> E.g. Kleopatra has a selftest to check some basic GnuPG functionality on
> startup and if that fails it tells the user what's wrong and why it can't work
> with that and bails out. Instead of trying to handle every special
> installation that might be conceivable.

If gpgme must have specific feature set of gnupg then please
explicitly state what configuration is supported. However, I thought
that gpgme should be an API to whatever available in gnupg and it
should not fail unless critical for its operation.

Just to understand the resolution Gentoo has:

 + + bzip2      : Use the bzlib compression library
 - - doc        : Add extra documentation (API, Javadoc, etc). It is
recommended to
                  enable per package instead of globally
 + + gnutls     : Add support for net-libs/gnutls (TLS 1.0 and SSL 3.0 support)
 - - ldap       : Add LDAP support (Lightweight Directory Access Protocol)
 + + nls        : Add Native Language Support (using gettext - GNU
locale utilities)
 + + readline   : Enable support for libreadline, a GNU line-editing
library that
                  almost everyone wants
 + + smartcard  : Build scdaemon software. Enables usage of OpenPGP
cards. For other
                  type of smartcards, try app-crypt/gnupg-pkcs11-scd. Bring in
                  dev-libs/libusb as a dependency; enable scdaemon.
 - - tofu       : Enable support for Trust of First use trust model; requires
                  dev-db/sqlite.
 - - tools      : Install extra tools (including gpgsplit and gpg-zip).
 - - usb        : Build direct CCID access for scdaemon; requires
dev-libs/libusb.
 - - wks-server : Install the wks-server

Thanks,
Alon

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Justus Winter
In reply to this post by Andre Heinecke
Andre Heinecke <[hidden email]> writes:

> Hi,
>
> On Tuesday 11 April 2017 12:29:51 Alon Bar-Lev wrote:
>> How can it be user fault if gnupg formally supports --disable-tofu?
>> Tests should succeeded or skipped based on enabled features of gnupg.
>> In Gentoo we are trying to support package configuration to allow
>> choice of what features to enable, gnupg is included.
>> Please skip tests and not fail if a valid supported feature is disabled.
>
> Well you can configure all kinds of stuff in GnuPG or worse, just install some
> parts of it (like gpg but no gpg-agent) to create broken setups. So I'm kind
> of wondering if GPGME's testsuite is not supposed to fail in cases where the
> GnuPG system is missing features. If you decide to live with that breakage /
> missing features then you just have to accept that the tests will fail. But
> the information that the features are missing is conveyed at build time
> instead of users facing Problems at runtime.
>
> For this specific point, disabled tofu, I agree that it truly should
> be
Agreed.  Done.

> optional but I'm starting to rethink / question if our approach to make the
> tests work against any GnuPG version is the right one or if it would be better
> for GPGME's test suite to fail and complain if something will not work with
> this GnuPG version. It's more about the problems we had regarding 2.0.x
> support for the test suite so maybe that should be a different thread.
>
> E.g. Kleopatra has a selftest to check some basic GnuPG functionality on
> startup and if that fails it tells the user what's wrong and why it can't work
> with that and bails out. Instead of trying to handle every special
> installation that might be conceivable.
I'd go even further.  I believe GnuPG has way too many knobs, both in
the programs as well as in the build system.  I strongly believe that
any configuration that we do not test as part of our continous
integration setup is simply broken.


Justus

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
Thank you!

Can we please release 1.9.1 so that I can publish it downstream?

Recent work was very important:
1. python: build: Reinstate prepare target.
2. python: build: Do not write into srcdir but into builddir.
3. python: build: Use pre-processor to load gpg-error.h.
4. python: build: Skip sync between PYTHONS and PYTHON_VERSIONS
5. python: tests: Skip TOFU if not enabled.
6. python: tests: Support python-libdir parameter to make it usable
for downstream.
7. qt: tests: Skip TOFU if not enabled.

Thanks,
Alon

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Justus Winter
Alon Bar-Lev <[hidden email]> writes:

> Can we please release 1.9.1 so that I can publish it downstream?

Unfortunately not until Werner returns from his vacation.  I'd say it
will have to wait to the 24th.  You'll have to use patches for now.

Justus

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
On 11 April 2017 at 14:48, Justus Winter <[hidden email]> wrote:
>
> Alon Bar-Lev <[hidden email]> writes:
>
> > Can we please release 1.9.1 so that I can publish it downstream?
>
> Unfortunately not until Werner returns from his vacation.  I'd say it
> will have to wait to the 24th.  You'll have to use patches for now.

Thanks!
I will wait, too many patches to publish.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
On 11 April 2017 at 14:49, Alon Bar-Lev <[hidden email]> wrote:

> On 11 April 2017 at 14:48, Justus Winter <[hidden email]> wrote:
>>
>> Alon Bar-Lev <[hidden email]> writes:
>>
>> > Can we please release 1.9.1 so that I can publish it downstream?
>>
>> Unfortunately not until Werner returns from his vacation.  I'd say it
>> will have to wait to the 24th.  You'll have to use patches for now.
>
> Thanks!
> I will wait, too many patches to publish.

Hi,
A kind reminder.
Thanks!

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Alon Bar-Lev-3
Hi,
Any chance of gpgme-1.9.1 release?
Thanks!

On 27 April 2017 at 12:16, Alon Bar-Lev <[hidden email]> wrote:

> On 11 April 2017 at 14:49, Alon Bar-Lev <[hidden email]> wrote:
>> On 11 April 2017 at 14:48, Justus Winter <[hidden email]> wrote:
>>>
>>> Alon Bar-Lev <[hidden email]> writes:
>>>
>>> > Can we please release 1.9.1 so that I can publish it downstream?
>>>
>>> Unfortunately not until Werner returns from his vacation.  I'd say it
>>> will have to wait to the 24th.  You'll have to use patches for now.
>>
>> Thanks!
>> I will wait, too many patches to publish.
>
> Hi,
> A kind reminder.
> Thanks!

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GPGME] python t-quick-key-manipulation.py fails

Justus Winter
Hi :)

Alon Bar-Lev <[hidden email]> writes:
> Any chance of gpgme-1.9.1 release?

Thanks for the remainder.  I'll create a task so it won't be lost.

Justus

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (497 bytes) Download Attachment