From alsaiditransport0 at gmail.com  Mon Nov  3 22:00:57 2025
From: alsaiditransport0 at gmail.com (Alsaiditransport)
Date: Mon, 3 Nov 2025 23:00:57 +0200
Subject: =?UTF-8?B?2K7Yr9mF2KfYqiDZhtmC2YQg2KfZhNi52YHYtCDZgdmKINiu2YXZitizINmF2LTZiti3?=
Message-ID: <CAEeabLNL6AkLmy1DSyjR6GFr6Fuwztbh87Go8-67nfeB=qA7kw@mail.gmail.com>

???? ????? *??? ?????* ????? ?? ???? ??????? ?????? ???? ?? ????? ???????
??? *???? ????* ?*????? ????* ?*????*? ??? ?????? ???? ???????? ??? ???????
???????? ???? ?????. ??? ??? ??????? ???? ????? ?????? ???? ?????? ????????
??????? ????? ?? ????? ????? ????? ????? ????? ?????? ?? ??????? ???
???????.

????? ???? ??? ??? ????? ????
<https://al-saiditransport.info/%D8%B4%D8%B1%D9%83%D8%A9-%D9%86%D9%82%D9%84-%D8%B9%D9%81%D8%B4-%D8%A8%D8%AE%D9%85%D9%8A%D8%B3-%D9%85%D8%B4%D9%8A%D8%B7/>
????? ??????? ??????? ?? ??? ?????? ???? ???????? ??? ????? ??? ???? ?????
??? ????. ??? ???? ????? ????? ???? ?? ?? ?????? ??????? ?????? ???????
??????? ?????????? ???????? ???? ????? ??????? ?????? ??? ????? ??? ??????
????? ?????? ?? ??????. ??? ????? ?????? ?? ???????? ?????? ??? ?????
?????? ?????? ??????? ??? ?? ???? ?? ??????.

??? *????? ????*? ???? ???? ??? ??? ?????? ????
<https://al-saiditransport.info/%D8%A7%D9%81%D8%B6%D9%84-27-%D8%B4%D8%B1%D9%83%D8%A9-%D9%86%D9%82%D9%84-%D8%B9%D9%81%D8%B4-%D8%A8%D9%85%D8%AD%D8%A7%D9%8A%D9%84-%D8%B9%D8%B3%D9%8A%D8%B1/>
???????? ??????? ???? ????? ??? ????????. ????? ?????? ??? ???? ??????
????? ?????? ?????? ?? ???? ????? ???? ????? ??????? ??? ???? ??????? ???
???? ??????? ?????? ??????? ??????. ??? ???? ?????? ?????? ?????? ?????
????? ????? ??????? ??? ?? ?????? ?? ???? ??????? ??????????? ?? ?????.

??? ???? ??? ??? ????
<https://al-saiditransport.info/%D8%A7%D9%81%D8%B6%D9%84-27-%D8%B4%D8%B1%D9%83%D8%A9-%D9%86%D9%82%D9%84-%D8%B9%D9%81%D8%B4-%D9%81%D9%8A-%D8%A8%D9%8A%D8%B4%D8%A9/>
??? ????? ???? ?? ???? ???????? ?? ??????? ???? ???????? ??? ?????? ?????
?? ????? ????????? ?? ????? ??? ???? ????? ?? ???? ???? ?????????. ????
?????? ????? ????? ???? ??????? ???? ?????? ?? ????? ???? ???? ??? ??????
???????. ??? ????? ??????? ??? ??????? ?? ???????? ??????? ??? ??? ???????
???????? ???????? ?????? ?????.

????? ??? ??????? ?????? ??? ??? ????: *????? ???? ??? ??? ???????? ?????
?? ???????*. ??? ?? ????? ?????? ???? ?? ???? ?????? ???? ?????? ?? ????
????? ?? ???? ????????? ????. ???? ??? ??????? ????? ??? ??????? ?? *????
????* ?? *????? ????* ?? *????* ???? ????? ??? ????? ?????? ??????? ??????
?? ??????? ??? ???????.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251103/b36a8cde/attachment-0001.html>

From kloecker at kde.org  Fri Nov  7 10:02:53 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Fri, 07 Nov 2025 10:02:53 +0100
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
Message-ID: <3583157.sQuhbGJ8Bu@daneel>

Hi Robert,

thanks for your email. Let's move this to the gnupg-devel at gnupg.org mailing 
list. I hope I'm using the correct email address of yours. mailman has 
replaced your address in the From header with "Robert J. Hansen via Gnupg-
users" <gnupg-users at gnupg.org> (probably because of SPF & friends).

On Donnerstag, 6. November 2025 20:53:26 Mitteleurop?ische Normalzeit Robert 
J. Hansen via Gnupg-users wrote:
> After using GPGMEPP for a week or so, I'm pleased with it. Somebody 
> clearly put some thought into how to make it a properly C++ library, 
> rather than just a thin wrapper around a C one. Whoever's responsible 
> for that (Ingo?), thank you.

Thanks, but that was long before I took over.

> However, I do have a couple of minor nits. (Of course I do. It's me.)

Believe me, I have more than just a couple of minor nits about the API. The 
problem is that we do guarantee ABI stability which makes it nigh to 
impossible to fix errors of the past or to modernize the API.

> First, a number of functions accept unsigned ints as a parameter. This 
> involves a minor pain point for those of us working in environments that 
> require us to follow the MISRA C++ guidelines. Admittedly, it's a 
> one-letter fix:
> 
> 	(*ctx).setKeyListMode(0);
> 
> 		|
> 
> 	     becomes
> 
> 		|
> 
> 		V
> 	(*ctx).setKeyListMode(0U);
> 
> but it would be nice if we could find some way to avoid one letter of 
> syntactic sugar and let us express code in the most natural way.
> 
> Second, MISRA has ? I can only call them _opinions_, shall we say ? on 
> the subject of pointers. Look at, e.g., creating a new Context:
> 
> 	auto ctx = unique_ptr<Context>(OpenPGP);
> 	if (nullptr == ctx) {
> 	    // handle the error
> 	}

See below for Robert correcting the above example.

> Here there are two problems. The first is that GPGMEPP is using 
> old-style enums rather than modern C++ class enums, which means they're 
> not typesafe and it's harder for static analysis tools to detect when 
> you're feeding in garbage.

Looking at the history the first registered commit in the current gpgmepp repo 
is from early 2004, i.e. almost a decade before the modernization of C++ 
started. (The commits that predate this date are lost in an old branch that's 
probably still available in some backup.)

Regarding class enums, I'm not yet sure how/when to use them properly. In my 
understanding they are unsuitable for bit flags and many of gpgmepp enums are 
bit flags.

> The second is that per MISRA, unique_ptrs and 
> shared_ptrs should be created only by calls to make_unique and/or 
> make_shared, not by direct application of the constructor.

I wholeheartedly agree with you and MISRA. But wait: There's
static std::unique_ptr<Context> create(Protocol proto);
since many years. What's missing is a function that returns a shared_ptr.

> Hence, two more suggestions. First, replace all enums with C++ class 
> enums, and second, make createForProtocol take a template parameter of 
> the type of pointer to return, whether unique, shared, or raw.

I'd appreciate if you would propose patches for this. I'm not sure how we can 
make those changes API- and ABI-compatible.

For "pure" enums (like Protocol) the problem is that converting them to "class 
enums" makes them, by definition, scoped which is ABI-compatible but not source 
compatible.

For enums that are used as bit flags I'm at a loss how class enums and bit flags 
can work. The internet seems to suggest that one should simply overload 
operator| to avoid the compiler's complaints, but to me (and others) this 
feels like forcing something to fit which doesn't fit.

For createForProtocol/create the easiest would probably be a new method with a 
different name that replaces the old methods. Too bad that the best name 
"create" is already taken. What about adding a non-templated createShared 
method to complement the existing createForProtocol and create? For version 
3.0 (which I'm not sure will ever happen) we could then clean this up. I'm 
open for alternative suggestions, i.e. we can still add a templated variant if 
you have a good suggestion for a name.

Regarding the implementation of create we can easily make create use 
make_unique internally.

> These minor problems aren't creating any obstacles to my development, 
> just requiring me to fill out a small amount of paperwork documenting 
> the deviations from MISRA. All in all I quite like GPGMEPP. Thanks for 
> the code, guys. :)

Thanks! It's nice to hear that it's useful for others.

On Donnerstag, 6. November 2025 22:00:52 Mitteleurop?ische Normalzeit Robert 
J. Hansen via Gnupg-users wrote:
> >      auto ctx = unique_ptr<Context>(OpenPGP);
> 
> 
> Gah! I was literally looking at my code while copying it and still 
> somehow managed to goof it.
> 
> "auto ctx = unique_ptr<Context>(Context::createForProtocol(OpenPGP));"

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251107/ccd40702/attachment.sig>

From max.allan at chainguard.dev  Fri Nov  7 11:08:16 2025
From: max.allan at chainguard.dev (Max Allan)
Date: Fri, 7 Nov 2025 10:08:16 +0000
Subject: GPG 2.4.7 locking problem
Message-ID: <CA+T1A2hnD7c7V21UnMg1h93+vb_DWR9XxvbZDY-FNoFZQWn6VQ@mail.gmail.com>

Hi,
I wanted to report this as a bug but it says I need to get permission to
raise bugs from a mailing list. So here I am.

When using GPG 2.4.7 or 2.4.8 in a Docker build process to add a key, the
gpg command will start keyboxd and gpg-agent. And keyboxd creates a lock
file. ( I tried going back to a 2.2 version and it works without creating a
keyboxd or a lockfile)

When those processes are killed the lock file remains. EVEN if you ran the
import with "--lock-never"

When the image is used, any gpg commands will fail because the hostname is
different and there is no longer a process 8.

You can see this problem without Docker:

/ # ps -ef

PID   USER     TIME  COMMAND

    1 root      0:00 /bin/sh

   41 root      0:00 ps -ef

/ # ls -l ~/.gnupg

ls: /root/.gnupg: No such file or directory

/ # gpg --import --lock-never me.gpg

gpg: directory '/root/.gnupg' created

gpg: /root/.gnupg/trustdb.gpg: trustdb created

gpg: key CECCAAB88A9758B4: public key "argo <argo at example.com>" imported

gpg: Total number processed: 1

gpg:               imported: 1

/ # ls -l ~/.gnupg/public-keys.d/pubring.db.lock

-rw-r--r--    2 root     root            24 Nov  7 09:56
/root/.gnupg/public-keys.d/pubring.db.lock

/ # ps -ef

PID   USER     TIME  COMMAND

    1 root      0:00 /bin/sh

   45 root      0:00 keyboxd --homedir /root/.gnupg --daemon

   49 root      0:00 gpg-agent --homedir /root/.gnupg --use-standard-socket
--daemon

   53 root      0:00 ps -ef

/ # kill -9 45 49

/ # ls -l ~/.gnupg/public-keys.d/pubring.db.lock

-rw-r--r--    2 root     root            24 Nov  7 09:56
/root/.gnupg/public-keys.d/pubring.db.lock



If you were in an "image build" process the keyboxd and gpg-agent processes
would be killed. And they don't remove the lockfile. And when the image is
used the hostname could be anything so it can't break the lock.

This feels like 2 bugs to me.
First: --lock-never still creates a lock.
Second: Terminating the process (without using gpgconf) does not remove the
unwanted lockfile.

I did ask on Stackoverflow  with a full example in Alpine, but didn't get
any responses yet.
https://stackoverflow.com/questions/79811273/using-gpg-in-docker-build-step-is-there-an-easier-way-or-option-to-autokill-the/79811281#79811281


Thanks,
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251107/a5ce0f5a/attachment.html>

From giacomo at tesio.it  Sat Nov  8 15:29:09 2025
From: giacomo at tesio.it (Giacomo Tesio)
Date: Sat, 8 Nov 2025 15:29:09 +0100
Subject: GPGME: gpgme_get_key bug
Message-ID: <20251108152909.7a46add3@hermes.development.it>

Hi, while working on a patch for Claws-Mail, I realized that
gpgme_get_key ignores context configuration set with either
gpgme_set_ctx_flag or gpgme_set_offline.

Looking at the source code in gpgme/src/keylist.c, I saw that a new
listctx is created "to avoid the user's I/O callback handlers" and 
part of the calling ctx's configuration is copied there.

However, imho, at least "auto-key-locate" ctx flag and offline mode
should be copied too, to actually serve the caller's request, as
they may impact the key retrieval.


You can find a patch attached.


Cheers,


Giacomo

PS: I tried to report this on bugzilla, but the registration page
suggest to ask here for credentials. Feel free to use "giacomo" as
handle, "Giacomo Tesio" as shown name, and this address as email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gpgme_get_key-respect-caller-s-ctx-configuration.patch
Type: text/x-patch
Size: 1150 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251108/363534fb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Firma digitale OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251108/363534fb/attachment-0001.sig>

From her at sorah.jp  Sun Nov  9 15:24:04 2025
From: her at sorah.jp (Sorah Fukumori)
Date: Sun, 9 Nov 2025 23:24:04 +0900
Subject: Requesting backport of read_key_file memory leak fix to 2.4
In-Reply-To: <87ed16du7r.fsf@akagi.fsij.org>
References: <20250113122821.2587166-2-her@sorah.jp>
 <87ed16du7r.fsf@akagi.fsij.org>
Message-ID: <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>

Hello,

Can the commit 137481fa1002c417cd2c0661b9eefd893b0149d3 have a review
for backport to the stable branch (STABLE-BRANCH-2-4)?
This bug can be reproduced on 2.4.8, and I'd like to get it fixed on
2.4 before it reaches EOL.

# I am unsure of a formalized way to request backports, pardon me if
I'm doing it wrong.

Thanks,
Sorah

---------- Forwarded message ---------
From: NIIBE Yutaka <gniibe at fsij.org>
Date: Tue, 14 Jan 2025 at 11:07
Subject: Re: [PATCH gnupg] agent: Fix a memory leak
To: Sorah Fukumori <her at sorah.jp>, <gnupg-devel at gnupg.org>


Hello,

Sorah Fukumori wrote:
> * agent/findkey.c (read_key_file): Free the buffer,
>   which were forgotten to be freed at commit 434a641d40c on T6944.
>   Otherwise the 'keyinfo --list' agent command gradually leads to
>   memory exhaustion.

Thank you, good catch.  I applied it to master, in the commit:

        137481fa1002c417cd2c0661b9eefd893b0149d3
--


-- 
Sorah Fukumori https://sorah.jp/


From wk at gnupg.org  Mon Nov 10 09:35:32 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 09:35:32 +0100
Subject: GPGME: gpgme_get_key bug
In-Reply-To: <20251108152909.7a46add3@hermes.development.it> (Giacomo Tesio's
 message of "Sat, 8 Nov 2025 15:29:09 +0100")
References: <20251108152909.7a46add3@hermes.development.it>
Message-ID: <87jyzyxp2j.fsf@jacob.g10code.de>

Hi!

On Sat,  8 Nov 2025 15:29, Giacomo Tesio said:

> However, imho, at least "auto-key-locate" ctx flag and offline mode
> should be copied too, to actually serve the caller's request, as
> they may impact the key retrieval.

I agree and applied your patch.  Thanks.


Shalom-Salam,

   Werner


ps.
I created the account for you.  Sorry for the trouble but we have
more and more problems with AI slop

-- 
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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251110/27669232/attachment.sig>

From wk at gnupg.org  Mon Nov 10 09:37:01 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 09:37:01 +0100
Subject: Requesting backport of read_key_file memory leak fix to 2.4
In-Reply-To: <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
 (Sorah Fukumori via Gnupg-devel's message of "Sun, 9 Nov 2025 23:24:04
 +0900")
References: <20250113122821.2587166-2-her@sorah.jp>
 <87ed16du7r.fsf@akagi.fsij.org>
 <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
Message-ID: <87framxp02.fsf@jacob.g10code.de>

Hi!

On Sun,  9 Nov 2025 23:24, Sorah Fukumori said:
> Can the commit 137481fa1002c417cd2c0661b9eefd893b0149d3 have a review
> for backport to the stable branch (STABLE-BRANCH-2-4)?

We can do this.  However, there might be no further 2.4 release.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251110/ea30606f/attachment.sig>

From wk at gnupg.org  Mon Nov 10 14:51:01 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 14:51:01 +0100
Subject: GPG 2.4.7 locking problem
In-Reply-To: <CA+T1A2hnD7c7V21UnMg1h93+vb_DWR9XxvbZDY-FNoFZQWn6VQ@mail.gmail.com>
 (Max Allan via Gnupg-devel's message of "Fri, 7 Nov 2025 10:08:16
 +0000")
References: <CA+T1A2hnD7c7V21UnMg1h93+vb_DWR9XxvbZDY-FNoFZQWn6VQ@mail.gmail.com>
Message-ID: <87ms4uvvwa.fsf@jacob.g10code.de>

On Fri,  7 Nov 2025 10:08, Max Allan said:

> When those processes are killed the lock file remains. EVEN if you ran the
> import with "--lock-never"

Oh, I forgot about this old option.  This may lead to all kind of
problems because it entirely disables the locking module for all kind of
locks.  We use file locks to protect the launching of daemons (gpg-agent,
keyboxd, dirmngr) as weel as to protect pubring.gpg and pubring.kbx
files.

> -rw-r--r--    2 root     root            24 Nov  7 09:56
> /root/.gnupg/public-keys.d/pubring.db.lock

and also to lock the sqlite database pubring.db so that only one keyboxd
process may use it.  There should be only one which is assured by using
a lock when launching keyboxd.

On Unix you may cat the file to see which process holds the lock.

> If you were in an "image build" process the keyboxd and gpg-agent processes
> would be killed. And they don't remove the lockfile. And when the image is

That depends on how you kill them; SIGKILL will for sure not clean them
up.  However we employ a stale lock removal method which works if the
lockfile has ben created on the same node (using uname(2)) but the
process does not anymore exist.

> Second: Terminating the process (without using gpgconf) does not remove the
> unwanted lockfile.

Try "gpgconf -K all" or send the SIGTERM more than 2 times to each
daemon.

> I did ask on Stackoverflow  with a full example in Alpine, but didn't get
> any responses yet.

Sorry, no time to read the log.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251110/b9376538/attachment.sig>

From gniibe at fsij.org  Tue Nov 11 03:30:30 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 11 Nov 2025 11:30:30 +0900
Subject: Requesting backport of read_key_file memory leak fix to 2.4
In-Reply-To: <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
References: <20250113122821.2587166-2-her@sorah.jp>
 <87ed16du7r.fsf@akagi.fsij.org>
 <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
Message-ID: <877bvx47y1.fsf@haruna.fsij.org>

Hello,

Sorah Fukumori wrote:
> This bug can be reproduced on 2.4.8, and I'd like to get it fixed on
> 2.4 before it reaches EOL.

Sorry, I should have done earlier.  Ahyhow, applied and pushed to
2.4 branch.
-- 


From me at chandlerdavis.cc  Thu Nov 13 14:04:48 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Thu, 13 Nov 2025 13:04:48 +0000
Subject: [PATCH gpgme]: Remove duplicate field description from gpgme_subkey_t
 in manual
Message-ID: <IAnpb7D6uyRhqIBj82DWCsyPhKM5V-ygPkHYzUDGGVrFFctbquV_Tex6bTN7R13Ok98VcuHJs8CMSUja1dM1-NyoL3dA79Gpj7jrxRJroW8=@chandlerdavis.cc>

Hello,

I was referred here from gnupg-users to submit a patch for the gpgme docs. I've done my best to follow the guidelines in the HACKING document, but please let me know if there's anything I missed or should keep in mind for the future.

Also, I'd like to request an account for the bug tracker. My handle is "bitcrshr", full name is "Chandler Davis", and email is "me at chandlerdavis.cc". Apologies if this is already being worked on from my previous email in the users list.

As an aside, I'm new to contributing via mailing list and am largely unfamiliar with the etiquette / norms. I was wondering if there is a GnuPG resource for that somewhere, or if you think it would be worthwhile for me to take a shot at creating one as I get familiarized. In the meantime, I'll dig into more general resources.

Many thanks, and have a good one!

Best,
Chandler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-doc-Remove-duplicate-is_cardkey-from-gpgme_subkey_t.patch
Type: application/octet-stream
Size: 1030 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251113/4df7cf0f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DCO
Type: application/octet-stream
Size: 1271 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251113/4df7cf0f/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251113/4df7cf0f/attachment.sig>

From wk at gnupg.org  Thu Nov 13 16:32:29 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Nov 2025 16:32:29 +0100
Subject: [PATCH gpgme]: Remove duplicate field description from
 gpgme_subkey_t in manual
In-Reply-To: <IAnpb7D6uyRhqIBj82DWCsyPhKM5V-ygPkHYzUDGGVrFFctbquV_Tex6bTN7R13Ok98VcuHJs8CMSUja1dM1-NyoL3dA79Gpj7jrxRJroW8=@chandlerdavis.cc>
 (Chandler Davis via Gnupg-devel's message of "Thu, 13 Nov 2025
 13:04:48 +0000")
References: <IAnpb7D6uyRhqIBj82DWCsyPhKM5V-ygPkHYzUDGGVrFFctbquV_Tex6bTN7R13Ok98VcuHJs8CMSUja1dM1-NyoL3dA79Gpj7jrxRJroW8=@chandlerdavis.cc>
Message-ID: <87a50qrlrm.fsf@jacob.g10code.de>

Hi!

On Thu, 13 Nov 2025 13:04, Chandler Davis said:

> docs. I've done my best to follow the guidelines in the HACKING
> document, but please let me know if there's anything I missed or
> should keep in mind for the future.

Thanks for the patch. I merely changed the "(doc) ..." to "doc: ... and
aded a line with "--" so that this change won't show up in the generated
ChangeLog.

> Also, I'd like to request an account for the bug tracker. My handle is
> "bitcrshr", full name is "Chandler Davis", and email is

Created.  You should receive a password reset mail.  But take care: we
are often under AI scraper siege so don't wonder when you see error
mails.

> As an aside, I'm new to contributing via mailing list and am largely
> unfamiliar with the etiquette / norms. I was wondering if there is a
> GnuPG resource for that somewhere, or if you think it would be

I don't think so.  We do it like we do this for decades.  Sending
patches as an attschment is just fine.  If you have a larger patch and
won't to break it up into several ones, "git format-patch" has the
options to do that.  However, an initial mail describing what you want
to do is a good idea.

Oh and yes: No ABI or ABI breaks - if that is required a longer
discussion will be needed.


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251113/1d2ea523/attachment.sig>