Bug#1071202: [pkg-gnupg-maint] Bug#1071202: src:gnupg2: upstream tarball ships files not in upstream revision control

Hello, For your information, let me explain about regexp support. Daniel Kahn Gillmor wrote: > regexp/_unicode_mapping.c | 284 + [...] > Maybe the right (and more up-to-date) solution is to build-depend on > unicode-data, strip both this file and UnicodeData.txt in >

Bug#1071168: [pkg-gnupg-maint] Bug#1071168: gnupg: Yubikey with KDF enabled: PKDECRYPT failed: Bad PIN

Hello, Julian Wollrath wrote: > after updating to 2.2.43 I cannot use a key stored on a Yubikey (with > KDF enabled, not sure, if that matters) anymore, since the PIN is > rejected: > gpg-agent[38887]: detected card with S/N XXX > gpg-agent[38889]: scdaemon[38889]: sending signal 12 to client

Bug#1058572: [pkg-gnupg-maint] Bug#1058572: Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd

Hello, again, YunQiang Su wrote: > gpg: error writing public keyring '[keyboxd]': Attempt to write a > readonly SQL database > Key generation failed: Attempt to write a readonly SQL database NIIBE Yutaka wrote: > I can't replicate this issue on my system. With a new us

Bug#1058572: [pkg-gnupg-maint] Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd

Hello, YunQiang Su wrote: > gpg: error writing public keyring '[keyboxd]': Attempt to write a > readonly SQL database > Key generation failed: Attempt to write a readonly SQL database I can't replicate this issue on my system. With a new user I created for the test, I had no problem; The

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

Hello, NIIBE Yutaka wrote: > I backported and pushed my changes to tmp-gniibe-v2.4. > > https://salsa.debian.org/gniibe/gnupg2 > > This is Debian compatible version of GnuPG 2.4.1. Today, I merged 2.4.3 from Andreas Metzler's tmp-ametzler-v2.4 branch. This is Debian com

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

NIIBE Yutaka wrote: > I'm going to backport the improvement to my branch of tmp-gniibe-v2.4 > for Debian. I backported and pushed my changes to tmp-gniibe-v2.4. https://salsa.debian.org/gniibe/gnupg2 This is Debian compatible version of GnuPG 2.4.1. --

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

NIIBE Yutaka wrote: > I was wrong. The ticket for agent_cache_housekeeping is: > > https://dev.gnupg.org/T3829 > > It was introduced because of some risk keeping passphrase. > > I'd like to consider to improve the implementation of cache and > expiratio

Bug#1050886: [pkg-gnupg-maint] Bug#1050886: Issues that need to be fixed in "yat2m" for transforming manuals to a man-page format

Bjarni Ingi Gislason wrote: > Package: gpgrt-tools > Version: 1.47-2 > Severity: normal > > Dear Maintainer, > > The following are issues that yat2m needs to correct when producing > man-page formatted manuals. > > The example is from "gpg(1)". Thank you for your bug report and good

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

NIIBE Yutaka wrote: > Besides, in my opinion, the agent_cache_housekeeping function makes less > sense (it's totally OK to only check the expiration on its use). Having > expired entries on memory is no problem at all, than running gpg-agent > process periodically; memory is cheap

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

NIIBE Yutaka wrote: > Based on your work of tmp-ametzler-v2.4 branch, I created my own fork. > > My hope is that the migration from 2.4 won't introduce (much) surprise > to Debian users. > >https://salsa.debian.org/gniibe/gnupg2/-/tree/tmp-gniibe-v2.4 > > This work of

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

Hello, Andreas Metzler wrote: > On 2023-04-30 Andreas Metzler wrote: > [...] >> However I have updated the GIT branches to 2.4.1 today. > > Now at 2.4.3. Based on your work of tmp-ametzler-v2.4 branch, I created my own fork. My hope is that the migration from 2.4 won't introduce (much)

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

Bug#1032611: ITP: sp800-90b-entropy-assessment -- Estimating the quality of a source of entropy

Package: wnpp Severity: wishlist Owner: NIIBE Yutaka X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: sp800-90b-entropy-assessment Version : 1.1.5 Upstream Contact: Chris Celi * URL : https://github.com/usnistgov/SP800-90B_EntropyAssessment * License

Bug#1014849: Newer jimtcl (>= 0.81) requires fix to scripts

Package: openocd Version: 0.11.0-1+b1 Severity: serious Hello, After I upgraded to libjim0.81, OpenOCD started to emit errors like: == Error executing event examine-end on target stm32f0x.cpu: /usr/bin/../share/openocd/scripts/mem_helper.tcl:37: Error: wrong # args: should be

Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9

On Mon, 11 Apr 2022 11:00:55 -0700 Vagrant Cascadian wrote: > Same problem with Gnuk, presumably multiple or all smartcards are > affected? I found an issue of scdaemon. At upstream development, it is tracked by: https://dev.gnupg.org/T5935 When the data is not so large (smaller than

Bug#972525: fixed in gnupg2 2.2.27-1

Aurelien Jarno wrote: > control: reopen 972525 > control: found 972525 gnupg2/2.2.27-2 Thanks a lot for sharing the fact. I assume that the failure occurs in a situation of heavy load, where it takes time for gpg-agent to start its service. In upstream, I opened another ticket, because I found

Bug#949761: gpgconf: make socketdir configurable to users

On Fri, 24 Jan 2020 17:21:43 +0100 Thorsten Glaser wrote: > Package: gpgconf > Version: 2.2.19-1 > Severity: important > > gpg2 and gpg-agent (used by gnupg (1.x) as well) now uses > GPG_AGENT_INFO=/run/user/2339/gnupg/S.gpg-agent:0:1 but > the directory /run/user/2339 is removed on logout by

Bug#987956: libgcrypt20: ECDH decryption fails with "gpg: public key decryption failed: Invalid object" error message

On Sun, 02 May 2021 19:47:15 +0200 "Xavier G." wrote: > Package: libgcrypt20 > Version: 1.8.7-4 > Severity: important > > Dear Maintainer, > > After a full-upgrade in Sid on 2021-05-02, `gpg --decrypt somefile.gpg` fails: > > gpg: encrypted with 256-bit ECDH key, ID [hopefully irrelevant] >

Bug#987297: Dependency to libpth20

Package: genometools-common Version: 1.6.1+ds-3 Severity: normal Hello, I am a package maintainer of GNU Pth, (non-preemptive) Portable Threads library. GNU Pth in Debian: https://tracker.debian.org/pkg/pth It's an old package. It used to be used by GnuPG 2.0. These days, mostly no

Bug#979379: ITS: src:gnupg2

Hello, On 2021-01-05 +0100, Christoph Biedl wrote: > | missing upstream releases, > > Several. Debian has 2.20, uploaded in March. Upstream is at 2.26. FYI, I tried to build GnuPG 2.2.26-1-of-mine package: https://salsa.debian.org/gniibe/gnupg2 I did: * fetch by 'git fetch ' *

Bug#972525: buildd: sbuild randomly fails to sign changes file despite valid signature keys

the initial connect to gpg-agent. I don't know if this patch fixes the particular problem of sbuild, but, it should improve the situation, hopefully, much. -- commit b1c56cf9e2bb51abfd47747128bd2a6285ed1623 Author: NIIBE Yutaka Date: Wed Jul 24 15:15:32 2019 +0900 common: Use

Bug#967969: pkg-config-crosswrapper wrongly asks to install dpkg-dev even if installed already

Control: merge 930492 Sorry, I should have installed newer mingw-w64-tools. I learned after writing the report. --

Bug#967969: pkg-config-crosswrapper wrongly asks to install dpkg-dev even if installed already

Package: pkg-config Version: 0.29.2-1 Severity: normal Tags: patch Hello, With newer dpkg-architecture (I'm using 1.19.7), when I cross build for i686-w64-mingw32, the command i686-w64-mingw32-pkg-config (linked to pkg-config-crosswrapper) fails with the message: Please install dpkg-dev to

Bug#954506: ttyrec: diff for NMU version 1.0.8-5.1

Sudip Mukherjee wrote: > I've prepared an NMU for ttyrec (versioned as 1.0.8-5.1) and > uploaded it to mentors for sponsoring. Please feel free to tell me if I > should remove it. Thank you for your work. It is OK for Debian. Ideally, it should not be Debian-only patch, so that upstream will

Bug#933713: [pkg-gnupg-maint] Bug#933713: libgpg-error-dev: make package fit for cross development

Hello, Let me explain that what direction we should go. On Tue 2020-01-28 13:01:04 +0100, Francois Gouget wrote: > The only blocker for making libgpg-error-dev Multi-Arch: same is > gpg-error-config. However gpg-error-config is not needed on Debian > since there is no need for -I or -L

Bug#949565: IPv6 Router Advertisement: skip interfaces by no-dhcp-interface

Package: dnsmasq Version: 2.80-1 Severity: normal Tags: ipv6 patch upstream Hello, Situation: My ISP doesn't offer IPv6 prefix delegation and just gives /64 IPv6 address. I configure my router with ndppd (NDP Proxy Daemon), running dnsmasq for internal network. It mostly works, but I observed

Bug#934237: [pkg-gnupg-maint] Bug#934237: yubikey communication fails on startup

Antoine Beaupre wrote: > When I login in the morning, my Yubikey setup fails to let me connect > to remove SSH servers: How do you invoke gpg-agent? If it is through your first SSH invocation, gpg-agent wouldn't know the place where to ask PIN (TTY and DISPLAY). You can check if you can use

Bug#926984: [pkg-gnupg-maint] Bug#926984: Bug#926984: gnupg2 FTBFS with gcc-9: dirmngr/dns.h:1058:24: error: lvalue required as unary '&' operand

Control: tags 926984 fixed-upstream It was fixed in GnuPG 2.2.14. --

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

Hello, I managed to identify the bug and upload the fix. Thanks. --

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

Here is some information. It is garbage collection + threads bug (possibly + dynamic loading). When I reproduce the failure (by make check) on my machine, it keeps running at gauche-c-wrapper/testsuite/cwrappertest.scm. gauche-c-wrapper/testsuite/test.log having:

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

Hello, Santiago Vila wrote: > but the failure rate is extremely high (around 70% here). Thanks for the number. When I built, I didn't get failure in such a rate. I built it in my machine (a few times), and upload it to Debian, where it automatically built on several machines, you know. So

Bug#922603: lightdm-gtk-greeter: Default layout no longer has "language" in indicators

Package: lightdm-gtk-greeter Version: 2.0.6-1 Severity: normal Hello, Testing lightdm-gtk-greeter in buster, I found that default layout no longer has "language" selection in indicators. It seems that it's upstream change, but someone (like me) would depends on this feature. For me, this is

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

Control: tags 919856 fixed-upstream Norbert Preining wrote: >> The exact cause would be there is an empty cache remained in >> gnome-keyring-daemon. In my case, it is under: > [...] >> Attached is a Python script (I name it test_clear.py) to clear the cache >> entry (your specific keygrip is

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

Hello, I have been chasing the bug in gpg-agent, pinentry, libscret, and gnome-keyring. But, I forgot to consider about a simple problem of data. Sorry, I should have considered that, in the first place. The exact cause would be there is an empty cache remained in gnome-keyring-daemon. In my

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

Norbert Preining wrote: >> "no-allow-external-cache" in your .gnupg/gpg-agent.conf. > > Confirmed, that made it work. Good. > Around 12/28 there was an update of libsecret in unstable, that was more > or less when it started - hard to say, I wasn't online for some time > around new year etc. I

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

Thanks for your patience. I think I identified an issue in your debug log. Not yet catch the bug, though. The problem is caching passphrase by libsecret using gnome-keyring-daemon. I believe that possible workaround is having "no-allow-external-cache" in your .gnupg/gpg-agent.conf. Let me

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

Hello, This is a report of my case. Sorry, it doesn't have a solution for you (yet). I hope you can find some information to try. I usually invoke gpg-agent manually (because I use my own development version). This time, I enable systemd socket activation. I did test with installed gnupg

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

Hello, Thanks for your testing again. I think that your ssh invocation is the first trigger to invoke gpg-agent (by systemd). Does SSH work successfully, when gpg-agent is invoked by gpg, by running something like "gpg --card-status" before running ssh? If SSH works after "gpg --card-status",

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

Hello, It looks like similar to the bug 835394. Manual workaround to set environment variables is: $ gpg-connect-agent updatestartuptty /bye As explained in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394#43 Norbert Preining wrote: > the default was

Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

Simon McVittie wrote: > The multiarch tuple used to form ${libdir} on Debian is not always > identical to the GNU host. [...] > There's a Debian-specific option "gcc -print-multiarch" added by a > Debian patch, although not all of our compilers have a similar patch > (gcc does but clang doesn't).

Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

Hello, again, Simon McVittie wrote: > For Debian, I wonder whether we might be able to patch the script to > remove this part, which looks like the only architecture variation: > > prefix=@prefix@ > exec_prefix=@exec_prefix@ > libdir=${PKG_CONFIG_LIBDIR:-@libdir@} >

Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

Hello, Thanks for your explanation. I learn. Let me explain from GnuPG development side. We care traditional UNIXen and unusual OSes. (minimum version of) GnuPG should be able to be built and installed in early stage of development. Simon McVittie wrote: > Control: tags -1 - wontfix OK. >

Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

Simon McVittie wrote: > The wontfix tag was because upstream are not willing to add pkg-config > metadata It was. Now, it has been changed. In the next version of libgpg-error (1.33), we will offer gpg-error.pc (if nothing is going wrong). I believe this change helps cross-compiling other

Bug#911035: O: ngetty -- getty replacement - one single daemon for all consoles

Package: wnpp Severity: normal I intend to orphan the ngetty package. The package description is: Ngetty is a daemon that starts login sessions on virtual console terminals, on demand. It is a good replacement for all those getty processes started from init that, most of the time, are only

Bug#911034: O: libpcre++ -- C++ wrapper class for pcre

Package: wnpp Severity: normal I intend to orphan the libpcre++ package. The package description is: PCRE++ is a C++ wrapper-class for the library PCRE (Perl Compatible Regular Expressions). . Its class allows you to use perl alike regular expressions in your C++ applications. You can use

Bug#911033: O: libopkele -- OpenID support library in C++

Package: wnpp Severity: normal I intend to orphan the libopkele package. The package description is: libopkele is a C++ implementation of an OpenID decentralized identity system. It provides OpenID protocol handling, leaving authentication and user interaction to the implementor. The only

Bug#911032: O: libapache2-mod-auth-openid -- OpenID authentication module for Apache2

Package: wnpp Severity: normal I intend to orphan the libapache2-mod-auth-openid package. The package description is: mod_auth_openid is an authentication module for Apache2. It handles the functions of an OpenID consumer as specified in the OpenID 2.0 specification. Upstream is no longer

Bug#906545: [pkg-gnupg-maint] Bug#906545: gnupg 2.1 (in stretch) fails to fetch some ECC keys

Roger Shimizu wrote: > I'd like to leave this to pkg maintainer, whether to backport those > patches, or release a latest 2.1.x for stretch. For Debian, I think that packaging 2.2.x for stable-bpo would be easier than cherry picking patches. --

Bug#906545: [pkg-gnupg-maint] Bug#906545: gnupg 2.1 (in stretch) fails to fetch some ECC keys

Hello, Thanks for your report. Roger Shimizu wrote: > Package: gnupg > Version: 2.1.18-8~deb9u2 > Severity: normal [...] > And I confirm above issue cannot be reproduced under gnugp 2.2 > (sid version). > So maybe this can be fixed for the stretch/stable version? In the upstream, it was fixed

Bug#898552: [pkg-gnupg-maint] Bug#898552: gnupg: wrong key in danish translation for --update-trustdb option

Hello, Jonas Smedegaard writes: > When running "gpg --update-trustdb" in a da_DK.UTF-8 locale, I am > presented with the following options: [...] > Last option "a" to "afslut" (i.e. "quit") does not work. > > Instead pressing "q" quits. Thanks. We also have another bug for " m

Bug#894983: gnupg2: CVE-2018-9234: Able to certify public keys without a certify key present when using smartcard

cations that occurred only with access to a > | signing subkey. This description sounds not accurate for me. In my opinion, the certifications are invalid. The smartcard problem was introduced by the commits of mine: commit fbb2259d22e6c6eadc2af722bdc52922da348677 Author: NIIBE

Bug#891663: [pkg-gnupg-maint] Bug#891663: [PATCH] libgpg-error: Add support for the riscv64 architecture

Hello, Thanks for your report. Karsten Merker wrote: > AIUI, libgpg-error requires a per-architecture header file > "src/syscfg/lock-obj-pub..h", which upstream doesn't > provide for riscv64. As upstream, the change is pushed by the commit: 596c0d7 --

Bug#878952: [pkg-gnupg-maint] Bug#878952: scdaemon: avoid ptrace on scdaemon?

Daniel Kahn Gillmor wrote: > Package: scdaemon > Version: 2.2.1-2 > Severity: normal [...] > Should we add a similar "prctl(PR_SET_DUMPABLE, 0)" to scdaemon as > well? I think we should. Or else, someone might confuse as if the specific attack condition is somehow

Bug#878812: [pkg-gnupg-maint] Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

Fixed in master of GnuPG git repo: 995c46ea77cff5b99b2fca17b547d6525a4f227e https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=995c46ea77cff5b99b2fca17b547d6525a4f227e It will be backported to 2.2 (STABLE-BRANCH-2-2). --

Bug#878812: [pkg-gnupg-maint] Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

Thanks Guido for the log. Now, I managed to replicate the problem. I created /tmp/0xDF6D76C44D696F6B from debian-keyring. The key is expired. And then, I get the key from keyserver. Now, we have two keyrings. In this situation, it hits bug_at. == $ /usr/bin/gpg

Bug#878812: [pkg-gnupg-maint] Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

Guido Günther wrote: >> > #4 0x556a0f29306f bug_at (gpg) >> > #5 0x556a0f243c1e do_we_trust (gpg) >> > #6 0x556a0f243fff find_and_check_key (gpg) >> > #7 0x556a0f2455b6 find_and_check_key (gpg)

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

intrigeri wrote: > Can you please take a look, and maybe attach an updated patch? OK. Attached is updated patch for gcr to fix this issue, by simply supplying parent's environ untouched, intended to be put under debian/patches/. While this patch fixes the particular issue,

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson wrote: > I tried this. I applied this change and I can confirm that I have > seen this message in all the failing tests I looked at. OK. > With that patch, I can still reproduce the failure. The passing tests > succeed and exit, leaving a failing

Bug#789927: Anthy library breakage

Osamu Aoki wrote: > If what NOKUBI Takatsugu's comment is correct, I wonder why anthy is > upgraded without coordinating with key users: > ibus > uim > fcitx > > (Please note these have many dependence packages so the testing > migration is slow if package version dependency

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson wrote: >> The invocation of gpg-agent by gpg frontend has an inherent race in the >> current implementation; When gpg frontend invokes gpg-agent, after >> spawning gpg-agent, gpg frontend tries to connect five times with one >> second intervals. When

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

Control: reassign -1 gcr NIIBE Yutaka <gni...@fsij.org> wrote: > Now, I guess that the problem is in the implementaiton of libgcr library. > > While I'm reading gcr-3.20.0/gcr/gcr-gnupg-process.c, getting the source > by apt source libgcr-base-3-1, I su

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

intrigeri wrote: > So I'm reassigning this to gnupg-agent, where the root cause of the > problem seems to live. It seems for me that gpg-agent can not do anything for this bug. I tried to locate the invocation of "gpg" from seahorse. I figured out that when this issue

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson wrote: >gpg --ignore-time-conflict > --no-options > --no-default-keyring > --homedir > /tmp/apt-key-gpghome.yLlu1bwwPI > --no-auto-check-trustdb > --trust-model > always > --batch > --import Thank you

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

Thanks for your reply. intrigeri wrote: > Anything else I should try? Something about $GPG_TTY, or starting > Seahorse from GNOME Terminal (instead of the GNOME Overview), perhaps? It seems that the most likely case is the following scenario: (1) Upon login, gpg-agent

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

Hello, intrig...@debian.org writes: > gpg-agent[11835]: DBG: error calling pinentry: Inappropriate ioctl for > device This error message is related to DISPLAY or GPG_TTY. I guess that pinentry is invoked with no DISPLAY and no GPG_TTY. It failed to open window, and then, it failed at

Bug#866964: Fwd: mpi_set_secure leads to heap corruption

point for concrete example for those routines. That's for constant-time computation. Debian-bug-id: 866964 Suggested-by: Mark Wooding <m...@distorted.org.uk> Signed-off-by: NIIBE Yutaka <gni...@fsij.org> (backport from master commit: 5feaf1cc8f22c1f8d19a34850d86fe190f1432e2) 1 file chang

Bug#862032: [pkg-gnupg-maint] Bug#862032: [scdaemon] yubikey 4 stops working after upgrade from 2.1.18-6

Shin Ice writes: > Package: scdaemon > Version: 2.1.18-7 > Severity: important > > --- Please enter the report below this line. --- > > Hi there, > > after upgrading to 2.1.18-7 my yubikey stops working again. > In difference to #852702 I can't get serious output to append

Bug#810417: [pkg-gnupg-maint] Bug#810417: gnupg: please switch to libusb 1.0

Daniel Kahn Gillmor wrote: > So i'm inclined to address this by just doing > --disable-smartcard-support for gnupg1 for debian. I think this would > adequately reflect upstream's preferred maintenance posture for GnuPG > smartcard access (that scdaemon is preferred), and

Bug#703062: please add udev rules for cardman 4040

Hello, Sorry to reply old bug report. On Thu, 14 Mar 2013 21:13:38 +0100 Reinhard Müller wrote: > Package: gnupg > Version: 1.4.11-3 > > Dear Maintainer, > > the Omnikey CardMan 4040 is a nice PCMCIA smart card reader supported by gpg. > It would work out of the box *if*

Bug#855056: [pkg-gnupg-maint] Bug#855056: scdaemon: Duplicate udev lines in debian/scdaemon.udev file

Hello, Thank you for your report. Teemu Likonen wrote: > Scdaemon package version 2.1.18-5 introduced new udev rules for > Nitrokey and Yubikey. All the Nitrokey lines were already in the file > so there are now duplicates. My bad. I didn't check well when I add the entries

Bug#854595: [pkg-gnupg-maint] Bug#854595: scdaemon: Yubikey smartcards (maybe others) are not recognized after update from 2.1.17-4 to 2.1.18-4

Hello, Thank you for your reporting. Camille MONCELIER wrote: > After updating gnupg2 to 2.1.18-4, I'm unable to use my gpg keys stored on a > Yubikey. > > I can easily reproduce the problem like this: If you don't need PC/SC service, and when it can be your option, please

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

Antoine Beaupré writes: > This reminds me - it sure looks like pcscd was crashing back > there. Should I revert back to using pcscd to try and reproduce the > problem and file a pcscd bug about this? Yes. I think that this is a different problem, and it's pcscd issue. --

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

Thanks a lot for your confirmation. Antoine Beaupré writes: >> If this works, the udev line should be included into scdaemon package in >> future, so that each user doesn't need to configure. > > I confirm the udev hack works. No, this is not a hack. This is a configuration

Bug#854359: [pkg-gnupg-maint] Bug#854359: gnupg: always fails when --recv-keys

Roger Shimizu <rogershim...@gmail.com> wrote: > On Wed, Feb 8, 2017 at 9:02 PM, NIIBE Yutaka <gni...@fsij.org> wrote: >> >> The keyservers have a problem and the current implementation of dirmngr >> doesn't like this particular problem. > > I think this

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

Hello, Thank you for reporting in detail. Antoine Beaupre wrote: > In Bug#854005, I have described a distinct issue I have experience > with my Yubikey since the upgrade of the GnuPG suite from 2.1.17 to > 2.1.18, and in the case of pcscd, from 1.8.19-1 to 1.8.20-1. [...] >

Bug#854359: [pkg-gnupg-maint] Bug#854359: gnupg: always fails when --recv-keys

Thanks a lot for your testing. I think that I located the issue. Roger Shimizu wrote: > $ dirmngr --server --homedir=/run/user/1000/test [...] > dirmngr[25354.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': > 'ip-209-135-211-141.ragingwire.net' [...] >

Bug#854359: [pkg-gnupg-maint] Bug#854359: gnupg: always fails when --recv-keys

Hello, Roger, Roger Shimizu wrote: > While trying to using caff to sign keys, I find I cannot retrieve other > people's keys. So for debug, I tried to get my own key by: > > $ gpg -vvv --debug-all --recv-keys 0x6C6ACD6417B3ACB1 It is the failure of dirmngr which does

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Hello, Thank you very much for the discussion. I appreciate the viewpoints from users. No, it's not frustrating at all. Daniel Kahn Gillmor wrote: > Can we offer a user experience that doesn't involve them making a choice > between two indistinguishable options? > > A

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka <gni...@fsij.org> wrote: >> This works. Actually, this is not mandatory. It is OK to have pcscd >> package installed **if not used**. > > I take it you mean t

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Daniel Kahn Gillmor wrote: > To be concrete, i believe the two proposed solutions for users are: [...] > Do not use CCID > --- > > echo disable-ccid:0:1 | gpgconf --change-options scdaemon > Correct. The things for PCSC is a bit complicated. Let me

Bug#852702: [pkg-gnupg-maint] Bug#852702: [gnupg2] gpg: OpenPGP card not available: No such device after upgrade to 2.1.18-3

Shin Ice writes: > Package: gnupg2 > Version: 2.1.18-3 > Severity: important > > --- Please enter the report below this line. --- > > Hi, > > after upgrading gnupg2 (and related) to version 2.1.18-3 the yubikey 4 > can't be used. On a different system (still sid) with

Bug#854005: [pkg-gnupg-maint] Bug#854005: Bug#854005: ssh-agent no longer works

NIIBE Yutaka <gni...@fsij.org> wrote: > Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC > is somehow broken in 2.1.18. Please try with internal CCID driver of > GnuPG. I mean, don't use PC/SC service. Or, please add: disable-ccid in your scdae

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Wouter Verhelst wrote: > wouter@gangtai:~$ cat .gnupg/scdaemon.conf > reader-port O2 Micro Oz776 01 00 > log-file /home/wouter/.gnupg/scdaemon.log > pcsc-driver libpcsclite.so Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC is somehow broken in 2.1.18.

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Hello, Thanks to dkg to explicitly CC me. On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote: > Since a recent upgrade, gnupg-agent no longer finds the authentication > (SSH) key on my OpenPGP smartcard: > > wouter@gangtai:~$ gpg --card-status It should be an issue of scdaemon. For

Bug#841143: [pkg-gnupg-maint] Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup)

Daniel Kahn Gillmor wrote: > fwiw, i don't want the behavior to be exactly the same as upstream -- i > don't want gpg-agent to wake up every few seconds on platforms where it > shouldn't need to, for example :/ Yes, I understand your purpose. +1 from me. Actually, I was

Bug#841143: race condition

Hello, I'm sorry I didn't put the context. I am a developer of GnuPG and nPth. I join the Debian GnuPG mailing list, so that development can go well. Thus, I receive your bug report. (I also maintain some packages in Debian but most are not related to GnuPG.) Since I felt that there is a kind

Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup)

Ian Jackson wrote: > I think that at least my patch > [PATCH 4/4] gpg agent lockup fix: Interrupt main loop when > active_connections_value==0 > is very likely a fix to an actual race. [...] > I would like this bug fixed in stretch. I think that this issue is

Bug#850686: npth can make reentrant calls to sigaddset

Hello, I am reading GNU C library manual. 24.7.2 Signal Sets: https://www.gnu.org/software/libc/manual/html_node/Signal-Sets.html All functions have MT-Safe | AS-Safe | AC-Safe attributes. So, I wonder what your problem is, and what you are suggesting. > This code is not properly

Bug#850808: emacs25-common: install-info dependency

Package: emacs25-common Version: 25.1+1-3 Severity: important Dear Maintainer, I did clean install of Debian Stretch and found that M-x info doesn't work well (because of empty dir entries). That's because install-info was not installed when I installed Emacs25 (so, I manually installed

Bug#846168: [pkg-gnupg-maint] Bug#846168: gnupg2: --export-ssh-key is not working

On 11/29/2016 06:46 AM, Hans Freitag wrote: > Exporting ssh2 keys is not working with gnupg 2.1.16 > > $ gpg2 --export-ssh-key SOMEKEYID > gpg: O j: Assertion "ret_found_key == NULL || ret_keyblock != NULL" > in lookup failed (../../g10/getkey.c:3677) > Abgebrochen Thank you for bug

Bug#811096: Re-open the bug (libpam-poldi: missing pam configuration)

reopen 811096 thanks In 0.4.2+git20161107.16912be-1, I closed this bug by offering the config, but it resulted bad configuration. It's: Part of /etc/pam.d/common-auth # here are the per-package modules (the "Primary" block) auth[success=2 default=ignore]

Bug#811096: libpam-poldi: missing pam configuration

Hello, Thank you for your bug report. On 01/16/2016 12:50 AM, Andrew Gallagher wrote: > Package: libpam-poldi > Version: 0.4.2+git20151221.338f78b-1 > Severity: important > Tags: patch > > Dear Maintainer, > > poldi requires the following extra file before it will be active in pam. It > will

Bug#806940: [pkg-gnupg-maint] Bug#806940: Bug#806940: gpgv-static possible?

On 11/09/2016 11:22 AM, Daniel Kahn Gillmor wrote: > ../common/libcommon.a(libcommon_a-stringhelp.o): In function `get_pwdir': > ./build-gpgv-static/common/../../common/stringhelp.c:378: warning: Using > 'getpwnam' in statically linked applications requires at runtime the shared > libraries from

Bug#840697: modemmanager: interferes NeuG TRNG

Package: modemmanager Version: 1.6.2-1 Severity: normal Dear Maintainer, I develop/use/sell USB TRNG (True Random Number Generator) device which works as an USB CDC/ACM device. The intention is that users can get the random bytes from /dev/ttyACM0 with no drivers installed. Unfortunately

Bug#840312: [pkg-gnupg-maint] Bug#840312: scdaemon: Add udev rule for Fujitsu Siemens smart card reader?

On 10/10/2016 10:11 PM, Petter Reinholdtsen wrote: > Hi. I got a smart card reader from Fujitsu Siemens that is not > recognized by scdaemon. Perhaps it should be added to the udev rules.d > file? Thanks for the report. If it works well, it should be added. > Perhaps it is better to try to

Bug#839614: gnupg2: what happened to scdaemon?

I replied only to the pkg-gnupg-maint list. I send again to the bug tracker. On 10/03/2016 06:44 AM, Kevin Gallagher wrote: > I updated packages at some point and now my smartcards don't work, > because scdaemon has disappeared. In the migration of gnupg2 to gnupg,

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

On 08/05/2016 10:52 PM, Petter Reinholdtsen wrote: > fbx@freedombox:~$ sudo chmod a+rw /dev/bus/usb/001/00* > fbx@freedombox:~$ gpg2 --card-status > Reader ...: 08E6:3438:C4CC14F3:0 > Application ID ...: D27600012401020100054202 > Version ..: 2.1 > Manufacturer .:

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

On 08/05/2016 09:01 PM, Petter Reinholdtsen wrote: > I decided to test again using an FreedomBox image to reduce the > difference since my initial testing. First I tested using version > 2.1.11-7 in Debian testing, and then using version 2.1.14-1 in Debian > experimental. Both fail. First the

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

On 08/03/2016 10:10 PM, Petter Reinholdtsen wrote: > My original test was done using a Freedombox image, which was armel. > > Todays test was done using some random RPi and SD card I found on my > desk and I did not notice it was using a different architecture. I can > try again on armel, if you

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

On 08/03/2016 09:03 PM, Petter Reinholdtsen wrote: > Thank you. I just tested on a Raspberry Pi using the gnupg2/scdaemon > version 2.1.14-2 in Debian experimental, and this now segfaults when I > try 'gpg2 --card-status'. But for some reason I can't get info from > valgrind, so here is the

  1   2   3   >