Jump to content
Enpass Discussion Forum

sxc4567

Members
  • Posts

    26
  • Joined

  • Last visited

  • Days Won

    5

sxc4567 last won the day on January 30 2021

sxc4567 had the most liked content!

sxc4567's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • First Post
  • Collaborator Rare
  • Reacting Well Rare
  • Conversation Starter

Recent Badges

8

Reputation

  1. Hi @Vinod Kumar, Thank you very much for your reply. I have to say, this sounds really excellent! I read through the linked thread as well; do I understand correctly that, so long as Enpass is locked (for example at the PIN prompt), there is very little risk of data leakage through memory - aside perhaps from UI libraries that are extremely difficult to control anyway?
  2. Hi there, I've been an avid Enpass user for many years and I love how it keeps improving! Recently though, I had a scare: Enpass core-dumped. This likely wasn't Enpass' own fault as it had been pretty stable until I upgraded my machine to Ubuntu 22.04; after the upgrade, I experienced a definite uptick in crashes with a number of apps that were running fine before. The main issue here is that Ubuntu decided to upload the crash report (complete with core dump) to their server without so much as notifying, much less prompting me! When I discovered this a few days later I was livid. I'm not sure the state Enpass was in when the crash occurred; it was possibly locked on the PIN prompt but it could also have been unlocked. I decided the risk was too big and proceeded to change all my passwords! You can imagine how pleasant and productive an activity this is... Now that I'm aware of the risk posed by this scenario, I'd like to rest a little easier next time something as drastic as this happens. Someone on reddit came up with the following tip: Does Enpass make use of this feature? If not, could it in the future? I'd love to get back on the reddit thread to point out that actually my data was safe all along, all thanks to Enpass.
  3. Hi @rubenJS Do you have the correct beta repo configured? This is where I got the "official" beta version 6.6.0.761 from, after testing various private debug builds over the last month in a bid to help the team resolve the issue. I do hope this build gets promoted soon as there's no doubt it's superior to every build, going back to version 6.3, which, I believe, introduced these crashes. In case you don't already have the beta repo installed: $ echo "deb https://apt.enpass.io/testing testing beta" | sudo tee /etc/apt/sources.list.d/enpass-beta.list $ sudo apt update $ apt policy enpass | head WARNING: apt does not have a stable CLI interface. Use with caution in scripts. enpass: Installed: 6.6.0.761 Candidate: 6.6.0.761 Version table: *** 6.6.0.761 500 500 https://apt.enpass.io/testing testing/beta amd64 Packages 100 /var/lib/dpkg/status 6.5.1.723 500 500 https://apt.enpass.io stable/main amd64 Packages 6.5.1.719 500 $ sudo apt upgrade enpass (obviously, you'd see your current version rather than "Installed: 6.6.0.761" as in above). You may also need to remove the "hold" to an earlier version in case you'd previously configured it per my 1st November post above: $ sudo apt-mark unhold enpass Needless to say, it's probably a good idea to backup your data before installing beta software ;-)
  4. Hi @Pratyush Sharma, A big THANK YOU to the entire team - and particularly developers - for finally fixing Enpass for Linux. It's taken a while but I'm pleased to confirm that version 6.6.0.761 finally addresses the constant crashes I've been experiencing on the Linux version for well over a year. I'm really glad I'll be able to continue using Enpass and hope that Linux users won't be left out in the cold for quite so long next time an issue like this crops up...
  5. "Last couple of weeks" is a bit of an understatement. As far as I am concerned, Enpass on Linux has been utterly broken since version 6.4 was released about a year ago. 6.5.0.701 is a bit more stable than the 6.4.x releases but 6.5.1 seems to be taking a step backwards. Any attempt to assist with debugging just seems to go down a black hole... at least they are kind enough to acknowledge them here... When I find the time, it feels like I'll have to start looking for an alternative. For me the must-have features (that Enpass would have, if it weren't for an unusable Linux version) are: Cross-platform support (Linux & iOS are the ones I need) Offline syncing support (Enpass' WebDav capability is good here) Support for segregated databases (aka "multi-vault") Feedback on suitable alternatives is welcome...
  6. In case this helps investigating the issue, I decided to run Enpass on the command line as follows: /opt/enpass/Enpass > /tmp/enpass_log 2>&1 & The logfile shows a large number of error messages that say: "QQmlComponent: Created graphical object was not placed in the graphics scene." (this happens as soon as Enpass is started, and some keep appearing later on). I'm wondering if this (and my large number of crashes) could be due to the fact that I use multiple workspaces? (note: workspaces are a standard GNOME feature that Enpass' developers may not be aware of. It's essentially a grouping of windows and your monitor displays one of them at a time). To move a window - such as Enpass' - to another workspace, right-click its titlebar and select "Move to Workspace Down". You can then use Win+PgUp/PgDown to move between workspaces. I typically choose the "Always on Visible Workspace" right-click option for Enpass, since I use it on multiple workspaces. Here's a list of error messages that appear (multiple times) in stdout/stderr while Enpass is running. The first one is by far the most frequent. QQmlComponent: Created graphical object was not placed in the graphics scene. Case insensitive sorting unsupported in the posix collation implementation Numeric mode unsupported in the posix collation implementation QObject::startTimer: Timers cannot have negative intervals This is with Enpass 6.5.0.701 as it's the only post 6.4 version that's stable enough to consider using presently. When Enpass crashes, it typically happens due to a SEGV (segmentation violation), which we could use to dump a memory image (core). Let me know if I can assist analyzing such a core dump although it's obviously not something I could share since it might possibly include clear-text passwords etc.
  7. Can we please have a simple toggle (perhaps under Settings -> Advanced) to "disable integrated crash reporter". Privacy conscious users will certainly appreciate the option too. Background For over a year, Enpass has been less than stable on Linux. I have documented, extensively, the issues faced. Things have improved a little recently with 6.5.0, before worsening again with 6.5.1. In any case, it's still far off with Enpass crashing at least a few times on me daily. This is on "vanilla" Ubuntu LTS (20.04), which has to be the most used desktop Linux distribution. The integrated crash reporter makes a bad situation worse by wasting even more time (up to a few seconds) upon a crash. I have used it to report *hundreds* of crashes and that seems to have made very little difference as to the stability of the product, nor did I ever get any feedback so I strongly suspect that all my reports are going down a great big black hole. Even if they were actually useful, it should be possible to disable it after reporting, say, 5 crashes. Thank you very much.
  8. @rubenJS not to worry, your post in perfectly on topic. What versions of Enpass and Pop_OS are you running? I found that Enpass 6.5.0.701 is the most stable for me on Ubuntu 20.04 (GNOME). This is supposedly a beta version, which you can install by following these instructions. Once you've done this, you can downgrade Enpass, as follows: sudo apt update apt-cache policy enpass # shows all versions available from the repositories sudo apt install enpass=6.5.0.701 # or whichever other version you'd like to try out sudo apt-mark hold enpass # prevent subsequent automatic upgrades by locking the installed version The last line "holds" enpass to the installed version, so it doesn't get upgraded automatically later. Use the same command with `unhold` if you'd like to try a newer version that will most hopefully fix things before too long...
  9. I'm having to share some passwords with a customer organization that also uses Ubuntu and finding it very hard to recommend Enpass due to the continuous crashes that have been ongoing since the beginning of the year. I noticed that 1Password is moving into the Linux space. I *really*, *really* like Enpass and desperately want to stay with it but the frustration caused by 10+ daily crashes is starting to add up...
  10. Hi @Garima Singh, I got an update to version 6.5.1.719 (beta) and it's *significantly worse* than the previous version (6.5.0.707). 6.5.0 would crash about once a day; 6.5.1.719 is back to crashing at least 10 times a day. I've just had a crash, followed by an immediate second crash just after typing the master password. I would strongly advise a rollback of 6.5.1.719. I also looked into the "logs" which I enabled, inside the Enpass app. All I get are a number of "info" entries logging interactions with the WebDav server where my vaults are stored (). They don't look very useful to me but I can send them across if that's helpful. PLEASE can we get the option to disable the automatic crash reporter? (make it default to submit the reports if you like). I can't believe that the 101th crash report I submitted is more useful than the 100 previous ones and this thing makes a bad situation much worse in terms of frustrating one's workflow with Enpass so long as it continues to crash as often.
  11. Hi @Garima Singh, Thanks again for following up. It's really good to see that you care about your Linux users. I have enabled logs and will email support@enpass.io with logs upon the next crash. Here's my answer to your generic questions: Size of database? I have 4 vaults, all synchronized with the iOS mobile version using a local WebDav server. Not sure vault #1: 1.1MB, 324 items, 4 attachments (1.5MB in total); #2: 411kB 165 items, 1 attachment (5kB); #3: 70kB, 14 items, no attachments; #4: 66kB, 12 items, no attachments I run standard Ubuntu 20.04.1, fully up-to-date; Gnome, X11, not Wayland. I run Enpass at system startup. I have to run it with `QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=1` (as documented in your support articles) to prevent it from being huge on my screen. One thing I do which might possibly contribute to the issue (?) is using multiple workspaces. I typically set Enpass to be "Always on visible workspace", so it can be invoked from whichever workspace I happen to be working on. Scenarios: Enpass typically crashes when invoked from Firefox (again, standard, up-to-date build, which is currently 80.0.1), when using a hotkey from a login form. The crashes can occur in a variety of scenarios, eg: before I even see the Enpass UI (so Firefox displays the "looking for Enpass app" page; and usually this takes a while and I often but not always get to see the crash reporter) before I interact with the UI; for example while I use the search box to look up an entry just as it's filling out the form and sometimes just after filling out the form. Previously (with v6.4.1) Enpass would crash so often that there were no observable pattern; sometimes it would crash at the start of the day, ie: just after waking up my laptop from ACPI sleep, but this seems to have improved with 6.5.0. So far with v6.5.0, the pattern appears to be related to filling out forms from Firefox. I haven't observed a correlation of crashes with system updates. Locking time? Do you mean Enpass locking? I have the following options enabled: When main window is closed System sleeps System is inactive for 2 minutes I also have the PIN option set I hope this is useful; I'll be sure to follow up with logs as/when Enpass crashes next time. I still think there ought to be an option to switch off the crash reporter; having had to suffer it for over 6 months before 6.5.0 came out was really no fun, I can assure you!
  12. Hi @Garima Singh, Thank you for following up. I suggest we continue in the new thread, which I see you've also commented on: Enpass beta 6.5.0 (701) MUCH more stable but crashes still
  13. Hi there, A massive THANK YOU for the release of beta 6.5.0 for Linux. I have documented the excruciating experience I had with the previous version (6.4.1) on stock Ubuntu 20.04, which was crashing up to 20 times a day on me! As soon as I saw news of the 6.5.0 beta, I didn't hesitate one second. The outcome: it's a massive improvement in stability as it only crashes maybe once a day on average; I probably use Enpass 20-30 times a day on my desktop. Still, once a day is not fully satisfactory; thus my queries: Is there any practical way I can help you debug these issues whilst the beta is being finalized? I've been sending those crash reports; you much have an absolute pile of them from me. Re the crash reports: PLEASE, can we have an option to turn these off? I don't believe the 100th crash report is going to add much value to the 99 before it and when Enpass is having a bad day, having to wait for them to gather their data and click through them increases the frustration manifold.
  14. Hi @Garima Singh, It's been over three months and I still face Enpass crashing several times every day on me on stock Ubuntu 20.04. It's come to the point where I dread having to log on to any website as I know by instinct this will very likely cause a 30+ seconds interruption in my workflow while Enpass takes its time to crash, present me with the crash reporter (have you been getting those???) and finally comes back up... As suggested previously, I'm most happy to help you debug this issue in any practical way. Otherwise I would really appreciate an ETA for a fix. I noticed that the Linux desktop version is a couple of minor versions behind Windows...
  15. @Pratyush Sharma is there a way I can disable the crash reporter please? I suppose that by now you have enough of my reports (must be 50 or so...) and I certainly have enough of having to go through the reporter several times a day, as this only serves to exacerbate the impact on my workflow. Many thanks!
×
×
  • Create New...