From epaulson10 at gmail.com  Thu Nov  3 05:04:04 2022
From: epaulson10 at gmail.com (Erik Paulson)
Date: Wed,  2 Nov 2022 21:04:04 -0700
Subject: [PATCH GnuPG] Use more helpful error when missing newline at EOF
Message-ID: <20221103040403.93658-1-epaulson10@gmail.com>

Currently, if the sshcontrol file does not have a newline at the end,
the agent will return the error "Line too long". This is confusing since
to the eyes of the user, the line is the correct length. This patch
checks for this case and instead returns "Incomplete line", which is a
more accurate description of the user's error.

Signed-off-by: Erik Paulson <epaulson10 at gmail.com>
---
I discovered this while setting up SSH agent support on a new machine
where my editor is not yet configured to add missing EOF newlines. Grep
shows me that this line-reading pattern is in several other files. If
the maintainers agree with this patch, I would be happy to submit a V2
updating those files as well.

 agent/command-ssh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/agent/command-ssh.c b/agent/command-ssh.c
index f237f9355..f02bc8613 100644
--- a/agent/command-ssh.c
+++ b/agent/command-ssh.c
@@ -953,7 +953,7 @@ read_control_file_item (ssh_control_file_t cf)
           /* Eat until end of line */
           while ((c = es_getc (cf->fp)) != EOF && c != '\n')
             ;
-          return gpg_error (*line? GPG_ERR_LINE_TOO_LONG
+          return gpg_error ((*line && c != EOF)? GPG_ERR_LINE_TOO_LONG
                                  : GPG_ERR_INCOMPLETE_LINE);
         }
 
-- 
2.38.1



From gusnan at librem.one  Sun Nov  6 02:12:08 2022
From: gusnan at librem.one (Andreas Ronnquist)
Date: Sun, 6 Nov 2022 02:12:08 +0100
Subject: [GPA] Port to GTK3 (Work in progress)
In-Reply-To: <20221030215559.355e188e@debian-i7>
References: <20221025120311.63f13ce7@debian-i7>
 <202210251723.09722.bernhard@intevation.de>
 <20221030215559.355e188e@debian-i7>
Message-ID: <20221106021124.7459dd87@debian-i7>

On Sun, 30 Oct 2022 21:56:34 +0100
Andreas Ronnquist via Gnupg-devel <gnupg-devel at gnupg.org> wrote:

>On Tue, 25 Oct 2022 17:23:09 +0200
>Bernhard Reiter <bernhard at intevation.de> wrote:
>
>>Am Dienstag 25 Oktober 2022 12:03:11 schrieb Andreas R?nnquist via 
>>Gnupg-devel:  
>>> I have managed to build GPA against GTK3 - is there any interest at all,
>>> or is GPA completely dead?    
>>
>>Thanks for making your work public!
>>
>>I believe Werner also had part of an GTK3 port in the work (but not entirely 
>>ready). Focus has shifted away a bit from GPA, it is a component
>>that is in need of a maintainer. 
>>
>>The question is if there is enough interest and people are willing to
>>help to develop and maintain GPA. 
>>In how far could you help with this and e.g. the GTK3 port?
>>  
>
>I would love to be able to keep it maintained, but I don't want to do
>it on my own, more eyes equals better code, of course.
>
>I have managed now to not only build on GTK3, but I have also began to
>do actual required migration from GTK2 technologies to GTK3 ones -
>which would of course make it easier to an eventual upcoming GTK4
>conversion.
>
>It looks like the first thing is to make it GtkApplication-based (which
>I have managed to do), and then in it's turn migrate the menus to
>GtkBuilder-based items.
>
>I would love some eyes on my code in the git repository, and would
>gladly accept merge requests there, both to further the conversion, but
>also if someone has better solutions to the changes I have done, I
>would also accept those.
>

Alright, I have hacked away and continued the GTK3 conversion - It was
way more work than I anticipated, but an initial version is buildable
(Nowhere near release quality yet though). 

It is not finished, but it is good enough to get an impression of what
a GTK3 version would look like.

I have moved the images from the pixmaps folder to the src folder, and
include them in a gresource file. (This is the modern way to build
resources to C code, so you don't have to load it from disk by hand and
have the resources loaded from file on program start, they are included
in the compiled binary - it's the more modern way of what was done with
xpm images, and can include all resources, not just images).

All menus and toolbars needed to be converted to this new way, and
menus in GTK3 cannot contain images, so that is a change. Toolbars can,
and I have used toolbars, but the toolbar widget is being removed in
GTK4, and should be replaced with a GtkBox with the proper layout and
settings. I have stayed with the standard GtkToolbar for now.

I think I have changed the places needed, but I haven't fully connected
all signals yet, and there are surely places where I have done mistakes
or simply not come to yet, there is still more work to be done, but you can
build and test the program with your current GTK3 theme. (One theme I
have tested I didn't get separators in the toolbar, but that is
theme-specific, using the Elementary theme all looks really nice).

All can be found at https://github.com/gusnan/gpa , and
pull-requests and suggestions would be greatly appreciated.

best
/Andreas R?nnquist
gusnan at librem.one

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signatur
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221106/388c1ef4/attachment.sig>

From bernhard at intevation.de  Fri Nov 11 13:41:26 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 11 Nov 2022 13:41:26 +0100
Subject: [GPA] Port to GTK3 (Work in progress)
In-Reply-To: <20221106021124.7459dd87@debian-i7>
References: <20221025120311.63f13ce7@debian-i7>
 <20221030215559.355e188e@debian-i7> <20221106021124.7459dd87@debian-i7>
Message-ID: <202211111341.34393.bernhard@intevation.de>

Am Sonntag 06 November 2022 02:12:08 schrieb Andreas Ronnquist via 
> Alright, I have hacked away and continued the GTK3 conversion - It was
> way more work than I anticipated, but an initial version is buildable
> (Nowhere near release quality yet though).
>
> It is not finished, but it is good enough to get an impression of what
> a GTK3 version would look like.

For more exposure, you could ask on 
  https://lists.gnupg.org/mailman/listinfo/gnupg-users
for people being interested in helping with GPA's development.

> All can be found at https://github.com/gusnan/gpa , and
> pull-requests and suggestions would be greatly appreciated.

Thanks for the two progress reports.
(I had hoped that Werner may hae the time to publish his work-in-progress
so you could compare)

Best,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221111/93234bd7/attachment.sig>

From gusnan at librem.one  Sat Nov 12 20:51:40 2022
From: gusnan at librem.one (Andreas Ronnquist)
Date: Sat, 12 Nov 2022 20:51:40 +0100
Subject: [GPA] Port to GTK3 (Work in progress)
In-Reply-To: <202211111341.34393.bernhard@intevation.de>
References: <20221025120311.63f13ce7@debian-i7>
 <20221030215559.355e188e@debian-i7>
 <20221106021124.7459dd87@debian-i7>
 <202211111341.34393.bernhard@intevation.de>
Message-ID: <20221112205042.4fd50126@debian-i7>

On Fri, 11 Nov 2022 13:41:26 +0100
Bernhard Reiter <bernhard at intevation.de> wrote:

>Am Sonntag 06 November 2022 02:12:08 schrieb Andreas Ronnquist via 
>> Alright, I have hacked away and continued the GTK3 conversion - It was
>> way more work than I anticipated, but an initial version is buildable
>> (Nowhere near release quality yet though).
>>
>> It is not finished, but it is good enough to get an impression of what
>> a GTK3 version would look like.  
>
>For more exposure, you could ask on 
>  https://lists.gnupg.org/mailman/listinfo/gnupg-users
>for people being interested in helping with GPA's development.
>

Thanks, that indeed sound like a good idea. Will do!

/Andreas


From dave at sleepmap.de  Tue Nov 15 10:34:13 2022
From: dave at sleepmap.de (David Runge)
Date: Tue, 15 Nov 2022 10:34:13 +0100
Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and add
 PEP517 support
Message-ID: <Y3NdGQffulZXJGVj@hmbx>

Hi,

the attached patches improve the sdist tarball creation by relying on
builtin features of setuptools wherever possible and allowing the
creation (and signing) of prerelease sdist tarballs.

Additionally, a pyproject.toml file now describes the build-system
requirements, which are used by PEP517 build backends and allows common
Python project management software to build gpg as part of a virtualenv.


I noticed, that the last release of gpg [1] is from 2018 and only covers
version 1.10.0 (which can not be built against current libgpg-error).
As I am currently working on a project that will likely make use of gpg
via integration in dulwich [2], I would be very happy, if a release could be
made in the near future (including an sdist tarball on pypi.org).
Ideally, there would also be prebuilt wheels, but they would likely have
to bundle libraries, so that is not so easy to do.
Having an up-to-date and functional sdist tarball would already be a
*huge* improvement for the Python ecosystem!

Best,
David

[1] https://pypi.org/project/gpg/
[2] https://pypi.org/project/dulwich/

-- 
https://sleepmap.de
-------------- next part --------------
From 2d1fc6414e01959856313ce61d59a71774286b04 Mon Sep 17 00:00:00 2001
From: David Runge <dave at sleepmap.de>
Date: Mon, 14 Nov 2022 00:14:47 +0100
Subject: [PATCH 1/2] Simplify and standardize Python sdist creation

lang/python/Makefile.am:
- Substitute `-alpha`, `-beta` and `-rc` version string components with
  `a`, `b` and `rc` (respectively), as that is used when Python version
  strings are constructed (https://peps.python.org/pep-0440/).
- Rely on the standard `dist/` directory created by `python setup.py
  sdist` instead of using a custom one which requires more overhead for
  no benefit.
- Remove the use of the invalid `--manifest` option to `python setup.py
  sdist` (MANIFEST.in is used automatically).
- Instead of trying to find `gpg` via `gpgconf`, just use `gpg`
  directly, when creating a detached signature for the sdist tarball.
- Provide a `clean` target which can be used to remove the `dist/`
  directory via `make clean -C lang/python`.

Signed-off-by: David Runge <dave at sleepmap.de>
---
 lang/python/Makefile.am | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am
index 845b7b17..99279e74 100644
--- a/lang/python/Makefile.am
+++ b/lang/python/Makefile.am
@@ -23,6 +23,9 @@ EXTRA_DIST = \
 	gpgme.i \
 	helpers.c helpers.h private.h
 
+# Python translates -alpha to a and -beta to b in version strings
+PY_PKG_VER = $(subst -alpha,a,$(subst -beta,b,$(subst -rc,rc,$(VERSION))))
+
 SUBDIRS = . tests examples doc src
 
 .PHONY: prepare
@@ -45,23 +48,20 @@ all-local: copystamp
 	    $$PYTHON setup.py build --verbose --build-base="$$(basename "$${PYTHON}")-gpg" ; \
 	done
 
-python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc: copystamp
-	$(MKDIR_P) python$(PYTHON_VERSION)-gpg-dist
+dist/gpg-$(PY_PKG_VER).tar.gz.asc: copystamp
 	CPP="$(CPP)" \
 	CFLAGS="$(CFLAGS)" \
 	srcdir="$(srcdir)" \
 	top_builddir="$(top_builddir)" \
-	  $(PYTHON) setup.py sdist --verbose --dist-dir=python$(PYTHON_VERSION)-gpg-dist \
-		--manifest=python$(PYTHON_VERSION)-gpg-dist/MANIFEST
-	gpgbin=gpgconf --list-components | grep OpenPGP | sed -e 's/gpg:OpenPGP://g'
-	$(gpgbin) --detach-sign --armor python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz
+	  $(PYTHON) setup.py sdist --verbose
+	gpg --detach-sign --armor dist/gpg-$(PY_PKG_VER).tar.gz
 
 .PHONY: sdist
-sdist:	python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc
+sdist:	dist/gpg-$(PY_PKG_VER).tar.gz.asc
 
 .PHONY: upload
-upload: python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz \
-        python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz.asc
+upload: dist/gpg-$(PY_PKG_VER).tar.gz \
+        dist/gpg-$(PY_PKG_VER).tar.gz.asc
 	twine upload $^
 
 CLEANFILES = copystamp \
@@ -69,6 +69,9 @@ CLEANFILES = copystamp \
 	data.h \
 	gpg
 
+clean:
+	rm -rf -- dist
+
 # Remove the rest.
 #
 # 'make distclean' clears the write bit, breaking rm -rf.  Fix the
-- 
2.38.1

-------------- next part --------------
From b23db649e10575a74c78a6679251175da076cfc7 Mon Sep 17 00:00:00 2001
From: David Runge <dave at sleepmap.de>
Date: Mon, 14 Nov 2022 00:22:01 +0100
Subject: [PATCH 2/2] Add pyproject.toml to list required build-systems

lang/python/pyproject.toml:
Add pyproject.toml file to add the required build-systems (setuptools
and swig). Adding the file with the `[build-system]` table allows PEP517
(https://peps.python.org/pep-0517/) aware build backends to function
properly, by automatically resolving build backends
(https://peps.python.org/pep-0518/).
This change allows to pull in `gpg` via pypi.org using Python project
management software such as flit, poetry and pdm, which are enabled to
build gpg in a virtualenv of a given project.

Signed-off-by: David Runge <dave at sleepmap.de>
---
 lang/python/pyproject.toml | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 lang/python/pyproject.toml

diff --git a/lang/python/pyproject.toml b/lang/python/pyproject.toml
new file mode 100644
index 00000000..14d55000
--- /dev/null
+++ b/lang/python/pyproject.toml
@@ -0,0 +1,2 @@
+[build-system]
+requires = ["setuptools", "swig"]
-- 
2.38.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221115/5cc99348/attachment.sig>

From dave at sleepmap.de  Tue Nov 15 18:37:47 2022
From: dave at sleepmap.de (David Runge)
Date: Tue, 15 Nov 2022 18:37:47 +0100
Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and add
 PEP517 support
In-Reply-To: <Y3NdGQffulZXJGVj@hmbx>
References: <Y3NdGQffulZXJGVj@hmbx>
Message-ID: <Y3PObpnDWYg2cduM@hmbx>

Hi again,

I noticed a small mistake in the pyproject.toml file that I provided.

Please find attached a revised version, which also properly states the
build-backend for setuptools.

Best,
David

-- 
https://sleepmap.de
-------------- next part --------------
From 2d1fc6414e01959856313ce61d59a71774286b04 Mon Sep 17 00:00:00 2001
From: David Runge <dave at sleepmap.de>
Date: Mon, 14 Nov 2022 00:14:47 +0100
Subject: [PATCH 1/2] Simplify and standardize Python sdist creation

lang/python/Makefile.am:
- Substitute `-alpha`, `-beta` and `-rc` version string components with
  `a`, `b` and `rc` (respectively), as that is used when Python version
  strings are constructed (https://peps.python.org/pep-0440/).
- Rely on the standard `dist/` directory created by `python setup.py
  sdist` instead of using a custom one which requires more overhead for
  no benefit.
- Remove the use of the invalid `--manifest` option to `python setup.py
  sdist` (MANIFEST.in is used automatically).
- Instead of trying to find `gpg` via `gpgconf`, just use `gpg`
  directly, when creating a detached signature for the sdist tarball.
- Provide a `clean` target which can be used to remove the `dist/`
  directory via `make clean -C lang/python`.

Signed-off-by: David Runge <dave at sleepmap.de>
---
 lang/python/Makefile.am | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am
index 845b7b17..99279e74 100644
--- a/lang/python/Makefile.am
+++ b/lang/python/Makefile.am
@@ -23,6 +23,9 @@ EXTRA_DIST = \
 	gpgme.i \
 	helpers.c helpers.h private.h
 
+# Python translates -alpha to a and -beta to b in version strings
+PY_PKG_VER = $(subst -alpha,a,$(subst -beta,b,$(subst -rc,rc,$(VERSION))))
+
 SUBDIRS = . tests examples doc src
 
 .PHONY: prepare
@@ -45,23 +48,20 @@ all-local: copystamp
 	    $$PYTHON setup.py build --verbose --build-base="$$(basename "$${PYTHON}")-gpg" ; \
 	done
 
-python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc: copystamp
-	$(MKDIR_P) python$(PYTHON_VERSION)-gpg-dist
+dist/gpg-$(PY_PKG_VER).tar.gz.asc: copystamp
 	CPP="$(CPP)" \
 	CFLAGS="$(CFLAGS)" \
 	srcdir="$(srcdir)" \
 	top_builddir="$(top_builddir)" \
-	  $(PYTHON) setup.py sdist --verbose --dist-dir=python$(PYTHON_VERSION)-gpg-dist \
-		--manifest=python$(PYTHON_VERSION)-gpg-dist/MANIFEST
-	gpgbin=gpgconf --list-components | grep OpenPGP | sed -e 's/gpg:OpenPGP://g'
-	$(gpgbin) --detach-sign --armor python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz
+	  $(PYTHON) setup.py sdist --verbose
+	gpg --detach-sign --armor dist/gpg-$(PY_PKG_VER).tar.gz
 
 .PHONY: sdist
-sdist:	python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc
+sdist:	dist/gpg-$(PY_PKG_VER).tar.gz.asc
 
 .PHONY: upload
-upload: python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz \
-        python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz.asc
+upload: dist/gpg-$(PY_PKG_VER).tar.gz \
+        dist/gpg-$(PY_PKG_VER).tar.gz.asc
 	twine upload $^
 
 CLEANFILES = copystamp \
@@ -69,6 +69,9 @@ CLEANFILES = copystamp \
 	data.h \
 	gpg
 
+clean:
+	rm -rf -- dist
+
 # Remove the rest.
 #
 # 'make distclean' clears the write bit, breaking rm -rf.  Fix the
-- 
2.38.1

-------------- next part --------------
From eb4e4ea274fc50b4433f827959773d178518b139 Mon Sep 17 00:00:00 2001
From: David Runge <dave at sleepmap.de>
Date: Mon, 14 Nov 2022 00:22:01 +0100
Subject: [PATCH 2/2] Add pyproject.toml to list required build-systems

lang/python/pyproject.toml:
Add pyproject.toml file to add the required build-systems (setuptools
and swig). Adding the file with the `[build-system]` table allows PEP517
(https://peps.python.org/pep-0517/) aware build backends to function
properly, by automatically resolving build backends
(https://peps.python.org/pep-0518/).
See https://setuptools.pypa.io/en/latest/build_meta.html for further
reference as to how setuptools handles this.

This change allows to pull in `gpg` via pypi.org using Python project
management software such as flit, poetry and pdm, which are enabled to
build gpg in a virtualenv of a given project.

Signed-off-by: David Runge <dave at sleepmap.de>
---
 lang/python/pyproject.toml | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 lang/python/pyproject.toml

diff --git a/lang/python/pyproject.toml b/lang/python/pyproject.toml
new file mode 100644
index 00000000..34258d48
--- /dev/null
+++ b/lang/python/pyproject.toml
@@ -0,0 +1,7 @@
+[build-system]
+requires = [
+  "setuptools",
+  "swig",
+]
+
+build-backend = "setuptools.build_meta"
-- 
2.38.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221115/d3298c2f/attachment.sig>

From jscott at posteo.net  Mon Nov 21 13:02:10 2022
From: jscott at posteo.net (John Scott)
Date: Mon, 21 Nov 2022 12:02:10 +0000
Subject: Guarantees of gpg_strerror_r may not hold
Message-ID: <64db8759f41cc816e4a0d0983473851ed272617d.camel@posteo.net>

Hi,

From inspecting the gpgrt source code, it seems that for system error
codes and on systems with POSIX-conforming strerror_r, gpg_strerror_r
calls out to strerror_r and, since strerror_r is not guaranteed to, null
terminates the buffer.

However, POSIX doesn't say that a partial error message will have been
written if strerror_r fails with ERANGE, and strerror_r is also allowed
to fail with other errors besides EINVAL and ERANGE. That means that if
the caller didn't initialize their buffer, there is a risk of their
buffer starting with uninitialized memory, something the GPGME docs say
won't happen.

I propose that if strerror_r fails, we should do the equivalent of
	snprintf(buf, bufsize, "GPG error %u\n", errcode);
to populate the caller's buffer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221121/d4701848/attachment.sig>

From dave at sleepmap.de  Thu Nov 24 00:18:51 2022
From: dave at sleepmap.de (David Runge)
Date: Thu, 24 Nov 2022 00:18:51 +0100
Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and add
 PEP517 support
In-Reply-To: <Y3PObpnDWYg2cduM@hmbx>
References: <Y3NdGQffulZXJGVj@hmbx>
 <Y3PObpnDWYg2cduM@hmbx>
Message-ID: <Y36qaZX9lCkwUHzW@hmbx>

On 2022-11-15 18:37:47 (+0100), David Runge wrote:
> I noticed a small mistake in the pyproject.toml file that I provided.
> 
> Please find attached a revised version, which also properly states the
> build-backend for setuptools.

Hi,

does someone have time to review these changes? It would be really great
if they could be included and released.

Without a working version on pypi.org, people trying to use the Python
integration have to host it themselves somehow or rely on system's
packaging (which may not be available depending on OS and does not work
easily for Python's virtual environments).

Best,
David

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221124/514b209e/attachment.sig>

From bernhard at intevation.de  Tue Nov 29 15:05:03 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 29 Nov 2022 15:05:03 +0100
Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and
 add PEP517 support
In-Reply-To: <Y36qaZX9lCkwUHzW@hmbx>
References: <Y3NdGQffulZXJGVj@hmbx> <Y3PObpnDWYg2cduM@hmbx>
 <Y36qaZX9lCkwUHzW@hmbx>
Message-ID: <202211291505.10201.bernhard@intevation.de>

Hi David,

Am Donnerstag 24 November 2022 00:18:51 schrieb David Runge:
> does someone have time to review these changes? It would be really great
> if they could be included and released.

thanks for sending a contribution!
Eventually someone will review your patches, I just don't know when.
So, they'll be useful for those who find them here.

Have you've done the steps in
https://github.com/gpg/gpgme/blob/master/doc/HACKING#license-policy
yet?

Best Regards,
Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221129/d9ff13c3/attachment.sig>

From dave at sleepmap.de  Tue Nov 29 15:47:32 2022
From: dave at sleepmap.de (David Runge)
Date: Tue, 29 Nov 2022 15:47:32 +0100
Subject: GPGME DCO
Message-ID: <Y4Ybp1oYdDqCh2+B@hmbx>

Hi!

As pointed out by Bernhard Reiter [1], please find attached the DCO for
my contribution posted to this list over the past weeks.

Best,
David

[1] https://lists.gnupg.org/pipermail/gnupg-devel/2022-November/035162.html

-- 
https://sleepmap.de
-------------- next part --------------
GPGME Developer's Certificate of Origin.  Version 1.0
=====================================================

By making a contribution to the GPGME project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the free software license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate free
    software license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same free software license
    (unless I am permitted to submit under a different license),
    as indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the free software license(s)
    involved.

Signed-off-by: David Runge <dave at sleepmap.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221129/9b3a6285/attachment-0001.sig>

From dave at sleepmap.de  Tue Nov 29 16:31:23 2022
From: dave at sleepmap.de (David Runge)
Date: Tue, 29 Nov 2022 16:31:23 +0100
Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and add
 PEP517 support
In-Reply-To: <202211291505.10201.bernhard@intevation.de>
References: <Y3NdGQffulZXJGVj@hmbx> <Y3PObpnDWYg2cduM@hmbx>
 <Y36qaZX9lCkwUHzW@hmbx> <202211291505.10201.bernhard@intevation.de>
Message-ID: <Y4Ylzt5HVlWocAb+@hmbx>

On 2022-11-29 15:05:03 (+0100), Bernhard Reiter wrote:
> So, they'll be useful for those who find them here.

Unfortunately, that is not the case, as Python projects developed in
virtualenvs (arguably a large chunk of today's projects) can not
integrate the existing sdist tarball from pypi.org [1], because it is so
outdated and can not be built/installed.
Adding the PEP517 integration (as done in my patches) is only the
preparation. It is also required that GPGME is released and to push an
up-to-date sdist tarball (which has to be generated by a make target) to
pypi.org (which only the maintainers of this project can do).

In its current state the only way the Python integration can be used is
if one's operating system (e.g. a Linux distribution) provides it as a
package (built alongside gpgme). This renders testing in virtualenvs,
where dependencies can be pinned and built reproducibly impossible
though.

> Have you've done the steps in
> https://github.com/gpg/gpgme/blob/master/doc/HACKING#license-policy
> yet?

Thanks for pointing that out! I had not, but have just sent it.

Best,
David

[1] https://pypi.org/project/gpg/

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221129/5a5cfa52/attachment.sig>

From gniibe at fsij.org  Wed Nov 30 04:38:13 2022
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 30 Nov 2022 12:38:13 +0900
Subject: Guarantees of gpg_strerror_r may not hold
In-Reply-To: <64db8759f41cc816e4a0d0983473851ed272617d.camel@posteo.net>
References: <64db8759f41cc816e4a0d0983473851ed272617d.camel@posteo.net>
Message-ID: <877czdm7ru.fsf@akagi.fsij.org>

Hello,

John Scott via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> That means that if the caller didn't initialize their buffer, there is
> a risk of their buffer starting with uninitialized memory, something
> the GPGME docs say won't happen.

Thank you for your suggestion.

To be consistent to other parts of the code, something like this is more
appropriate, I suppose.

==========================
diff --git a/src/strerror.c b/src/strerror.c
index fb1bebf..51e57d8 100644
--- a/src/strerror.c
+++ b/src/strerror.c
@@ -96,7 +96,21 @@ system_strerror_r (int no, char *buf, size_t buflen)
 static int
 system_strerror_r (int no, char *buf, size_t buflen)
 {
-  return strerror_r (no, buf, buflen);
+  int saved_errno;
+  int r = strerror_r (no, buf, buflen);
+
+  if (r)
+    {
+      if (r < 0)
+        saved_errno = errno;
+      else
+        saved_errno = r;
+
+      snprintf (buf, buflen, "strerror_r failed: %i\n", r);
+      return saved_errno;
+    }
+
+  return 0;
 }
 
 #endif	/* STRERROR_R_CHAR_P */
-- 


From wk at gnupg.org  Wed Nov 30 13:44:12 2022
From: wk at gnupg.org (Werner Koch)
Date: Wed, 30 Nov 2022 13:44:12 +0100
Subject: Guarantees of gpg_strerror_r may not hold
In-Reply-To: <877czdm7ru.fsf@akagi.fsij.org> (NIIBE Yutaka's message of "Wed, 
 30 Nov 2022 12:38:13 +0900")
References: <64db8759f41cc816e4a0d0983473851ed272617d.camel@posteo.net>
 <877czdm7ru.fsf@akagi.fsij.org>
Message-ID: <87r0xkhasj.fsf@wheatstone.g10code.de>

On Wed, 30 Nov 2022 12:38, NIIBE Yutaka said:

> +      snprintf (buf, buflen, "strerror_r failed: %i\n", r);

May I suggest to use

         snprintf (buf, buflen, "[errno=%i]\n", r);

Sich bracketed error messages are often used if there is a problem wit
the error message.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221130/ef76d8d8/attachment.sig>

From wk at gnupg.org  Wed Nov 30 13:47:30 2022
From: wk at gnupg.org (Werner Koch)
Date: Wed, 30 Nov 2022 13:47:30 +0100
Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and
 add PEP517 support
In-Reply-To: <Y3NdGQffulZXJGVj@hmbx> (David Runge's message of "Tue, 15 Nov
 2022 10:34:13 +0100")
References: <Y3NdGQffulZXJGVj@hmbx>
Message-ID: <87mt88han1.fsf@wheatstone.g10code.de>

Hi!

I might be misunderstanding something.  However, we do not do anything
with pypi in GnuPG.  Thus I can't see what your patch is about.  In fact
GPGME comes with its own and different Python language bindings.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221130/75f93451/attachment.sig>

From dave at sleepmap.de  Wed Nov 30 15:31:15 2022
From: dave at sleepmap.de (David Runge)
Date: Wed, 30 Nov 2022 15:31:15 +0100
Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and
 add PEP517 support
In-Reply-To: <87mt88han1.fsf@wheatstone.g10code.de>
References: <Y3NdGQffulZXJGVj@hmbx>
 <87mt88han1.fsf@wheatstone.g10code.de>
Message-ID: <Y4dpS01Z20845Ego@hmbx>

On 2022-11-30 13:47:30 (+0100), Werner Koch wrote:
> I might be misunderstanding something.  However, we do not do anything
> with pypi in GnuPG.

The current available gpg package on pypi.org [1] is an sdist tarball,
generated from gpgme 1.10.0.
The gpgme sources even provide a make target [2] for upload to pypi.org.
It appears that Justus Winter [3] is the person, that last updated and
maintained the sdist tarball for you.

> Thus I can't see what your patch is about.

The 1st patch is about creating an sdist tarball (using the existing
make target) without specifying obsolete options and also allowing the
use of prerelease versions (because Python names them differently - e.g.
1.0.0-alpha -> 1.0.0a).
The 2nd patch is about enabling PEP517 [4] based build backends, which can
use PEP518 [5] based build requirements in a pyproject.toml, to build a
wheel from the sdist tarball on pypi.org.

> In fact GPGME comes with its own and different Python language
> bindings.

As noted above, the sdist tarball on pypi.org was generated from the
gpgme sources (albeit from a very old version) in 2018.

Please reinstate this going forward, as it allows Python projects to use
gpg in virtualenvs (which is a huge chunk of current projects) for
testing and running a project.

Without an up-to-date and functional sdist tarball on pypi.org, projects
can only use system provided packages, which makes projects not be
self-contained and unable to test and run in a Python virtual
environment.

Best,
David

[1] https://pypi.org/project/gpg/
[2] https://github.com/gpg/gpgme/blob/ac4536990a4fed4a45a0851260c029e69d0cadf6/lang/python/Makefile.am#L62-L65
[3] https://pypi.org/user/justus.winter/
[4] https://peps.python.org/pep-0517/
[5] https://peps.python.org/pep-0518/

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221130/07ce7d9e/attachment.sig>