Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #179836 > unrolled thread

Almost all gpg2 operations hang after upgrade to stretch/testing

Back to article view | Back to linux.debian.user

Contents

  Almost all gpg2 operations hang after upgrade to stretch/testing Nathanael Schweers <Nathanael.Schweers@outdooractive.com> - 2017-04-06 10:10 +0200
    Re: Almost all gpg2 operations hang after upgrade to stretch/testing Nicolas George <george@nsup.org> - 2017-04-06 10:20 +0200
      Re: Almost all gpg2 operations hang after upgrade to stretch/testing Nathanael Schweers <Nathanael.Schweers@outdooractive.com> - 2017-04-06 10:30 +0200
        Re: Almost all gpg2 operations hang after upgrade to stretch/testing Nicolas George <george@nsup.org> - 2017-04-06 10:40 +0200
          Re: Almost all gpg2 operations hang after upgrade to stretch/testing Nathanael Schweers <Nathanael.Schweers@outdooractive.com> - 2017-04-06 10:50 +0200
          Re: Almost all gpg2 operations hang after upgrade to stretch/testing Darac Marjal <mailinglist@darac.org.uk> - 2017-04-06 10:50 +0200
            Re: Almost all gpg2 operations hang after upgrade to stretch/testing Richard Owlett <rowlett@cloud85.net> - 2017-04-06 13:30 +0200
              Re: Almost all gpg2 operations hang after upgrade to stretch/testing Curt <curty@free.fr> - 2017-04-06 16:50 +0200
                Re: Almost all gpg2 operations hang after upgrade to stretch/testing Richard Owlett <rowlett@cloud85.net> - 2017-04-06 20:50 +0200
                  Re: Almost all gpg2 operations hang after upgrade to stretch/testing Brian <ad44@cityscape.co.uk> - 2017-04-06 21:50 +0200
                  Re: Almost all gpg2 operations hang after upgrade to stretch/testing Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-13 15:50 +0200
                    Re: Almost all gpg2 operations hang after upgrade to stretch/testing <tomas@tuxteam.de> - 2017-04-13 16:30 +0200
                      Re: Almost all gpg2 operations hang after upgrade to stretch/testing John Hasler <jhasler@newsguy.com> - 2017-04-13 16:50 +0200
                        Re: Almost all gpg2 operations hang after upgrade to  stretch/testing Celejar <celejar@gmail.com> - 2017-04-13 18:00 +0200
                          Re: Almost all gpg2 operations hang after upgrade to stretch/testing John Hasler <jhasler@newsguy.com> - 2017-04-13 18:20 +0200
                            Re: Almost all gpg2 operations hang after upgrade to stretch/testing GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 18:40 +0200
                        Re: Almost all gpg2 operations hang after upgrade to stretch/testing <tomas@tuxteam.de> - 2017-04-14 10:50 +0200

#179836 — Almost all gpg2 operations hang after upgrade to stretch/testing

Hi fellow debian users,


after upgrading a system running debian jessie/stable, I performed an
upgrade to stretch/testing, which went fairly well for the most part.  I
had a few issues, but nothing I couldn’t handle.


I have unresolved issues with gpg though.  This is what happened so far:

Most operations on gpg2 gave me a message that the old keys will be
migrated.  The problem is: this seemed to hang indefinitely, without
consuming many resources.  As I couldn’t find a solution, I copied my
whole ~/.gnupg directory to a different machine, where the migration had
been successful for other keys (created and used on debian jessie, then
migrated to archlinux, gpg2 version 2.1.19).  This worked, and I copied
~/.gnupg back again.  The problem is: this didn’t resolve my issue.  The
migrated keys work fine on the archlinux machine where I performed the
migration, yet practically all operations on my debian machine simply
hang without much output as to what is supposed to happen or consuming
resources.  While writing this mail I realized that the slightly older
version of gpg2 on stretch (2.1.18) may be an issue.  Can this be the case?


For instance gpg2 -K --verbose prints "gpg: using pgp trust model", but
then just hangs.  Trying to decrypt a file via gpg2 -d --verbose
<filename> simply outputs what my public key is (I think a fingerprint
is listed), and then also hangs.


gpg2 -k on the other hand works.


As I have a backup of my complete home directory from before the system
upgrade, I still have access to ~/.gnupg as it was before the upgrade,
should that be necessary.


Does anyone have an idea what the problem might be?


Best regards,

Nathanael Schweers

[toc] | [next] | [standalone]

#179837

[Multipart message — attachments visible in raw view] — view raw

Le septidi 17 germinal, an CCXXV, Nathanael Schweers a écrit :
> For instance gpg2 -K --verbose prints "gpg: using pgp trust model", but
> then just hangs.  Trying to decrypt a file via gpg2 -d --verbose
> <filename> simply outputs what my public key is (I think a fingerprint
> is listed), and then also hangs.
> 
> gpg2 -k on the other hand works.

Is the GPG agent running correctly?

You could try strace to see what exactly is blocking.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#179838

When I run strace gpg2 -d notes.org.gpg strace stops output in mid
syscall(?)

[... cut ...]

open("/usr/share/locale/en_US/LC_MESSAGES/libgpg-error.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
getuid()                                = 1000
stat("/run/user/1000", {st_mode=S_IFDIR|0700, st_size=160, ...}) = 0
getuid()                                = 1000
stat("/run/user/1000/gnupg", {st_mode=S_IFDIR|0700, st_size=140, ...}) = 0
getuid()                                = 1000
stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600,
st_size=0, ...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 6
stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600,
st_size=0, ...}) = 0
connect(6, {sa_family=AF_UNIX,
sun_path="/run/user/1000/gnupg/S.gpg-agent"}, 34) = 0
read(6,


It seems to me that strace shouldn’t just stop in the middle of an
argument list, but I might be wrong.


I ran ps in a different terminal to see what gpg stuff is running:

$ ps ax | grep -i gpg
 5230 pts/1    S+     0:00 strace gpg2 -d notes.org.gpg
 5232 pts/1    SL+    0:00 gpg2 -d notes.org.gpg
 5260 ?        SLs    0:00 /usr/bin/gpg-agent --daemon
--enable-ssh-support --use-standard-socket --write-env-file
/run/user/1000/gpg-agent.info
 5307 pts/4    S+     0:00 grep --color=auto --exclude-dir=.bzr
--exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg
--exclude-dir=.svn -i gpg


Also the socket file seems fine:

$ ls -l /run/user/1000/gnupg/S.gpg-agent
srw------- 1 schweers schweers 0 Apr  6 08:54
/run/user/1000/gnupg/S.gpg-agent


On 04/06/2017 10:15 AM, Nicolas George wrote:
> Le septidi 17 germinal, an CCXXV, Nathanael Schweers a écrit :
>> For instance gpg2 -K --verbose prints "gpg: using pgp trust model", but
>> then just hangs.  Trying to decrypt a file via gpg2 -d --verbose
>> <filename> simply outputs what my public key is (I think a fingerprint
>> is listed), and then also hangs.
>>
>> gpg2 -k on the other hand works.
> Is the GPG agent running correctly?
>
> You could try strace to see what exactly is blocking.
>
> Regards,
>

[toc] | [prev] | [next] | [standalone]

#179839

[Multipart message — attachments visible in raw view] — view raw

Le septidi 17 germinal, an CCXXV, Nathanael Schweers a écrit :
> connect(6, {sa_family=AF_UNIX,
> sun_path="/run/user/1000/gnupg/S.gpg-agent"}, 34) = 0
> read(6,
> 
> It seems to me that strace shouldn’t just stop in the middle of an
> argument list, but I might be wrong.

It is perfectly normal. strace will print the contents of the buffer
that has just been read, but for that, it must wait that the syscall
finished.

Thus, we know that the problem is the agent not responding at all to the
client. stracing the agent may give more information.

>  5307 pts/4    S+     0:00 grep --color=auto --exclude-dir=.bzr
> --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg
> --exclude-dir=.svn -i gpg

As a side note, you might be interested to know "git grep"; it greps
tracked files but not the repository, and even works when working out of
tree.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#179840

Nicolas George <george@nsup.org> writes:

> Le septidi 17 germinal, an CCXXV, Nathanael Schweers a écrit :
>> connect(6, {sa_family=AF_UNIX,
>> sun_path="/run/user/1000/gnupg/S.gpg-agent"}, 34) = 0
>> read(6,
>> 
>> It seems to me that strace shouldn’t just stop in the middle of an
>> argument list, but I might be wrong.
>
> It is perfectly normal. strace will print the contents of the buffer
> that has just been read, but for that, it must wait that the syscall
> finished.
>
> Thus, we know that the problem is the agent not responding at all to the
> client. stracing the agent may give more information.

Ah, thanks a lot for that tip!  I went again and looked how the agent is
started, as it immediately respawned whenever I sent SIGTERM to it.

Turns out, I still had a systemd user service, which started the agent
using environment variables and the like.  As soon as I had removed that
service and performed a reboot (I’m not sure what exactly would have to
be restarted), everything worked!

At any rate, you really saved my day, thank you so much!

>
>>  5307 pts/4    S+     0:00 grep --color=auto --exclude-dir=.bzr
>> --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg
>> --exclude-dir=.svn -i gpg
>
> As a side note, you might be interested to know "git grep"; it greps
> tracked files but not the repository, and even works when working out of
> tree.

Those seem to be the default arguments for grep or something.  I use
oh-my-zsh, it may come from there.  Also, I know about git grep, yet
hardly use it.  Maybe I should ;)

Regards,
Nathanael Schweers

[toc] | [prev] | [next] | [standalone]

#179841

On Thu, Apr 06, 2017 at 10:32:04AM +0200, Nicolas George wrote:
>Le septidi 17 germinal, an CCXXV, Nathanael Schweers a écrit :
>> connect(6, {sa_family=AF_UNIX,
>> sun_path="/run/user/1000/gnupg/S.gpg-agent"}, 34) = 0
>> read(6,
>>
>> It seems to me that strace shouldn’t just stop in the middle of an
>> argument list, but I might be wrong.
>
>It is perfectly normal. strace will print the contents of the buffer
>that has just been read, but for that, it must wait that the syscall
>finished.
>
>Thus, we know that the problem is the agent not responding at all to the
>client. stracing the agent may give more information.
>
>>  5307 pts/4    S+     0:00 grep --color=auto --exclude-dir=.bzr
>> --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg
>> --exclude-dir=.svn -i gpg
>
>As a side note, you might be interested to know "git grep"; it greps
>tracked files but not the repository, and even works when working out of
>tree.

I can also recommend "ag" (debian package: silversearcher-ag), which is
astoundingly fast as searching text. It ignores VCS directories as
above, it searches compressed files without needing to be told (so no
need for zgrep, bzgrep etc), and it mmap()s files for very quick
scanning. 

>
>Regards,
>
>-- 
>  Nicolas George



-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#179854

On 04/06/2017 03:42 AM, Darac Marjal wrote:
> [snip]
> I can also recommend "ag" (debian package: silversearcher-ag), which
> is astoundingly fast as searching text. It ignores VCS directories
> as above, it searches compressed files without needing to be told
> (so no need for zgrep, bzgrep etc), and it mmap()s files for very
> quick scanning.

Reading the man page prompted further investigation.
Attempted a web search examples or tutorials with only enough success to 
tantalize me more. They were pages about other topics which had comments 
suggesting that the page's author try silversearcher-ag.
Could you point me to such a page whose primary focus is silversearcher-ag?

TIA

[toc] | [prev] | [next] | [standalone]

#179862

On 2017-04-06, Richard Owlett <rowlett@cloud85.net> wrote:

> Could you point me to such a page whose primary focus is silversearcher-ag?
>

"silversearcher-ag tutorial" as search terms brought me rapidly to this
page.

http://conqueringthecommandline.com/book/ack_ag

[toc] | [prev] | [next] | [standalone]

#179874

On 04/06/2017 09:40 AM, Curt wrote:
> On 2017-04-06, Richard Owlett <rowlett@cloud85.net> wrote:
>
>> Could you point me to such a page whose primary focus is silversearcher-ag?
>>
>
> "silversearcher-ag tutorial" as search terms brought me rapidly to this
> page.
>
> http://conqueringthecommandline.com/book/ack_ag

That demonstrated something, but not what might have been expected.
I've been avoiding Google for personal reasons and using DuckDuckGo 
instead. DuckDuckGo does not return that page - I'd assumed the two 
search engines were equally productive.

As to the content of the page got no more than reading the man page. BUT 
how its author approached the subject hints that the tool is aimed a 
different mind set. Thanks for the feedback.

[toc] | [prev] | [next] | [standalone]

#179877

On Thu 06 Apr 2017 at 13:41:15 -0500, Richard Owlett wrote:

> On 04/06/2017 09:40 AM, Curt wrote:
> >On 2017-04-06, Richard Owlett <rowlett@cloud85.net> wrote:
> >
> >>Could you point me to such a page whose primary focus is silversearcher-ag?
> >>
> >
> >"silversearcher-ag tutorial" as search terms brought me rapidly to this
> >page.
> >
> >http://conqueringthecommandline.com/book/ack_ag
> 
> That demonstrated something, but not what might have been expected.

I love the technique. It seems to say something, but doesn't.

Something was demontrated. Quite what - you will never get to know,

Something was expected. You will not be informed.

Talk about contentless postings. The sum of human knowledge has not been
improved.

> I've been avoiding Google for personal reasons and using DuckDuckGo instead.

"personal reasons" is about as wide as it gets as a reason. It's also as
squishy as the previous responses.

> DuckDuckGo does not return that page - I'd assumed the two search engines
> were equally productive.
> 
> As to the content of the page got no more than reading the man page. BUT how
> its author approached the subject hints that the tool is aimed a different
> mind set. Thanks for the feedback.

Mindsets. That's the problem.

[toc] | [prev] | [next] | [standalone]

#180061

On Thursday 06 April 2017 19:41:15 Richard Owlett wrote:
> I've been avoiding Google for personal reasons and using DuckDuckGo
> instead. DuckDuckGo does not return that page - I'd assumed the two
> search engines were equally productive.

No, they are not.  That is why some of us sadly use Google - it has a LOT of 
faults and problems, but it is a superb search engine.

Morally, of course, DuckDuckGo wins.

Lisi

[toc] | [prev] | [next] | [standalone]

#180062

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 13, 2017 at 02:43:48PM +0100, Lisi Reisz wrote:
> On Thursday 06 April 2017 19:41:15 Richard Owlett wrote:
> > I've been avoiding Google for personal reasons and using DuckDuckGo
> > instead. DuckDuckGo does not return that page - I'd assumed the two
> > search engines were equally productive.
> 
> No, they are not.  That is why some of us sadly use Google - it has a LOT of 
> faults and problems, but it is a superb search engine.
> 
> Morally, of course, DuckDuckGo wins.

Part of Google's perceived superiority is that it "learns to know you": a
couple of search terms thrown in, for Google is "search terms + context",
while for DDG, the context is missing.

I've a nice anecdote for you: a friend of mine is doing her master's
thesis in molecular biology and had a bunch of articles she researched
from her PC at work (via Google). At home, she wanted to look up something
and didn't have the refs handy, so she repeated the search... only to
get totally different results, more suitable to an interested layperson.

Her box at the lab had a different personality than the one at home
(we had a talk about this a couple of days before, and she's an incredibly
smart person, so that's why she noticed).

Since then she's a DuckDuckGo user :-)

What's the problem? Using DuckDuckGo "right" entails being aware of
that and putting slightly more work into establishing context with
additional search terms. DDG won't equal Google any time (much less
raw power), but "training" your querying skills helps reduce most
of the difference in quality. Google makes you lazy because "it
already knows what you're looking for".

I switched from Google to DDG a couple of years ago, falling back
to Google when "there must be a hit for that, dammit". From one
to two fall-backs weekly, I'm now solidly below once a month.

So if you want to do yourself a favour (in terms of skills and
autonomy), my advice would be to always try first DDG, then Google,
and try to think about how the differences come about.

Enjoy
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljviUMACgkQBcgs9XrR2kYBbwCdHylQwi0jcfDUL4HJr/HWpzhT
Zm0Anj4MpRY4p2kVhaVGbDzdDgWz2Moa
=hm50
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#180063

tomas writes:
> Part of Google's perceived superiority is that it "learns to know
> you": a couple of search terms thrown in, for Google is "search terms
> + context", while for DDG, the context is missing.

Google does not "learn to know you" if you block all its scripts and
cookies, which is how I use it.  It's still vastly superior to the Duck.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#180070 — Re: Almost all gpg2 operations hang after upgrade to stretch/testing

On Thu, 13 Apr 2017 09:43:26 -0500
John Hasler <jhasler@newsguy.com> wrote:

> tomas writes:
> > Part of Google's perceived superiority is that it "learns to know
> > you": a couple of search terms thrown in, for Google is "search terms
> > + context", while for DDG, the context is missing.
> 
> Google does not "learn to know you" if you block all its scripts and
> cookies, which is how I use it.  It's still vastly superior to the Duck.

Well, it could in theory still try to build profiles of searchers via
IP addresses [I understand that this wouldn't be that reliable, due to
things like proxies and NAT]. Do we know for a fact whether it does [or
does not]?

Celejar

[toc] | [prev] | [next] | [standalone]

#180073

tomas writes:
> Part of Google's perceived superiority is that it "learns to know
> you": a couple of search terms thrown in, for Google is "search terms
> + context", while for DDG, the context is missing.

I wrote:
> Google does not "learn to know you" if you block all its scripts and
> cookies, which is how I use it.  It's still vastly superior to the Duck.

Celejar writes:
> Well, it could in theory still try to build profiles of searchers via
> IP addresses [I understand that this wouldn't be that reliable, due to
> things like proxies and NAT]. Do we know for a fact whether it does
> [or does not]?

I see no evidence that it does, nor do I see any reason why it would
bother.  At least 99% of its users accept the cookies and scripts.  Why
would it care about a few weirdos like me given that it wouldn't work
very well anyway?
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#180076

John Hasler:
> I see no evidence that it does, nor do I see any reason why it would
> bother.  At least 99% of its users accept the cookies and scripts.  Why
> would it care about a few weirdos like me given that it wouldn't work
> very well anyway?

It is reporting on weirdos like you that paves its way to alot of
uncharted territory of invasive identification.  IOW weirdo IPs are of
interest.
Have you tried startpage.com  They sell "secure" email service but it
seems that is about the only thing they sell.  A bit of a pain but may
be worth your weirdo while.  They search google for you and provide you
with safe links of documents and media.


-- 
 "The most violent element in society is ignorance" rEG

"Who died and made you the superuser?"  Brooklinux

[toc] | [prev] | [next] | [standalone]

#180116

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 13, 2017 at 09:43:26AM -0500, John Hasler wrote:
> tomas writes:
> > Part of Google's perceived superiority is that it "learns to know
> > you": a couple of search terms thrown in, for Google is "search terms
> > + context", while for DDG, the context is missing.
> 
> Google does not "learn to know you" if you block all its scripts and
> cookies, which is how I use it.  It's still vastly superior to the Duck.

Others have already chimed in. My reading proposal:

  https://panopticlick.eff.org/

It's Google's core business. They even invest a lot of money in clients
(Mozilla, Chrome, Android). Why should they refrain from that?

When I say they "know" you I mean not personally, but statistically. It's
not some Evil Mastermind (TM) who is after you, but simple, plain, cold
business.

It doesn't make sense to go all paranoid over that. I know that even if
I keep my own mail server they analyze all my mails (enough of my peers
have an @gmail address, enough of my stuff is in public mailing lists,
ready for harvesting), but I see it as my duty to not feed that machine
beyond what's "reasonable" (yes, this is a judgement call).

"Just because you're paranoid doesn't mean they are not after you"
                                                  -- Joseph Heller

cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljwjJMACgkQBcgs9XrR2kYZ4QCdFCKkBfsXM6luYNOn5apfaE6E
VbwAniQJUd3/lPSNRKJbebxKmdwJ6+O+
=ZFm/
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web