• Members 14 posts
    Dec. 19, 2018, 3:13 p.m.

    For several users the pEp mode isn't working anymore, as some already pointed out at the Enigmail Forum

    In my case this occurred one or two weeks ago. Before it was working without problems for several month. I already tried deactivating other plugins, reinstalling pEp-Engine and Enigmail - no success.

    Enigmail 2.0.9
    Thunderbird 60.3.0
    debian 9.6
    pEp JSON Adapter version 0.14.1 "(39) Gemünden". package_version="1.0.24"
    pEpEngine version 0.9.0

    I attached a (anonymized with XXXXX) logfile covering start, switching to forced pep mode and then sending the message (from 15:48:02)

    insert_drive_file
    log.txt

    Text, 41.2 KB, uploaded by peri on Dec. 19, 2018.

  • Dec. 23, 2018, 7:01 p.m.

    Do you get any errors when starting the

    yourself?

    Indicates that the pep adapter isn't listening to calls

  • Members 14 posts
    Dec. 23, 2018, 11:49 p.m.
  • Dec. 25, 2018, 1:48 p.m.

    Does ~/.pEp.management.db exist? Might be corrupt or have the wrong permissions

  • Members 14 posts
    Dec. 26, 2018, 12:51 p.m.

    Yes, normal permissions (-rw-r--r--)
    I even renamed it and it was rebuild at restart. Also uninstalled pEp-Files and Enigmail and reinstalled everything again.

  • Members 14 posts
    Dec. 28, 2018, 9:35 a.m.

    Probably helpful: I discovered that on my laptop everything is running fine. It's the same system and the same versions and has the same or at least a very similar thunderbird profile (i copied it from my desktop some months ago). But I discovered some differences:
    1. pEp didn't generate a .pEp_management.db-shm and .pEp_management.db-wal on the defective desktop install
    2. Enigmail on the defective desktop has the normal long enigmail menu (Decrypt/Verify ... [12 other points] ... About Enigmail).
    On the working laptop it's the short Enigmail menu (key management and preferences)

    EDIT: Ok, I think that's not helpful, the file came from another software opening the database and the missing pEp menue seems to be a consequence from the pep service not running.

  • Members 14 posts
    Dec. 28, 2018, 10:37 a.m.

    It seems that the .pEp_management.db can't be generated anymore (even if I uninstall and reinstall enigmail and PEP completly). If I start pep-json-server manually, it is generated, but seems to be empty (4kb instead of 225kb on the working laptop install)

  • Members 14 posts
    Jan. 7, 2019, 5:06 p.m.

    I narrowed down the problem: I restored the pep-json-server of an old pEp version (1.0.8) from an backup - and then everything works fine. It works with an old database as well as without any database - then it is created.

    So the problem seems to be a bug in the actual version of the pep server executable, which makes trouble in some installs.

  • Jan. 16, 2019, 11:28 a.m.

    Just as correction: if you try to start the pep-json-server manually, then you need to have the right CWD, specifically

    XXX/pepmda/share/pEp
    

    and then you invoke

    ../../bin/pep-json-server
    

    from there.

  • Jan. 16, 2019, 11:38 a.m.

    Does the current 1.0.24 binary still doesn't start when you do it from the right CWD? See other post.

    Otherwise I would like to know what's the error which appears with the current 1.0.24 binary, which you can also get directly from here: enigmail.net/download/pEp/linux/pepmda-linux+1.0.0+1.0.24-x86_64.zip

    You can backup your current pepmda/ folder, completely delete it then and unpack that zip there which will have a pepmda/ folder as the root folder: that's also the way the update is done, by deleting that folder and replacing it with the new contents.

  • Members 14 posts
    Jan. 16, 2019, 3:47 p.m.

    Used the path as you described, now there is a different error ...

    With version 0.13.0 "(36) Hatzfeld". package_version="1.0.8" (the working version from my backup)

    Cannot create first session! PEP_STATUS: 0x122 "PEP_INIT_CANNOT_OPEN_SYSTEM_DB".
    

    (Server keeps on running though - so this error seems not to be relevant)

    And with version 0.14.1 "(39) Gemünden" from the normal, automated update as well as with the binaries from your link:

    *** Error in `../../bin/pep-hotfix': double free or corruption (out): 0x00007ffe9130f6a0 ***
    ======= Backtrace: =========
    /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f8948a14bfb]
    /lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7f8948a1afc6]
    /lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7f8948a1b80e]
    ../../bin/pep-hotfix(+0x2e92)[0x55da66288e92]
    ../../bin/pep-hotfix(+0x33dc)[0x55da662893dc]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f89489c42e1]
    ../../bin/pep-hotfix(+0xfda)[0x55da66286fda]
    ======= Memory map: ========
    55da66286000-55da6628b000 r-xp 00000000 fe:00 9982155                    /home/m/.icedove/XXXXXXXX/pepmda/bin/pep-hotfix
    55da6648a000-55da6648b000 r--p 00004000 fe:00 9982155                    /home/m/.icedove/XXXXXXXX/pepmda/bin/pep-hotfix
    55da6648b000-55da6648c000 rw-p 00005000 fe:00 9982155                    /home/m/.icedove/XXXXXXXX/pepmda/bin/pep-hotfix
    55da6648c000-55da6648d000 rw-p 00000000 00:00 0 
    55da682c5000-55da682e7000 rw-p 00000000 00:00 0                          [heap]
    7f8944000000-7f8944021000 rw-p 00000000 00:00 0 
    7f8944021000-7f8948000000 ---p 00000000 00:00 0 
    7f894878d000-7f89487a3000 r-xp 00000000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7f89487a3000-7f89489a2000 ---p 00016000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7f89489a2000-7f89489a3000 r--p 00015000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7f89489a3000-7f89489a4000 rw-p 00016000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7f89489a4000-7f8948b39000 r-xp 00000000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7f8948b39000-7f8948d39000 ---p 00195000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7f8948d39000-7f8948d3d000 r--p 00195000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7f8948d3d000-7f8948d3f000 rw-p 00199000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7f8948d3f000-7f8948d43000 rw-p 00000000 00:00 0 
    7f8948d43000-7f8948d66000 r-xp 00000000 fe:00 655429                     /lib/x86_64-linux-gnu/ld-2.24.so
    7f8948f3a000-7f8948f3c000 rw-p 00000000 00:00 0 
    7f8948f62000-7f8948f66000 rw-p 00000000 00:00 0 
    7f8948f66000-7f8948f67000 r--p 00023000 fe:00 655429                     /lib/x86_64-linux-gnu/ld-2.24.so
    7f8948f67000-7f8948f68000 rw-p 00024000 fe:00 655429                     /lib/x86_64-linux-gnu/ld-2.24.so
    7f8948f68000-7f8948f69000 rw-p 00000000 00:00 0 
    7ffe912f0000-7ffe91311000 rw-p 00000000 00:00 0                          [stack]
    7ffe913b7000-7ffe913b9000 r--p 00000000 00:00 0                          [vvar]
    7ffe913b9000-7ffe913bb000 r-xp 00000000 00:00 0                          [vdso]
    ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
    
    
  • Jan. 16, 2019, 5:17 p.m.

    Does this also happen when no server is running, that is, when you kill all pep-json-server instances or restart the system (such that no pep-json-server is running)?

  • Members 14 posts
    Jan. 17, 2019, 11:49 a.m.

    Just tested:

    New version: yes
    old version:no

    New version:
    1. Searched for pep server in process activity, killed the process
    2. Deleted the working binaries, copied the binaries from your download
    3. Changed to .../pepmda/share/pEp
    4. Started /pepmda/bin/pep-json-server

    *** Error in `../../bin/pep-hotfix': double free or corruption (out): 0x00007ffe55038cc0 ***
    ======= Backtrace: =========
    /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f24830adbfb]
    (...)
    

    Then old version:
    1. Stopped the server
    2. Copied the old Hatzfeld binaries
    3. Changed to .../pepmda/share/pEp
    4. Started /pepmda/bin/pep-json-server
    Everything runs without error.

    Interesting though: The hatzfeld version is shown running under systemd, while on my laptop (where gemünden works) the pep server is running directly, when started from CLI. Could that result in some path issues?

  • Members 4 posts
    Jan. 19, 2019, 11:17 p.m.

    PEP_INIT_CANNOT_OPEN_SYSTEM_DB still indicates a problem accessing $TBPROFILE/pepmda/share/pEp/system.db, not the ~/.pEp_management.db. The System DB path is hardcoded to a lookup in the current working directory, i.e. "system.db". So I guess there is still some mismatch with the path here.

  • Members 4 posts
    Jan. 19, 2019, 11:29 p.m.

    Developer of pep-hotfix here. So we have a bug in the hotfixer apparently :-(.

    This hotfix basically scans and eventually edits $GNUPGHOME/gpg.conf and ./gpg-agent.conf, to revert some bad writing we made previously. It creates backups with suffix .$NR.pep.bkp alongside the originals. The hotfix is not run once $TBPROFILE/pepmda/share/pEp json-hotfix-1.dat file exists.

    Any chance we could figure out why it is crashing?

  • Members 14 posts
    Jan. 20, 2019, 11 a.m.

    Can confirm: Hotfix crashes on desktop, when started from CLI - on laptop it works. json-hotfix-1.dat exists on laptop, on desktop it has never been generated.

  • arrow_forward

    Thread has been moved from Standard.

  • Members 4 posts
    Jan. 23, 2019, 4:40 p.m.

    I would love to better understand the problem on your desktop. Any chance you can provide more information on your environment?

    Maybe you can compile pep-hotfix with debugging to see where it crashes? Or maybe I can figure out something if you send me a newline-preserving representation of your gpg.conf and gpg-agent.conf to claudio.luck@pep.foundation

    The hotfix code is here: pep.foundation/dev/repos/pEpJSONServerAdapter/file/default/hotfixes.

    For a debug build of the hotfix binary this should be sufficient:

    hg clone https://pep.foundation/dev/repos/pEpJSONServerAdapter/
    cd pEpJSONServerAdapter/hotfixes
    make "CC=cc -g2"
    gdb --batch --quiet -ex run -ex quit pep-hotfix
    
  • Members 14 posts
    Jan. 23, 2019, 5:43 p.m.

    Sure, I will try to compile, even if I'm not exactly a developer.

    First I installed the following packages because of several include errors:
    libjs-excanvas (0.r3-4)
    mercurial (4.0-1+deb9u1)
    mercurial-common (4.0-1+deb9u1)
    uuid-dev (2.29.2-1+deb9u1)
    libassuan-dev (2.4.3-2)
    libgpg-error-dev (1.26-2)
    libgpgme-dev (1.8.0-3+b2)

    Then I copied the missing repo of pepengine:
    hg clone https://pep.foundation/dev/repos/pEpEngine/

    But now i'm stuck with this include error:

    cc -g2 -I. -I../../pEpEngine/src -o pep-hotfix ../../pEpEngine/src/platform_unix.c ../../pEpEngine/src/stringlist.c main.c
    In file included from ../../pEpEngine/src/pEp_internal.h:109:0,
                     from ../../pEpEngine/src/stringlist.c:4:
    ../../pEpEngine/src/sync.h:205:22: fatal error: sync_fsm.h: No such file or directory
     #include "sync_fsm.h"
                          ^
    compilation terminated.
    In file included from ../../pEpEngine/src/pEp_internal.h:109:0,
                     from main.c:4:
    ../../pEpEngine/src/sync.h:205:22: fatal error: sync_fsm.h: No such file or directory
     #include "sync_fsm.h"
                          ^
    compilation terminated.
    Makefile:9: recipe for target 'pep-hotfix' failed
    make: *** [pep-hotfix] Error 1
    
    
  • Members 14 posts
    Jan. 23, 2019, 6:08 p.m.

    Ok,
    1. installed more packages:
    automake (1:1.15-6)
    libtool (2.4.6-2)
    gdb (7.12-6)
    2. Compiled pEpEngine
    3. Copied the sync_fsm.h from pEpEngine/sync/generated to pEpEngine/src
    4. Compiled hotfix successfully

    ~/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes$ gdb --batch --quiet -ex run -ex quit pep-hotfix
    gpg_conf /home/XXXXXXXX/.gnupg/gpg.conf
    gpg_agent_conf /home/XXXXXXXX/.gnupg/gpg-agent.conf
    *** Error in `/home/XXXXXXXX/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes/pep-hotfix': double free or corruption (out): 0x00007fffffffe0c0 ***
    ======= Backtrace: =========
    /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7ffff7aaabfb]
    /lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7ffff7ab0fc6]
    /lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7ffff7ab180e]
    /home/XXXXXXXX/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes/pep-hotfix(+0x2f03)[0x555555556f03]
    /home/XXXXXXXX/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes/pep-hotfix(+0x344d)[0x55555555744d]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffff7a5a2e1]
    /home/XXXXXXXX/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes/pep-hotfix(+0xfda)[0x555555554fda]
    ======= Memory map: ========
    555555554000-555555559000 r-xp 00000000 fe:00 11540985                   /home/XXXXXXXX/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes/pep-hotfix
    555555758000-555555759000 r--p 00004000 fe:00 11540985                   /home/XXXXXXXX/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes/pep-hotfix
    555555759000-55555575a000 rw-p 00005000 fe:00 11540985                   /home/XXXXXXXX/Schreibtisch/Hotfix/pEpJSONServerAdapter/hotfixes/pep-hotfix
    55555575a000-55555577c000 rw-p 00000000 00:00 0                          [heap]
    7ffff0000000-7ffff0021000 rw-p 00000000 00:00 0 
    7ffff0021000-7ffff4000000 ---p 00000000 00:00 0 
    7ffff7823000-7ffff7839000 r-xp 00000000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7ffff7839000-7ffff7a38000 ---p 00016000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7ffff7a38000-7ffff7a39000 r--p 00015000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7ffff7a39000-7ffff7a3a000 rw-p 00016000 fe:00 655396                     /lib/x86_64-linux-gnu/libgcc_s.so.1
    7ffff7a3a000-7ffff7bcf000 r-xp 00000000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7ffff7bcf000-7ffff7dcf000 ---p 00195000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7ffff7dcf000-7ffff7dd3000 r--p 00195000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7ffff7dd3000-7ffff7dd5000 rw-p 00199000 fe:00 659902                     /lib/x86_64-linux-gnu/libc-2.24.so
    7ffff7dd5000-7ffff7dd9000 rw-p 00000000 00:00 0 
    7ffff7dd9000-7ffff7dfc000 r-xp 00000000 fe:00 655429                     /lib/x86_64-linux-gnu/ld-2.24.so
    7ffff7fcc000-7ffff7fce000 rw-p 00000000 00:00 0 
    7ffff7ff4000-7ffff7ff8000 rw-p 00000000 00:00 0 
    7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0                          [vvar]
    7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0                          [vdso]
    7ffff7ffc000-7ffff7ffd000 r--p 00023000 fe:00 655429                     /lib/x86_64-linux-gnu/ld-2.24.so
    7ffff7ffd000-7ffff7ffe000 rw-p 00024000 fe:00 655429                     /lib/x86_64-linux-gnu/ld-2.24.so
    7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 
    7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
    ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
    51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    A debugging session is active.
    
        Inferior 1 [process 383] will be killed.
    
  • Members 14 posts
    Jan. 23, 2019, 6:34 p.m.

    Ok, I found the error:

    It's your backup routine, when the backup files in the directory count up to 98:
    gpg.conf.98.pep.bkp

    If I remove them to another folder, the hotfix runs fine. If I move them back, it crashes.

    There seems to be no problem with the backup notification in the files itself though. Also the gpg-agent.conf.98.bkp is no problem.

    After I discovered this, I went to install the Gemünden version to /.thunderbird/XXXXXX/pepmda, stopped the pep-json-server and restarted Thunderbird. Voila, everything works fine with the new version.

  • Members 4 posts