Can't open certain types of documents

netj

On my 1Password for Families/Teams vault, I wanted to keep a shell script I use for setting up new Macs (executable with a .tool filename extension) that carries sensitive information. I can successfully add it to my vault and see the entry from everywhere else, but when I try to do an "Open With > Terminal" it tells me it's a damaged file. I can copy the file through "Show in Finder" and use it from my Terminal with no problem, but still get the same error if I open it from Finder by double clicking it. Quick Look works fine for other pdfs and images, and some software license files (.plist?) seem to open fine through the "Open With" menu. (I still want 1P to allow me to double click for opening.) Can this be fixed? It seems 1P is marking something special on these .tool files and OS X seems to view them somehow as damaged?

rickfillion

Hi @netj,

Thanks for writing in. This is interesting... I wonder if there are extended attribute issues here that need to be looked into. Is there any chance that you could email me an example tool file to rick@agilebits.com so that I can make sure that I'm working with the same thing as you are, and I can take a look at what's going on... how the file that we end up with differs from the original. The file contents themselves should be bit for bit the same. So that doesn't leave much other than extended attributes that I can think of.

Rick

netj

Hi @rickfillion,

Thanks for your quick response and taking a deeper look into this. It seems any .tool file would reproduce this, such as an harmless one as I linked below (I couldn't attach the file, so pointing to my Dropbox). I'm pretty much using the latest OS X and 1P (10.11.3 and 6.1 from MAS) on both Macs.

https://www.dropbox.com/s/xv23f2zq5rtdai4/hello.tool?dl=0

~Jaeho

rickfillion

Hi @netj,

Thanks for the example. I've determined what's going on and I think it's something we can fix on our end, and I have a workaround for you though it's a little manual for now. The problem is that when we decrypt the file, the resulting file has read/write permissions where it needs read/write/execute. I've filed a bug (OPM-3917) on our end so that we can look at correcting that.

Rick

OPM-3917

rickfillion

Hi @netj,

I have an update for you... we've resolved OPM-3917 as Won't Do. Due to security implications, we will not be setting the executable bit on any decrypted documents. You'll need to set that yourself on files you decrypt from a Document. It's a bit more hassle, but there's no good way for us to ensure that we aren't putting a user in a dangerous position in this case.

Rick

netj

Hi @rickfillion,

I understand setting executable bits in general can undermine security. However, I would argue 1P should rather give a warning when the file is added, instead of silently changing the file's attribute when it's decrypted from the other end. In a broader sense, it's corrupting user's data. Moreover, these executable files are added explicitly by the user to a vault that's accessible exclusively by himself/herself or many a few more family/team members, so I think the user should have an option to mark such docs as "trustable." I guess it's also possible to add executable documents to 1P via Automator/AppleScript, etc., but executables added through those automated paths can always be marked as untrusted/tainted by default, and require user interaction to turn them into trusted ones. In short, I believe it's better to prevent bad things from getting added in the first place than silently failing and embarrassing users later, and allowing superusers to take the risk and add such executable files will make 1P much more useful.

Regardless of my opinion above, could you kindly teach me how to set the executable bit manually? I tried chmod +x but that doesn't work/isn't enough, and I don't really know much about manipulating OS X specific extended attributes.

~Jaeho

rickfillion

Hi @netj,

Yeah, it'd be nice for us to do more to help the user here. We'll see what we can do to make it better.

As for how to add the executable bit, chmod o+x is what you're looking for. You were close. o in this case stands for 'owner'. You're asking to add executable permissions for the owner of the file.

Rick

netj

@rickfillion It'd be great if you can voice in my "marking files as trusted" feature request to the team or to that issue (OPM-3917).

I think my question wasn't clear enough. I was hoping to double click from Finder to open a new Terminal from that file, but it still tells me the file is damaged. Is there any way to mark it as not damaged? (which sounds strange..) Without the standard executable file bit, I can just run bash .../hello.tool to run the script, but wanted to lazy. :) (btw I think o is for "others" and we have to use u+x. +x I used is shorthand for ugo+x..)

~Jaeho

rickfillion

@netj : You're absolutely right, o IS for others. That's what I get for trusting my memory on that. So sorry.

I wasn't able to reproduce Finder telling me that the file was damaged. Without the executable bit here, it would switch go the Terminal but not do anything. When I added the executable bit it worked as expected. I'm not sure what's causing your system to mark it as damaged. Can you run xattr -p on the file to see if there are any extended attributes on it after it comes out of 1Password there?

Rick

netj

Here's what I get:

$ xattr -l  hello.tool 
com.apple.quarantine: 0006;56eb0694;2BUA8C4S2C.com.agilebits.onepassword-osx-helper;

It seems I can open it directly from Finder after deleting that "quarantine" flag and setting the executable bit:

xattr -d com.apple.quarantine  hello.tool
chmod +x  hello.tool
open  hello.tool

Thanks for teaching me the xattr command! At least I can now know how make the local copy useful again. That quarantine flag is sticky and didn't let me open even after duplicating it to another place.

rickfillion

Hi @netj,

We aren't explicitly adding the quarantine, so that must be OS X that's doing that on our behalf. It's interesting that it's doing that. I assume you're on 10.11 and that's why it's behaving differently than it is here on 10.10?

Rick

invictus26

I'm not totally sure this is related, but a lot of my software licenses have license files that I store in 1Password, but when I switched to the family version, the license files just show up as plist files (for example). I assume that they were executable before.

netj

Sorry for my lag @rickfillion. Yes I'm on 10.11 and using an app from the App Store. The decrypted file seems to be under ~/Library/Group Containers/. It sounds like if I use the 1P app outside App Store might actually help?

UPDATE: Yes, it seems at least the quarantine attr isn't set by the non-MAS app, one less annoying step for me. I think this quaratine flag would be the same for all App Store apps.

~Jaeho

AGAlumB

@netj: Thanks for following up! I also wanted to mention that the case we need to be concerned about isn't you adding an executable file to your own vault, but the fact that someone else could with a shared vault. Someone in your Family (or on your Team) probably wouldn't do this maliciously, but neither are most of the infected email attachments we receive from the guy in the office. :angry:

I'm not totally sure this is related, but a lot of my software licenses have license files that I store in 1Password, but when I switched to the family version, the license files just show up as plist files (for example). I assume that they were executable before.

@invictus26: Sorry for the confusion! Since local vaults in the standalone 1Password apps attach files to other items, you simply wouldn't have noticed the file type of the license files. But 1Password for Families/Teams doesn't have attachments; rather, these files are stored as Documents (which can be linked to other items), and that's why they're more visible to you now. I hope this helps! :)

rickfillion

@netj : ah...it didn't even occur to me that the quarantine flag might be based on MAS vs non-MAS. Thanks for checking that out.

@invictus26 : 1Password license files are plists with a custom extension. I'd be curious to know how they're showing up as plists for you though, as the custom extension should tell the OS not to treat them as such. The fact that they're a plist behind the covers is an implementation detail.

invictus26

Sorry if I'm not being clear, but my point is the behavior has changed with the family vault. Before, I could click on the attachment and it would open up and register the associated app. Now, I click the attachment, and it just shows the plist file content. How am I supposed to use that to activate my software?

Ben

@invictus26,

Okay, that is even more strange. If you select the Document in the listing, and hover over where it says "Quick Look" you should see a downward facing arrow (to the right of "Quick Look"). Clicking on that arrow should bring up a menu with the option "Show in Finder." What file do you get when you click that? Is it just a plist file?

Is the registration file supposed to be a plist?

Ben

invictus26

So, for example, if I click on the license file for Hazel, it takes me to this screen:

You're right that I can get to the file in finder using the arrow (I didn't know that before you mentioned it), but it's pretty strange behavior to see the plist content for a license file, when it would just show a clickable icon in the past.

AGAlumB

@invictus26: Thanks for making that crystal clear! I was able to reproduce this myself. It appears that 1Password for Mac is seeing that this is a plaintext XML file and displaying it inline. We'll see if there's a way to improve that. As a workaround, you can download it directly from the web interface. Thanks for bringing this to our attention! :)

ref: b5-1726