User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; sv-SE; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; sv-SE; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Files indexed in Mac OS X 10.4 metadata store may have the kMDItemWhereFroms attribute (see http://developer.apple.com/documentation/Carbon/Reference/MetadataAttributesRef/index.html for reference). This allows for using Mac OS X own search system to search for files based on where they were downloaded from. This feature can be seen in Safari; download a file (with Safari) and bring up it's details in Finder. You should see the address from where it was downloaded. Reproducible: Always Actual Results: - Expected Results: - -
dupe of bug 90918 ?
Well, I didn't read all of the comments on bug the bug mentioned (#90918) but from what I can tell that regards writing the address in the comments field (kMDItemFinderComment?). This is a good idea aswell since the kMDItemWhereFrom is _not_ duplicated when copying a file (hopefully that behaviour will change in later versions of OS X). This feature would be OS X 10.4 (or later) specific.
If bug 90918 ever gets fixed, Fx could use those methods to set that bit of metadata. In the meantime, Fx can probably do something itself (within the limitations of the publicly-available APIs); see bug 325873 comment 4 for some discussion of the issue.
Related bugs/enhancements: #125729 #154580 #325873 #90918 Could this OS X 10.4 specific feature be implemented as an add-on? I'm new to Mozilla/Firefox development so I can't really tell... Related: see Ecamms DownloadComment Safari plug-in (http://www.ecamm.com/mac/free/) - it adds the download URL to comments for Safari.
pbeck: http://www.liquidx.net/blog/tag/coding/ -jacobolus
also: http://tinyurl.com/juhae Looks like it's an undocumented call to add kMDItemWhereFroms, but some people have gotten it working.
In Mac OS X 10.5 there's a way to set this normally, with constants in LSQuarantine.h. In any case it just looks to be a binary plist in the form of [data URL, origin URL] set on the com.apple.metadata:kMDItemWhereFroms xattr. Might be able to port it back to Tiger as well.
Created attachment 292163 [details] [diff] [review] Use the undocumented MDItemSetAttribute call The LSQuarantine API won't set kMDItemWhereFroms. I know, because I'm working with it over on bug 407215. But this will. (It's a patch to the Camino trunk and will only work in conjunction with the patch on bug 407215, which hasn't landed yet.) It demonstrates the use of the undocumented MDItemSetAttribute call. This patch is 10.4-and-up-only and requires the 10.4 SDK. Since this is currently undocumented, in a landable patch, I might look up the symbol at runtime, in case it disappears from a future SDK or in case they decide to declare it publicly (in which case the declaration in this patch would conflict).
Comment on attachment 292163 [details] [diff] [review] Use the undocumented MDItemSetAttribute call This proof-of-concept Camino implementation is obsolete, the real implementation is on bug 325873. A core patch can be modeled after the work in that bug, possibly working in nsDownloadManager.cpp, in the same way that bug 401748 can do quarantining based on bug 407215.
This is a security issue and should be treated as such.
*** Bug 566068 has been marked as a duplicate of this bug. ***
*** Bug 503629 has been marked as a duplicate of this bug. ***
Just a word of thanks for the people looking into this. HyperStudio 5 for Mac OS X now uses the feature in Safari extensively in support of Creative Commons licensing, and support of students doing classroom work where HyperStudio lets then put in the attributions and source URL for every media element. Thanks! Roger Wagner (Designer, HyperStudio)
after extensive testing to get bash to deal with null-bytes (it would be nice in many hackish situations) and then hacking on macports's xattr (http://trac.macports.org/browser/trunk/dports/sysutils/xattr/Portfile) (mostly to get it to handle utf-8 file-paths correctly) - i finally try to set xattr com.apple.metadata:kMDItemWhereFroms to the xml form of a plist: <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><array><string>source</string></array></plist> and by golly gosh it worked - simple as that btw for those of you who want to know the data in the xattr is the binary1 format which can be converted to xml1 with the plutil(1) utility (but then you need a temp file cause the little thing doesn't think printing binary data "makes sense" :/ ) hope this helped pzss \/ike
*** Bug 623882 has been marked as a duplicate of this bug. ***
*** Bug 630289 has been marked as a duplicate of this bug. ***
Created attachment 508627 [details] security dialog that does not appear for Firefox users Tested by downloading e.sh in http://www.squarefree.com/bug337051/.
For maximal security benefit, we'll also need to fix bug 401748. com.apple.quarantine works best when kMDItemWhereFroms is also present. (I sniffed around with mdls, GetFileInfo, and xattr.)
Created attachment 613200 [details] [diff] [review] Patch for this bug and for 401748. Overview: - Core logic based on file_metadata_mac.{h,mm} from Chromium project. - Core logic is called from nsDownload::setState, if state transitions to DOWNLOAD_FINISHED Questions: - Any idea how to avoid the ugly (const char*) casts? - The include of file_metadata_mac from nsDownloadManager using #include "../../../ipc/chromium/src/chrome/common/file_metadata_mac.h" does not feel right, any ideas?
Additional comments: - This is only manually tested, automated test case seems non-trivial. - Compiled against MacOS 10.6 SDK and not really latest mozilla-central.
Comment on attachment 613200 [details] [diff] [review] Patch for this bug and for 401748. Hi Stefan, thanks for the patch! I'll flag one of our Mac pros to provide some feedback on it. One thing I noticed is that you're adding code to ipc/chromium/, which probably isn't what we'd want to do - this code probably belongs somewhere under widget/cocoa, and we probably want to expose it via XPCOM on an existing interface (maybe nsILocalFileMac?). Markus may have better suggestions.
Hi Gavin, original reason to add it to ipc/chromium was that a) code is coming from chromium project b) there is already a similar, but unused file quarantine_mac.{h,mm} in the same folder.
Yeah, I was aware of the origin. There is some unused code in ipc/chromium because we just copied over things wholesale. There's no reason to put other, non-IPC related code under ipc/chromium, so it would be better to put it in a more logical spot based on function. We'll need to confirm that the license terms for the copied code is suitable. I imagine it uses the same license as all the other chromium code that we've used, but we'll need to double check :)
Looks like some of the original code is actually from Camino (bug 325873).
As a reference, while I was researching this: Only Firefox stable + beta are automatically opted-in to quarantine via their bundle id (/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist). Aurora and Nightly each have different bundle ids and currently don't mark any files. Safari and Chrome have the LSFileQuarantineEnabled entry in their Info.plist but no Firefox build has. With OS X 10.8 there's a new feature called Gatekeeper. But the Gatekeeper checks are only called on files having the com.apple.quarantine flag being set. So any software downloaded with Firefox Aurora and Nightly currently prevents Gatekeeper from doing its job.
(In reply to comment #25) Hanno, your comment isn't really relevant to this bug. > the Gatekeeper checks are only called on files having the > com.apple.quarantine flag being set This is an Apple bug ... or a design flaw. > Only Firefox stable + beta are automatically opted-in to quarantine > via their bundle id > (/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist). Aurora > and Nightly each have different bundle ids and currently don't mark > any files. Safari and Chrome have the LSFileQuarantineEnabled entry > in their Info.plist but no Firefox build has. This is indeed a problem with Firefox, but (as best I can tell) no bug has ever been opened on it (though bug 401744, bug 401748 and bug 400227 all touch on aspects of it). Please open a bug on this yourself. Categorize it the same way as bug 401748, and call it something like "Firefox nightlies need to opt in to Apple's quarantine system".
Comment on attachment 613200 [details] [diff] [review] Patch for this bug and for 401748. There's already some feedback to be addressed re: code location, but can someone provide feedback on the code itself?
Comment on attachment 613200 [details] [diff] [review] Patch for this bug and for 401748. I just tested this (an updated version) in current code, and basically it works fine. But not in distros whose bundle id isn't "org.mozilla.firefox" (i.e. not in nightlies). Which means that the patch is incomplete by itself, and that we'll also need to add the following key to Info.plist: <key>LSFileQuarantineEnabled</key> <true/> I tested downloading the current version of Firefox from http://www.mozilla.org/. I used 'xattr -l' to see what "extended attributes" were added to the downloaded dmg file itself, and to the copy of Firefox dragged out from it. The kMDItemWhereFroms stuff (included in the com.apple.metadata extended attribute) always gets added to downloaded files (e.g. the FF 15.0.1 dmg file), regardless of whether or not the Info.plist file of the patched FF distro has the LSFileQuarantineEnabled key described above. However it doesn't also get added to the copy of an app dragged from a downloaded dmg file. No quarantine stuff at all gets added, either to the downloaded dmg file or to the app dragged from it, if the patched FF distro's Info.plist file doesn't have the LSFileQuarantineEnabled key. But if the patched FF distro's Info.plist file has this key, the downloaded dmg file and the app dragged out from it have a com.apple.quarantine extended attribute that includes the standard quarantine information plus the information added by the call to AddQuarantineMetadataToFile(). The com.apple.metadata extended attribute, to which data is added by the call to AddOriginMetadataToFile(), doesn't seem to contribute to the information stored in the com.apple.quarantine extended attribute. Commenting out the call to AddOriginMetadataToFile() makes no difference to its contents. Finally (and best of all), if an app has a com.apple.quarantine extended attribute with the additional data added by the patch's call to AddQuarantineMetadataToFile(), you see additional information in the quarantine dialog displayed by the OS the first time you try to run it: There's a Show Web Page button that will take you to the page from which its dmg file was downloaded.
Created attachment 669327 [details] [diff] [review] Patch for this bug and bug 401748, updated to current trunk