Andreas Metzler wrote:
> Package: gnupg2
> Version: 2.4.5-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>From GnuPG, I factored out spawn functions into libgpg-error (mainly for
support of Windows 64-bit). Since libgpg-error
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
>
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 388
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 n
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 direct
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 c
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.
--
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
> expiration, n
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 descript
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
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 wo
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) surpris
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 An
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
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 "ex
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 t
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
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 elo
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]
>
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 so
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 '
* import
round
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
c
Control: merge 930492
Sorry, I should have installed newer mingw-w64-tools. I learned after
writing the report.
--
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 u
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
ev
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 directives
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 n
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 you
Control: tags 926984 fixed-upstream
It was fixed in GnuPG 2.2.14.
--
Hello,
I managed to identify the bug and upload the fix. Thanks.
--
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:
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 far
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 imp
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 har
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 c
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
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 exp
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 to
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", t
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 pinentry-gn
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).
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@}
> PKG_CONFIG_PAT
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.
>
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 pack
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 ta
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 it
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 us
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 act
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.
--
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 b
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 = back to the ma
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 Yutaka
Date: M
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
--
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 different for scdaemon.
--
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).
--
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 --no-d
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)
>> >
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, I think that more clea
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 test (so far, only one out of a
> t
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 is correctly record
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 a machine is busy enough and sched
Control: reassign -1 gcr
NIIBE Yutaka 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 suspect the function
> _gcr_gnupg_proc
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 occurred (replacing gpg by
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 for minimizing. I'd like to clarif
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 is invoked with no DISPL
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 isatty
cry_mpi_ec_mul_point for concrete example for those
routines. That's for constant-time computation.
Debian-bug-id: 866964
Suggested-by: Mark Wooding
Signed-off-by: NIIBE Yutaka
(backport from master commit:
5feaf1cc8f22c1f8d19a34850d86fe190f1432e2)
1 file changed, 1 insertion(+), 1 deletion(-
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 to the bug
> report sinc
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 it would remove the
> dep
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* only normal users had
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 for Nitrokey. Well
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
try using the interna
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.
--
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 needed.
It seems fo
Roger Shimizu wrote:
> On Wed, Feb 8, 2017 at 9:02 PM, NIIBE Yutaka wrote:
>>
>> The keyservers have a problem and the current implementation of dirmngr
>> doesn't like this particular problem.
>
> I think this conclusion is just the same as upstream.
> So a
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.
[...]
> anything i can do to
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'
[...]
> dirmngr[25354.0]: resolving 'ip-20
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 actual key retrieval.
In my
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 few ideas (no idea how pl
Daniel Kahn Gillmor wrote:
> On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka wrote:
>> This works. Actually, this is not mandatory. It is OK to have pcscd
>> package installed **if not used**.
>
> I take it you mean that the system-wide pcscd service itself needs to be
&
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 describe.
> Do not use PCSC
>
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 version 2.1.16-3
> all works
NIIBE Yutaka 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 scdaemon.conf if you wan
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. Please try with inte
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 2.1.18,
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 inspired
by your patches
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 o
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 a bug in the patches of
debian/pat
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 reent
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
install-
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 repo
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] pam_unix.so
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 al
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
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 modemm
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 rec
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, scdaemon'
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 .: ZeitCo
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 tes
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
1 - 100 of 293 matches
Mail list logo