Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> I do wonder if it would be a good idea to try and document when org will
>> evaluate code in org files. This would include not just babel block
>> evaluation, but also elisp evaluation in table formulas, block header
>> arguments, file option arguments and possibly other subtle cases. This
>> may enable us to see if we have the granularity of controls correct or
>> identify inconsistencies and omissions. This information might then be
>> useful in defining a security model which could then identify what
>> controls are actually necessary and how to implement them to provide a
>> more straight-forward configuration for end users. It could also provide
>> valuable input into what additional tests may be necessary to ensure
>> things are working as expected. 
>
> 17.13 Code Evaluation and Security Issues

That page is a good start. However, I think it highlights why not having
a clear model limits the utility of the options being provided.

Consider this scenario -

I am a reasonably experienced Emacs user, but wouldn't describe myself
as proficient with elisp. I can do some basic stuff and I have an
init.el file which I basically understand, although there are some
borrowed bits which to be honest, I don't fully understand.

I use org mode a lot. I really like literate programming and find the
whole babel stuff really cool. I also make extensive use of tables and
the spreadsheet capability to track statistics on my projects and use
gnuplot, ditta and plantuml to generate plot, diagrams etc from that
data. Obviously, I trust all the code in these files as I wrote it!

On occasion, I get org files from colleagues. While I do basically trust
my colleagues, I don't want to just blindly allow execution of the code
in these files. I would like to check what the code does before agreeing
to allow it to run.

On very rare occasions, I get an org file from an untrusted source. In
this situation, I want iron clad assurances none of the code from this
file is executed.

Based on the information in section 17.13, how do I configure my Emacs
so that

1. All the code in the files I wrote just runs and doesn't bother me with
annoying execute questions.

2. Code in files from colleagues is shown to me and I'm asked if it
should be executed. Once I say yes, I don't want to be bothered about it
again i.e. next time I open that file, I want org mode to know I trust
it.

3. Absolutely no code in files which are not from the two preceding
sources is to be executed unless I explicitly approve it. 

How does this fictitious user achieve this configuration? Is it a
reasonable expectation that most users will be able to write the elisp
necessary to achieve this model?

It feels like what we currently have is a selection of disconnect knobs
which the user can tweak, but with no over-arching mechanism to help
manage these settings for various scenarios.

Finally, are we 100% certain that these different code evaluation
circumstances are the only ones? Can we be certain there isn't areas
where options or variables are set which couldn't be used to evaluate
code (similar to be previously identified execution of code in block
headers which occurred before the checks on code evaluation?)?  

It also feels like the approach we have taken here is almost a throwback
to a past era where he had a lot more trust. What we seem to have is
protection against accidental execution of code rather than protection
against code with malicious intent which has been crafted to be
difficult to spot and deliberately takes advantages of small 'holes' or
over-sight in the controls supplied.

Re: orgmode 9.6

[Jean Louis]

* Paul Schlesinger  [2022-12-16 02:04]:
> started getting an encoding warning when i would tell emacs I wanted to
> quit. The warning indicated the offending characters but they were in an
> unformatted buffer on the screen and I became fatigued trying to correct
> them.  

That will happen not only in the Org mode.

What do you see on screen, which are the problematic characters?



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Pedro Andres Aranda Gutierrez]

No, please. For two reasons:

1.- In HTML, you have 
2.- This could trickle to other backends where it makes sense

Thanks, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Tim Cross  writes:

> I do wonder if it would be a good idea to try and document when org will
> evaluate code in org files. This would include not just babel block
> evaluation, but also elisp evaluation in table formulas, block header
> arguments, file option arguments and possibly other subtle cases. This
> may enable us to see if we have the granularity of controls correct or
> identify inconsistencies and omissions. This information might then be
> useful in defining a security model which could then identify what
> controls are actually necessary and how to implement them to provide a
> more straight-forward configuration for end users. It could also provide
> valuable input into what additional tests may be necessary to ensure
> things are working as expected. 

17.13 Code Evaluation and Security Issues

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: orgmode 9.6

[Ihor Radchenko]

Paul Schlesinger  writes:

> ...  At the end of the day I quit emacs, saving all my
> work for the day in a very large folder tree that includes all my working
> files and this is rsync'ed onto a usb disk that is a backup and is
> sync'ed to a disk on my home computer and I have redundant backups. About
> one month ago upgraded to orgmode  9.6 using elpa  and about a week ago I
> started getting an encoding warning when i would tell emacs I wanted to
> quit. The warning indicated the offending characters but they were in an
> unformatted buffer on the screen and I became fatigued trying to correct
> them.  If I save the file as raw-text I preserve all the org formatting and
> structure.  I upgraded ny home computer to 9.6 and this started happening
> on it also.

Thanks for reporting!

Did you notice which file this happened to?
If you did, does opening only that file, editing it, and closing trigger
the issue?

We need more information to understand what is happening.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[FR] Add support for racket images in org-babel

[dalanicolai]

Hello,

I am trying out racket  which seems to provide a
quite nice plotting package .
Also, it is easy to install and configure, easy to learn. and it has great
learning material.
It looks like a great simple (compared to common-lisp or clojure)
alternative to python
(so far for the enthusiasm).

I have not asked anywhere yet, but I do not know a 'standard org-mode' way
to make org-mode show the plot images. Racket creates a temp image file and
returns a string that includes the path to the file. The actual format of
the string is:

"\"#\""

I could create a patch for it, but I am not sure how to best implement it
(in a clean way).

Currently, I am simply using the following advice (while including in the
header ':results file'):

  (with-eval-after-load 'ob-scheme
> (defun ob-racket-advice (orig-fun  args)
>   (let ((result (print (apply orig-fun args
> (if (string-match "\"# (nth 1 (string-split result " " nil ">\""))
>   result)))
>
> (advice-add 'org-babel-execute:scheme :around #'ob-racket-advice))
>

however, it would be great if support could be added to ob-scheme itself.
I would be happy to do it, but as mentioned before I don't think I know how
to do it in the proper way. I would probably just add a condition around the
'result' in 'org-babel-execute:scheme' as follows:

  (org-babel-result-cond result-params
>(if (and (eq impl 'racket)
>  (string-match "\"# (nth 1 (string-split result " " nil ">\""))
>   result)
>(org-babel-scheme--table-or-string table)))
>

Thank you!

orgmode 9.6

[Paul Schlesinger]

Using the included orgmode 9.52 on emacs 28.1 for much of my daily work,
university professor.  At the end of the day I quit emacs, saving all my
work for the day in a very large folder tree that includes all my working
files and this is rsync'ed onto a usb disk that is a backup and is
sync'ed to a disk on my home computer and I have redundant backups. About
one month ago upgraded to orgmode  9.6 using elpa  and about a week ago I
started getting an encoding warning when i would tell emacs I wanted to
quit. The warning indicated the offending characters but they were in an
unformatted buffer on the screen and I became fatigued trying to correct
them.  If I save the file as raw-text I preserve all the org formatting and
structure.  I upgraded ny home computer to 9.6 and this started happening
on it also.  I have returned my current computers to the included org 9.52
and the problem has stopped.  Can anyone report a similar issue, a cause
and a solution.
Thank you

Paul H. Schlesinger MD, PhD
Washington University School of Medicine
Don't let your models of reality become confused with reality itself.

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Tim Cross]

Max Nikulin  writes:

> On 15/12/2022 19:25, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> I would consider reverting the commit causing user prompt for every
>>> variable.
>> I disagree. If anything, we can set the default value of
>> `org-confirm-babel-evaluate-cell' to nil and apply this patch.
>> Then, we can get the old behaviour back yet allowing concerned users to
>> have more security.
>
> I am leaving it up to you. Form my point of view it will be dead code that 
> increases
> complexity with no practical outcome. Unfortunately setting
> `org-confirm-babel-evaluate-cell' to anything other than nil results in 
> annoyance rather
> than security.
>
> Perhaps advising `org-babel-execute-src-block' with `y-or-n-p' is a better 
> treatment for
> my paranoia.
>
>> This patch does not only affect src blocks. It affects all the users of
>> `org-babel-read'.
>
> Mostly it is called with INHIBIT-LISP-EVAL set to t.
>
>>> https://list.orgmode.org/Y1uFDWOjZb85lk+3@protected.localdomain
>>> Re: [BUG][Security] begin_src :var evaluated before the prompt to
>>> confirm execution
>> How is it related to the current discussion?
>> The purpose of the security feature discussed here is not for web
>> browsers or anything like that.
>
> I am not going to add malicious source blocks to my private org files. For 
> some code it is
> better to have a prompt, but generally the issue is not excessively 
> important. I tend to
> inspect org files fetched from net in some other application at first 
> (browser, less, or
> vim).
>

While I would argue that is a good practice, it isn't always practicable
for all users. For example, Emacs together with Emacspeak is my primary
accessible interface. While I could use a browser, it would be severely
inconvenient and frustrating.

I have to admit I also have some concerns here. These may or may not be
well founded. My biggest concern is that we don't seem to have a clear
security model. It feels like we are responding to security threats in a
piecemeal and reactive manner and without any clear model. As a result,
there is a risk we will end up with a complex solution where we don't
fully understand how all the separate pieces interact. This could result
in a complex configuration with a low level of confidence, two of
the worst attributes to have when it comes to security.




> Accidental evaluation of code is a real danger for those who insist on 
> opening links to
> org file directly in emacs or even propose to use org as a kind of browser. I 
> raised the
> security issue in response to passionate messages demanding direct ways to 
> work with org
> files from the web. I decided to remind the context with hope that it would 
> help to
> reevaluate severity of the issue.
>

My concern here is that given the power of link configuration, source
blocks, local variables, .dir-local, evaluated block header code etc, it
is extremely difficult to actually know when code will be executed.

One thing I do feel is a risk is that if we don't get the right balance,
the questions about code evaluation may fall to the level of annoying
noise which people get rid of by simply enabling all code evaluation
without question. Obviously, this would be a very bad security decision,
but as we know from years of experience, users will frequently
prioritise convenience over security. If they are unnecessarily 'nagged'
regarding code evaluation, I suspect this is what will happen (noting
that unnecessary is very subjective). 

> I do not have a better proposal, but I think I see movement in a wrong 
> direction.

I'm not sure if I have a better proposal either. I'm not even sure if
this is solely an org issue. It could be that Emacs itself needs a
clearer or better understood and explicit security model. This seems
particularly relevant given the growth in support for downloading,
installing and running code from packages distributed by repositories
with no assessment or vetting of code. I find it quite inconsistent that
when I download and install a new theme, I have to explicitly mark it as
'safe', but I can download a package from melpa, elpa etc with no
additional checks or without having to agree to allow access to whatever
service or data it wants. 

I do wonder if it would be a good idea to try and document when org will
evaluate code in org files. This would include not just babel block
evaluation, but also elisp evaluation in table formulas, block header
arguments, file option arguments and possibly other subtle cases. This
may enable us to see if we have the granularity of controls correct or
identify inconsistencies and omissions. This information might then be
useful in defining a security model which could then identify what
controls are actually necessary and how to implement them to provide a
more straight-forward configuration for end users. It could also provide
valuable input into what additional tests may be necessary to ensure
things are working as expected. 

Re: [PATCH] LSP support in org-src buffers

[João Pedro]

On Mon, December 12 2022 13:16, Ihor Radchenko  wrote:

> If an src block has :tangle option, it is probably reasonable to display
> it together with other tangled blocks.
> If an src blocks does not have a :tangle option, :context might be used
> as the means to group blocks together. But then, the value should be
> some kind of string - blocks with the same :context name will be grouped
> together.

That makes much more sense. Though I still think the user should be able
to, even with a :tangle option, be able to choose whether they want to
edit that particular source block with the whole context or not, cause
it might be slow for some huge tangled files, for example.

> And, of course, the whole thing may be behind a defcustom switch. Or
> file option.

Yup! I prefer to have both options, a file option and a defcustom. This
allows me to have a global configuration, but change it to a particular
file without having to deal with the local variables block in Org files.

> We are not in hurry. Any progress will be appreciated as long as there
> is some.

All right. I'll keep you posted on it.

-- 
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Ihor Radchenko]

Bastien, I need your comment on the old commit of yours.

Stefan  writes:

>> 2. If you can, try to load Emacs with minimal Org-related settings.
>>Then, try to load agenda and let me know if you see the warning.
>
> I did some manual bisecting of my config, and I noticed that the warnings in 
> "Media.org" go away when I remove `(org-startup-align-all-tables t)` from my 
> config.  
>
> So I did some more digging, reduced 
> my config to just contain `org-startup-align-all-tables` set to t, 
> my agendas limited to Media.org, 
> and removed most headings from Media.org.

Thanks! It looks like you found the culprit.

`org-startup-align-all-tables' triggers a function that changes buffer
contents (tables) during Org loading. For same reason, this function is
executed with modification hooks being suppressed and cache missing the
edits as a result.

The problematic commit is
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9c4d403ada376dca771d9c2dadd7e9eebf4d5f7f

The commit seems to be applied around the time when we did some
aggressive optimizations for agenda views. However, I do not see any
email thread relevant to this particular commit.

Bastien, do you remember the rationale behind the linked commit? The
commit message is not particularly informative.

It appears to me that removing `org-unmodified' around table alignment
should be safe, but I may be missing something.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hi,

On Thu, Dec 15, 2022, at 13:16, Ihor Radchenko wrote:
> 1. Check the value of `org-element--cache-change-tic' right after
>opening an Org file 

first its 1, 

(when I start fresh and add 1 byte to the buffer the value is 13955)

> and the values of `after-change-functions' and
>`after-change-functions' in Org buffer after you see the warning.

after starting the =t= agenda (which results in the warnings):

the value of org-element--cache-change-tic is still 1,

the value of after-change-functions is
`(org-element--cache-after-change jit-lock-after-change 
flyspell-after-change-function org-fold-core--fix-folded-region t 
ws-butler-after-change)`

(I disabled `ws-butler` because that sounded suspicious, but that did not 
resolve the warnings)


> 2. If you can, try to load Emacs with minimal Org-related settings.
>Then, try to load agenda and let me know if you see the warning.

I did some manual bisecting of my config, and I noticed that the warnings in 
"Media.org" go away when I remove `(org-startup-align-all-tables t)` from my 
config.  

So I did some more digging, reduced 
my config to just contain `org-startup-align-all-tables` set to t, 
my agendas limited to Media.org, 
and removed most headings from Media.org.

With a minimal Media.org I get a "Org parser error",
see here for sample and backtrace:
https://gist.github.com/stefan2904/5a2b33d42a947f36402b548d9b186b67

(here the parser error turns into an incorrect error when I change the length 
of the URL ...)


With a very minimal Media.org I get a "Cached element is incorrect",
apparently because the table is not aligned?
see here for sample file and backtrace:
https://gist.github.com/stefan2904/688afdc2ebfeece8e0fa19a24d9ca321

Both errors go away when I set `(org-startup-align-all-tables nil)`.

>It looks to me like you have something unusual in your Org setup or
>some third-party package interfering.


Best,
 Stefan

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Greg Minshall]

Johan,

> Absolutely, I just wanted to clarify that there is no confusion as to
> what an R list is in the context of R itself (as far as I can
> tell). Your post made it sound like there is.

ah, indeed -- thanks!

cheers, Greg

Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Ihor Radchenko]

Tim Cross  writes:

> I don't see any reason not to allow captions for examples either.

In LaTeX, example blocks are exported as verbatim. I am not sure if we
can even put captions into verbatim.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Max Nikulin]

On 15/12/2022 19:25, Ihor Radchenko wrote:

Max Nikulin writes:


I would consider reverting the commit causing user prompt for every
variable.


I disagree. If anything, we can set the default value of
`org-confirm-babel-evaluate-cell' to nil and apply this patch.

Then, we can get the old behaviour back yet allowing concerned users to
have more security.


I am leaving it up to you. Form my point of view it will be dead code 
that increases complexity with no practical outcome. Unfortunately 
setting `org-confirm-babel-evaluate-cell' to anything other than nil 
results in annoyance rather than security.


Perhaps advising `org-babel-execute-src-block' with `y-or-n-p' is a 
better treatment for my paranoia.



This patch does not only affect src blocks. It affects all the users of
`org-babel-read'.


Mostly it is called with INHIBIT-LISP-EVAL set to t.


https://list.orgmode.org/Y1uFDWOjZb85lk+3@protected.localdomain
Re: [BUG][Security] begin_src :var evaluated before the prompt to
confirm execution


How is it related to the current discussion?
The purpose of the security feature discussed here is not for web
browsers or anything like that.


I am not going to add malicious source blocks to my private org files. 
For some code it is better to have a prompt, but generally the issue is 
not excessively important. I tend to inspect org files fetched from net 
in some other application at first (browser, less, or vim).


Accidental evaluation of code is a real danger for those who insist on 
opening links to org file directly in emacs or even propose to use org 
as a kind of browser. I raised the security issue in response to 
passionate messages demanding direct ways to work with org files from 
the web. I decided to remind the context with hope that it would help to 
reevaluate severity of the issue.


I do not have a better proposal, but I think I see movement in a wrong 
direction.

Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Tim Cross]

Max Nikulin  writes:

> On 15/12/2022 16:31, Ihor Radchenko wrote:
>> The actual parser does allow empty lang in src blocks, setting :lang
>> element property to nil. Should we stop doing this and treat such src
>> blocks as paragraphs? Or should we allow empty lang and instead adapt
>> the exporters to treat empty lang correctly?
>
> Source blocks without language may be treated as #+begin_example blocks. I 
> believe, a
> warning should be issued in such case.
>
> I do not see a reason why caption is not allowed for examples.

Yes, I think I agree. Semantically, a src block without a language is
really just an example block - it cannot be executed or evaluated and is
essentially reduced to a example block.

I think having a warning is also a good idea as it will alert users when
they have inadvertently forgotten to add the lang.

I don't see any reason not to allow captions for examples either.

Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Timothy]

Hi Ihor,

> There is an inconsistency here between Org parser and
>  + manual.
>
> The actual parser does allow empty lang in src blocks, setting :lang
> element property to nil. Should we stop doing this and treat such src
> blocks as paragraphs? Or should we allow empty lang and instead adapt
> the exporters to treat empty lang correctly?

My 2c: a nil lang seems like the “less wrong” option.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Max Nikulin  writes:

>> Should we then extend `org-babel-check-evaluate' to accept "All" answer
>> in the coming bugfix release?
>
> I would consider reverting the commit causing user prompt for every 
> variable.

I disagree. If anything, we can set the default value of
`org-confirm-babel-evaluate-cell' to nil and apply this patch.

Then, we can get the old behaviour back yet allowing concerned users to
have more security.

> ... I believe, there should be single prompt on attempt to execute 
> a source block. I admit it is not easy to implement.

This patch does not only affect src blocks. It affects all the users of
`org-babel-read'.

Note that my suggestion about "All" may as well include "All in current
block/Yes". It should not be too hard to implement, I think.

> I am not comfortable with attempts to consider Org as a format for web 
> browser similar to HTML: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
> Features great for personal notebooks and authoring of documents are 
> disaster for documents from non-trusted sources.
>
> In particular, I consider the following reaction as unreasonably 
> optimistic. I am afraid, a lot of work is required to achieve such goal.
>
> https://list.orgmode.org/Y1uFDWOjZb85lk+3@protected.localdomain
> Re: [BUG][Security] begin_src :var evaluated before the prompt to 
> confirm execution

How is it related to the current discussion?
The purpose of the security feature discussed here is not for web
browsers or anything like that.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Ihor Radchenko]

Stefan  writes:

> sorry, I was not aware of that. I am sending the full backtrace unredacted to 
> you directly. 
>
> The respective org files are in a git repo, and there I don't see any edits 
> in the files since starting emacs (also not after manually saving all org 
> buffers).
>
> Let me know if you need anything else.

Thanks!

This still looks quite strange.

Can you please:

1. Check the value of `org-element--cache-change-tic' right after
   opening an Org file and the values of `after-change-functions' and
   `after-change-functions' in Org buffer after you see the warning.

2. If you can, try to load Emacs with minimal Org-related settings.
   Then, try to load agenda and let me know if you see the warning.

   It looks to me like you have something unusual in your Org setup or
   some third-party package interfering.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Max Nikulin]

On 15/12/2022 16:10, Ihor Radchenko wrote:

Max Nikulin writes:


I am still in doubts if

10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey
`org-confirm-babel-evaluate'

was an unambiguous improvement. Perhaps it just forces more users to set
`org-confirm-babel-evaluate' to nil compromising their security to more
severe degree.


Should we then extend `org-babel-check-evaluate' to accept "All" answer
in the coming bugfix release?


I would consider reverting the commit causing user prompt for every 
variable. I believe, there should be single prompt on attempt to execute 
a source block. I admit it is not easy to implement.


Main purpose of the new patch is to allow old behavior. Unfortunately it 
adds more complexity to logic around user prompts and classifying some 
expressions as safe.


I am not comfortable with attempts to consider Org as a format for web 
browser similar to HTML: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
Features great for personal notebooks and authoring of documents are 
disaster for documents from non-trusted sources.


In particular, I consider the following reaction as unreasonably 
optimistic. I am afraid, a lot of work is required to achieve such goal.


https://list.orgmode.org/Y1uFDWOjZb85lk+3@protected.localdomain
Re: [BUG][Security] begin_src :var evaluated before the prompt to 
confirm execution

On 28/10/2022 14:30, Jean Louis wrote:

* Ihor Radchenko [2022-10-28 06:19]:

Jean Louis writes:

* Max Nikulin [2022-10-27 06:21]:

Expected result:
No code from the Org buffer and linked files is executed prior to
confirmation from the user.


Should that be or is it a general policy for Org mode?


Yes, it is a general policy.
Org should not execute arbitrary Elisp without confirmation, unless the
user customizes the confirmation query to non-default.


That is nice to know. It opens doors for browsing Org files within Emacs.


On 15/12/2022 16:10, Ihor Radchenko wrote:

In future release, we may go for more powerful prompt as discussed in
https://orgmode.org/list/8735cyxonl.fsf@localhost


Single prompt for whole bunch of code related to particular block was 
not discussed in that thread, that time the issue was not as sever as 
now. By the way, is it reliable to use (buffer-file-name 
(buffer-base-buffer)) in `org-confirm-babel-evaluate' to determine if 
some file resides in a "safe" directory? It may be discussed in that thread.


I believe that :var code is equally dangerous to the source block body. 
However while nobody pushes Org as a web browser format, it is better to 
implement a transparent and consistent approach to prevention of 
non-trusted code execution.

Re: [BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hello,

sorry, I was not aware of that. I am sending the full backtrace unredacted to 
you directly. 

The respective org files are in a git repo, and there I don't see any edits in 
the files since starting emacs (also not after manually saving all org buffers).

Let me know if you need anything else.

Best,
 Stefan


On Thu, Dec 15, 2022, at 09:14, Ihor Radchenko wrote:
> Thanks, but a small portion of the backtrace is not helpful here.
> "Cached element is incorrect" appears to be related to some buffer edits
> being missed by the cache, which can only be visible by looking at the
> full history of registered cache edits.
>
> There is a reason why this much backtrace is generated. The real problem
> often appears long time before the actual issue is caught by
> self-verification code.

Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Max Nikulin]

On 15/12/2022 16:31, Ihor Radchenko wrote:


The actual parser does allow empty lang in src blocks, setting :lang
element property to nil. Should we stop doing this and treat such src
blocks as paragraphs? Or should we allow empty lang and instead adapt
the exporters to treat empty lang correctly?


Source blocks without language may be treated as #+begin_example blocks. 
I believe, a warning should be issued in such case.


I do not see a reason why caption is not allowed for examples.

Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Kaushal Modi]

On Thu, Dec 15, 2022, 4:32 AM Ihor Radchenko  wrote:

> Johan Bolmsjö  writes:
>
> > #+caption: Caption 1
> > #+begin_src
> > foo bar baz
> > #+end_src
>
> There is an inconsistency here between Org parser and
> https://orgmode.org/worg/org-syntax.html + manual.
>
> The actual parser does allow empty lang in src blocks, setting :lang
> element property to nil.



Should we stop doing this and treat such src
> blocks as paragraphs?


I think that this would cause more of a surprise to the user when something
in a source block exports as a plain paragraph instead of in a  block
(for HTML exports).

Or should we allow empty lang and instead adapt
> the exporters to treat empty lang correctly?
>

I vote for this one. Then

#+begin_src
foo
#+end_src

will be analogous to this in Markdown:

```
foo
```

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[tomas]

On Thu, Dec 15, 2022 at 09:18:14AM +, Ihor Radchenko wrote:
> Tom Gillespie  writes:

[...]

> I am generally skeptical about our ability to provide universal way to
> judge if a given sexp is safe or not. It should be left to the user.

This might live in the middle of some thicket deep in the intersection
of Undecidability Plains and Ill-Definedness Swamps. Crocodiles don't
dare near there and nobody knows whether there are Dragons.

Or something :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

[Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Ihor Radchenko]

Johan Bolmsjö  writes:

> #+caption: Caption 1
> #+begin_src
> foo bar baz
> #+end_src

There is an inconsistency here between Org parser and
https://orgmode.org/worg/org-syntax.html + manual.

The actual parser does allow empty lang in src blocks, setting :lang
element property to nil. Should we stop doing this and treat such src
blocks as paragraphs? Or should we allow empty lang and instead adapt
the exporters to treat empty lang correctly?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Tom Gillespie]

> It's purpose is also different.
> I am generally skeptical about our ability to provide universal way to
> judge if a given sexp is safe or not. It should be left to the user.

I am in complete agreement.

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Tom Gillespie  writes:

> Interestingly, as I was looking through my notes in
> orgstrap, I see my past self had found a macro
> org-babel-one-header-arg-safe-p which pointed to
> defconst org-babel-safe-header-args, but that is
> a const and not really user configurable.

It's purpose is also different.
I am generally skeptical about our ability to provide universal way to
judge if a given sexp is safe or not. It should be left to the user.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Max Nikulin  writes:

> I am still in doubts if
>
> 10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey 
> `org-confirm-babel-evaluate'
>
> was an unambiguous improvement. Perhaps it just forces more users to set 
> `org-confirm-babel-evaluate' to nil compromising their security to more 
> severe degree.

Should we then extend `org-babel-check-evaluate' to accept "All" answer
in the coming bugfix release?
Then, users may conveniently allow evaluation without a push to disable
the prompt altogether.

In future release, we may go for more powerful prompt as discussed in
https://orgmode.org/list/8735cyxonl.fsf@localhost

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Does variable 'org-goto-interface' exist?

[Ihor Radchenko]

Max Nikulin  writes:

> Actually I am surprised that symbols are not 
> transformed to help links in info buffers.

Well. https://yhetil.org/emacs-devel/86lfm3k05m@duenenhof-wilhelm.de

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Does variable 'org-goto-interface' exist?

[Ihor Radchenko]

Max Nikulin  writes:

> Alain, are you motivated enough to search in emacs bug tracker and in 
> emacs-devel mailing list archives if such options were considered? From 
> my point of view it is better to improve completion than to modify the 
> Org Manual just for org-goto. Feel free to add me as X-Debbugs-CC if you 
> decide to create a feature request or a bug.

I agree. It is better if Emacs fixes this issue.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60085

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Johan Tolö]

Greg Minshall  writes:

[snipped]
"Proper list" in the context of this discussion and pertaining 
to R
would be a =list()=, not a vector which is what is usually 
returned by
=c()=. A =data.frame()= is a special case of a =list()= where 
every

column has to have the same length.


well, it's a language mapping problem.  what one considers a 
"list" in

org-mode is
- well
- something like
- this
  - maybe with
  - this

whereas in e-lisp, '("well" "something like" '("this" '("maybe 
with"

"this"))).


Absolutely, I just wanted to clarify that there is no confusion as 
to what an R list is in the context of R itself (as far as I can 
tell). Your post made it sound like there is.


[snipped]


--
Johan Tolö

Re: org-agenda-dim-blocked-tasks don't use org-todo face

[Ihor Radchenko]

Mark Kerr  writes:

> I understand your viewpoint,  Ihor. Actually, it was mainly the font
> size of the TODO keyword that I wanted to retain, not the colour.
>
> The org-agenda-dimmed-todo-face overlay overrides the size set in
> org-todo face, which breaks my layout.

It should not, by default.
If it is, please try to reproduce the problem starting from emacs -Q, so
that I can see what is ha penning using my Emacs.

> I have been fiddling with the face and overlay rules, but my knowledge
> is not up to the task. From what I can tell, overlays always overwrite
> faces.

No, they do not. Overlays apply their faces on top of text properties
and on top of overlays with lower priority.

"On top" means that only face attributes that are "specified" are
overwritten. `org-agenda-dimmed-todo-face' only overwrites :foreground
by default.

Note, however, that your Emacs theme might change this. You can examine
the output of M-x describe-face  org-agenda-dimmed-todo-face .
Pay attention to "Inherit", if any. The attributes of inherited faces
are also considered.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-element-cache error on file open [9.6 (9.6-g555dac @ /Users/scott/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Scott Otterson  writes:

> When I open an org file, I get the following warning.
>
> Warning (org-element-cache): org-element--cache: Org parser error in
> energytop.org::1159387. Resetting.
>The error was: (error "Invalid search bound (wrong side of point)")
> Backtrace:
> nil

Thanks for reporting!

Please set org-element--cache-self-verify to 'backtrace,
org-element--cache-self-verify-frequency to 1.0, and debug-on-error to
t. Then, please report the full backtrace when the issue appears again.

Note that backtrace will contain parts of your actual file. You may
consider stripping sensitive data or sending the backtrace privately.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Ihor Radchenko]

Stefan  writes:

> While trying to reproduce the "Org parser error" error issue (see other 
> thread), I got multiple "Cached element is incorrect" warnings (backtrace 
> excerpt below).
>
> Here is one that appeared when trying to loading the =t= agenda:

Thanks, but a small portion of the backtrace is not helpful here.
"Cached element is incorrect" appears to be related to some buffer edits
being missed by the cache, which can only be visible by looking at the
full history of registered cache edits.

There is a reason why this much backtrace is generated. The real problem
often appears long time before the actual issue is caught by
self-verification code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How to disable completely org-persist

[Ihor Radchenko]

Ihor Radchenko  writes:

> Upon further investigation, it looks like we need Org persist all the
> time. As temporary storage, at least. In particular, downloading remote
> images requires org-persist to store files somewhere. All the times.
> ...
> So, we cannot disable org-persist and should not even do it with Emacs
> -Q. Instead, we may redirect org-persist-directory to /tmp in some
> scenarios. I will look into doing this soon.

I am going to do the following in order to reduce the issue with
littering `user-emacs-directory':

1. When there is no data stored by org-persist (e.g. when the user
   disabled `org-element-cache-persistent' and never uses image
   downloading), do not write anything and do not create the empty
   index.

2. `org-persist-disable-when-emacs-Q' will redirect
   `org-persist-directory' to a temporary directory.
   (this is a bugfix)
   
3. Users who think that org-persist is still on the way may set
   `org-persist-directory' explicitly to, say,
   `temporary-file-directory'.

Let me know if there are any objections.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at