Re: Policy for opening url links in documents
Am Mittwoch, dem 16.08.2023 um 14:33 -0400 schrieb Scott Kostyshak: > I think Daniel is talking about: > > Document > Settings > Format > Output > "Allow running external > programs" Or, for that matter, Tools > Preferences > File Handling > Converters > Use needauth option > > Whether 5 or 6, I wonder if it would be helpful to combine the > preferences. i.e., have a preference "Trust document content", and > then > allow the user finer control if they prefer? I also think it should be something along the line of shell escape, i.e., people can chose to trust open link or abort, and they can decide to trust the document. An important issue is that, if people chose to trust the document, the trust should only hold on the current computer (as with shell escape). Otherwise evil persons could set the trust before sending. So a dialog that says: LyX wants to open the following link in an external application: Be aware that this might entail security infringements. Only do this if you trust the target! How do you want to proceed? [Open link] [Abort (=default)] [ ] Trust this document and do not ask me again! --- I am not sure we really need a pref to bypass this measure, or disable the feature completely (as in needauth). This strikes me overregulation. BTW are we talking URLs only or also links to local files? If the latter is also considered to be harmful, things will get significantly more complicated if lyxpaperview.py is involved. The dialog above can be implemented easily (for web links). -- Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On 8/16/23 19:26, Stephan Witt wrote: Am 17.08.2023 um 01:00 schrieb Richard Kimberly Heck : On 8/16/23 18:29, Pavel Sanda wrote: On Wed, Aug 16, 2023 at 05:30:56PM -0400, Richard Kimberly Heck wrote: Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... I'm always quite paranoid about this. I suppose (5) is OK if people know what they're doing. Could we combine (3) and (5)? If we only have (5), then people might not discover this functionality. If discoverability is a problem in the case of 5, we might simply let the item in context menu visible, but disabled, so people get curious... But perhaps in the dialog we could say something like, "If you want to disable this warning, see Tools> Preferences> Whatever". So you propose two RCs - one for 5) and one for disabling 3)? No, I meant one for (5), which would disable (3). Riki BTW, there is a RC already (but not evaluated in this code path) - citation_search. Perhaps it can be used here? That seems to be for something else---whether to use a script to search for a PDF or whatever---but it seems kind of redundant, since citation_search_view also has to be set. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
Am 17.08.2023 um 01:00 schrieb Richard Kimberly Heck : > > On 8/16/23 18:29, Pavel Sanda wrote: >> On Wed, Aug 16, 2023 at 05:30:56PM -0400, Richard Kimberly Heck wrote: Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... >>> I'm always quite paranoid about this. I suppose (5) is OK if people know >>> what they're doing. Could we combine (3) and (5)? If we only have (5), then >>> people might not discover this functionality. >> If discoverability is a problem in the case of 5, we might simply let >> the item in context menu visible, but disabled, so people get curious... >> >>> But perhaps in the dialog we could say something like, "If you want to >>> disable this warning, see Tools> Preferences> Whatever". >> So you propose two RCs - one for 5) and one for disabling 3)? > > No, I meant one for (5), which would disable (3). > > Riki BTW, there is a RC already (but not evaluated in this code path) - citation_search. Perhaps it can be used here? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On 8/16/23 18:29, Pavel Sanda wrote: On Wed, Aug 16, 2023 at 05:30:56PM -0400, Richard Kimberly Heck wrote: Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... I'm always quite paranoid about this. I suppose (5) is OK if people know what they're doing. Could we combine (3) and (5)? If we only have (5), then people might not discover this functionality. If discoverability is a problem in the case of 5, we might simply let the item in context menu visible, but disabled, so people get curious... But perhaps in the dialog we could say something like, "If you want to disable this warning, see Tools> Preferences> Whatever". So you propose two RCs - one for 5) and one for disabling 3)? No, I meant one for (5), which would disable (3). Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On Wed, Aug 16, 2023 at 05:30:56PM -0400, Richard Kimberly Heck wrote: > >Now what are your opinions what we should do about it? > >1) nothing. > >2) add dialog before launching url. safer but super annoying. > >3) add dialog before launching url + dont ask again checkbox. > >not implemented - we'll also need to add session keys, which > >get erased often. > >4) add link target to context menu (non trivial to implement) > >5) add (by default disabled) checkbox in security preference to allow > >opening links for citations and hyperlinks similarly as we do with > >scripts. > >6) ? > > > >I tend to go for 5, but there might be other options I did not think of... > > I'm always quite paranoid about this. I suppose (5) is OK if people know > what they're doing. Could we combine (3) and (5)? If we only have (5), then > people might not discover this functionality. If discoverability is a problem in the case of 5, we might simply let the item in context menu visible, but disabled, so people get curious... > But perhaps in the dialog we could say something like, "If you want to > disable this warning, see Tools> Preferences> Whatever". So you propose two RCs - one for 5) and one for disabling 3)? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [#2 iteration]: Breakdown of remaining 2.4 bugs
On 8/6/23 07:52, Pavel Sanda wrote: * Blockers to decide before next release (string/format changes) #12849 - hebrew quoation marks - has a patch which adds them (checked/looks OK), I would be inclined to commit; but I'd like to hear if the correct solution isn't rather some LTR fix. (JMarc/Juergen - any opinion?) Got committed. #11824 - References preview - Riki & ajd work on this, but there might be some hard-to-solve issues; might be deffered to later RCs, it only removes string, not add new one (currently!) I think this will be OK. The apparent problem is really due to my abusing refstyle. I'll have another look in the next few days. #11765 - closing groups shortcut; I'm not in favour of commiting the proposed patch, except of adding shortcut; but others might have different opinion, Stephan, any input? Seems resolved. * Fonts/LaTeX output/search - Juergen any chance to chime-in? #12831 - Udi proposes changing order how we output LaTeX font options. Has a patch which looks legit to me, but I would like someone to look over and give +1 Fixed. #12848 - Font's options not exported in certain cases; has a patch, not clear to me whether solution of disabling UI is correct Fixed. #12851 - arabic + luatex + babel fix - has patch, but I don't have idea; if no-one checks I would be inclined to trust Udi and commit in the next iteration Fixed. #12779 - "Search as you type" issue; the original report is imho borderline invalid, but the additional report in comment 2 looks like real issue Fixed. *Normal bugs #10468 - selection assymetry, JMarc might get to that some day later Can wait. #12842 - UTF-8 in math label; Koji + Enrico work on that Fixed. #12852 - seems we can't open weird filenames under Windows anymore (worked in 2.3), but might be difficult to reproduce I think we have a fix, but someone needs to commit it. It would be good to do this before the next release, so it can be tested. * Mac bugs: I can't really evaluate these. * Cosmetics, we can retarget #12214 - docking/painting of search dialog; not essential we have worse issues with widgets Retargeted. #12776 - cosmetics - needs someone with Qt6 on linux to reproduce. Anyone at least to reproduce? Fixed. * Enhacements, easy to retarget #12797 - content in equations into ToC, needs opinion of people using equations / ToC whether we want it. Please come and comment. This works as it is. The big question is whether to include more than we presently do. Previously, it only made sense to include labeled equations, since the label is all that shows up. Now, it would be possible to list all displayed equations, but it's not clear if that's a good idea or not. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On 8/16/23 10:35, Pavel Sanda wrote: Hi, as a part of #12878 Stephan raised a question to what degree should we allow opening external links which are part of citation in the document (or rather part of .bib file). Currently we allow opening links stored in the "url" field of bibtex entry or files stored in "file" field by entry in the context menu; what's worse we don't show the link, so one can not check url itself - malevolent url can be provided (e.g. attacker web site, or maybe url scheme trying to execute some local stuff). (We also allow similar thing for hyperlink insets, but we at least show the target in caption of the inset.) Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... I'm always quite paranoid about this. I suppose (5) is OK if people know what they're doing. Could we combine (3) and (5)? If we only have (5), then people might not discover this functionality. But perhaps in the dialog we could say something like, "If you want to disable this warning, see Tools> Preferences> Whatever". Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Warnings during compilation of 2.3.8dev
On 8/16/23 14:30, Scott Kostyshak wrote: On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote: ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays [-Warray-compare] 3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes This one is a real bug though, fixed at master by eaebe404ae6c83 and not backported. Scott? Sure I can backport. Riki is that OK? OK. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On 2023-08-16 20:33, Scott Kostyshak wrote: On Wed, Aug 16, 2023 at 06:30:38PM +0200, Daniel wrote: On 2023-08-16 16:35, Pavel Sanda wrote: Hi, as a part of #12878 Stephan raised a question to what degree should we allow opening external links which are part of citation in the document (or rather part of .bib file). Currently we allow opening links stored in the "url" field of bibtex entry or files stored in "file" field by entry in the context menu; what's worse we don't show the link, so one can not check url itself - malevolent url can be provided (e.g. attacker web site, or maybe url scheme trying to execute some local stuff). (We also allow similar thing for hyperlink insets, but we at least show the target in caption of the inset.) Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... FWIW, I have seen only 1, 2 and 3 implemented in other applications when launching external URLs but none of the others. A possible 6) Per document enabling: when there are external URLs in a document that could be opened, a message appears at the top asking whether the document should be trusted in that respect. It's similar to how VS Code asks whether to enable extensions for a document. Not sure whether I like myself. I think Daniel is talking about: Document > Settings > Format > Output > "Allow running external programs" No, I wasn't aware of that option's existence and still don't know what it does. :) Not sure where the misunderstanding is though. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On Wed, Aug 16, 2023 at 06:30:38PM +0200, Daniel wrote: > > On 2023-08-16 16:35, Pavel Sanda wrote: > > Hi, > > > > as a part of #12878 Stephan raised a question to what degree should we allow > > opening external links which are part of citation in the document (or rather > > part of .bib file). > > > > Currently we allow opening links stored in the "url" field of bibtex entry > > or > > files stored in "file" field by entry in the context menu; what's worse we > > don't show the link, so one can not check url itself - malevolent url can be > > provided (e.g. attacker web site, or maybe url scheme trying to execute some > > local stuff). > > > > (We also allow similar thing for hyperlink insets, but we at least show > > the target in caption of the inset.) > > > > Now what are your opinions what we should do about it? > > 1) nothing. > > 2) add dialog before launching url. safer but super annoying. > > 3) add dialog before launching url + dont ask again checkbox. > > not implemented - we'll also need to add session keys, which > > get erased often. > > 4) add link target to context menu (non trivial to implement) > > 5) add (by default disabled) checkbox in security preference to allow > > opening links for citations and hyperlinks similarly as we do with > > scripts. > > 6) ? > > > > > > I tend to go for 5, but there might be other options I did not think of... > > FWIW, I have seen only 1, 2 and 3 implemented in other applications when > launching external URLs but none of the others. > > A possible > > 6) Per document enabling: when there are external URLs in a document that > could be opened, a message appears at the top asking whether the document > should be trusted in that respect. > > It's similar to how VS Code asks whether to enable extensions for a > document. Not sure whether I like myself. I think Daniel is talking about: Document > Settings > Format > Output > "Allow running external programs" Whether 5 or 6, I wonder if it would be helpful to combine the preferences. i.e., have a preference "Trust document content", and then allow the user finer control if they prefer? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Warnings during compilation of 2.3.8dev
On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote: > > > ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays > > [-Warray-compare] > > 3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes > > This one is a real bug though, fixed at master by eaebe404ae6c83 and not > backported. > Scott? Sure I can backport. Riki is that OK? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On 2023-08-16 16:35, Pavel Sanda wrote: Hi, as a part of #12878 Stephan raised a question to what degree should we allow opening external links which are part of citation in the document (or rather part of .bib file). Currently we allow opening links stored in the "url" field of bibtex entry or files stored in "file" field by entry in the context menu; what's worse we don't show the link, so one can not check url itself - malevolent url can be provided (e.g. attacker web site, or maybe url scheme trying to execute some local stuff). (We also allow similar thing for hyperlink insets, but we at least show the target in caption of the inset.) Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... FWIW, I have seen only 1, 2 and 3 implemented in other applications when launching external URLs but none of the others. A possible 6) Per document enabling: when there are external URLs in a document that could be opened, a message appears at the top asking whether the document should be trusted in that respect. It's similar to how VS Code asks whether to enable extensions for a document. Not sure whether I like myself. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Warnings during compilation of 2.3.8dev
On Wed, Aug 16, 2023 at 11:17:22AM +0200, Jean-Pierre Chrétien wrote: > C++ Compiler:g++ (12.2.0) ... > std::binary_function??? is deprecated [-Wdeprecated-declarations] ... > _Result> struct std::unary_function??? is deprecated ... > ???std::const_mem_fun_ref_t<_Ret, _Tp> std::mem_fun_ref(_Ret (_Tp::*)() > const) [with _Ret = bool; _Tp = lyx::ParamInfo::ParamData]??? is deprecated: I wouldn't worry about deprecaction warnings with new gcc. 2.4 will be long out before we might get hit by this > ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays > [-Warray-compare] > 3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes This one is a real bug though, fixed at master by eaebe404ae6c83 and not backported. Scott? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Policy for opening url links in documents
Hi, as a part of #12878 Stephan raised a question to what degree should we allow opening external links which are part of citation in the document (or rather part of .bib file). Currently we allow opening links stored in the "url" field of bibtex entry or files stored in "file" field by entry in the context menu; what's worse we don't show the link, so one can not check url itself - malevolent url can be provided (e.g. attacker web site, or maybe url scheme trying to execute some local stuff). (We also allow similar thing for hyperlink insets, but we at least show the target in caption of the inset.) Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Warnings during compilation of 2.3.8dev
Dear developers, I had to recompile 2.3.8dev becaus the then enchant bug (see https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg219915.html) With : Configuration Host type: x86_64-pc-linux-gnu Special build flags: build=development std-regex warnings assertions stdlib-debug use-enchant Bundled libraries:boost C++ Compiler:g++ (12.2.0) C++ Compiler flags: -Wall -Wextra -fPIC -g -O -std=c++14 -Wno-deprecated-copy C++ Compiler user flags: Linker flags: Linker user flags: Qt Frontend: Qt version: 5.15.8 Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx-2.3.8dev I get warnings : binary_function: 4 occurences ../../../../2.3.x/src/frontends/qt4/GuiDocument.cpp:172:18: warning: ‘template struct std::binary_function’ is deprecated [-Wdeprecated-declarations] 172 | : public binary_function /usr/include/c++/12/bits/stl_function.h:131:12: note: declared here 131 | struct binary_function unary_function: 7 occurences ../../2.3.x/src/BranchList.cpp:30:38: warning: ‘template_Result> struct std::unary_function’ is deprecated [-Wdeprecated-declarations] 30 | class BranchNamesEqual : public std::unary_function /usr/include/c++/12/bits/stl_function.h:117:12: note: declared here 117 | struct unary_function others: ../../2.3.x/src/LyXRC.cpp: In function ‘void lyx::actOnUpdatedPrefs(const LyXRC&, const LyXRC&)’: ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays [-Warray-compare] 3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes |~~^~~ ../../2.3.x/src/insets/InsetCommandParams.cpp: In member function ‘lyx::docstring lyx::InsetCommandParams::getFirstNonOptParam() const’: ../../2.3.x/src/insets/InsetCommandParams.cpp:596:41: warning: ‘std::const_mem_fun_ref_t<_Ret, _Tp> std::mem_fun_ref(_Ret (_Tp::*)() const) [with _Ret = bool; _Tp = lyx::ParamInfo::ParamData]’ is deprecated: use 'std::mem_fn' instead [-Wdeprecated-declarations] 596 | not1(mem_fun_ref(&ParamInfo::ParamData::isOptional))); | ~~~^~~ /usr/include/c++/12/bits/stl_function.h:1389:5: note: declared here 1389 | mem_fun_ref(_Ret (_Tp::*__f)() const) | ^~~ -- Jean-Pierre -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
