Bug#1022702: [pkg-gnupg-maint] Bug#1022702: I volunteer to maintain GnuPG and friends in the long-term
Hi! On Thu, 27 Jul 2023 15:24, NIIBE Yutaka said: > - ... and default keyserver choice: > debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch FWIW, if you need to change the default, the proper location is /etc/gnupg/dirmngr.conf and not a source code patch. > - And for the specific keyserver, there are local changes: > debian/patches/import-merge-without-userid/ Which breaks the gnupg policy and are harmful for the entire ecosystem. There is a reason that we we use a syncing keyserver instead of the x-th attempt to for a "verifying" keyserver onto PGP users. > - Upstream deprecates systemd support, which was originally introduced > in Debian version. Perhaps, we will need a Debian local patch for > this. The problem here is that GnuPG has its own way to start its agents. Using systemd activation here introduces races because you can't have two (advisory) locking systems where each does not know about the other. For an engineering POV we can't switch to socket activation for portability reasons. Keep in mind that the heaviest desktop users of gpg are on Windows and we tried hard to keep changes as small as possible. That benefits all users: On Linux, AIX, *BSD and Windows. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature
Bug#1022702: I volunteer to maintain GnuPG and friends in the long-term
Hello, I'd like to help the packaging of GnuPG and its friends in Debian, in the long term. I am a developer of the GnuPG team, and DD who maintains scute in Debian. I joined the team in 2011, then, mainly working for smartcard support. I don't think I can help solving the policy issue which Andreas Metzler addressed. Rather, I'm afraid that I will make the situation more complicated and unsolvable, if I will try to solve something political by myself. So, I should work for the parts where there are no conflicts of policy (between GnuPG and IETF specification thing). For the packaging work, I think that we should value current Debian specific changes, so that Debian users will see less surprise. We need to maintain Debian specific changes (for foreseeable future, at least). Here are some topics of Debian specific changes. - Debian packaging of GnuPG has its specific preferences: debian/patches/update-defaults/ - ... and default keyserver choice: debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch - And for the specific keyserver, there are local changes: debian/patches/import-merge-without-userid/ And the change of upstream which should not be introduced for Debian users: - Upstream deprecates systemd support, which was originally introduced in Debian version. Perhaps, we will need a Debian local patch for this. Today, I cloned libgpg-error, libassuan, npth, and gnupg2 from salsa.d.o. I found that we have an issue of build for x86_64-w64-mingw32. In the upstream, we maintain a local change of libtool to change shared library name for 64-bit version (so that users can see less problem when installing 32-bit version and 64-bit version at the same time). In the current Debian build process, the local change of libtool is ignored. IIUC, it's not intentional. Let me start by fixinig this problem (of libgpg-error) at first. --
Bug#1022702: I volunteer to maintain GnuPG and friends in the long-term
On Tue, 2023-07-25 at 09:42 +0100, Jonathan McDowell wrote: > The longer term question is whether any of us are stepping up to help > out with full package maintenance, which I believe should be a > prerequisite of an upload to unstable if we don't hear from Eric or dkg. I'm neither a DD nor a DM, but I do believe I have some qualifications. I'd like to join the team and stick around for the long-haul. - I'm familiar with MinGW, C, and cross-compilers, so I can help build the binaries that target Windows. I'm familiar with best practices with building for foreign (non-Debian) architectures in Debian packages, maintaining bare-metal toolchains with the Electronics+Kernel teams to support firmware. - I program with GPGME and like writing small utilities with it. - I use niche features such as LDAP searching for S/MIME certificates, gpgsm generally, multiple smartcard support, TOFU, DANE, and more, so I can test that these work. - I love autopkgtests and want to write more. I have a lot to learn, but one of my ideas is to install slapd (the OpenLDAP directory server) and check that the GnuPG suite can fetch certificates and OpenPGP keys. I'm familiar with LDAP programming, so my idea is to write some OpenLDAP glue to upload the keys, then call GPGME functions to fetch them again and see they're the same. signature.asc Description: This is a digitally signed message part
