Re: [PATCH] ob-java

[Bastien]

Hi Jarmo,

Jarmo Hurri  writes:

> (I wonder if it would be possible to have timestamps in worg. I have
> bumped into situations before where I have not known the temporal
> relationship between worg documentation and current org version.)

Good point.  I think worg documentation, when related to a specific
Org feature, should mention the Org version it relates to, rather than
a timestamp.  As an additional info, the timestamp is good, but not
enough.

Let's try to follow this convention from now on.

-- 
 Bastien

Re: Thoughts on the standardization of Org

[Tim Cross]

Jean Louis  writes:

> * Tim Cross  [2020-11-11 01:30]:
>>
>> Jean Louis  writes:
>>
>> > * Maxim Nikulin  [2020-11-10 19:31]:
>> >> 2020-11-10 Greg Minshall wrote:
>> >> >
>> >> > i would guess
>> >> > using 'cat -v' to read e-mail is 100% safe.  even throwing in
>> >> > uudecode(1), or whatever is needed to decode base64, (and then piping
>> >> > through 'cat -v', of course ), it's probably still safe.
>> >>
>> >> Please, check that you have at least updated tmux before applying such
>> >> "safe" handler: https://www.openwall.com/lists/oss-security/2020/11/05/3 
>> >> The
>> >> news are too recent to not mention the link in such context.
>> >>
>> >> The sour story is that it is unsafe to feed non-trusted files directly to
>> >> terminal. A filter against control sequences is required.
>> >
>> > Is there anyway to disable control sequences? Than cat can be aliased.
>>
>>
>> It should be noted that this vulnerability is a buffer overflow exploit
>> which ASLR effectively mitigates. This doesn't mean that it isn't a
>> serious bug in tmux, but it does mean that unless you have disabled
>> ASLR, there is no known exploit (i.e. it is only theoretical). Given the
>> popularity of tmux, I suspect it will be patched and a new version
>
> Do you know how to disable control sequences?

No, I doubt you can as they are fairly fundamental to tmux operation.

--
Tim Cross

Re: Thoughts on the standardization of Org

[Jean Louis]

* Tim Cross  [2020-11-11 01:30]:
> 
> Jean Louis  writes:
> 
> > * Maxim Nikulin  [2020-11-10 19:31]:
> >> 2020-11-10 Greg Minshall wrote:
> >> >
> >> > i would guess
> >> > using 'cat -v' to read e-mail is 100% safe.  even throwing in
> >> > uudecode(1), or whatever is needed to decode base64, (and then piping
> >> > through 'cat -v', of course ), it's probably still safe.
> >>
> >> Please, check that you have at least updated tmux before applying such
> >> "safe" handler: https://www.openwall.com/lists/oss-security/2020/11/05/3 
> >> The
> >> news are too recent to not mention the link in such context.
> >>
> >> The sour story is that it is unsafe to feed non-trusted files directly to
> >> terminal. A filter against control sequences is required.
> >
> > Is there anyway to disable control sequences? Than cat can be aliased.
> 
> 
> It should be noted that this vulnerability is a buffer overflow exploit
> which ASLR effectively mitigates. This doesn't mean that it isn't a
> serious bug in tmux, but it does mean that unless you have disabled
> ASLR, there is no known exploit (i.e. it is only theoretical). Given the
> popularity of tmux, I suspect it will be patched and a new version

Do you know how to disable control sequences?

Re: Thoughts on the standardization of Org

[Greg Minshall]

Maxim,

thanks.  small note.

> The sour story is that it is unsafe to feed non-trusted files directly
> to terminal. A filter against control sequences is required.

thus, the '-v' argument to cat(1) (which Rob Pike famously considered
harmful. :)

cheers.

Re: How to wrap Org code generated by a source block?

[Ihor Radchenko]

> I tried also with =:wrap src org=, but then upon export it's exported
> literally as Org src code, instead of interpreted as such.

An alternative might also be =:wrap export org=.


Diego Zamboni  writes:

> Hi Chuck,
>
> Thanks! =:results drawer= is exactly what I was looking for :)
>
> I tried also with =:wrap src org=, but then upon export it's exported
> literally as Org src code, instead of interpreted as such. The drawer was
> exactly what I needed, and allows reevaluation of the block, replacing all
> the results correctly.
>
> Cheers,
> --Diego
>
>
> On Tue, Nov 10, 2020 at 6:41 PM Berry, Charles 
> wrote:
>
>>
>>
>> > On Nov 10, 2020, at 6:13 AM, Diego Zamboni  wrote:
>> >
>> > I want to generate some parts of my document programmatically from an
>> emacs-lisp src block - i.e. the code produces Org markup which I want to
>> then export. Is there a way to wrap the #+RESULTS block in an environment
>> that still gets evaluated as Org text (e.g. when exporting)?
>> >
>> >
>>
>>
>> Try `:results drawer'
>>
>> You can also do fancy stuff using `:wrap "src ..."' where `...' is a
>> language and additional header args. One language choice is `org', but I
>> don't think this approach is what you need.
>>
>> HTH,
>> Chuck
>>

Re: Thoughts on the standardization of Org

[Tim Cross]

Tom Gillespie  writes:

> This is a great sub-thread that should probably be its own top level
> thread on org security.
>
> Org files are mostly benign unless the user does something extremely
> dangerous like
> setting enable-local-eval t. However, there are some areas where
> arbitrary code can be
> executed (as intended) that some users may not be aware of. Consider
> the following.
>
> #+begin_src elisp :var lol=(message "If I were evil I could use
> call-process here to give you nasal demons")
> #+end_src
>
> When is the closure for the variable lol evaluated? The most obvious time is 
> if
> you run the block. The less obvious time is if you run org export!
>
> More subtly.
>
> #+name: some-block
> #+begin_src elisp
> #+end_src
>
> #+call: some-block() :var pwnd=(message "oops!")
>
> When will the closure for pwnd be called? When exporting it happens before
> you receive the prompt asking whether you want to execute some-block!
> Very easy to fool someone who doesn't know how top level closures work
> into goofing on that one. Furthermore even when a file also sets
>
> #+property: header-args :eval no-export
>
> then the closure will still be evaluated!
>
> Or how about
>
> Running org export can execute arbitrary code even if you decline to run 
> blocks
> or set default header-args in your config. This means that it is not safe to,
> for example, run a public server that transforms arbitrary org files into 
> pdfs.
>
> How about some more fun?
>
> #+name: some-block
> #+begin_src elisp :tangle ./itsatrap.el :dir (message "OH NO")
> #+end_src
>
> Yep. That does what you think it does. If you tangle the file, arbitrary code
> execution. No tangling files from strangers either.
>
> The examples I present here do require user input to fire off the process,
> it won't happen without them doing something but it is much easier to
> C-c C-e h h or C-c C-v t when you are an expert user, so you have to
> be careful. Sharp tools.
>
> Despite these examples, the ability to define values using arbitrary closures
> is one of Org's most powerful features.
>
> In the context of standardization, this suggests that it might be nice to
> have a dynamic variable that controls whether bare closures will be
> evaluated (one might already exist, I have no idea), along with a spec
> that says what the failure modes should be if one is encountered that
> cannot be evaluated.
>
> In the context of org generally, maybe that variable could also be used like
> org-confirm-babel-evaluate and take a function as an argument, ask if t, don't
> ask if nil, or ask only if result is t (or was it nil ... regardless match
> org-confirm-babel-evaluate). org-confirm-closure-evaluate maybe? (Again if
> this already exists, then woo!).
>

Another one, which I think is even a little more subtle, is table
formula evaluation. Using the advanced features of tables, you can
define a table that will automatically run formulas (which could be a
calc expression OR an elisp function) when you navigate through a table,
such as by hitting tab to move to the next column. I imagine this is
something you could easily do as tabbing through a table is a
convenient way to browse the contents.

While by default, org is pretty good, the real risk is that I suspect
many will have tweaked the evaluation settings - I know I have and while
I would not evaluate or export anything in an org file I was sent until
I had assessed it, mistakes do happen and I could easily hit C-c C-c in
the wrong context and cause a block to be evaluated without any
prompting for confirmation.

Given the complexities of dynamic content evaluation in org, perhaps a
simple solution would be to add a special MIME handler function which
would open an org file in a restricted mode, ignoring user settings
affecting code evaluation and preventing any form of evaluation, even if
the user asks for it. Basically, allow viewing, folding, navigation of
the org file, but no evaluation. If the user wants to export or tangle
or update tables etc, they would be forced to save the file and then
re-open it as a normal org file. It would be this handler function you
would configure in your MIME types as the function to run to view an org
attachment etc.

You could take it one step further an allow the definition of a 'tursted
senders' list. When opening an org attachment, this list is checked and
if the sender is in the list, normal org open process is applied,
otherwise the restricted MIME open function is applied. This would be
similar to the Gmail approach for handling images.

--
Tim Cross

Re: Thoughts on the standardization of Org

[Tom Gillespie]

This is a great sub-thread that should probably be its own top level
thread on org security.

Org files are mostly benign unless the user does something extremely
dangerous like
setting enable-local-eval t. However, there are some areas where
arbitrary code can be
executed (as intended) that some users may not be aware of. Consider
the following.

#+begin_src elisp :var lol=(message "If I were evil I could use
call-process here to give you nasal demons")
#+end_src

When is the closure for the variable lol evaluated? The most obvious time is if
you run the block. The less obvious time is if you run org export!

More subtly.

#+name: some-block
#+begin_src elisp
#+end_src

#+call: some-block() :var pwnd=(message "oops!")

When will the closure for pwnd be called? When exporting it happens before
you receive the prompt asking whether you want to execute some-block!
Very easy to fool someone who doesn't know how top level closures work
into goofing on that one. Furthermore even when a file also sets

#+property: header-args :eval no-export

then the closure will still be evaluated!

Or how about

Running org export can execute arbitrary code even if you decline to run blocks
or set default header-args in your config. This means that it is not safe to,
for example, run a public server that transforms arbitrary org files into pdfs.

How about some more fun?

#+name: some-block
#+begin_src elisp :tangle ./itsatrap.el :dir (message "OH NO")
#+end_src

Yep. That does what you think it does. If you tangle the file, arbitrary code
execution. No tangling files from strangers either.

The examples I present here do require user input to fire off the process,
it won't happen without them doing something but it is much easier to
C-c C-e h h or C-c C-v t when you are an expert user, so you have to
be careful. Sharp tools.

Despite these examples, the ability to define values using arbitrary closures
is one of Org's most powerful features.

In the context of standardization, this suggests that it might be nice to
have a dynamic variable that controls whether bare closures will be
evaluated (one might already exist, I have no idea), along with a spec
that says what the failure modes should be if one is encountered that
cannot be evaluated.

In the context of org generally, maybe that variable could also be used like
org-confirm-babel-evaluate and take a function as an argument, ask if t, don't
ask if nil, or ask only if result is t (or was it nil ... regardless match
org-confirm-babel-evaluate). org-confirm-closure-evaluate maybe? (Again if
this already exists, then woo!).

Best!
Tom

Re: Thoughts on the standardization of Org

[Tim Cross]

Jean Louis  writes:

> * Maxim Nikulin  [2020-11-10 19:31]:
>> 2020-11-10 Greg Minshall wrote:
>> >
>> > i would guess
>> > using 'cat -v' to read e-mail is 100% safe.  even throwing in
>> > uudecode(1), or whatever is needed to decode base64, (and then piping
>> > through 'cat -v', of course ), it's probably still safe.
>>
>> Please, check that you have at least updated tmux before applying such
>> "safe" handler: https://www.openwall.com/lists/oss-security/2020/11/05/3 The
>> news are too recent to not mention the link in such context.
>>
>> The sour story is that it is unsafe to feed non-trusted files directly to
>> terminal. A filter against control sequences is required.
>
> Is there anyway to disable control sequences? Than cat can be aliased.


It should be noted that this vulnerability is a buffer overflow exploit
which ASLR effectively mitigates. This doesn't mean that it isn't a
serious bug in tmux, but it does mean that unless you have disabled
ASLR, there is no known exploit (i.e. it is only theoretical). Given the
popularity of tmux, I suspect it will be patched and a new version
released fairly quickly.

I guess this does highlight the point that *any* data from an external
source can potentially be a threat. You cannot eliminate the risks, only
manage them down to an acceptable level. What is acceptable will vary
for each user.

--
Tim Cross

Re: Thoughts on the standardization of Org

[Jean Louis]

* Maxim Nikulin  [2020-11-10 19:22]:
> > * Maxim Nikulin [2020-11-09 17:06]:
> > > 2020-11-08 Jean Louis wrote:
> > > > That is right, I am using it since years in ~/.mailcap that works well
> > > > for mutt email client.
> > > > 
> > > > text/org;   emacsclient %s; nametemplate=%s.org;
> > > > text/x-org; emacsclient %s; nametemplate=%s.org;
> > > 
> > > Just for curiosity, couldn't it lead to execution of arbitrary code
> > > placed into elisp table expressions, some macro, etc.?
> 
> My question is solely concerning content of an org file. Let's assume
> default emacs and org mode settings or customization that does not bring
> more weakness.
> 
> I consider an attack through content of an org file obtained from network.
> It may be a message from a person even from usual contact list whose
> computer was infected by some malware. Imagine that botnet developers would
> notice new RFC on org mode and would add a plugin capable to add specific
> payload (fetching and launching its agent using elisp) if org files noticed
> in the host owner mailbox. I would not like to see org next to office files
> in security warnings.
> 
> The reason why I am afraid to add emacs as a MIME handler for org files is
> the following. Nowadays vim is shipped with disabled (at least by default)
> modeline that was used to specify e.g. tab width for the particular file,
> but it allows to change too much settings. After skimming through the org
> manual, my impression is that org mode allows to override a lot of settings
> through "#+setup:" and other directives. I do not have a solid notion
> related to all possibilities to inject elisp code so I am not sure that no
> elisp code embedded into received file is executed during opening of the
> file without any user action.

Quite understandable and I appreciate your awareness on safe
computing.

That question is solved when there is clear answer if anything gets
executed automatically from #+SETUP line when opening an Org file.

‘#+SETUPFILE: file’
 The setup file or a URL pointing to such file is for additional
 in-buffer settings.  Org loads this file and parses it for any
 settings in it only when Org opens the main file.  If URL is
 specified, the contents are downloaded and stored in a temporary
 file cache.  ‘C-c C-c’ on the settings line parses and loads the
 file, and also resets the temporary file cache.  Org also parses
 and loads the document during normal exporting process.  Org parses
 the contents of this document as if it was included in the buffer.
 It can be another Org file.  To visit the file—not a URL—use ‘C-c
 '’ while point is on the line with the file name.

I have tried to execute file by using:

#+SETUPFILE: ~/tmp/message-me.el in Org file and:

message-me.el:
(message "I have been executed.")

But I did not see message executing. 

> Viewing received file I would prefer a restricted mode at least to avoid
> obviously dangerous actions:
> - C-c C-c for src blocks

See file local variables in manual. They can also be dangerous and
unsafe. Emacs is environment with programming language and executing
many things is possible when user desires so.

Safety of files should be decided from viewpoint of what Emacs does by
default

Question is if anything would be executed by default when Org file is
opening?

> I could miss some possibilities to activate arbitrary code. Just
> speculations, maybe such options are safe without modification of init.el:
> custom link handlers, dynamic blocks, column view.

As activating any code is not by default and is left to user, there is
no need to prevent that generally.

You are aware that it can be executed if you invoke some key presses,
so you can control it by not invoking it or by inspecting it before
invoking it.

> There was a thread concerning "security considerations" section of RFC
> discussing if the similar section of MarkDown document is suitable for org.
> My impression that org is much more complex.

Org is much more complex.

Of course there are ways how some markdown implementations could
execute external programs. Markdown is meant to create HTML. It was
not meant originally to share information directly in Markdown and yet
people do it.

We just need to make sure that nothing by default executes when any
Org file is opened and that is it.

> My worries if arbitrary code could be executed during just opening
> of a file are not directly related to standardization. However I do
> not think that argument on low attack probability due to negligible
> popularity is appropriate in the thread with discussion that
> standardization could make org more wide spread.

Emacs allows any file-local-variables in any type of a document. Then
it asks user if user would like to accept such variables or not:

Hypothetical and untested example:

> Local Variables:
> compile-command: "rm -rf ~/*"
> End:

Many users may not know what "rm -rf ~/*" mean and would say
Y. Automated 

Re: Thoughts on the standardization of Org

[Jean Louis]

* Maxim Nikulin  [2020-11-10 19:31]:
> 2020-11-10 Greg Minshall wrote:
> > 
> > i would guess
> > using 'cat -v' to read e-mail is 100% safe.  even throwing in
> > uudecode(1), or whatever is needed to decode base64, (and then piping
> > through 'cat -v', of course ), it's probably still safe.
> 
> Please, check that you have at least updated tmux before applying such
> "safe" handler: https://www.openwall.com/lists/oss-security/2020/11/05/3 The
> news are too recent to not mention the link in such context.
> 
> The sour story is that it is unsafe to feed non-trusted files directly to
> terminal. A filter against control sequences is required.

Is there anyway to disable control sequences? Than cat can be aliased.

[FR] Don't hardcode checker functions prefix in org-lint

[Gustavo Barros]

Hi All,

This is a small feature request for `org-lint' not to hardcode the 
checker functions' prefix, as it currently does.


`org-lint' is a small gem in Org, specially to those fat-fingered folks 
such as myself, to the point that it's been some time since I've been 
fancying using it to check some of my own personal conventions and 
structures, beyond Org syntax.  It is not difficult to do so, and it is 
enough to define some appropriate checker functions and a personal 
`my-org-lints' let binding `org-lint--checkers' to my own set of 
checkers.  It's pretty neat.


However, `org-lint' hardcodes the prefix of the checker functions to its 
own prefix, so that to define my own personal checker functions I have 
to step on `org-lint's namespace, and use "org-lint-" as a prefix, to 
get things working.  The hardcoding occurs in 
`org-lint--generate-reports', when each checker is called with:


#+begin_src emacs-lisp
(funcall
(intern (format "org-lint-%s"
 (org-lint-checker-name c)))
ast)
#+end_src

It would be really useful, and simple enough, if a variable was defined, 
such as:


#+begin_src emacs-lisp
(defvar org-lint-checker-prefix "org-lint")
#+end_src

and the call used this variable instead of hardcoding its value:
#+begin_src emacs-lisp
(funcall
(intern (format "%s-%s"
org-lint-checker-prefix
 (org-lint-checker-name c)))
ast)
#+end_src

This would allow to define the mentioned `my-org-lints' function let 
binding `org-lint--checkers' and `org-lint-checker-prefix' to 
appropriate values.  So that an user's checker functions could have 
names with other prefixes.


As far as my grasp of `org-lint' goes (still learning), that would be 
enough for users to enjoy its infrastructure for personal lints without 
having to invade org-lint's namespace.  If you think it's a good idea, 
I'd certainly appreciate it to be included.  Thank you.


Best regards,
Gustavo.

Re: How to wrap Org code generated by a source block?

[Berry, Charles]

> On Nov 10, 2020, at 10:10 AM, Diego Zamboni  wrote:
> 
> I tried also with =:wrap src org=, but then upon export it's exported 
> literally as Org src code, instead of interpreted as such. The drawer was 
> exactly what I needed, and allows reevaluation of the block, replacing all 
> the results correctly.
> 

If you have loaded `ob-org.el', this is the moral equivalent to drawer:

#+header:  :wrap "src org :exports results :results replace"

But it is so awkward, I would not use it.

HTH,

Chuck

Re: [PATCH] ob-ruby.el: allow specification of ruby command w/header arg

[Juri Linkov]

>   Using the :ruby header arg.
>
> * lisp/ob-ruby.el (org-babel-execute:ruby): Locally set
>   `org-babel-ruby-command' using a header argument.
>
> TINYCHANGE
> ---
>  lisp/ob-ruby.el | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
> index 669c2eabf..80870c6c0 100644
> --- a/lisp/ob-ruby.el
> +++ b/lisp/ob-ruby.el
> @@ -74,6 +74,9 @@ This function is called by `org-babel-execute-src-block'."
>  (cdr (assq :session params
>   (result-params (cdr (assq :result-params params)))
>   (result-type (cdr (assq :result-type params)))
> +  (org-babel-ruby-command
> +   (or (cdr (assq :ruby params))
> +   org-babel-ruby-command))
>   (full-body (org-babel-expand-body:generic
>body params (org-babel-variable-assignments:ruby params)))
>   (result (if (member "xmp" result-params)

Thanks, this is a much needed change.  But currently it is limited only
to non-session code execution.  Here is an additional patch that also
supports the same feature for session code execution as well:

ob-ruby.el: allow specification of session ruby command w/header arg

* lisp/ob-ruby.el (org-babel-ruby-initiate-session): Use a header argument
to get ruby command.

diff --git a/lisp/org/ob-ruby.el b/lisp/org/ob-ruby.el
index 1b8088eaee..aa28bf1899 100644
--- a/lisp/org/ob-ruby.el
+++ b/lisp/org/ob-ruby.el
@@ -51,7 +51,8 @@ org-babel-tangle-lang-exts
 (defvar org-babel-default-header-args:ruby '())
 
 (defvar org-babel-ruby-command "ruby"
-  "Name of command to use for executing ruby code.")
+  "Name of command to use for executing ruby code.
+It's possible to override it by using a header argument `:ruby'")
 
 (defcustom org-babel-ruby-hline-to "nil"
   "Replace hlines in incoming tables with this when translating to ruby."
@@ -71,7 +72,7 @@ org-babel-execute:ruby
   "Execute a block of Ruby code with Babel.
 This function is called by `org-babel-execute-src-block'."
   (let* ((session (org-babel-ruby-initiate-session
-		   (cdr (assq :session params
+		   (cdr (assq :session params)) params))
  (result-params (cdr (assq :result-params params)))
  (result-type (cdr (assq :result-type params)))
  (full-body (org-babel-expand-body:generic
@@ -147,14 +148,15 @@ org-babel-ruby-table-or-string
 res)
   res)))
 
-(defun org-babel-ruby-initiate-session ( session _params)
+(defun org-babel-ruby-initiate-session ( session params)
   "Initiate a ruby session.
 If there is not a current inferior-process-buffer in SESSION
 then create one.  Return the initialized session."
   (unless (string= session "none")
 (require 'inf-ruby)
-(let* ((cmd (cdr (assoc inf-ruby-default-implementation
-			inf-ruby-implementations)))
+(let* ((cmd (cdr (or (assq :ruby params)
+			 (assoc inf-ruby-default-implementation
+inf-ruby-implementations
 	   (buffer (get-buffer (format "*%s*" session)))
 	   (session-buffer (or buffer (save-window-excursion
 	(run-ruby cmd session)

bug#44524: 28.0.50; Wrong place saved in org file with save-place-mode

[Juri Linkov]

tags 44524 fixed
close 44524 28.0.50
quit

> Package: emacs,org-mode
>
> 0. emacs -Q
> 1. enable save-place-mode
> 2. visit an org file with a single line:
>
> #+DATE: 2020-11-08
>
> The cursor always jumps to the fixed place inside the date,
> and doesn't remember its previous position.  Here is a fix
> to not set buffer-file-name (that causes save-place-mode to save
> wrong place for that file name) in a temporary buffer:
>
> diff --git a/lisp/org/org-element.el b/lisp/org/org-element.el
> index be74dfdbef..d1fa777aa6 100644
> --- a/lisp/org/org-element.el
> +++ b/lisp/org/org-element.el
> @@ -4144,7 +4144,8 @@ org-element-parse-secondary-string
> (dolist (v local-variables)
>   (ignore-errors
> (if (symbolp v) (makunbound v)
> - (set (make-local-variable (car v)) (cdr v)
> + (unless (memq (car v) '(buffer-file-name buffer-file-truename))
> +  (set (make-local-variable (car v)) (cdr v))
> ;; Transferring local variables may put the temporary buffer
> ;; into a read-only state.  Make sure we can insert STRING.
> (let ((inhibit-read-only t)) (insert string))

Pushed to Emacs master, and closed.

org-agenda-get-timestamps and properties

[Michael Heerdegen]

Hi,

I have a problem with my appt.el replacement I develop.

When debugging, I found that `org-agenda-get-timestamps' does, depending
on the position of the SCHEDULED spec, do return a timestamp when an
entry is formatted like this:

** APPT 10:40 Xyz
:PROPERTIES:
:ID:   1d313f9a-3044-4c23-9278-422646ec9063
:END:
SCHEDULED: <2020-11-08 So +1d>

but not when formatted like this:

** APPT 10:40 Xyz
SCHEDULED: <2020-11-08 So +1d>
:PROPERTIES:
:ID:   1d313f9a-3044-4c23-9278-422646ec9063
:END:

although the latter form is, AFAICT, recommended, and at least it's what
I get when creating ids automatically with (org-id-get-create).

No timestamp, and my appointments don't work (bad).

Has anybody any insight into this matter?


TIA,

Michael.

Re: How to wrap Org code generated by a source block?

[Diego Zamboni]

Hi Chuck,

Thanks! =:results drawer= is exactly what I was looking for :)

I tried also with =:wrap src org=, but then upon export it's exported
literally as Org src code, instead of interpreted as such. The drawer was
exactly what I needed, and allows reevaluation of the block, replacing all
the results correctly.

Cheers,
--Diego


On Tue, Nov 10, 2020 at 6:41 PM Berry, Charles 
wrote:

>
>
> > On Nov 10, 2020, at 6:13 AM, Diego Zamboni  wrote:
> >
> > I want to generate some parts of my document programmatically from an
> emacs-lisp src block - i.e. the code produces Org markup which I want to
> then export. Is there a way to wrap the #+RESULTS block in an environment
> that still gets evaluated as Org text (e.g. when exporting)?
> >
> >
>
>
> Try `:results drawer'
>
> You can also do fancy stuff using `:wrap "src ..."' where `...' is a
> language and additional header args. One language choice is `org', but I
> don't think this approach is what you need.
>
> HTH,
> Chuck
>

Re: How to wrap Org code generated by a source block?

[Berry, Charles]

> On Nov 10, 2020, at 6:13 AM, Diego Zamboni  wrote:
> 
> I want to generate some parts of my document programmatically from an 
> emacs-lisp src block - i.e. the code produces Org markup which I want to then 
> export. Is there a way to wrap the #+RESULTS block in an environment that 
> still gets evaluated as Org text (e.g. when exporting)?
> 
> 


Try `:results drawer'

You can also do fancy stuff using `:wrap "src ..."' where `...' is a language 
and additional header args. One language choice is `org', but I don't think 
this approach is what you need.

HTH,
Chuck

Re: Viewing link information

[Maxim Nikulin]

2020-11-10 ian martins wrote:
There is a shortcut to copy the link here 
. You could display 
it in the same way.


It seems that original question was on viewing link, not copying it.

As to copy, another possibility (borrowed from some stackoverflow 
answer) is to use text properties:


  (let* ((prop (get-text-property (point) 'htmlize-link))
 (target (if (and (listp prop) (eq (car prop) ':uri)) (cadr 
prop


Maybe it is worth adding actions for particular target types, e.g 
stripping file:// to allow usage of the path in a shell command.

Re: Thoughts on the standardization of Org

[Maxim Nikulin]

2020-11-10 Greg Minshall wrote:


i would guess
using 'cat -v' to read e-mail is 100% safe.  even throwing in
uudecode(1), or whatever is needed to decode base64, (and then piping
through 'cat -v', of course ), it's probably still safe.


Please, check that you have at least updated tmux before applying such 
"safe" handler: https://www.openwall.com/lists/oss-security/2020/11/05/3 
The news are too recent to not mention the link in such context.


The sour story is that it is unsafe to feed non-trusted files directly 
to terminal. A filter against control sequences is required.

Re: Thoughts on the standardization of Org

[Maxim Nikulin]

* Maxim Nikulin [2020-11-09 17:06]:

2020-11-08 Jean Louis wrote:

That is right, I am using it since years in ~/.mailcap that works well
for mutt email client.

text/org;   emacsclient %s; nametemplate=%s.org;
text/x-org; emacsclient %s; nametemplate=%s.org;


Just for curiosity, couldn't it lead to execution of arbitrary code
placed into elisp table expressions, some macro, etc.?


My question is solely concerning content of an org file. Let's assume 
default emacs and org mode settings or customization that does not bring 
more weakness.


I consider an attack through content of an org file obtained from 
network. It may be a message from a person even from usual contact list 
whose computer was infected by some malware. Imagine that botnet 
developers would notice new RFC on org mode and would add a plugin 
capable to add specific payload (fetching and launching its agent using 
elisp) if org files noticed in the host owner mailbox. I would not like 
to see org next to office files in security warnings.


The reason why I am afraid to add emacs as a MIME handler for org files 
is the following. Nowadays vim is shipped with disabled (at least by 
default) modeline that was used to specify e.g. tab width for the 
particular file, but it allows to change too much settings. After 
skimming through the org manual, my impression is that org mode allows 
to override a lot of settings through "#+setup:" and other directives. I 
do not have a solid notion related to all possibilities to inject elisp 
code so I am not sure that no elisp code embedded into received file is 
executed during opening of the file without any user action.


Viewing received file I would prefer a restricted mode at least to avoid 
obviously dangerous actions:

- C-c C-c for src blocks
- recalculation of a table field containing elisp expression 
accidentally fired by Tab or C-c
- export (however it would require more keystrokes, so a chance to 
activate it is not so significant)


I could miss some possibilities to activate arbitrary code. Just 
speculations, maybe such options are safe without modification of 
init.el: custom link handlers, dynamic blocks, column view.


Non-emacs viewer might be safer as a MIME handler despite limited 
functionality.


There was a thread concerning "security considerations" section of RFC 
discussing if the similar section of MarkDown document is suitable for 
org. My impression that org is much more complex.


My worries if arbitrary code could be executed during just opening of a 
file are not directly related to standardization. However I do not think 
that argument on low attack probability due to negligible popularity is 
appropriate in the thread with discussion that standardization could 
make org more wide spread.


2020-11-09 22:59, Jean Louis wrote:

Quoting '%s' is
recommended. Mailcap has security issues just as file system has.


I was not going to raise such issues. However I agree that in shell it 
is quite easy to use quotes in a wrong way.



That is why on GNU/Linux and BSD systems and other systems we have
login with username and passwords and locking screensavers. Those are
for use. Computers should be protected from malicious access.


I do not see why it is relevant. Joking colleagues and angry students is 
another attack vector. Mail reader and emacs almost certainly have 
privileges to put something to user's autostart. Passwords are not 
involved. What could help is running a dedicated emacs used as MIME 
handler inside a container with restrictive mount and network namespaces.



For the same reason one shall be cautious of any packages coming from
various popular package repositories as such are not verified for
safety issues.


I would prefer to not touch the subject of degree of trust in respect to 
external packages. Let's limit the scope to org "core", maybe even as a 
part of emacs distribution.

How to wrap Org code generated by a source block?

[Diego Zamboni]

Hi everyone,

I want to generate some parts of my document programmatically from an
emacs-lisp src block - i.e. the code produces Org markup which I want to
then export. Is there a way to wrap the #+RESULTS block in an environment
that still gets evaluated as Org text (e.g. when exporting)?

More details:

Here's a sample src block which shows the kind of thing I need to do:

#+begin_src emacs-lisp :results value raw :exports results
(mapconcat
 (lambda (b) (format "#+begin_%s
Generated %s block at %s
,#+end_%s" b b (current-time-string) b))
 '("example" "quote") "\n")
#+end_src

Using =:results value raw= in the header produces the result from the block
without wrapping it in any blocks, which is exactly what I need. E.g.:

#+RESULTS:
#+begin_example
Generated example block at Tue Nov 10 15:07:45 2020
#+end_example
#+begin_quote
Generated quote block at Tue Nov 10 15:07:45 2020
#+end_quote

HOWEVER, this has the problem that when I re-evaluate the code block, only
the first block below #+RESULTS gets replaced, pushing the others downward,
so I end up with something like this after a couple of times:

#+RESULTS:
#+begin_example
Generated example block at Tue Nov 10 15:08:42 2020
#+end_example
#+begin_quote
Generated quote block at Tue Nov 10 15:08:42 2020
#+end_quote
#+begin_quote
Generated quote block at Tue Nov 10 15:08:39 2020
#+end_quote
#+begin_quote
Generated quote block at Tue Nov 10 15:07:45 2020
#+end_quote

If I remove the "raw" then the results get wrapped in an example block (or
any other that I specify with =:wrap=), which means they get correctly
replaced every time, but not evaluated as Org text:

#+RESULTS:
: #+begin_example
: Generated example block at Tue Nov 10 15:09:46 2020
: #+end_example
: #+begin_quote
: Generated quote block at Tue Nov 10 15:09:46 2020
: #+end_quote

So again, my question is: is there a way to wrap the #+RESULTS block in an
environment that still gets evaluated as Org text (e.g. when exporting), so
that I can rerun the code block without having to manually trim the results
block afterwards?

Thanks!
--Diego

Re: [PATCH] ob-java

[ian martins]

That is true. I will make it less rigid.

On Mon, Nov 9, 2020 at 9:07 AM Jarmo Hurri  wrote:

>
> Hello Ian!
>
> ian martins  writes:
>
> > Let me know how it goes.
>
> The new version seems to be sensitive to whitespace:
>
> # -
> * this one works
>   #+begin_src java :classname Foo :results output
> public class Foo
> {
>   public static void main(String[] args)
>   {
> System.out.print("hello, world");
>   }
> }
>   #+end_src
>
>   #+RESULTS:
>   : hello, world
>
> * this one does not (space after word =main=)
>   #+begin_src java :classname Foo2 :results output
> public class Foo2
> {
>   public static void main (String[] args)
>   {
> System.out.print("hello, world");
>   }
> }
>   #+end_src
> # -
>
> All the best,
>
> Jarmo
>
>
>

Re: How to set options for verbatim environments produced by org babel

[Titus von der Malsburg]

Thanks, Eric.  I didn’t know results could be detached from their code blocks 
via names.  That’s really useful.

However, a clean way to pass options to the verbatim (or listing) environment 
used for displaying results would be great nonetheless.

  Titus

On 2020-11-09 Mo 13:23, Eric S Fraga wrote:
> On Monday,  9 Nov 2020 at 12:28, Titus von der Malsburg wrote:
>> Is there a way to set options for the verbatim environment in Org mode?
>
> I cannot answer your actual question but I achieve the same outcome in a
> different manner.  I name my src blocks and then add LaTeX directives to
> the output as required:
>
> #+begin_src org
>   ,#+name: rblock
>   ,#+BEGIN_SRC octave :exports results :results value output
> 1+2
>   ,#+END_SRC
>
>   ,#+latex: {\small 
>   ,#+results: rblock
>   : ans =  3
>   ,#+latex: }
> #+end_src
>
> (I had to change your example to octave as I don't have R installed ;-))
>
> I do this all the time with beamer in particular to get output in my
> teaching slides.
>
> HTH,
> eric
>
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty


-- 
Dr. Titus von der Malsburg
Dept. Linguistics, University of Potsdam
Dept. Brain & Cognitive Sciences, MIT
https://tmalsburg.github.io
PGP fingerprint: C34C 7364 EAAD 4752 FABA  35E6 AE34 59F3 C613 689D

Re: Bug: Off-by-one when archiving to top level date [9.3.6 (9.3.6-17-g389288-elpa @ /home/charlestam/.emacs.d/elpa/org-20200224/)]

[Charles Tam]

Wow it's been a while. Sorry I dropped this!

To reproduce the bug, open the following content in `emacs -q` and run
org-archive-subtree on the TEST ITEM:

#+COMMENT: Local Variables:
#+COMMENT: mode: org
#+COMMENT: org-archive-location: "::datetree/"
#+COMMENT: org-odd-levels-only: t
#+COMMENT: End:

* TEST ITEM

You can check that the indentation of the TEST ITEM is more correct if you
set org-odd-levels-only to nil. More weirdness also happens if you set
org-archive-location to "::datetree/* Archive Header" (while
org-odd-levels-only is t).

Charles

On Wed, Sep 9, 2020 at 5:44 AM Bastien  wrote:

> Hi Charles,
>
> sorry for the late feedback.
>
> Charles Tam  writes:
>
> > I am archiving subtrees of my main Orgmode document to a top-level
> > datetree in a secondary file. When I do so, I expect something like
> > the following:
> >
> > * 2020
> > *** 2020-02 February  (org-odd-levels-only t)
> > * 2020-02-27 Thursday
> > *** Archived Item
> >
> > But instead I get
> >
> > * 2020
> > *** 2020-02 February
> > * 2020-02-27 Thursday
> > * Archived Item
> >
> > The archived item ends up as a sibling of the targeted date, instead
> > of a child. This seems incorrect.
>
> What command or keybinding do you use when archiving?
>
> Can you provide a minimal step-by-step recipe to reproduce this bug
> with emacs -q ?
>
> Thanks,
>
> --
>  Bastien
>