From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id oM8UITWxEmV2LwEAG6o9tA:P1 (envelope-from ) for ; Tue, 26 Sep 2023 12:23:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id oM8UITWxEmV2LwEAG6o9tA (envelope-from ) for ; Tue, 26 Sep 2023 12:23:49 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E094D5EC2D for ; Tue, 26 Sep 2023 12:23:48 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=FX2AO7W+; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1695723829; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=xjjP4Pg5yNDC6Aj0SPPrDTQHlmEz1WD7HZXYErrnBhY=; b=YvL/fsPrT+tmn7YXYgvU0XfMg2YWQ9Ex2tXLQBM3ObsRKwwMH75f4fFSJRZ9WOhY6ppgId LR1Vpfdvcp+q9MuoCAKK3Zg0zivicLOnS6TIgnBSbXI16Pz10H4g4Z9k9uN59oM90S+xNJ tgBjnQN00ZgFc+7DJc18wWYD5wavExHi2KGqz7jPIJAobM4KpqrMDrRGT91Ss4o+yli8cZ BW6/ikUdFiCt+hUE3rT11g5M4Nh/zNoHvZQuL8ocxc+BIDB44Wcsf1zMILGhisjMa/Kh6n Z0CKZ4SGVJY+fatm0UZ7gRNbTTBvyflzC8JVVtbvz0CrO2d3W4C8SsmiMEI8WQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1695723829; a=rsa-sha256; cv=none; b=RjBQsdScT5SmRCBSowagNJyGQ0wVQsdm53p8SoGJVKFlvF/veqmxlQwQI0nEe+irjU2DCi Nq6vnRXW1vMhESydtEaS7VlXEBvedy+YOR6Kvm2ZnGJkKMdYN//m+eGc2uDa1ex1Km3wQT S4a761nQj8PfPKUY4rVxY9ej7L8+UNrBr+33c/cxAlhSVcMnwWAELA49RJFi/8SShx/xRC hsTng5qyF/0gctrY+VEr0Vjno8fnRoax80x6WJ4zFAY+Eey6suddcWGMRl/VEBenySKjjC p2DTWqzgEz38WHZhu4vKttZ86thdByT1JyboFjHw+Od0PRuIowrrCQzExTjobA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=FX2AO7W+; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ql5DU-0007CK-Pt; Tue, 26 Sep 2023 06:22:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ql5DS-0007Bv-O0 for emacs-orgmode@gnu.org; Tue, 26 Sep 2023 06:22:54 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ql5DQ-0007FV-0d for emacs-orgmode@gnu.org; Tue, 26 Sep 2023 06:22:54 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4CBFF240027 for ; Tue, 26 Sep 2023 12:22:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695723769; bh=acfL5d3tjiOjp7sg3l+5+sG1pQKvzOpL03GTy5gq+0Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=FX2AO7W+2sP7DEu4HILQymhV01Y+FC5YqX9GBZG5RfysAPTlh96Ej3czOf6fK3Xpq 3hmWil7F7NUm9GUV5CBjjH2oLciEQF/WCGv5Hf3RH9M0AlOwZVxU9O8d6ZQO270Wz1 o6wymeqh1XppR6CWEs+H3e8q1oC6gz0F4OdwzaMijtRisOJjHHLO4wjPu2vSKARpBe oDMm7cUhfsbR8oYcRJgjJiaTzhpT6+eOG1kwsFNQbJI2gIF6DUG/+ndDli+43UNNq8 raUZzA4ABziyU1tPOpb1s/5AE6mGmIPlmwjrBg0gZnw3bX+8F+Ql+5emetUKYigUOo fanBjeoBFuIYA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RvwmS2yfhz9s23; Tue, 26 Sep 2023 12:22:48 +0200 (CEST) From: Ihor Radchenko To: Visuwesh Cc: Max Nikulin , emacs-orgmode@gnu.org Subject: Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)] In-Reply-To: <87y1gul4oq.fsf@gmail.com> References: <87jzsintv0.fsf@gmail.com> <87lecx2nff.fsf@localhost> <87y1gul4oq.fsf@gmail.com> Date: Tue, 26 Sep 2023 10:24:02 +0000 Message-ID: <878r8t9qrh.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -9.47 X-Migadu-Spam-Score: -9.47 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Queue-Id: E094D5EC2D X-TUID: 4/5fVkurhwMZ Visuwesh writes: >> Please, use `make-temp-file' to create files in the temporary >> directory that may be world writable. Predictable file names there are >> undesired from security point of view. > > What harm does it cause? /tmp directory can be written by any program and the file, while kept there, might be modified by malicious code. Not that I know a concrete example what harm can be done in this particular case, but it is generally a good practice to make file names in /tmp random. >> At first, I expected more common with the following project >> https://github.com/abo-abo/org-download/ >> however even the approach to fetch images from clipboard is different. > > I have never used that package, this is what I wrote in a discussion > with Ihor in the Matrix room which we iteratively improved. It was > mostly written with my workflow in mind. Without knowledge of how > others work, I cannot improve the implementation. I also don't > understand what the linked package from the Commentary section (which is > why I never used it). The package does similar things, except that it focuses on downloading images from URL stored in clipboard or by making a screenshot. Dnd is also supported there, but just for a single URL/file path. Max, unless you see something particular that is implemented better in org-download, let's just ignore that library. I eyeballed the code and I do not see anything that we need to account for, except some more specialized features (like attaching screenshots), which we can always add in future, if necessary. >> I am in doubts if the following code is more suitable for org.el or >> for org-attach.el > > I have the same doubts. The patch implements dnd and media handlers, which constitute Org mode integration with the rest of Emacs. So, they are a part of major mode definition. If we want to keep things clean, we may create org-dnd.el and org-yank-media.el and put the relevant functions there, only leaving the major mode setup in org.el I do not think that org-attach is the right place for this new functionality. >> Could it be extended to any mime type? If so I would avoid "image" in >> its name. `org-yank-media-save-dir'? > > It should be easy enough to do it but do we want to go there? Isn't the patch handling non-images as well? AFAIU, the only case when images are considered separately is when image data is in clipboard. In theory, we might handle, for example, html markup in clipboard specially, but I am not sure if that's what people expect. >>> + "Method to save images yanked from clipboard and dropped to Emacs. >>> +It can be the symbol `attach' to add it as an attachment, or a >>> +directory name to copy/cut the image to that directory." >>> + :group 'org >>> + :package-version '(Org . "9.7") >>> + :type '(choice (const :tag "Add it as attachment" attach) >>> + (directory :tag "Save it in directory")) >>> + :safe (lambda (x) (or (stringp x) (eq x 'attach)))) >> >> Unsure if every directory may be considered as safe (e.g. ~/.ssh/) > > Is there a reliable way to know which directory is "safe"? If not, then > let the users shoot themselves in the foot. We can just say :safe nil (omit the keyword). Then, users will be prompted and can decide which directories are truly safe for them. >>> +(declare-function org-attach-attach "org-attach" (file &optional visit-dir method)) >>> + >>> +(defun org--image-yank-media-handler (mimetype data) >>> + "Save image DATA of mime-type MIMETYPE and insert link at point. >>> +It is saved as per `org-media-image-save-type'. The name for the >>> +image is prompted and the extension is automatically added to the >>> +end." >>> + (let* ((ext (symbol-name (mailcap-mime-type-to-extension mimetype))) >>> + (iname (read-string "Insert filename for image: ")) >> >> Unless 'attach is used, `read-file-name' would allow saving to >> arbitrary directory with path completion. > > Sorry, I don't understand what you mean here. I am not really familiar > with attachment facilities of org-mode. Imagine that user enters something like "/tmp/non-existing-directory/image-file" as an answer to "Insert filename for image: " prompt. >> Is there a chance to request for link description? Unsure if >> `org-insert-link' may be easily reused. > > This would include too many prompts and make the whole process annoying > again. +1. If users want to have a link description, they can easily follow the prompt with C-c C-l to edit the inserted link. >> I do not know if it can be easily implemented, but it may be useful to >> control attachment/generic directory at the moment when a particular >> image is yanked/dropped instead of purely relying on predefined user >> option. > > Sorry, I don't understand what you mean here. Note that my usage of > attachments is sparse. "Particular image" is hard to determine since > the only reliable data at hand is its mimetype. He meant that users might want to alternate between saving to attach dir and saving to `org-yank-image-save-type' set to custom directory. ... which might theoretically be needed, but I see it as unnecessary over-engineering. Let's keep things simple and consider implementing more complex behavior if we get actual feature requests. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at