Jump to content
Enpass Discussion Forum

lemonjuice

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by lemonjuice

  1. Following on from my previous message, using launchctl disable user/<uid>/in.sinew.Enpass-Launcher finally prevented the unwanted running of Enpass at login. I did this once as the user, and once as root, just to be sure.
  2. I have found a couple of workarounds and a probable diagnosis of the problem. For the first workaround, type "launchctl remove in.sinew.Enpass-Launcher" in a Terminal after logging in. (Note: no "sudo"; this is a launch agent, not a launch daemon.) You will need to do this every time you log in, for each account which has ever run Enpass. The second workaround is more permanent but requires Apple's developer tools and a good technical knowledge. Nobody who doesn't understand all the steps here or who lacks knowledge of Unix administration should attempt it, and attempt it at your own risk. Edit a copy of the plist at /var/db/com.apple.xpc.launchd/loginitems.<uid>.plist, where <uid> is the UID of the account, to remove the two entries for the Enpass Launcher. As root, ensure it has the correct ownership and permissions, and atomically rename it over the original version using mv. Reboot. Login and run Enpass. Now look at that plist and notice the change! Note that Enpass doesn't honour its own setting to "start on system startup" (I guess you meant "on login") and always starts anyway - another bug, by the look of it. It appears the Enpass app's bundle ID changed from in.sinew.Enpass-Desktop in version 5 to in.sinew.Enpass-Desktop.App in version 6. My guess is the problem only appears for accounts which previously ran Enpass 5. The bad plist uses the old bundle ID. This bug is more serious than it first appears. It is causing a new process to be created every 10 seconds, with the associated page file activity, and therefore probably also writing quite a lot to the SSD in addition to the log file itself.
  3. It's now been two working weeks since I reported this bug here, with no response from Sinew. However, I can report on a successful workaround. Exporting to a .txt file does work. The format is fairly obvious, and I was able to write a small program which massaged it into the kind of text file with delimiters that Unix utilities like. From there, I used the sort and diff utilities to verify both my vaults held the same data (even though one was from Enpass 5 and the other from Enpass 6). I would be able to fairly easily create a .csv file from there for export to another password manager, which alleviates the other concern I had about these bugs. However, the average user could not do this.
  4. Happening for me with the latest versions of both Enpass (6.1.2) and macOS (10.14.6). Most easily spotted by selecting "system.log" in Console when running as an administrator: Aug 19 17:10:03 REDACTED com.apple.xpc.launchd[1] (in.sinew.Enpass-Launcher[39450]): LaunchServices returned a bundle URL that does not match with the LoginItem's known association. Aug 19 17:10:03 REDACTED com.apple.xpc.launchd[1] (in.sinew.Enpass-Launcher[39450]): Service exited with abnormal code: 78 Aug 19 17:10:03 REDACTED com.apple.xpc.launchd[1] (in.sinew.Enpass-Launcher): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
  5. I have encountered what looks like *two* bugs in the .csv export function on macOS. I am trying to write a .csv file to the top-level directory of a mounted encrypted sparse image. That is, I have a 500MB file on my desktop, which when I click on it and feed macOS a password, gets mounted as /Volumes/passwords. I select Enpass's Export menu item, choose CSV, and browse to /Volumes/passwords. Then I click the export box, enter my master password and Enpass says it has successfully exported the file. Except it hasn't. It doesn't appear in the directory, or, as far as I can tell using "find -name", anywhere. Looking at the copy of in.sinew.Enpass.plist in the container Library/Preferences with "plutil -p", I saw that it tried to write to "file:///Volumes/". That's the first bug. It is stripping the last component of the path and trying to write to the directory above the one it should be. So I got a bit cunning and created the directory "/Volumes/passwords/dummy" (also proving that I could write to the mounted volume) and tried again. This time the .plist file said "file:///Volumes/passwords/", confirming my analysis of the first bug. But it still didn't write the file anywhere I could find, so that's the second bug. I am using Enpass 6.1.2 downloaded from the web site, on macOS 10.14.6. This worked using Enpass 5.5.7 on the same (current) version of macOS on another machine, writing to the same sparse bundle (which I later copied to the machine with 6.1.2). Indeed, what I was actually trying to do was dump the vaults on the two machines and then use "sort" and "diff" to check one really was a mirror of the other as they were supposed to be.
×
×
  • Create New...